Im Rahmen meiner Masterarbeit, welche ich in der VUSec-Gruppe (die System & Network Security Group an der Vrije Universität Amsterdam) absolvierte, schafften wir es, eine CPU-Sicherheitslücke aufzudecken. Diese ermöglichte es, sensitive Daten über das Netzwerk auszulesen, womit sie alles andere als harmlos ist. In diesem Blogbeitrag berichte ich über die Findings meiner Masterarbeit, die Reaktionen sowie die Auswirkungen auf die Cyber Security.
Die gute Nachricht zu Beginn: Die Sicherheitslücke wurde von Intel anerkannt und – erfreulich für mich und meine Forschungskollegen – ein Bug Bounty (quasi ein Kopfgeld für Programmfehler) ausbezahlt. Und ebenfalls zu meiner Freude wurde die Masterarbeit, die daraus resultierte, vom IEEE Symposium on Security and Privacy Peer-Reviewed und akzeptiert. Was das heisst? Im Mai 2020 können wir unsere Ergebnisse an der gleichnamigen Konferenz in San Francisco präsentieren. Und – als wäre das noch nicht genug – ebenso am Chaos Communication Congress (36C3), der Ende Dezember stattfand.
Cache-Side-Channel-Angriffe als echte Bedrohung
Die entdeckte Sicherheitslücke (CVE-2019-11184) zeigte, dass netzwerkbasierte Cache-Side-Channel-Angriffe eine realistische Bedrohung darstellen. Cache-Angriffe werden traditionell verwendet, um vertrauliche Daten in einer lokalen Umgebung zu entwenden. Dabei werden geteilte Hardware-Ressourcen ausgenutzt. Ein Beispiel hierzu wäre von einer vom Angreifer gesteuerten virtuellen Maschine zu einer anderen virtuellen Maschine, die sich den CPU-Cache auf einer Cloud-Plattform teilen. Mit CVE-2019-11184 wird diese Bedrohung auf das Netzwerk ausgeweitet; sprich Cache-Aktivitäten einer Maschine können über das Netzwerk ausgelesen werden. So kann die Vertraulichkeit einer SSH-Sitzung ohne Malware auf dem Client oder dem Server von einer dritten Maschine aus gebrochen werden. Die Hauptursache für die Sicherheitslücke ist eine neue Intel-Funktion namens DDIO, welche Netzwerkgeräten und anderen Peripheriegeräten Zugriff auf den CPU-Cache gewährt. DDIO ist seit 2012 standardmässig auf allen Intel Server CPU per Default aktiviert. Ursprünglich als Leistungsoptimierung gedacht, zeigten unsere Forschungsergebnisse, dass DDIO schwerwiegende Sicherheitsrisiken mit sich bringt und Server in lokalen Netzwerken Remote-Side-Channel-Angriffen aussetzen kann.
Intel stimmte zu, dass dies eine signifikante Sicherheitslücke darstellt und empfiehlt, den direkten Zugriff von nicht vertrauenswürdigen Netzen auf Server mit DDIO und RDMA (Remote Direct Memory Access) zu limitieren. Dies bedeutet im Wesentlichen, dass in nicht vertrauenswürdigen Netzwerkumgebungen DDIO und/oder RDMA deaktiviert werden sollten.
Aber was ist DDIO genau?
Data Direct I/O – kurz DDIO – ist eine leistungssteigernde Technologie auf aktuellen Intel Server-Prozessoren. Anstatt vom langsamen RAM zu lesen, ermöglicht DDIO Peripheriegeräten den Zugriff auf den schnelleren Computer-Cache.
In traditionellen Architekturen, in denen die Netzwerkkarte den direkten Speicherzugriff (DMA) verwendet, wird die Speicherlatenz allein schnell zum Engpass. Dies kann schon mit Netzwerkkarten von 10Gb/s erfolgen. Um diesen Engpass zu beseitigen, führte Intel DDIO ein: Eine Architektur, bei der Peripheriegeräte direkten Cache-Zugriff auf den Last Level Cache der CPU betreiben können. Die folgende Abbildung veranschaulicht den Unterschied zwischen direktem Cache-Zugriff (orange) und direktem Speicherzugriff (blau).
Und was ist nun CVE-2019-11184?
Mit CVE-2019-11184 – unserer gefundenen Sicherheitslücke – zeigten wir wie schon erwähnt, dass es möglich ist, die Vertraulichkeit einer SSH-Sitzung von einem dritten Computer aus zu brechen, ohne dass bösartige Software auf dem Remote Server oder Client ausgeführt wird. Der Angreifer tut dies, indem er ausschliesslich Netzwerkpakete an den Remote Server sendet.
Um es noch genauer zu formulieren, kann mit CVE-2019-11184 die Ankunftszeit der einzelnen Netzwerkpakete aus einer SSH-Sitzung über einen Remote-Cache-Side-Channel ausgelesen werden. Warum das sinnvoll ist? In einer interaktiven SSH-Sitzung werden bei jeder Tasteneingabe Netzwerkpakete direkt übertragen. Folglich kann mit CVE-2019-11184 jedes Mal, wenn ein User ein Zeichen innerhalb einer verschlüsselten SSH-Sitzung auf der Konsole eingibt, die Ankunftszeit anhand des entsprechenden Netzwerkpakets ausgelesen werden. Da Menschen unterschiedliche Tippmuster haben, können aus der Ankunftszeit direkt Buchstaben extrahiert werden. Als Beispiel ist die Eingabe von «s» direkt nach «a» schneller als die Eingabe von «g» nach «s». Dadurch kann man mit den gewonnenen Daten des Remote-Side-Channel-Angriffs eine statische Analyse der Ankunftszeiten von Paketen, einen so genannten Keystroke-Timing-Angriff, durchführen. So kann herausgefunden werden, was in der privaten SSH-Sitzung für Informationen eingegeben resp. übertragen wurden. Der komplette Angriffspfad ist also relativ komplex. So haben wir nicht nur eine Sicherheitslücke gefunden, sondern auch eine Studie verfasst, wie aus Ankunftszeit von Netzwerk-Paketen ganze Wörter rekonstruiert werden können. Die folgende Abbildung veranschaulicht, wie ein User das Wort «because» eintippt und als Vergleich, wie wir die Ankunftszeiten aus dem Remote Cache rekonstruieren konnten.
In unserem Angriff nutzten wir die Tatsache, dass der DDIO-fähige Anwendungsserver über eine gemeinsame Ressource (den Last Level Cache) zwischen dem CPU und der Netzwerkkarte verfügt. Unser Team hat anschliessend wichtige Eigenschaften von DDIO «Reverse Engineered», oder anders gesagt, analysiert und nachkonstruiert. Dadurch konnten wir verstehen, wie der Cache mit DDIO geteilt wird. Wir nutzten dieses Wissen, um sensible Informationen aus dem Cache des Anwendungsservers mit Hilfe eines Cache-Side-Channel-Angriffs über das Netzwerk auszulesen. Um den Angriff zu vereinfachen, setzten wir auf die Remote Direct Memory Access (RDMA) Technologie. RDMA ermöglichte es unserem Exploit, den relativen Speicherort von Netzwerk-Paketen auf dem Zielserver zu kontrollieren.
CVE-2019-11184 in den Medien
Kurz nach dem Public Disclosure, welches am 10. September 2019 stattfand, gab es zahlreiche Berichterstattungen in den Medien, unter anderem auf namhaften Technologie-News-Seiten wie Ars Technica, ZDNet und Heise sowie auf Twitter.
Ein Proof-of-Concept-Video finden Sie hier; mehr Informationen zum Angriff und die ganze Forschungsarbeit hier:
Bildquelle (Nr. 1; Michael Kurth): https://media.ccc.de/v/36c3-10884-practical_cache_attacks_from_the_network_and_bad_cat_puns
