On August 1, 2024, Retail payments began to be disrupted in Indian banks and suddenly, massive news broke, stating Brontoo Technology Solutions – a collaborator with C-Edge Technologies, which is a joint venture between TCS (Tata Consultancy Services) and SBI (State Bank of India), was impacted by a ransomware attack, according to NPCI (National Payment Corporation of India). C-Edge primarily provides technology services to cooperative and regional rural banks.
![Source: NDTV Profit Tweet](https://blogs.juniper.net/wp-content/uploads/2024/08/fig1NPCI_tweet.png)
CloudSek’s research confirmed that the RansomEXX group was responsible for the attack.
This group is a very well known organization for executing ransomware attacks against businesses, government organizations, banks, health care and other sectors. This group has been active since 2018, debuted as Defray777, and made its name finally in 2020. This group is suspected to be operating from Eastern Europe or Russia.
![Source: NDTV Profit Tweet](https://blogs.juniper.net/wp-content/uploads/2024/08/fig2NDTV_Tweet.png)
In March 2024, a significant ransomware attack linked to the RansomEXX group struck the Ministry of Defense in Peru. This event highlighted the group’s ability to infiltrate important government institutions, emphasizing their targeting of high-profile entities and the potential consequences of ransomware on critical infrastructure. More details of the attack can be found online.
Analysis of the Attack
Brontoo Technology Solutions filed a report with CertIn (Indian Computer Emergency Response Team) which revealed that the attack originated from a misconfigured Jenkins server, setting off the chain of events. On further analysis, the threat actor leveraged CVE-2024-23897 to gain initial unauthorized access to the victim’s environment.
CVE-2024-23897 is a vulnerability in the Jenkins Command Line Interface, where an attacker tries to gain unauthorized access to targeted systems. The sample ransom note by this group looks like the image below:
![Sample Ransom Note](https://blogs.juniper.net/wp-content/uploads/2024/08/fig4Ransom_Note-1024x430.png)
CVE-2024-23897: In-Depth Technical Analysis
Jenkins is an open-source automation server which enables developers across the globe to build, test, and deploy their software. This vulnerability leverages Jenkins Command Line (CLI). To access this CLI, we can use SSH (Secure Shell), WebSocket or HTTP via CLI Client.
This vulnerability allows an unauthenticated user to read the first few lines of any files on the file system. It arises from inadequate input validation of user-supplied strings when processing CLI commands. It exists because the command parser’s built-in feature has not been disabled by default. If successfully exploited, this vulnerability can lead to the leakage of sensitive files and data, potential command execution, and enable a ransomware attack. The version Juniper Threat Labs will use to demonstrate the attack as shown below:
![Vulnerable Jenkins Setup](https://blogs.juniper.net/wp-content/uploads/2024/08/fig5.Version-1024x500.png)
After executing POC (Proof of Concept) in our lab, we observed that the two POST requests are going to /cli endpoint. One is for uploading and the other for downloading the command.
Upload is used to send the command as shown below:
![POST Upload Request](https://blogs.juniper.net/wp-content/uploads/2024/08/fig6-1024x418.png)
In this instance, we are attempting to send the command /etc/group to the /cli endpoint. Similarly, a download request is used to execute the command and retrieve its output, as demonstrated in the image below:
![POST Download Request](https://blogs.juniper.net/wp-content/uploads/2024/08/fig7.png)
As seen in the image above, the command sent in the first request is executed, and its output is received in the second request as root:x: 0: which corresponds to the first line of the /etc/group file.
After examining the /cli endpoint, we initiated a search that directed us to jenkins-core-2.235.1.jar. And after decompiling the files, we continued our search for that specific code which handles POST request with /cli endpoint, and bingo! It is in CliCrumbExclusion.java which calls CliCrumbExclusion.process(). This verifies and ensures ‘/cli‘ is present in the URI path and then the chain.dofilter() function processes the request which leads to CLIAction.getTarget() function, as illustrated below:
![Decompiled snippet of CliCrumbExclusion.java](https://blogs.juniper.net/wp-content/uploads/2024/08/fig8-1024x519.png)
As seen from the decompiled code above, this function ensures the Req.method should be POST and the parameter remoting value should be false. The same can be observed from our Wireshark capture below.
If the above conditions match, the code throws an exception PlainCliEndpointResponse().
![Decompiled snippet1](https://blogs.juniper.net/wp-content/uploads/2024/08/fig9-1024x479.png)
Later this exception is caught and FullDuplexHttpService() is executed, and the upload and download connection verification is started as shown in the image below.
![Decompiled snippet2](https://blogs.juniper.net/wp-content/uploads/2024/08/fig10.-1024x539.png)
Eventually, the method FullDuplexHttpService.generateResponse() is called, which stores the value of session in uuid then the value to Side header is inspected. As per the value of Side header, the request and response are identified.
After further digging into the code, we end up on the command’s arguments which are stored in the variable args and will be parsed using the method CmdLineParser.parseArgument(). Once the arguments are further parsed, the commands will be executed.
![Decompiled snippet3](https://blogs.juniper.net/wp-content/uploads/2024/08/fig11-1024x472.png)
If any exception is raised, it will be handled by CliCommand.logFailedCommandAndPrintExceptionErrorMessage() and in the error message we can observe the output of the command we sent.
Key Takeaways and Industry Implications
The key takeaways and broader industry implications derived from this incident are outlined in the following points:
1. Importance of Regular Patching and Updates
The attack on C-Edge Technologies underscores the critical need for organizations to promptly apply security patches and updates. The Jenkins vulnerability (CVE-2024-23897) exploited in this incident demonstrates how outdated software can provide an entry point for cybercriminals.
2. Rigorous Configuration Management
Misconfigurations, like the one in the Jenkins server that facilitated this attack, are preventable security flaws. Organizations must implement stringent configuration management practices to ensure systems are securely configured and regularly audited.
3. Adoption of Zero Trust Architecture
The traditional perimeter-based security model is no longer sufficient. Adopting a Zero Trust architecture, where no entity inside or outside the network is trusted by default, enhances security by continuously verifying the identity and trustworthiness of every user and device.
4. Incident Response Preparedness
Having a robust incident response plan is essential. The ability to respond to ransomware attacks quickly and effectively can limit damage, reduce downtime, and enhance recovery efforts. Organizations should regularly update and practice their incident response procedures.
5. Focus on Supply Chain Security
The attack on C-Edge Technologies highlights the significant repercussions of third-party vulnerabilities. Organizations must evaluate the security practices of their supply chain partners and ensure they adhere to stringent security standards.
Conclusion
Customers of Juniper Networks’ SRX Series Next-Generation Firewall (NGFW) with an IDP (Intrusion Detection and Prevention) license are safeguarded against this vulnerability using the following signature:
HTTP: CTS: JENKINS-RCE-CLI-PARS
For all Juniper customers, it is recommended to upgrade the vulnerable Jenkins Servers to the latest patched or stable versions to prevent these ransomware attacks. The Jenkins Advisory for this CVE is here.
Juniper Networks’ Cloud ATP has identified this ransomware with a threat level of 10, indicating a critical risk.
![](https://blogs.juniper.net/wp-content/uploads/2024/08/image-1-1024x261.png)
![](https://blogs.juniper.net/wp-content/uploads/2024/08/image-2-1024x240.png)