KI in Offensive Security

KI und im speziellen Sprachmodelle wie ChatGPT sind in aller Munde. In vielen Bereichen wird daran gearbeitet, mittels KI Prozesse zu optimieren bzw. zu automatisieren. Auch in der Security-Branche tut sich so einiges. In diesem Blogpost möchten wir einen kleinen Einblick in aktuelle Entwicklungen in der Welt des Offensive Security Tooling geben.
 

Wer sich mit offensiver Security, also Penetration Testing, Bug Hunting und Co. beschäftigt, der stellt oft fest: Die spannenden und spektakulärsten Software-Schwachstellen werden immer noch manuell gefunden. Das Tooling beschränkt sich oft auf einen Code Editor, einen Debugger und vielleicht ein paar Python-Skripte. So beindruckend das auch sein mag, es skaliert einfach nicht. Es wird mehr Software geschrieben, als Security-Expert*innen Code reviewen können. Wie kann man die Arbeit von Security-Expert*innen nun optimieren oder sogar automatisieren?

Das automatisierte Auffinden und Ausbessern von Schwachstellen ist ein Ziel, das sowohl die akademische Forschung als auch in einige R&D-Abteilungen von Firmen anstreben. Vor fast zehn Jahren hat die DARPA, der Forschungsarm des US Militärs, die Cyber Grand Challenge (CGC) gestartet, die dann jedoch auf der DEFCON Konferenz im August 2016 ihr Ende fand. Das Ziel dieser Veranstaltung war es, komplett autonom agierende Systeme zu entwickeln, die Schwachstellen in Software entdecken, ausnutzen und ausbessern können und diese Systeme in einem Wettbewerb gegeneinander antreten zu lassen (im Stil eines “Capture the Flag”). DARPA nennt diese Art von System Cyber Reasoning System (CRS). Das Problem: Die Teilnehmer*innen der CGC haben zwar beeindruckende CRS entwickelt, diese CRS hatten jedoch außerhalb des Wettbewerbs nicht direkt den Nutzen den man sich vielleicht erhofft hatte. Die Gründe:

• CGC beschränkte sich auf die Analyse von kompilierten C/C++ code und hatte einen starken Fokus auf das Aufspüren von Memory Corruption-Angriffen, wie zum Beispiel Buffer Overflows. Auch wenn aktuell immer noch ein Großteil der Software-Schwachstellen diese Art von Problemen zurückgehen, so sind der Großteil der modernen Web und Cloud Dienste in Programmiersprachen entwickelt, die diese Art von Schwachstelle in der Regel nicht aufweisen.
• Im CGC kam ein eigenes Betriebssystem mit stark eingeschränkter Funktionalität zum Einsatz (Beispielsweise kein Dateisystem, nur sehr wenige Kommunikationsmöglichkeiten). Das vereinfachte die Analyse und machte es möglich, mit den damaligen Technologien ein vollständig autonom agierendes Cyber Reasoning System zu entwickeln. In der Praxis gibt es jedoch eine Vielzahl von Möglichkeiten, wie ein Angreifer mit Software interagieren kann. Es zeigte sich, dass das ein großes Bottleneck bei der Automatisierung ist.

Auch wenn die Cyber Reasoning Systeme aus dem CGC nicht direkt Anwendung gefunden haben, so hat die Security Community doch einiges aus diesem Wettbewerb gelernt. Zum Beispiel wurde klar, dass coverage-guided fuzzing der wohl effektivste und effizienteste Weg ist, um Schwachstellen automatisch zu finden. Allerdings zeigt sich auch hier: Um Fuzzing in die Praxis zu bringen benötigt es Know-How und vor allem Zeit, Fuzzing in den Entwicklungsprozess zu integrieren.

Nun hat die DARPA bei der DEFCON Konferenz diesen August den Nachfolger der Cyber Grand Challenge abgeschlossen. In der AIxCC, der AI Cyber Challenge, hat die DARPA das Setting so erweitert, dass es näher an der Realität von Software Teams liegt. Ähnlich zu dem CGC-Wettbewerb mussten die Cyber Reasoning-Systeme autonom Schwachstellen auffinden, einen Testcase zum Reproduzieren erstellen (Proof-of-Vulnerability) und dann auch einen Patch erstellen. Diesmal gab es Source Code statt Binärdateien und es mussten sowohl C- als auch Java-Projekte analysiert werden. Die wichtigste Änderung jedoch: Jedes CRS hat Zugriff auf ein großzügiges KI-Budget bekommen. Damit konnten die Teilnehmer aktuelle KI-Modelle, vor allem Large Language Models wie ChatGPT, nutzen, um Prozesse zu automatisieren. Die Ergebnisse sind spannend und die entwickelten Cyber Reasoning-Systeme haben fantastische Ergebnisse geliefert:

• Interessant ist der Trend, dass Systeme, die mehr LLM Budget genutzt haben, auch besser im Wettbewerb abgeschnitten haben. Systeme, die eher mehr auf klassische Programmanalyse (Fuzzing, Static Analysis) setzen, haben schlechter im Wettbewerb abgeschnitten.
• Alle Systeme der Finalisten sind Open Source - Auch wenn nicht alle aktiv weiterentwickelt werden, so werden wir in den nächsten Monaten und Jahren sicher noch einige der Techniken und Komponenten aus den AIxCC-Systemen in der Praxis wiederfinden.
• Die meisten Systeme nutzten immer noch klassische Programmanalyse im Hintergrund um Schwachstellen zu identifizieren. Hier wurde von den meisten Teilnehmer*innen auf eine Kombination aus statischen Code-Analyse Tools und Fuzzing gesetzt. LLMs wurden hier verwendet, um diese Techniken zu optimieren und deren Ergebnisse zu bewerten.

Der AIxCC Wettbewerb hat gezeigt, dass KI das Potenzial hat, die Probleme, die wir mit Security Tooling aktuell haben, zu lösen. Auch außerhalb des AIxCC Wettbewerbs werden am laufenden Band neue KI Tools vorgestellt, die Security-Expertise automatisieren. Wir sehen hier einige spannende Einsatzszenarien von KI:

1. Reduzieren von False Alarms in Code-Analyse-Tools: Viele Code-Analyse-Tools, vor allem statische Analyse-Tools (SAST), erzeugen auch viele falsche Meldungen. Gerade in Softwareprojekten, wo diese Tools nicht von Anfang an zum Einsatz gekommen sind, melden sie eine hohe Anzahl an falscher Schwachstellen. Zu viele dieser falschen Meldungen und die Produktivität der Entwickler*innen wird gehemmt, Findings werden nicht ausreichend gut analysiert, oder schlichtweg ignoriert. LLMs können hier Abhilfe schaffen: Ausgestattet mit den richtigen Tools, können LLMs genutzt werden, um die Kritikalität von Problemen im Code einzuschätzen, Datenflüsse im Code nachzuvollziehen, Tests für gemeldete Probleme zu erstellen, oder kleine Fehler direkt auszubessern. Hier gibt es viel Potenzial um Entwickler*innen und Security-Expert*innen unter die Arme zu greifen.
2. Einführung und Optimierung von Fuzzing: Fuzzing hat sich als dynamische Programmanalyse-Technik bereits etabliert. Jedoch benötigt man für den Einsatz von Fuzzing einen Test Harness, ähnlich zu einem Unit Test, um gewisse Komponenten der Software auszuführen und andere Komponenten durch Mocks zu ersetzen. Im AIxCC-Wettbewerb wurden einige neue Techniken entwickelt, um diese Fuzzing Harnesses effizienter zu machen und zu erweitern, so dass größere Teile der Software von Fuzzing abgedeckt werden. AI-gestütztes Fuzzing hat also das Potenzial, Fuzzing auch in Projekten zu nutzen, wo den Entwickler Teams die Fuzzing-Expertise fehlt.
3. Continous Security and Penetration Tests: Fertig entwickelte Software-Systeme oder IT-Umgebungen werden oft durch einen Penetration Test geprüft, in dem ein/e Security Expert*in einen Angriff simuliert und versucht, wie ein Angreifer in das System einzudringen. Das Problem ist jedoch, dass Penetration Tests immer nur den Zustand des Software-Systems zu einem gewissen Zeitpunkt darstellen. Bei agiler Entwicklung und mehreren Deployments pro Tag mittes Continuous Integration/ Continuous Deployment (CI/CD) Pipeines ist ein einzelner Penetration Test nicht mehr so aussagekräftig. Der Trend geht also dazu, Security Testing zu automatisieren: Security-orienterte Testfälle in der CI Pipeline verhindern Regressionen und können Sicherheitsmaßnahmen validieren. Dynamic Application Security Testing (DAST) Produkte versuchen, Schwachstellen in Testumgebungen zu identifizieren. Mittels LLMs können viele der Workflows eines typischen Penetration Tests bereits automatisiert werden. Hier gibt es das Potenzial, dass KI es ermöglicht, einen “Continous Penetration Test” durchzuführen.

Es gibt also viel Potenzial Offensive Security mit KI zu automatisieren. Im offensiven Bereich, also dem Auffinden von Schwachstellen, ist es auch leichter mit den Schwächen einer KI umzugehen. Es ist zwar unmöglich zu beweisen, dass ein System sicher ist, es ist jedoch leicht zu zeigen, dass ein System unsicher ist: Man entwickelt einen Proof-of-Concept Exploit um zu demonstrieren, dass eine Schwachstelle existiert. So kann man relativ leicht testen, ob die KI nur halluziniert oder ob sie tatsächlich eine Schwachstelle gefunden hat.

Bevor wir all das in der Praxis verwenden werden, wird noch einiges an Engineering passieren müssen. So muss der Einsatz von LLMs noch günstiger werden. Ein Beispiel: Das Buttercup CRS von Trail of Bits hat im Rahmen des AIxCC-Wettbewerbs rund 39.000 $ an Cloud Compute und LLM Budget verbraucht, um 28 Schwachstellen zu identifizieren. Das sind also rund 1400 $ pro Bug. Da die Projekte aber auch absichtlich eingesetzte Schwachstellen enthielten, muss man davon ausgehen, dass ein echter Einsatz eines solchen Systems weitaus mehr kosten wird. In bestehenden Prototypen und Systemen wird fast immer auf die stärksten und größten Sprachmodelle zurückgegriffen. Es ist nicht klar, ob das tatsächlich für alle Aufgaben notwendig ist. Man könnte also versuchen mit kleineren, aber spezialisierteren KI-Modellen hier die Kosten zu reduzieren.

Das Fazit unserer Analyse ist, dass wir in naher Zukunft eine Vielzahl von spannenden Projekten und innovativen Produkten erwarten können, die das Tooling von Security-Expert*innen langfristig verändern werden. Wir bleiben engagiert und werden weiterhin aufmerksam verfolgen, wie sich diese Trends entwickeln. Zudem unterstützen wir gerne bei der Bewertung und Integration neuer KI-basierter Sicherheitsprodukte, um sicherzustellen, dass unsere Partner und Kunden von den besten verfügbaren Lösungen profitieren können.