Beider Suche nach Schwachstellen und CVEs gibt es ein Problem mit dem Suchraum. Die Angriffsfläche ist scheinbar unbegrenzt, sodass die Auswahl des Ziels oft als die wichtigste Fähigkeit eines Bug-Bounty-Jägers angesehen wird.
In diesem Artikel werde ich den Prozess beschreiben, mit dem ich den Suchraum eingegrenzt habe. Von Millionen von Codezeilen bis hin zur Identifizierung von drei fehlerhaften Zeilen. Dabei halfen mir natürlich die neuesten LLM-Agenten sowie meine langjährige Erfahrung im Bereich Anwendungssicherheit, wodurch ich Fehlalarme vermeiden konnte, die häufig auftreten, wenn Agenten auf Reward Hacking ausgerichtet sind.
Der Suchraum
ImOktober 2025 kündigte Wiz in Zusammenarbeit mit den drei großen cloud Google Cloud, AWS und Microsoft einen neuen Hacking-Wettbewerb namens „Zeroday Cloud an. Inspiriert von Hacking-Wettbewerben wie „Pwn2Own“ umfasste „Zeroday Cloud 20 Open-Source-Softwareziele, Bibliotheken, Anwendungen und Toolkits, die cloud häufig zum Aufbau und Betrieb cloud verwenden. Das Ziel des Wettbewerbs war einfach, wenn auch nicht leicht zu erreichen: die Demonstration einer nicht authentifizierten Remote Code Execution (RCE) auf dem Zielobjekt.
Grenzen setzen
Auseinem riesigen Suchraum wurde die anfängliche Zielauswahl auf nur zwanzig Repositorys festgelegt. Abgesehen von möglichen Authentifizierungsumgehungen können wir die zu berücksichtigenden Codepfade weiter auf diejenigen beschränken, auf die ein nicht authentifizierter Benutzer Zugriff hat. Darüber hinaus legen die meisten Zielregeln fest, dass Exploits in der Regel über einen lokalen HTTP-API-Server über das Netzwerk bereitgestellt werden müssen.
Ein Ort, um anzufangen
Umerste Anhaltspunkte zuerhalten, haben wir zwei Möglichkeiten. Traditionell würde man den Quellcode und die Anwendungslogik manuell überprüfen, um nach verdächtigen Funktionen zu suchen. Datei-Uploads, Skript-Engines oder Dokument-Renderer sind alles Bereiche, die bei der Ausführung von beliebigem Code hilfreich sein könnten.
Angesichts des noch immer großen Suchraums und der begrenzten Zeit entschied ich mich für einen anderen Ansatz. Da es sich bei den Zielen um öffentlich zugängliche Code-Repositorys handelt, trainierte ich ein statisches Code-Analyse-Tool auf die Codebasis, um Hinweise zu generieren.
WieSie auf dem Screenshot unten sehen können, wurden pro Ziel Dutzende oder sogar Hunderte von Code-Ergebnissen generiert. Diese dienten als Ausgangspunkt für meine LLM-gestützte Suche nach Schwachstellen.
Fehlerverfolgung mit Claude
Nichtalle Code-Ergebnisse sind gleichermaßen interessant. Nur diejenigen, die das Potenzial hatten, das Ziel des Wettbewerbs, die Remote-Code-Ausführung, voranzutreiben, sollten untersucht werden. Dazu gehören Probleme wie:
- „Eval erkannt“
- „Shell=True im Subprozessaufruf“
- „Deserialisierung von Pickles in Pytorch“
- „Nicht statischer Befehl in Exec“
- „Benutzereingabe in path.join“
- „Gefährlicher Schreibbefehl“
Meine Eingabeaufforderungen variierten je nach Codezeile und markiertem Problem, hatten aber dennoch ein allgemeines Thema.
Beispielaufforderung:
Ich verwende ein statisches Analyse-Tool, um Schwachstellen in meinem Code zu identifizieren. Dieses Tool hat diese Codezeile als potenziellen Code-Injektions- und Ausführungspunkt identifiziert. Ihre Aufgabe besteht darin, den Ursprung der in dieser Zeile ausgeführten Eingabe zurückzuverfolgen, um festzustellen, ob sie an irgendeiner Stelle vom Benutzer gesteuert oder beeinflusst werden könnte. Bitte antworten Sie mit einer detaillierten Analyse, in der Sie die ausgeführte Eingabe bis zu ihrer Quelle zurückverfolgen.
Die konkurrierenden LLMs
SowohlGemini 2.5 als auchClaude Sonnet 4.5 schnitten bei der Rückverfolgung verdächtiger Codezeilen bis zu ihrer Quelle ordentlich ab. Sie verfolgten den Injektionspunkt methodisch zurück und beschrieben die Transformationen und Manipulationen, denen die Eingabe dabei unterzogen wurde.
DieUnterschiede zwischen den beiden Modellen zeigen sich in ihrer Analyse der Ausnutzbarkeit. Während das eine Modell eine skeptische, konservative Haltung einnahm, war das andere eher darauf bedacht, potenzielle Risiken zu finden und tangentiale Schwachstellen zu untersuchen. Schauen wir uns an, wie sich diese beiden Modelle bei meiner ersten Auswertung der Ergebnisse der statischen Codeanalyse geschlagen haben.
Der konservative Architekt vs. der eifrige Praktikant
DieGemini-Persönlichkeit könnte als graubärtiger, skeptischer Architekt beschrieben werden. Wenn sie gebeten wird, eine Codezeile auf das Potenzial für die Ausführung von beliebigem Code zu überprüfen, ist ihre Antwort sowohl konservativ als auch etwas eingeschränkt auf eine einfallslose Sichtweise des Ausnutzungspfads. Sie ist entschieden nicht übermäßig enthusiastisch und verkörpert auch keine „unkonventionelle” Denkweise.
Hierversucht Gemini 2.5 mich davon zu überzeugen, dass mit einer bestimmten Codezeile alles in Ordnung ist (siehe Abbildung A: Gemini's Conservative Triage). Es ist fest davon überzeugt, dass der ausgeführte Code aus einer Konfigurationsdatei stammt und daher nicht ausnutzbar ist. Das Modell versucht, alle intellektuellen Türen für weitere Untersuchungen zu schließen.
Claude hingegen ähnelt Ihrem enthusiastischsten Praktikanten. Brillant, aber sprunghaft. Was ihm an Perspektive fehlte, machte er durch seinen Wunsch wett, jeden Schützengraben zu räumen. SeineAntwort auf dieselbe Eingabe wich erheblich vom ursprünglichen Ziel ab, eine Taint-Analyse durchzuführen, um potenzielle willkürliche Code-Injektionen zu erkennen, und stattdessen optimistische Aussagen über andere potenzielle Sicherheitsrisiken zu machen.
Hiersehen Sie, wie Claude eifrig mögliche nächste Schritte vorschlägt (siehe Abbildung B: Claudes Eifer). In der Praxis habe ich noch nie erlebt, dass Claude Sonnet geantwortet hat, ohne einen Hoffnungsschimmer für eine potenzielle Schwachstelle zu bieten. Wie Sie unten sehen können, werden selbst bei der Darstellung von Abhilfemaßnahmen diese immer als potenzielle Risiken dargestellt, wenn sie nicht korrekt umgesetzt werden.
Du bist die Tafel Architektur
DerArbeitsablauf macht Sie – den Menschen im Kreislauf – ganz natürlich zum unverzichtbaren Experten. Ich fand mich in der Rolle des Advocatus Diaboli wieder, stellte das konservative Denken des Architekten in Frage und fungierte als der Nüchterne gegenüber den enthusiastischen Vorschlägen des Praktikanten. Das eine Modell gegen das andere auszuspielen und den besseren der beiden Vorschläge auszuwählen, ist die Blackboard-Architektur in der Praxis.
Die Blackboard-Architektur ist im Wesentlichen ein Entwurfsmuster, das es mehreren spezialisierten Large Language Model (LLM)-Agenten ermöglicht, zusammenzuarbeiten, um komplexe, chaotische Probleme zu lösen. Sie ist in einer Multi-LLM-Umgebung effektiv, da sie den Agenten einen zentralen, gemeinsamen Arbeitsbereich – das „Blackboard“ – zur Verfügung stellt, in dem sie kommunizieren und schrittweise eine Lösung entwickeln können, ohne an einen starren, vordefinierten Arbeitsablauf gebunden zu sein.
DiesesKonzept lässt sich am besten als Teamzusammenarbeit vorstellen. Jedes Teammitglied bringt einzigartige Fähigkeiten mit, und obwohl Sie nicht direkt miteinander sprechen können, kommunizieren Sie miteinander und entwickeln die Lösung, indem Sie auf eine gemeinsame Tafel oder ein Whiteboard schreiben.
AusgefeilteMulti-Agenten-Systeme verfügen über einen „Overlord“ oder Agentenmanager, der die besten Lösungen auswählt und dem Agententeam hilft, schwierige Situationen zu meistern. Mein Ad-hoc-Workflow entwickelte sich ganz natürlich dahin, dass ich als Blackboard, Agentenmanager und Vermittler zwischen starken Persönlichkeiten fungierte.
Eine umfassendere Definition von Erfolg
Undhat dieser Arbeitsablauf Früchte getragen? Nicht in der Weise, wie ich es mir ursprünglich erhofft hatte. In den paar Wochen, in denen ich potenzielle Software-Schwachstellen in Open-Source-Code untersucht habe, ist es mir nicht gelungen, das strenge Ziel der nicht authentifizierten Remote-Code-Ausführung zu erreichen. Dank Claudes Neugier und meiner Bereitschaft, mich auf Entdeckungsreisen zu begeben, habe ich jedoch einige interessante Probleme in der Codebasis aufgedeckt, die zuvor nicht identifiziert worden waren.
Ich vermute, dass die meisten Schwachstellenforscher, die KI zur Suche nach Fehlern einsetzen, versuchen, ihr Over/Under zu optimieren. Identifizieren Sie die relevantesten Schwachstellen mit dem höchsten CVSS-Wert von 10,0 mit möglichst wenigen Zyklen. Dies hat Raum für die menschliche Intuition gelassen, die weiterhin eine Rolle bei der Entdeckung von Schwachstellen spielt. Vorerst bleiben wir die unverzichtbaren Experten in diesem Bereich.
Bleiben Sie dran (insbesondere in 90 Tagen), um die Fortsetzung der Diskussion über die KI-gestützte Fehlersuche zu verfolgen und mehr über die Einzelheiten der Schwachstellen zu erfahren, die ich mit Hilfe mehrerer KI-Agenten aufgedeckt habe.
