Overview
Recently, a high severity vulnerability called CVE-2021-44228 produced great upheaval in the internet world. Spotted in various versions of the most popular Java logging library Log4j, the vulnerability allows attackers to sneak past the authentication process of remote servers and execute arbitrary code on sensitive data.
The exploit of CVE-2021-44228 has an impact on a wide variety of services, from modern cloud infrastructures such as VMWare to video games running locally on your machine such as Minecraft, as long as they are running on affected versions of Log4j.
How does it work?
Log4j is a widely used library in the Java environment to handle logging histories. It has a powerful feature that allows logged messages to gather external information by format strings via JNDI (Java Naming and Directory Interface). The JNDI interface allows Log4j to retrieve data from a wide variety of protocols such as DNS, LDAP, NIS, etc.
When Log4j logged some format string like this:
JNDI may automatically request program “malware” from external host some-evil-attacker.com and attempt to execute it. In reality, this program can be malware, ransomware, and even crypto-mining software, which poses great privacy risks and performance pitfalls to the targeted machines.
Here is a high-level example of how the exploit works:
Why is it particularly painful?
Most modern websites welcome user input. The aforementioned format string that contains a link to orchestrated malware could be inserted by seemingly legitimate users. There had already been reports suggesting that you can run code on the Apple server by changing the device name in iPhone settings. Not to mention the hackers will broadcast malicious requests containing such payloads all across the internet. Yeah, they don’t care who is the victim since the target can be completely random.
Another problem is about the vulnerability’s accessibility. Most developers who have basic knowledge of JNDI can easily reproduce this exploit on many platforms that were deemed unbreakable, so the scale of the upcoming swarms of attacks is beyond imagination.
How to protect yourself?
If you are a developer:
The latest update from the Apache Log4j team recommended the following to organizations under immediate impact:
- Upgrade to Log4j 2.15.0
- For those who cannot upgrade to 2.15.0,
- In releases >=2.10, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
- For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
There are plenty of instructions towards mitigation/solutions specific to your platforms. Currently, Google Cloud Platform is offering a rule-based filter against it in the Cloud Armor and network-based threat detection in the Cloud IDS. Amazon Web Services has come up with tons of hot patches to a wide variety of their services. Microsoft is rolling out updates in products such as 365 Defender and Azure Firewall. All platforms are doing their best to mitigate the issue by improving their WAF. Meanwhile, you can also find a lot of open-source proof of concepts on GitHub.
If it is impossible to immediately patch the root cause, you should closely monitor the logs generated by Log4j to identify any suspicious JNDI strings. Some of the attackers will use obfuscation such as
to get past regex-based filters, so you probably need some heuristics to parse them correctly!
If you do not deem yourself as very technical:
- Upgrade your operating system to the latest version
- Upgrade your software to the latest version, as thoroughly as possible. Especially if you know it is running on Java Virtual Machine, they tend to have .jar and .class files in their installation folders.
- Do not panic and follow the instructions from your software vendor’s announcement.
- Refrain from using free software that specifically stated it does not come with any warranty in its license (unless its developer is aware of what’s going on and fixed the problem)
How is team Acho handling this?
Our engineering team at Acho is closely monitoring the vulnerability. Our logging system does not run on Log4j so we are not among the vulnerable systems. As of December 12th, we have not identified any security threat in our system log yet.
The security of your data is our top concern. We will put a lot of effort in the following days to detect and quarantine malicious requests towards our backend infrastructure to protect your data.
References:
- CVE-2021-44228:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 - Official fix PR:
https://github.com/apache/logging-log4j2/pull/608 - Google Cloud IDS signature updates to help detect CVE-2021-44228 Apache Log4j vulnerability:
https://cloud.google.com/blog/products/identity-security/cloud-ids-to-help-detect-cve-2021-44228-apache-log4j-vulnerability - Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation By Microsoft:
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ - Apache Log4j2 Security Bulletin (CVE-2021-44228) - Amazon:
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
