Sie werden sich wahrscheinlich nicht mehr erinnern, aber 2004 führte die Defense Advanced Research Projects Agency (DARPA), die Wissenschafts- Behörde des US-Verteidigungsministeriums, die erste 'DARPA Grand Challenge' durch: Über 100 Fahrzeuge traten an, um einen Hindernissparkur von circa 240 km Länge ohne menschliches Eingreifen autonom zu durchfahren. Eine damals gewaltige Herausforderung. Und so war es keine große Überraschung, als keines der Fahrzeuge die Ziellinie erreichte (die autonom zurückgelegte Strecke lag unter 12 km). Heute, zwölf Jahre später, scheinen selbstfahrende Autos zum Greifen nah. Fahrerassistenzsysteme wie Teslas Autopilot sind bereits auf unseren Straßen unterwegs - geben aber nur einen Vorgeschmack auf das was uns erwartet. Was 2004 undenkbar war, ist heute (fast schon) ein Premium-Feature und wird morgen (vielleicht auch erst übermorgen?) zur Serienausstattung aller Fahrzeuge gehören.
Die gewaltige Herausforderung besteht heute in der automatisierten Analyse zuvor unbekannter Programme auf Sicherheitslücken und dem automatisierten Patchen. Derzeit erfordert die Identifizierung von Sicherheitslücken ein hohes Maß an Kreativität und 'händischer' Arbeit. Zwar greifen Experten auf einen großen Pool an Tools zurück, jedoch bleibt die Auswertung der Ergebnisse dieser Tools manuelle Arbeit. Ebenfalls ist die Entwicklung von Patches als Gegenmaßnahmen ein weitgehend manueller Prozess.
Hacking-Wettbewerb auf der Defcon 2016
Den wirkungsvollsten Weg der Automatisierung zu identifizieren, war auch der Ziel des Hacking-Wettbewerbs auf der diesjährigen Defcon. In 96 Runden traten die Cyber Reasoning Systeme (CRS) genannten Hacking-Bots der Teams insgesamt acht Stunden lang gegeneinander an. In jeder Runde erhielten die Bots den ausführbaren Binärcode der dem System zuvor unbekannten Programme, in denen Sicherheitslücken identifiziert werden sollten. Die Bots mussten diese Programme
selbständig starten;
die Funktionalität gewährleisten;
auf Sicherheitslücken hin untersuchen und schließlich
Patches entwickeln und diese
in den Maschinencode installieren und auch noch
gegen Angriffe der gegnerischen Bots verteidigen - Capture-the-Flag (CTF) Prinzip.
So schnitten die Teams dabei ab:
Rang | Systemname | Team / Unternehmen |
1 | MAYHEM | ForAllSecure, Carnegie Mellon University, Pittsburgh |
2 | XANDRA | TECHx Gramma Tech / University of Virginia |
3 | MechaPhish (Mechanical Phish) | Shellpish UC Santa Barbara |
4 | Rubeus | Raytheon, Arlington, VA |
5 | GALACTICA | CodeJitsu, Berkeley, UC, Syracuse, N.Y. |
6 | JIMA | CSDS, Moscow, Id. |
7 | Crspy | Disekt, Athens, Ga. |
Im Laufe des Wettkampfs identifizierten die Bots 650-mal Sicherheitslücken und entwickelten selbständig jeweils einen Proof-of-Vulnerability (POV). Darunter befand sich eine Sicherheitslücke, die selbst den DARPA-Programmierern nicht bekannt war. Einem Bot gelang es sogar, sich gegen das Ausnutzen dieser Sicherheitslücke zu schützen, ohne sie zu kennen. Es wurden 650 Sicherheitslücken identifiziert und 421 Patches entwickelt.
Wie genau die sieben Bots zu diesen Ergebnissen kamen, bleibt bisher ein weitgehend gut gehütetes Geheimnis. Zum einen um es den anderen Teams schwerer zu machen, zum anderen wird eine zukünftige kommerzielle Vermarktung der Bots nicht ausgeschlossen. Das Team Shellpish hat allerdings bereits angekündigt, den Code ihres Bots vollständig zu veröffentlichen. Es ist aber nicht bekannt, inwieweit die Teams überhaupt die vollen Veröffentlichungsrechte besitzen.
Methoden der Teams
Zur Identifizierung der Sicherheitslücken kamen mehrere dynamische und statische Methoden zum Einsatz. Die Schwierigkeit dabei war, möglichst alle Code-Segmente zu überprüfen. Dieses Ziel ist mit der Methode Dynamic-Analysis-Fuzzing am besten zu erreichen. Beim Fuzzing werden durch systematisches Ausprobieren einer großen Anzahl von Eingabedaten Anomalien in einem Zielsystem provoziert. Fuzzing kann jedoch bei mangelhafter Auswahl der Eingabedaten einen sehr zeitaufwendigen Prozess darstellen und erfordert daher den Eingriff von Experten.
Um in kurzer Zeit eine möglichst hohe "Code Coverage" zu erreichen, wurde eine Kombination von Symbolic Execution und Fuzzing eingesetzt. Dabei wurde zunächst mittels Symbolic Execution ein Pfadbaum der Anwendung herauskristallisiert. Auf Basis dieses Pfadbaumes wurde der Fuzzer in die Lage versetzt, an einen bestimmten Eingabepunkt in der Anwendung zu gelangen, ohne die dafür notwendigen Eingabedaten mühsam "erraten" zu müssen. Neben den dynamischen Methoden kamen auch statische, wie Static-Machine-Code-Analysis zu Einsatz. Hier einige der relevanten Angriffstools:
In den Tests eingesetzte Produkte und Methoden (Auszug) | |
Concolic Execution (or whitebox fuzzing) | Herleitung von Eingabe-/Angriffspfaden mit anschließendem Fuzzing |
Control Flow Integrity (CFI) | Verfahren zur Sicherstellung der Integrität des Kontrollflusses eines Programms. |
Data Delineation Analysis (DDA) | Heuristische Analyse zum Herleiten der Größe und Position von Objekten im Binärcode. |
Data Flow Analysis | Analysetechnik zur Bewertung von Datenflüssen innerhalb eines Programms. |
Data Flow Integrity (DFI) | Wurde entwickelt um sicherzustellen, dass der Datenfluss nicht manipuliert wurde. |
Dynamic Program Analysis | Analysiert das Verhalten eines Programms zur Laufzeit und identifiziert auftretende Fehler. |
Dynamic Taint Analysis | Verfahren zur Erkennung von Abhängigkeiten der Variablen untereinander. |
Fault Remediation | Generiert der entwickelte Patch Folgefehler (Funktion)? |
IDA Pro Disassembler | Ein für Windows, Linux und Mac OS X verfügbarer multi-Prozessor-Disassembler und -Debugger. |
Instruction-Location Randomization (ILR) | Einfach zu implementierende Methode mit wenig Overhead zur Verhinderung von "arc injection" Angriffen. |
Program Shepherding | Methode zur Verhinderung von Exploits indem Programmanweisungen und Datenfluss analysiert werden. |
Secure Dynamic Code Generation (SDCG) | Eine multi-Prozessor-basierte Architektur, die ein höheres Sicherheitsniveau bietet |
Secure In-process Monitoring (SIM): | Verfahren, um Prozesse zur Laufzeit vor externen Manipulationen zu schützen. |
Die zu den Sicherheitslücken entwickelten Patches lassen sich in zwei Gruppen unterteilen:
Specific Purpose, die eine bestimmte Sicherheitslücke schließen und
General Purpose, die aus allgemeinen Systemhärtungen, wie Memory Randomization und Trennung von nicht ausführbaren (non-executable) und ausführbaren (executable) Daten bestehen.
Weitere "Patches" umfassen Intrusion Detection/Prevention Systeme und Filtern der Eingabedaten auf identifizierte Angriffe. Außerdem wurde versucht, die Patches der anderen Teams zu analysieren und die eigenen Patches gegen Analysen der anderen Teams zu schützen. Die Bots mussten selbstständig entscheiden, ob und wann sie patchen. Denn während des Patchens wird die Verfügbarkeit des jeweiligen Dienstes eingeschränkt. Daher wurden Sicherheitslücken, die schwer zu identifizieren waren, erst spät oder gar nicht gepatcht, obwohl der Patch frühzeitig bereitstand.
Die fortschreitende Automatisierung der IT-Security
Die Automatisierung wird sich auch im Bereich IT-Security schnell durchsetzen. Automatisierungs-Bemühungen sind bekannt und auch die eingesetzten Methoden. So gehört Fuzzing und auch die entsprechenden Tools (zum Beispiel der AFL Fuzzer) bei High-End-Security-Beratungsunternehmen bereits heute zum Standard. Die Konfiguration der Tools und Auswertung der Ergebnisse wird jedoch auch weiterhin von Experten vorgenommen.
Auch bei der Entwicklung von Patches ist der Anteil an händischer Arbeit derzeit noch hoch. Die autonomen Patches der Bots setzen eine automatisierbare Überprüfung der Funktionalität voraus. Das ist in den meisten Fällen nicht gegeben. Zurzeit stecken allgemein anwendbare, automatisierte und funktionale Testverfahren noch in den Kinderschuhen.
Foto: ARKHIPOV ALEKSEY - shutterstock.com
Viele der erkannten und gepatchten Sicherheitslücken stellen nur simple Fehler dar; die Bots beherrschen komplexere Sicherheitslücken und die Erstellung von Patches für sie (noch) nicht. Die Teilnahme des Gewinners der DARPA Cyber Grand Challenge mit dem Namen "Mayhem" an einem CTF Wettkampf im Rahmen der Defcon 24 in Las Vegas zeigt deutlich die Grenzen auf: Mayhem erlangte den vorletzten Platz gegen menschliche Gegner. So sind Vergleiche zu den früheren ersten Schach- und Go-Wettkämpfen zwischen Mensch und Computer durchaus angebracht. Automatisierte Systeme wie Cyber Reasoning Systems werden immer intelligenter und erfolgreicher, so dass sie bei automatisierten Security-Tests Menschen weit hinter sich lassen werden.
Neu ist die Kombination von Methoden/Tools und die automatisierte Tool-Steuerung. Die eingesetzten Methoden sind nicht neu. In diesem Wettbewerb der DARPA wurden nur simple Sicherheitslücken und solche identifiziert, deren Muster dem Bot bekannt waren. Die angestrebte automatisierte Identifizierung von Sicherheitslücken ist nicht trivial. Auch nach dem automatisierten Security Patching muss die Funktion der Software naturgemäß noch erhalten bleiben. Dazu muss der Bot die Funktionen des zu patchenden System also "verstehen". Das dazu notwendige, autonome funktionale Testen ist allerdings derzeit nur mit Einschränkungen möglich.
Insgesamt stellt der Wettbewerb gleichwohl einen bemerkenswert großen Fortschritt im Security Testing dar: Mit den entwickelten Tools können Angriffe erkannt und wirkungsvoll verhindert werden. Sicherheitslücken lassen sich automatisiert identifizieren, patchen und korrigieren werden. Erste Produkte auf der Basis dieses Wettbewerbs dürften ausgewählten Kunden derzeit schon angeboten werden. (fm)