Log Injection Angriffe auf SIEMs

Um Angriffe frühzeitig erkennen zu können, sollten möglichst viele Informationen über Systeme gesammelt werden. Wenn Unternehmen gut aufgestellt sind, werden diese Events zu einem zentralen System, einem Security Information and Event Manangement System (SIEM) gesendet, wo diese automatisch ausgewertet werden. Das SIEM überprüft die Events auf Auffälligkeiten und sendet Benachrichtigungen, falls welche gefunden werden. Außerdem können die Logs später für die Analyse von Ereignissen verwendet werden. Dadurch ist ein SIEM ein wirksames und oft genutztes Mittel, um die Unternehmensinfrastruktur zusätzlich zu schützen.

Allerdings versuchen die Angreifer möglichst unerkannt zu bleiben und vorherrschende Sicherheitsvorkehrungen zu umgehen. Während Manipulationen auf Systemen oft durch die generierten Events erkannt werden können, wird dabei oft vergessen, dass das SIEM selbst Ziel eines Angriffes werden kann. Das SIEM wird in der Regel vom Blue Team verantwortet, welches für die Überwachung, Erkennung und Abwehr von Angriffen verantwortlich ist. Wenn fehlerhafte Logs ins SIEM gelangen, dann kann das Blue Team davon abgelenkt werden und den eigentlichen Angriff übersehen. Dadurch würden möglicherweise die falschen Rechner in Quarantäne geschickt und isoliert, während die Angreifer weiter mit weniger auffälligen Angriffen ihre Rechte ausweiten können. So könnten auch die Compliance Anforderungen verletzt werden und es zu rechtlichen Konsequenzen kommen.

Auf der Defcon 32 wurde das Tool log-slapper präsentiert, womit solche gezielten Angriffe auf das SIEM Splunk, welches eins der meist eingesetzten SIEMs ist, durchführbar sind.

Funktionsweise eines SIEM

Um Angriffe auf SIEMs verstehen zu können, muss man zuerst den Aufbau verstehen. Alle folgenden Ausführungen beziehen sich auf Splunk, wobei ähnliche Angriffe auf andere SIEM Produkte sehr wahrscheinlich ebenfalls möglich sind.

Am Anfang der Kette stehen die Datenquellen, dies können z.B. SQL Server, Linux Server oder Windows Clients sein. Auf jedem dieser Systeme ist ein Universal Forwarder installiert. Der Universal Forwarder leitet die Events über TCP/IP weiter an die Heavy Forwarder, der die Daten vorverarbeitet. Der Heavy Forwarder leitet die Events wiederum an die Indexer. Die Indexer sind dafür zuständig die Daten zu indizieren, sodass diese durchsucht werden können. Mit Hilfe der anderen Komponenten können Nutzer sich schließlich Events über die Oberfläche anzeigen lassen und durchsuchen. Dabei sind weitergehende Funktionalitäten wie das Einrichten von automatischen Alerts auf relevante Muster möglich.

Neben den Universal Forwardern ist es auch möglich, Events direkt über den HTTP Event Collector (HEC) an den Heavy Forwarder zu schicken. Der HTTP Event Collector wird vor allem für Applikationslogs verwendet, während die Universal Forwarder für Systemlogs verwendet werden. Dabei werden die Daten über HTTP(s) versendet, wobei man sich mit einem Token authentifiziert.

Log Slapper

In der ersten Version von log-slapper war es möglich, die Funktionsweise von HEC auszunutzen mit der Limitation, dass nur manche Attribute von gesendeten Events verändert werden konnten und keine komplett neuen Logs erzeugt werden konnte. Außerdem benötigen Angreifer root Zugriff auf das System. In der zweiten Version sind diese Limitierungen aufgehoben. Der Angriffsweg über HEC bietet dennoch wertvolle Erkenntnisse, weshalb dieser zuerst erklärt wird, bevor der Deep Dive in den neuen, wesentlich gefährlicheren Angriffsweg erfolgt. Beide Angriffswege erfordern, dass die Angreifer bereits initialen Zugriff auf ein internes System erlangt haben, z.B. durch Phishing.

Angriffe durch HEC

Nachdem Angreifer initialen root Zugriff auf ein System erlangt haben, kann der Angreifer den TCP Netzverkehr mitschneiden. Da Splunk die Daten nicht verschlüsselt, sondern im Klartext sendet, ist der Netzverkehr leicht zu verstehen und zu verändern. log-slapper fängt die von Splunk generierten Netzwerkpakete ab und kann entsprechende Header wie die IP-Adresse und den Hostnamen verändern. Dabei ist log-slapper auch in der Lage das ausgeführte Kommando zu verändern, indem das entsprechende Kommando zuerst auf dem Host ausgeführt wird und anschließend das von Splunk generierte Netzwerkpaket mit der gewünschten IP-Adresse und Hostnamen verändert wird. Auf der Seite von Splunk gibt es keine weiteren Kontrollen, ob die Logs legitim sind.

Direkter Angriff

Die Angriffe über HEC sind limitiert, weil die Angreifer root Zugriff brauchen und Logs nur bis zu einem gewissen Grad geändert werden können. Um weiterführende Angriffe durchführen zu können - ohne die vorherigen Limitationen - hat der Autor von log-slapper die Kommunikation mit dem Indexer reverse engineert. Das eingesetzte proprietäre Protokoll S2S verwendet verschiedene Kommunikationsschritte wie ein Hello Paket und das anschließende Datenpaket. Details dazu können in der Defcon Präsentation gefunden werden. Auf Basis der Erkenntnisse wurde log-slapper so erweitert, dass über eine Nachimplememtierung des Protokolls direkt neue und benutzerdefinierte Logs an Splunk gesendet werden können. Dadurch können bspw. Logs in der Vergangenheit oder Zukunft erstellt werden sowie von anderen Computern erstellt werden. Außerdem ist kein root Zugriff mehr nötig und es reicht aus, wenn man die Splunk Instanz im Netzwerk mit dem Angriffsrechner erreicht.

Demo

Wer log-slapper selbst ausprobieren möchte, kann dies recht einfach tun. Zum bauen der log-slapper Binary folgt man der Readme. Zusätzlich benötigt man nur noch eine Standalone Splunk Instanz, die mit einer minimalen Konfiguration über Docker gestartet werden kann. Dafür kann z.B. die folgende Docker Compose Datei verwendet werden:

1version: '3'
2
3services:
4splunk:
5image: splunk/splunk:latest
6container_name: splunk
7environment:
8- SPLUNK_START_ARGS=--accept-license
9- SPLUNK_PASSWORD=<secure_password>
10
11ports:
12- "8000:8000"
13- "9997:9997"

Über http://localhost:8000 erreicht man anschließend die Web-Oberfläche von Splunk, auf die mit dem Nutzer admin und dem vergebenen Passwort zugegriffen werden kann. Der Port 9997 wird für das Ingesten von Daten verwendet und wird in der Docker Konfiguration auf localhost gemappt. Daher kann 127.0.0.1 in Log Slapper als Target IP verwendet werden. Log Slapper inkludiert bereits einige Beispielangriffe. In diesem Fall verwenden wir die defcon-demo-attack.yaml Datei. Um den Angriff erfolgreich ausführen zu können, muss die hinterlegte Target IP (s. Bild) auf 127.0.0.1 geändert werden.

Anschließend kann man Log Slapper ohne weitere Konfiguration den Angriff ausführen lassen.

Der Defcon Demo Angriff sendet zwei Windows Event Logs zu Splunk, die auf Zeitstempel in der Zukunft datiert sind. Die Logs stammen von der IP 10.10.13.37 und sind dem beliebigen Hostnamen defcon-test-32 zugeordnet. Die Events werden in dem Index main gespeichert. Wenn man nun in der Splunk Oberfläche nach Events im main Index sucht, werden die Events standardmäßig nicht angezeigt. Erst wenn man manuell den Zeitraum bis ins Jahr 2027 erweitert, werden die Events sichtbar.

Mitigation

Um solche Angriffe zu erkennen, kann man sich verschiedene Informationen zu Nutze machen. Zum einen sollte man regelmäßig die Access Logs des Indexer auf Auffälligkeiten analysieren. Zum anderen gibt es ein verstecktes Feld in Splunk, dass normalerweise zum Debuggen verwendet wird, und die Zeit speichert, wann der Logeintrag am Indexer eingegangen ist. Das Feld heißt hidden_indextime und kann somit verwendet werden, um Time-Travel Angriffe zu erkennen.

Idealerweise härtet man aber die Splunk Instanz, sodass die Angriffe direkt unterbunden werden. Zuerst sollte man die Verschlüsselung in Splunk aktivieren, die standardmäßig aufgrund von Performance Nachteilen deaktiviert ist. Dabei sollte zwingend ein eigenes Zertifikat verwendet werden, da das Root Zertifikat von Splunk bei allen Instanzen identisch ist.

Wenn HEC verwendet wird und der Heavy Forwarder öffentlich ist, sollten zudem die Ports entsprechend geschützt sein. Außerdem sollte kein Public Indexer verwendet werden. Wenn man die Sicherheit noch weiter erhöhen möchte, kann man einen eigenen Check implementieren, der alle Logs verwirft, bei denen die Source IP nicht mit der Log IP übereinstimmt. Zuletzt sollte man die HEC Tokens regelmäßig rotieren, für den Fall, dass diese mal abhanden kommen.

Generell zeigt dies, dass Blue Teams die eingesetzte Log Infrastruktur kritisch hinterfragen sollten, da Angreifer sich damit einen Vorteil verschaffen können. Deshalb sollte das Ingesten, Verarbeiten und Speichern von Logs möglichst gut abgesichert werden.

Quellen

• The SIEMless Hack Präsentation