Software-Lieferkette im Griff

Wenn Hacker in die Infrastruktur von Softwareentwicklern vordringen, diese kompromittieren und legitime Updates mit Trojanern versehen, ist das für die Nutzer der betroffenen Produkte kaum zu erkennen, wie verschiedene Vorfälle in den vergangenen Jahren gezeigt haben. Eine Patentlösung für dieses Problem gibt es noch nicht, aber mit einer Kombination von Techniken lassen sich Netzwerke durchaus verteidigen. Dabei geht es darum, kleinste Veränderungen im Verhalten kritischer Software und der Systeme, auf denen sie läuft, zu erkennen.

Forscher des Analytics-Spezialisten Splunk haben mehrere Techniken kombiniert, um anhand eindeutiger "Fingerabdrücke" zu erkennen, welche Anwendungen in einem Netzwerk HTTPS-Verbindungen herstellen. Sie machen sich dabei den Umstand zunutze, dass Malware ganz unabhängig davon, wie sie bereitgestellt wird, meistens mit eigenen TLS-Bibliotheken oder -Konfigurationen (TLS = Transport Layer Security) daherkommt. Damit können ihre HTTPS-Handshakes in den Traffic-Log-Daten identifiziert werden. Sie sehen anders aus als TLS-Client-Hashes von zuvor genehmigten Anwendungen.

Nutzung des JA3-Standards

SSL/TLS-Client-Fingerprints zu verwenden, um bösartigen Datenverkehr in Netzwerken zu identifizieren, ist keine neue Idee. Experten von Salesforce haben einen Standard namens JA3 entwickelt, der einen MD5-Hash aus mehreren Attributen der TLS-Konfiguration eines Clients erstellt. Diese Attribute werden in der so genannten "Client-Hello"-Nachricht - der Startnachricht eines TLS-Handshakes - gesendet. Dabei werden Attribute wie etwa die SSL-Version, akzeptierte Chiffren, die Liste der Erweiterungen, elliptische Kurven und elliptische Kurvenformate verknüpft; aus dem Ergebnis wird dann ein MD5-Hash berechnet. Theoretisch ist es zwar möglich, dass verschiedene Client-Anwendungen ähnliche TLS-Konfigurationen aufweisen, aber die Forscher glauben dennoch, dass die Kombination mehrerer Attribute eindeutig genug ist, um das Identifizieren von Programmen zu ermöglichen.

Auch für TLS-Server lassen sich anhand von Attributen in den "Server-Hello"-Nachrichten solche Fingerabdrücke erstellen. Dieser Ansatz wird JA3S genannt. Er ist allerdings nicht ganz so zuverlässig, weil Server mehrere TLS-Versionen und -Konfigurationen unterstützen. Sie werden ihre Antworten auf der Grundlage der vom Client unterstützten und angeforderten Daten anpassen. So antwortet ein und derselbe Server mit unterschiedlichen TLS-Konfigurationsattributen auf verschiedene Clients.

Eine JA3S-Unterstützung wurde bereits vielen Tools für Netzwerk-Monitoring und Sicherheit hinzugefügt - sowohl Open-Source- als auch kommerziellen Produkten. Das Splunk-Team hat nun verschiedene Methoden der Nutzung von JA3S im Kontext seiner Datenanalyseplattform und deren verschiedenen Abfragetypen untersucht. "In unseren Tests mit realen Unternehmensdaten sowie mit denen aus unseren Testumgebungen hat sich gezeigt, dass anormale Aktivitäten mit hoher Wahrscheinlichkeit über anormale JA3S-Hashes erkannt werden können", schreiben die Forscher in einem kürzlich veröffentlichten Papier. "Das hängt aber von vielen Faktoren ab. Um die Zahl der False-Positives zu begrenzen, wird wohl eine Whitelist mit erlaubten Anwendungen zugrunde gelegt werden müssen."

Der Fall SolarWinds

Bösartiger Datenverkehr lässt sich dann am besten identifizieren, wenn auf kritischen Servern nur eine begrenzte Anzahl von Anwendungen laufen, die ausgehende Verbindungen initiieren dürfen. Das war beispielsweise beim Angriff auf die Lieferkette von SolarWinds der Fall, bei dem Hacker einen Trojaner als Bestandteil eines Updates für die Infrastruktur-Monitoring-Lösung "Orion" einschmuggelten. Orion ist ein Programm, das einen häufigen und uneingeschränkten Netzwerkzugang braucht und normalerweise auf einem dedizierten Rechner läuft. (Lesen Sie auch: So wird Ihre Software-Lieferkette gehackt)

Splunk arbeitet dabei mit zwei Arten von Abfragen, die darauf abzielen, entweder das zuerst entdeckte oder das "seltenste" Auftreten von JA3-Fingerprints im Netzwerkverkehr eines bestimmten Host-Systems zu identifizieren. Beide Abfragen können auf nicht autorisierte Anwendungen wie Backdoors und Trojaner hinweisen, die HTTPS-Verbindungen herstellen. "Das Erkennen abnormaler Aktivitäten über eine Abfrage des ersten Auftretens erwies sich als hilfreich, wenn der Analyst mit den Netzwerkaktivitäten vertraut war und eine Erlaubnisliste (von JA3S-Hashes und/oder Servernamen zum Herausfiltern bekannter Entitäten) nutzte", so die Forscher.

Das Zeitfenster für die abgefragten Verkehrsdaten ist ebenfalls wichtig: Fällt es zu klein oder zu groß aus, können die bösartigen Aktivitäten übersehen werden. Die Forscher fanden heraus, dass ein Zeitfenster von sieben Tagen bei dieser Art von Abfrage die besten Ergebnisse lieferte; die bösartigen Anfragen erschienen in den Top-20-Abfrageergebnissen.

Die Wahl des Zeitrahmens und das Verwenden einer Liste mit erlaubten Anwendungen ist noch wichtiger für den zweiten Abfragetyp, der in einem Datensatz die am seltensten auftretenden JA3-Hashes nach Servernamen identifizieren soll. Die Ergebnisse für diesen Abfragetyp waren über verschiedene Zeitfenster hinweg inkonsistent und enthielten viele falsch-positive Ergebnisse. Das brachte die Forscher zu dem Schluss, dass die Ergebnisse solcher Abfragen nur in Kombination mit denen anderer Abfragen verwendet werden sollten, um verdächtige Connections zu identifizieren.

Wahrscheinlichkeits-Score errechnen

Die Forscher verwendeten daraufhin einen nativen Splunk-Befehl namens "anomalydetection", mit dem sie die Ergebnisse von Abfragen filtern und einen Wahrscheinlichkeits-Score für jedes Ereignis berechnen können. Das erwies sich als effektiv, erforderte aber eine Anpassung des Wahrscheinlichkeits-Schwellenwerts in Abhängigkeit von der Menge der gesammelten Daten und der gewünschten Sensibilität.

"Die Nutzung des Befehls anomalydetection erwies sich als effektiv beim Erkennen bösartiger anormaler Aktivitäten über einen Zeitraum von 24 bis 48 Stunden", so die Forscher. Längere Zeiträume hätten die Effektivität der Abfrage verringert. "In Experimenten mit kleineren Netzwerken mit einem einzigen /24-Netblock wurde die bekannte bösartige Aktivität durchweg ohne eine Erlaubnisliste unter den ersten 30 Ereignissen identifiziert. In Netzwerken mit mehreren oder umfangreicheren Netblocks war das jedoch nicht der Fall."

Um die Geschwindigkeit der Analyse zu erhöhen, entwickelten die Forscher eine Technik, mit der sie die Abfrageergebnisse in einer Nachschlagetabelle speichern und ordnen konnten. Andere Abfragen konnten sie dann gegen diese Tabelle laufen lassen. Das verbesserte zwar nicht die Genauigkeit beim Erkennen von Anomalien, aber die Geschwindigkeit bei der täglichen Arbeit wurde um das 100-fache erhöht.

Außerdem kombinierten die Experten die JA3-Abfrageergebnisse mit den Daten des Windows-Systemüberwachungsdienstes von Sysmon, was zu einer sehr viel genaueren und leistungsfähigeren Einstufung potenziell bösartiger Aktivitäten führte. Das liegt daran, dass Sysmon der Untersuchung Informationen über die Prozessausführung hinzufügt.

"So korrelieren wir Windows-Prozesse mit JA3S-Hashes mit dem jeweiligen server_name", erklären die Forscher. "Beispielsweise können wir so einen Powershell.exe-Prozess identifizieren, der sich mit einem externen Host verbindet. Um die relevanten Daten zu sammeln, muss Sysmon so konfiguriert werden, dass Ereignisse, die eine Netzwerkverbindung initiieren (EventCode 3), erfasst werden. Olaf Hartong hat ein Dienstprogramm für die modulare Konfiguration von Sysmon geschrieben und Open Source zur Verfügung gestellt, das vielleicht den einfachsten Weg bietet, die benötigten Daten schnell zu sammeln."

Grenzen des TLS-Fingerprinting

Obwohl diese Methoden vom Splunk-Team im Zusammenhang mit der hauseigenen Datenanalyseplattform erforscht wurden, sind sie nicht darauf beschränkt. Sie können für den Einsatz mit anderen Tools für Datenerfassung und Traffic-Analyse angepasst werden.

Generell ist aber festzustellen, dass diese Techniken immer dann viele False-Positives generieren, wenn sie zur Erkennung von Anomalien an Endpunkten verwendet werden, wo allgemeines Browsing erlaubt ist oder ein großes Volumen an HTTPS-Verkehr von verschiedenen Anwendungen zu verschiedenen Servern erzeugt wird. Mit anderen Worten: Diese Techniken zur Anomalieerkennung funktionieren dann gut, wenn sie auf Servern und Systemen mit wenigen geschäftskritischen Anwendungen eingesetzt werden, die im kritischsten Netzwerksegment laufen.

Angriffe auf die Software-Lieferkette haben natürlich nicht nur Auswirkungen auf Server-Anwendungen, die nur auf einer begrenzten Anzahl von Systemen eingesetzt werden. Im Jahr 2017 gelang es Hackern, die Infrastruktur von CCleaner, einem Systemoptimierungs- und Bereinigungstool, zu kompromittieren und ein mit einem Trojaner versehenes Update auf 2,2 Millionen Computer von Privatkunden und Unternehmen zu platzieren.

Der "Second-stage Payload" erreichte aber nur eine begrenzte Anzahl hochwertiger Ziele, darunter auch einige Technologieunternehmen. Im selben Jahr meldete auch Microsoft einen Angriff, bei dem Hacker den Update-Mechanismus eines in Unternehmen weit verbreiteten Third-Party-Tools kompromittiert hatten. Angreifer bevorzugen solche Produkte, die auf Workstations und Mitarbeiter-Laptops in Unternehmen oft weit verbreitet sind.

Angriffe auf Software-Lieferkette lassen sich nicht ganz verhindern

Trotz der Vorstöße von Splunk gibt es derzeit alles in allem kein Produkt und keine Technik, die in der Lage ist, Angriffe auf die Software-Lieferkette vollständig zu erkennen und zu blockieren. Hintergrund ist, dass diese Attacken die legitimen Privilegien ausnutzen, die Anwendungen und Update-Mechanismen auf Rechnern zugeteilt wurden. Eine Rückkehr zu den Zeiten, in denen Software-Updates monate- oder jahrelang nicht bereitgestellt wurden und die Systeme immer anfälliger für bereits bekannte Angriffsszenarien wurden, ist sicher keine Lösung.

Ein Problem ist, dass viele Unternehmen nicht über aktuelle Software- und IT-Inventare verfügen. Sie wissen oft nicht im Detail, welche Anwendungen auf den Computern in ihrem Netzwerk laufen. Das gilt noch mehr in Pandemiezeiten, in denen viele Mitarbeiter zu Hause oft mit ihren eigenen Geräten arbeiten und von dort eine Verbindung zum Unternehmensnetz herstellen. Auch mit den aktuellen Configuration Management Databases (CMDBs) ist es unmöglich, eine Liste zulässiger Softwareaktualisierungs-Server für alle Anwendungen in einem Netzwerk zu erstellen, da die Softwarehersteller diese Informationen nicht veröffentlichen. Und selbst wenn sie es tun, ändern sich deren Domänennamen und IP-Adressen häufig.

Unternehmen müssen dieses Problem irgendwie angehen. Am besten sie konzentrieren sich erst einmal auf kritische Anwendungen und Server, die nur eine relativ begrenzte Zahl an ausgehenden Verbindungen zum Internet haben. "Der erste Schritt besteht darin, eine Asset-Liste zu erstellen. Dann können Sicherheitsteams Forschungsarbeiten durchführen, wie wir es gemacht haben, um Angriffen auf die Lieferkette mit Hilfe von JA3S zu erkennen", sagt Ryan Kovar, Distinguished Security Strategist bei Splunk.

"Sie können ganz allgemein beginnen. Wenn Sie so vorgehen wie wir, werden Sie bald Ergebnisse sehen. Diese werden aber nicht ausreichend genau und granular sein, wenn Sie nicht eine Art Whitelist nutzen oder nicht genau wissen, was die Assets sind, die Sie zu verteidigen versuchen." Splunk empfiehlt den Sicherheitsprofis, sich nicht auf alle Vorgänge im Netzwerk zu konzentrieren, sondern auf die Dinge, deren Output oder Veränderungen für wichtig gehalten werden.