Log4Shell Exploitation Lab (CVE-2021-44228)

Die Log4Shell-Schwachstelle wurde in einer isolierten Laborumgebung end-to-end nachgestellt, von der ersten Ausnutzung bis hin zu einem vollständigen Remediation-Bericht. Durchgeführt als Teil eines MSc-Kursprojekts gemeinsam mit Aditya Chaudhari und als gemeinsamer Bericht verfasst.

Was ich gemacht habe

• Einrichtung einer verwundbaren, auf Log4j basierenden Tomcat-Webanwendung in einem Docker-Container
• Schreiben eines Python-Skripts zur Generierung des Exploit-Payloads sowie Aufsetzen eines bösartigen LDAP-Servers und eines HTTP-Servers zur Bereitstellung
• Auslösen der JNDI-Injection-Kette durch Senden eines manipulierten Lookup-Strings, anschließendes Abfangen der resultierenden Reverse Shell mit netcat und Bestätigung des Root-Zugriffs
• Neuaufbau desselben Containers mit einem gehärteten Dockerfile (JNDI-Lookups deaktiviert über JAVA_OPTS) und Bestätigung, dass der Exploit nicht mehr funktionierte
• Verfassen eines strukturierten Schwachstellenberichts mit Root Cause, Patch-Historie und Netzwerk-Mitigationsmaßnahmen – so, wie man ihn tatsächlich einem Kunden oder Entwicklungsteam übergeben würde

Warum ich es auf diese Weise gemacht habe

Ich wollte die vollständige Exploit-Kette selbst verstehen, statt nur darüber zu lesen. Log4Shell ist eine gute Schwachstelle, um daraus zu lernen, weil sie Java-Klassenladung, LDAP und JNDI gleichzeitig betrifft, und die anschließende Patch-Geschichte zeigt, wie Remediation tatsächlich aussieht – über das bloße Anwenden eines Updates hinaus.