Top Ten ATT&CK Techniques: The Rise of ‘Hunter-Killer’ Malware
Read More
Suleyman Ozarslan, PhD & Hüseyin Can Yüceel | December 16, 2021
It seems that we will be talking about Log4j for weeks, maybe months to come. Even though a patch for the first Log4j vulnerability (CVE-2021-44228) was released on December 10th, another Log4j vulnerability (CVE-2021-45046) was found on December 14th, 2021. Picus updated Picus Threat Library within hours after the release of the first PoC exploits and gave detailed explanations in the blogs on how to simulate and prevent Log4Shell attacks and remediate those attacks with WAFs and IPSs.
In this blog, 4-step quick mitigation plan for Log4j attacks is explained.
Update: In addition to two vulnerabilities mentioned in this blog post, a new denial of service (DoS) vulnerability affecting Apache Log4j versions prior to 2.17.0 is found. This vulnerability is called CVE-2021-45105 and its CVSS score is 7.5 (high).
Test your security controls against Log4Shell now!
In most cases, when there is a vulnerability in a product, it is easy to detect whether we have a vulnerable version of this product in our environment or not. We can check product banners, names, paths, and file hashes to find vulnerable product versions. For example, you can quickly check your systems for Sunburst vulnerability in Solarwinds by just checking the product version displayed in the footer of the Orion Web Console login page.
However, it is challenging to check your environment for affected Log4j versions and affected products because of the following reasons:
Briefly, it is very challenging to discover 100% of vulnerable assets. As with the ShellShock vulnerability, you may encounter applications with the Log4j vulnerability after months. Moreover, many public exploits are available, and research for different methods to exploit the vulnerability is still underway. Incident response and threat hunting are also challenging since the JNDI string is not actually logged if the exploitation is successful.
While mid and long term operations continue to discover vulnerable assets, respond to potential incidents, and hunt for retroactive threats, you must take the following immediate measures to limit the attack surface:
Since detecting all vulnerable assets in the network is hard, it is best to start with public-facing critical assets to limit the attack surface. Note that the effectiveness of black-box external scanning is very limited for the Log4j vulnerabilities. This type of scan focuses on finding vulnerable services according to banners of web server applications, such as Apache Tomcat. However, the attack surface is larger than the applications focused on external scans. Log4j rabbit hole runs deep, where finding vulnerable assets is challenging for even white-box internal scans; relying only on external scans creates a false sense of security.
You should simulate attacks to understand whether your security devices are preventing these attacks or not. To measure the actual effectiveness of your security products against Log4j vulnerability exploitation attacks, you should test all valid variants of Log4j exploits, including evasive payloads. You should also test JNDI-related naming services other than LDAP, such as DNS, RMI, NDS, NIS, and CORBA. However, generating all applicable payloads, setting up a test environment, and testing your security controls against all these payloads is also a time-consuming process.
Test your security controls with Picus now!
How does Picus help?
Picus platform automatically simulates 48 known variants of Log4j exploits within minutes without causing single damage to your environment and assesses your security posture. Picus Labs’ experts continuously research new variants and add them to the platform.
Remote code execution (RCE) attempts to exploit the Log4j vulnerability can be blocked by web application firewalls (WAF) and intrusion prevention systems (IPS) by inspecting ingress network traffic. For egress JNDI traffic from the vulnerable system to the attacker’s system, firewall rules should be set in place to block attacks.
How does Picus help?
Picus platform provides prevention signatures of WAF, IPS, and NGFW vendors, such as F5, Citrix, ModSecurity, Cisco, Palo Alto, Fortinet, Check Point, Forcepoint, McAfee, Trend Micro, and Snort. See our previous blog post.
Apache released a patch for CVE-2021-44228. However, it was incomplete, and CVE-2021-45046 was discovered, and a new patch was released. There might be more patches on the way, and it is crucial to follow vendor updates. In addition, you should run attack simulations, identify the gaps in your security controls and fix these gaps as a continuous effort.
How Picus Helps?
Picus helps you to:
Click here to benefit from the special offer of the Picus platform and be resilient for Log4j attacks!
Watch how you can easily simulate Log4j attacks to assess your security posture and prevent them with signatures of your WAF, IPS, and NGFW.