0:00:02 Emily Wearmouth: Es wurde viel über die potenziellen Risiken gesprochen, die Frontier-KI-Modelle mit sich bringen könnten, und der heutige Gast wird uns eine alternative Perspektive geben. Er ist ein Red-Team-Mitarbeiter innerhalb eines Sicherheitsteams und nutzt Frontier-Modelle mit großem Erfolg. Willkommen also zum Security Visionaries Podcast Mohit Kulamkolly. Mohit ist leitender Ingenieur im roten Team im Netskope-Sicherheitsteam, und es ist großartig, dich bei uns zu haben, Mohit.
0:00:26 Mohit Kulamkolly: Danke. Danke, dass ich hier sein darf. Ja, ich freue mich, im Podcast zu sein. Ja.
0:00:31 Emily Wearmouth: Sie haben ein paar Blogbeiträge geschrieben, und sie haben mich dazu veranlasst, Sie zu kontaktieren, weil Sie in diesen Artikeln über Arbeit gesprochen haben, die Sie und Ihr breiteres Team mit diesen Modellen in Ihren Red-Teaming-Bemühungen geleistet haben. Und ich wollte das ein wenig besprechen, und es gibt ein paar verschiedene, ich nenne sie Experimente. Ich hoffe, das lässt sie nicht zu klein klingen. Es gibt ein paar verschiedene Experimente und verschiedene Modelle, die Sie verwendet haben, und meine Absicht ist es, Ihnen viele Fragen zu stellen, die hoffentlich alle Details und Entdeckungen offenlegen, die Sie im Laufe Ihres Prozesses gemacht haben. Seit Sie Zugang zu Frontier-KI-Modellen erhalten haben – und ich glaube, Netskope ist im Juni dieses Jahres "Glasswing" beigetreten – führt Ihr Team einige wirklich informative Experimente durch. Sie haben diese Frontier-Modelle in den Weg von Netskopeeigenen Sicherheitsprodukten gestellt, wenn ich es richtig verstehe, und versucht herauszufinden, ob sie ernsthafte Sicherheitsfehler finden können, insbesondere Speicherbeschädigungsfehler.
0:01:26 Emily Wearmouth: Unsere Zuhörer kommen aus einer wirklich breiten Kirche, und könntest du, Mohit, damit beginnen, einem Zuhörer, der vielleicht selbst nie direkt mit Schwachstellenforschung zu tun hat, erklären, was ein Gedächtniskorruptionsfehler ist und warum er als eine der gefährlicheren und schwerer zu findenden Kategorien von Sicherheitsfehlern gilt?
0:01:45 Mohit Kulamkolly: Ja, klar, klar. Ja, das trifft es genau. Fangen wir also mit dem an, was Speicherkorruption selbst verbuggt, wie du zu Recht angemerkt hast. Ein Speicherfehler tritt also auf, wenn eine Software ihren eigenen zugewiesenen Speicherplatz falsch verwaltet. Dies wird vom Betriebssystem verwaltet, aber dann von der Software selbst zugewiesen und entschieden. Wenn das passiert, entstehen Schwachstellen, die mehrere weitere Auswirkungen im Betriebssystem auslösen können, was kein erwartetes Verhalten ist. Warum ist es also gefährlich? Denn wir machen einen Schritt zurück und erklären, warum es gefährlich ist, es besser zu verstehen. Wir können das Betriebssystem grob in zwei Teile unterteilen. Einer ist also der Benutzermodus und der andere der Kernel-Modus. Der Benutzermodus ist also der Ort, an dem alle Programme, alle unsere Programme, bleiben, und der Kernel-Modus ist das, was mit dem Betriebssystem zusammenhängt.
0:02:44 Mohit Kulamkolly: Und der Benutzermodus braucht immer wieder Dinge vom Kernel, um bestimmte Aktionen auszuführen und alles. Hier beginnt also die Angriffsfläche. Wenn also ein Programm im Benutzermodus abstürzt, bleibt es im Benutzermodus selbst. Und wenn es beginnt, Dinge vom Kernel abzufragen, kann der Angreifer das ebenfalls sehen oder der Angreifer kann es ebenfalls verwenden. Auf diesem Weg kann es auch Dinge im Betriebssystem zum Absturz bringen, was zu weiteren Schwachstellen führt. Deshalb ist es im Vergleich zu anderen Schwachstellen sehr gefährlich.
0:03:15 Emily Wearmouth: Und was wollten Sie herausfinden, indem Sie diese KI-Modelle auf diese Speicherfehler verwiesen haben?
0:03:22 Mohit Kulamkolly: Im Grunde operiert Netskope also innerhalb des Systems innerhalb der Entität des Betriebssystems eines Kunden. Und wenn eine Schwachstelle ausgelöst wird, handelt es sich um eine Gedächtnisbeschäftigung. Wie gesagt, es kann zu einem Ausfall des Systems führen oder zu Schwachstellen für Privilegieneskalationen und all diesen Dingen. Das Ziel war also zu sehen, ob eine Schwachstelle innerhalb Netskope Client insbesondere zu etwas eskalieren kann, das das Betriebssystem betrifft. Wir brechen also von unserem Programm aus und gehen ins große Ganze, was katastrophaler ist als nur das Netskope Client Absturz. Also ja, das war das Ziel.
0:04:03 Emily Wearmouth: Und bevor wir uns ansehen, wie Sie die KI-Tools nutzen, wie würden Sie normalerweise nach diesen Schwachstellen suchen, bevor Sie Frontier AI hatten?
0:04:13 Mohit Kulamkolly: Also, bevor es damit beginnt, herauszufinden, was die Angriffsfläche ist. Es gibt also APIs, die für diese Art von Kommunikation geschrieben sind, die vom Benutzermodus zum Kernel-Modus stattfinden. Also versucht man zunächst herauszufinden, welche APIs es gibt und wie das Programm geschrieben wird, ganz aus der Black-Box-Perspektive. Wenn ich von Black Box spreche, haben wir keinen Quellcode, nichts dergleichen. Da haben wir also angefangen. Und von dort aus versuchen wir herauszufinden, ob eine von uns gesendete Nutzlast oder Daten zu einem Absturz innerhalb eines Systems oder innerhalb dieses jeweiligen Betriebssystems führt. Und wir versuchen es immer wieder, um herauszufinden, welche Nutzlast oder Anweisung der Fehler ist. Deshalb versuchen wir, Fuzzer selbst zu entwickeln. Das haben wir jetzt im Detail beschrieben. Deshalb habe ich Fuzzer entwickelt, die helfen, diese Schwachstellen zu erkennen.
0:05:10 Mohit Kulamkolly: Aber die KI in diesem Bild hat sich auf ein ganz anderes Testniveau New entwickelt, bei dem viel, viel mehr Fachwissen nötig ist, um überhaupt in diesen Bereich einzusteigen. Und durch das Aufkommen von KI können wir es weiter eskalieren.
0:05:29 Emily Wearmouth: Und ich werde hier aus Ihrem Blogbeitrag zitieren. Also, in der ersten Phase der Arbeit, die Sie gemacht haben, und Sie haben OpenAI 5.5 verwendet, habe ich das richtig verstanden?
0:05:38 Mohit Kulamkolly: Cyber-Modell.
0:05:39 Emily Wearmouth: Du hast gesagt, dein Ausgangspunkt sei, dass du nicht einfach die KI fragen, mir einen Bug suchen und der Antwort vertrauen kannst. Man muss ihm die gleichen Werkzeuge geben, die ein echter menschlicher Insektenjäger nutzen würde, und jede seiner Behauptungen gegen ein echtes, laufendes System abgleichen lassen. Um also die Punkte dort in der richtigen Reihenfolge zu betrachten: Warum ist es gefährlich? Das wissen wir vielleicht. Sagen Sie mir ausdrücklich, warum es gefährlich ist, einfach dem Wort eines Modells zu vertrauen, dass es eine Schwachstelle gefunden hat? Und was könnte schiefgehen, wenn du diese Verifizierungsphase überspringst?
0:06:09 Mohit Kulamkolly: Ja, klar. Bevor ich also noch tiefer darauf eintauche, denke ich, dass ich die Aussage vielleicht schon länger widersprechen werde, weil mir das Mythos mit den New Experimenten beigebracht hat. Was bei diesen Cybermodellen, OpenAI 5.5 oder dem Cybermodell, passiert, ist, dass sie auf einer riesigen Datenmenge trainiert werden, alles Sicherheitslücken und -erkenntnisse. Es ermöglicht also Halluzinationen in Situationen, in denen es Annahmen treffen muss statt Informationen. Wenn du das Modell also einfach bittest, die Schwachstelle für dich zu finden, ist das das Einzige, was es kennt. Es muss also aus den Annahmen, die es ursprünglich getroffen hat, schließen. In gewisser Weise ist es also gut, was wir später herausgefunden haben. Anfangs, wenn wir schreiben wollten, mussten wir sicherstellen, dass wir unsere Ergebnisse so deterministisch wie möglich bezüglich waren. Da haben wir beschlossen: Okay, fangen wir mit dem an, was wir wissen.
0:07:11 Mohit Kulamkolly: Versuchen wir, das weiter auszubauen, und dann gehen wir auf das Kapitel ein, was wir nicht wissen und was das Modell leisten kann.
0:07:17 Emily Wearmouth: Okay. Und erzähl mir, was du hier eigentlich aufgebaut hast. Wie sieht ein Labor für eine solche Einrichtung eigentlich aus?
0:07:24 Mohit Kulamkolly: Ja, ohne sehr ins Detail zu gehen, wie es ist, ist es auf einer sehr allgemeinen Ebene so, dass man einem Schwachstellenforscher die Werkzeuge gibt, die er braucht. Ich meine, es muss nötig sein, damit es bestimmte Aktionen ausführen kann. Denken Sie also darüber nach: Es gibt virtuelle Missionen, in denen die Software läuft. Es gibt virtuelle Missionen, in denen die Werkzeuge laufen. Also habe ich einfach alle miteinander verbunden, die Punkte zusammengefügt und dem Modell diesen gegeben, und es dann gebeten, eine Schwachstelle auf eine sehr spezifische Weise zu suchen, die ich mit meinen Erfahrungen mit den bisherigen Jagdversuchen betrachten würde. So haben wir damit angefangen. So sieht das Labor auf sehr hoher Ebene aus.
0:08:12 Emily Wearmouth: Ich werde eine potenziell knifflige Frage stellen. In den letzten ein bis zwei Wochen gab es viele Geschichten über Agenten und KI, die aus Sandboxen ausgebrochen sind und Dinge getan haben, die vielleicht die ihnen zugewiesenen Aufgaben beantworten, aber sicherlich nicht auf eine Weise, mit der wir uns wohlfühlen würden. Gibt es bestimmte Leitplanken, die Sie um diese Experimente herum aufbauen, in der Hoffnung, dass sie ausbrechen könnten? Wie stellst du sicher, dass es nicht passiert?
0:08:36 Mohit Kulamkolly: Ja, das ist eine sehr gute Frage, denn gerade in diesem Kontext, wenn ein Agent gebeten wird, eine bestimmte Aufgabe zu erledigen, sagen wir das nicht auf eine sehr spezifische Weise. Das habe ich anfangs gemacht, und ich habe verstanden, dass das für den Agenten eine Begrenzung sein könnte. Um daraus auszubrechen, haben wir eine individuelle Sandbox-Umgebung geschaffen. Jede virtuelle Mission hat also eine Sandbox-Umgebung, die nicht gebrochen werden kann oder nicht zugänglich ist, wenn wir es ausdrücklich nicht erlauben. Gerade bei diesen Test-Windows-Rechnern funktionieren virtuelle Missionen am besten statt eines Docker-Containers oder ähnlicher Konzepte. Das ist also das Maß an Isolation, das wir für einzelne Werkzeuge und den Zugang dafür geschaffen haben. Und wir führen all diese Tests auf einem separaten System und einer separaten Mission ohne ordentlichen Internetzugang durch.
0:09:34 Emily Wearmouth: Ich denke, es vom Internet fernzuhalten, ist eines der wichtigsten Dinge, um seine Fähigkeit, abtrünnig zu werden, einzuschränken. Du hast auch in dem von dir geschriebenen Artikel erwähnt, dass du das um eine Zielmaschine herum gebaut hast, die speziell abstürzen darf, und eine separate Maschine, die sie mit einem Debugger überwacht. Warum hast du diese getrennt gehalten und warum ist es sinnvoll, es tatsächlich abstürzen zu lassen, anstatt es zu stoppen, bevor das passiert?
0:09:58 Mohit Kulamkolly: Ja, das ist also das ganze Konzept dieser Gedächtniskorruptionsschwachstelle und warum das interessant ist. Immer wenn ein System versucht herauszufinden, dass ein Speicher von einem Programm falsch behandelt wird, geht es in eine Fail-Safe-Phase. Das ist also eine Crashphase, die passiert. Wenn man also versucht, einen einzelnen Bug zu testen, wenn man versucht, eine einzelne Nutzlast auf mikroskopischer Ebene zu testen, ist der beste Weg, zunächst zu bestätigen, dass der Bug existiert, um zu sehen, ob er abstürzt oder nicht. Und wenn es einen absurden Absturz gibt, bedeutet das, dass es eine falsche Erinnerungshandhabung gibt. Dann können wir später besprechen, wie wir es eskalieren können, welche Systemproduktionen wir umgehen müssen, und so weiter und so fort. Solche Dinge kommen also in einer späteren Phase auf. Aber um noch zu einer interessanten Sache hinzuzukommen, die du erwähnt hast: Warum pausieren wir es nicht kurz bevor es abstürzt?
0:10:53 Mohit Kulamkolly: Es gibt also auch ein solches System. Das machen wir also auch intern. Es ist eine Snapshot-Fuzzing-Infrastruktur, die wir aufgebaut haben, bei der wir versuchen, sie kurz vor dem Absturz aufzufangen, damit wir sie millionenfach wiederholen können, um New Varianten unserer Schwachstelle zu finden. Also ja, das ist der ganze Kontext.
0:11:12 Emily Wearmouth: Und ich habe noch eine Frage zu dieser Phase des Experiments. Ich behalte mir das Recht vor, mehr zu fragen, aber im Moment denke ich, dass ich eine habe. Es klingt so, als hätten sich viele der frühen Hypothesen des Modells über Bugs als falsch herausgestellt. Dass es veraltete Annahmen über die Software verwendete. Und ich habe mich gefragt, warum Sie festgestellt haben, dass das passiert? Und was, wenn überhaupt, hat das Modell daraus gelernt, sich zu irren und diese Phase des Fehlers zu durchlaufen?
0:11:43 Mohit Kulamkolly: Ja, was bei dieser Art von Software passiert, ist, dass es schwierig ist, diese Art von Software zu testen, weil sie sehr stark von der Umgebung abhängt, in der sie eingesetzt wird. Wenn also kleine Anpassungen am Betriebssystem vorgenommen werden, zum Beispiel wenn eine Funktion oder ein Programm im Hintergrund laufen sollte, aber es läuft nicht, wird die Software sich nicht so verhalten, wie sie sollte. Das ist einer der Gründe, warum das System sich nicht nur an die Umgebung anpassen muss, die es für Schwachstellen hat, sondern gleichzeitig auch den nächsten Schritt bestimmen muss, basierend auf dem Ergebnis dort. Es ist also nicht nur so, okay, das ist das Standardverfahren, mach es einfach. Man muss also sicherstellen, dass das System das akzeptiert oder die Software bereit ist, das Standardverfahren zu akzeptieren und es funktioniert, bevor man Nutzlasten einsetzt.
0:12:39 Mohit Kulamkolly: Denn wenn du hier keine KI einbaust, werde ich viele Nutzlasten einreichen und dann reagiert die KI nicht oder die Software reagiert nicht einmal. Wie kann ich es also testen? Das ist also ein Grund, warum das Modell diese Korrektur vorgenommen hat. Ja.
0:12:54 Emily Wearmouth: Rechts. Was wir bisher besprochen haben, war deine erste Phase. Sie hatten also Menschen, Sie selbst, die alle Schritte entwarfen, und dann wurde die KI gebeten, Aufgaben innerhalb eines von Ihnen entworfenen Prozesses auszuführen. Ich möchte, dass wir jetzt zu deiner zweiten Phase übergehen. Für deine zweite Phase hast du das Modell geändert und stattdessen mit Claude Mythos gespielt. Gab es einen Grund, das zu ändern, oder wolltet ihr ursprünglich Experimente mit beiden durchführen? Oder gab es einen Vorteil, den Sie durch den Wechsel zu einem anderen Modell hatten?
0:13:30 Mohit Kulamkolly: Nicht wirklich. Wir haben einfach New ausgefallenen Werkzeuge und New Analoga.
0:13:34 Emily Wearmouth: Wir alle haben das schon erlebt. Okay. Und bei diesem zweiten Versuch werde ich versuchen, zu skizzieren, was anders war, und dann bin ich sicher, dass du das noch etwas genauer beleuchten wirst. Anstatt also jeden Schritt zu entwerfen und dann das Modell zur Ausführung zu bitten, haben Sie das Modell gebeten zu entscheiden, was untersucht werden soll. Du hast es dann gebeten, jeden gefundenen Fehler gegen ein echtes System zu beweisen. Und dann, was anscheinend ein ziemlich kritisches Element ist, verlangte man auch, dass eine zweite unabhängige Kopie von sich selbst doppelt mit diesem Beweis überprüft wurde. Du gibst dem Ganzen mehr Ablauf, baust aber auch mehr Kontrollen ein, weil du mehr vom menschlichen Aufwand entfernst. Können Sie mir erklären, was Sie dazu gebracht hat – vom Abschluss bis zum Abschluss Ihrer OpenAI-Experimente – was Sie dazu gebracht hat, es so zu gestalten?
0:14:30 Mohit Kulamkolly: Wir haben also unsere Lehren aus OpenAI gelernt, als wir mit den Tests mit Mythos begonnen haben. Also unter der Haube, alle Sicherheiten, alle Modelle. Sie sind also im Grunde alle Vorhersagesysteme. Auch wenn wir sagen, sie hätten New Software entwickelt und alles, sagen sie einfach sehr effizient voraus, was als Nächstes kommt, basierend auf dem Kontext, der ihm gegeben wird. Je mehr man also den Kontext einschränkt oder immer mehr den Kontext an die Leine legt, desto weniger wird die Art von Informationen, die es erzeugen kann, abnehmen. Als wir also mit OpenAI getestet haben, haben wir es als Fuzzer hergestellt. Wir haben darum gebeten, darauf aufzubauen. Jetzt wollten wir sehen, ob es nur eine Erweiterung daraus bauen konnte, weil wir ihm den Fuzzer gegeben haben.
0:15:21 Mohit Kulamkolly: Also haben wir den Fuzzer aus dem Bild entfernt und ihm beigebracht, wie man den Fuzzer baut und wie man das selbst machen kann. Entweder machen Sie das selbst, oder Sie machen einfach das, was Sie für richtig halten, um diese spezielle Schnittstelle des Programms zu erreichen. Deshalb wollten wir es auf diese Weise versuchen. Anstatt also ein Geländer darum herumzuziehen. Also hat es sehr gut funktioniert. So verstanden wir, wie sich das Modell verhielt und wie es kreativ war, um eine Schwachstelle zu erkennen. Das ist also der Kern des Problems.
0:15:57 Emily Wearmouth: Gab es zusätzliche Überlegungen, die Sie berücksichtigen mussten, weil Sie diesmal mehr Kontrolle abgaben? Gab es verschiedene Strukturierungen oder zusätzliche Leitplanken, die du für nötig hieltest?
0:16:10 Mohit Kulamkolly: Ja, mehr Isolation. Ich denke, mehr Isolation war der Schlüssel dafür. Das Modell, nicht unser Arbeitssystem. Wir hatten also einen separaten Laptop nur zum Testen. Es war außerhalb des Netzes. Und dann ja, diesmal haben wir alles gegeben. Anstatt ihn also zu bitten, die Werkzeuge zu nutzen, die im System vorhanden sind, haben wir einfach dafür gesorgt, dass er immer mehr isoliert wird. Ja, das ist alles.
0:16:35 Emily Wearmouth: Okay. Und dann, denke ich, indem man es einbaut und doppelt überprüft, was es produziert, gibt es auch zusätzliche Leitplanken für die Schlussfolgerungen, die es zieht, ich schätze, dass man in das Modell einbaut.
0:16:47 Mohit Kulamkolly: Ja, ja. Rechts.
0:16:49 Emily Wearmouth: Wie hast du verhindert, dass es sich selbst davon überzeugt hat, dass es richtig ist? Wie hast du es geschafft, diese doppelte Kontrolle so weit getrennt zu halten, dass sie es nicht konnte? Ich meine, eines der Dinge, die wir in der letzten Woche gesehen haben, war ein Agent, der buchstäblich so weit gegangen ist, Deepfakes von Mitarbeitern zu erstellen, um intern eine Zustimmung zu bekommen. Wir wissen also, dass KI weiß, wie man überzeugt. Wie hast du sichergestellt, dass es nicht nur sich selbst oder diese sekundäre Überprüfung überzeugt hat, dass das, was es tut, richtig ist?
0:17:21 Mohit Kulamkolly: Ja. Das Wesentliche daran ist auch das, was wir zuvor besprochen haben, nämlich dass das Modell ein Vorhersagesystem ist und der Kontext hier ein zentraler Bestandteil ist. Ich möchte auch hier dasselbe Konzept verwenden, den Kontext. Fast immer, zu 100 % der Fälle, wenn ein Modell etwas falsch macht, liegt das daran, dass es nicht den richtigen Kontext hat oder es schlechten Kontext hat, würde ich sagen. Der Grund, warum es zwei getrennte Systeme gibt, liegt also aus demselben Grund. Immer wenn ein Modell New Arbeit betrachtet, bedeutet das einfach, dass es von einem klaren Kontext zum Fenster betrachtet wird. In dieser Hinsicht trifft es keine zuvor geschaffenen falschen Annahmen. Auch in dem von dir genannten Fall läuft alles darauf hinaus, was das Modell erreichen muss. Das Ziel eines Agenten muss also nicht das Ziel des anderen Agenten sein.
0:18:16 Emily Wearmouth: Ah, interessant.
0:18:18 Mohit Kulamkolly: Und basierend auf dem, was du gesagt hast, könnte das ursprüngliche Ziel nicht darin bestehen, Deepfakes von genau diesem Mitarbeiter zu erstellen, sondern vielmehr, dieses Sign-off-System zu umgehen. Es macht also alles falsch, was es kann, aber das Modell hat aus seinem Kontext nichts Schädliches getan, sondern aus dem externen Kontext schon. Der Kontext ist also ein König. Ja.
0:18:40 Emily Wearmouth: Ich denke, du hast also ein wenig Reibung zwischen den beiden Stufen eingebaut: Wenn es seine eigene Arbeit nicht überprüft, ist es ein anderer KI-Agent, der die Arbeit überprüft, damit er nicht zusammenarbeitet und man eine Abgrenzung zwischen den beiden beibehält. Das ist ein wirklich interessanter Designpunkt.
0:18:58 Mohit Kulamkolly: Genau, genau. Ja.
0:19:00 Emily Wearmouth: Erzählen Sie uns also von dem, was dieser hier herausgefunden hat. Wie hat es funktioniert? Was ist daraus geworden?
0:19:08 Mohit Kulamkolly: Ja, wir haben aus diesen beiden ersten Experimenten viele gute Ergebnisse erzielt. So konnten wir etwa 17 bis 18 Schwachstellen nur bei Open-Source-Software finden. Diese Software nutzt Netskope also zur Entwicklung unserer Produkte. Aber dann werden diese Schwachstellen in den Upstream-Paketen entdeckt und dann an die richtigen Mitarbeiter gemeldet, die sie verwalten. Und dann gab es diese Speicherbeschädigungslücken, die ich entdeckt habe. Es gab also auch 15 bis 20 Speicherbeschädigungslücken. Und schließlich hatten wir für die Differenzialprüfung vier oder fünf Stück, die wir fanden. Das ist also nicht der gemeinsame Maßstab, es wurden 20.000 Schwachstellen gefunden, und das ist nur ein kleiner Maßstab, von dem ich spreche, 15 bis 20. Der Grund oder der entscheidende Punkt ist, dass jede Schwachstelle, wenn sie von einem Kunden gemeldet wird oder auf Netskope gemeldet wird, einem IWF zugeschrieben wird.
0:20:15 Mohit Kulamkolly: Diese IWF-Vorfälle werden also zu enormen Verlusten für die spezielle Einrichtung führen, die sie erlitten hat. Wenn wir es in unseren Produkten finden, sparen wir viel Geld und schaffen dann das Vertrauen unserer Kunden in Bezug darauf, wogegen wir uns stellen.
0:20:35 Emily Wearmouth: Ja. Jetzt habe ich aus Ihrem Artikel wieder etwas aufgeschrieben, das ich erforschen wollte und das besonders interessant aussah. Es gab einen Bug, den das Modell auf der Kernelseite gefunden hat, und du hast eine Geschichte über einen Absturz erzählt, der erst passierte, als es etwas Subtiles darüber herausfand, wie Speicher hinter den Kulissen verteilt wird. Möchten Sie uns dieses spezielle Beispiel auf einer übergeordneten Ebene erklären?
0:20:59 Mohit Kulamkolly: Ja, klar, klar. Ich denke also, diese Schwachstelle lag in einem Konfigurationsparser. Dieser Konfigurationsparser kopierte also im Grunde den Registry-Wert mit einer String-langen Kopierfunktion in eine exakt große Pool-Allokation. Und diese stringverknüpfte Kopierfunktion hatte keine vorhandene Outbound-Prüfung. Also der Scheck aus der Grenze. Aus diesem Grund handelt es sich also um eine Lehrbuch-Schwachstelle, die sehr leicht ausgenutzt werden kann. Um diese Schwachstelle zu erreichen, gab es also fast fünf oder sechs Voraussetzungen, die erfüllt werden mussten. Voraussetzungen sind also einfach so einfach wie zu prüfen, ob die Software einen bestimmten Dienstname akzeptiert oder ob es sich um etwas anderes handelt, das sie akzeptiert, oder eine andere Version, die sie akzeptiert. Das sind alles Voraussetzungen.
0:21:54 Mohit Kulamkolly: Nachdem alle Voraussetzungen erfüllt waren, ist der Absturz immer noch nicht passiert. Also musste er in den Debugger springen und versuchen, den Allocator zu verdummen. Und dann stellte sich heraus, dass das Betriebssystem offenbar etwas namens Null-Terminator hinzugefügt hat, was sehr häufig vorkommt. Und dann hat der Allokator diesen Puffer im Grunde zu einer vollständigen Tabelle abgerundet. Das führte dazu, dass eine Offbound-Lektüre nicht dort landete, wo wir sie gelandet hatten. Dann hat er die Geometrie des Allokators herausgefunden, wie das passiert, und dann den Exploit so geändert, dass er genau zu dem übereinstimmt, was den Fehler auslöst. Das ist also auf sehr hoher Ebene passiert. Ja.
0:22:35 Emily Wearmouth: Ein Teil des Grundes, warum ich dich darum gebeten habe, das zu erklären, war, weil ich den Mind-Blow-Moment erleben wollte. Ich meine, die Komplexität und die Detailschichten, in die sich das hier einlässt, wenn man sich eine Welt vorstellt, in der man dieses Ergebnis manueller erreicht hat, wie lange dauert es, wie viele Arbeitsstunden? Wie würde das aussehen? Oder glaubst du einfach, dass es nur zufällig passiert?
0:23:02 Mohit Kulamkolly: Ich meine, es wären Tage und Tage voller Mühe. Und dann, wie du sagst, wäre es auch ein Unfall. Weil es sehr schwierig ist, diese Dinge herauszufinden, denn wenn man einen Debugger anschaut und versucht herauszufinden, wo der Allocator schiefgelaufen ist, ist es schwierig, weil man viele Informationen verstehen muss, die dort sind. Vielleicht sind Sie kein Experte in genau diesem speziellen Bereich, aber Sie müssen all diese Dinge wissen, um die Zusammenhänge zu erkennen. Also ja, es könnte ein Zufall sein, dass Sie auf diese Probleme stoßen oder monatelang und stundenlang Mühe investieren, um diese Schwachstelle zu finden.
0:23:40 Emily Wearmouth: Es gab noch einen anderen, den ich in deinem Artikel interessant fand. Es war ein Bug, der mehrere Tage und tausende Versuche gebraucht hat, selbst mit der KI. Du hast also davon gesprochen, dass ein menschliches Äquivalent Tage und Tage dauern würde. Selbst mit der KI am Laufen hat das mehrere Tage und tausende Versuche gedauert. Was hielt diesen Prozess am Laufen? Was hat sich zwischen den gescheiterten Versuchen und dem einen, der schließlich funktionierte, verändert? Und warum ist es nicht ausgelaufen? Ich meine, wie lange, wenn es statt Tausenden von Versuchen gedauert hätte, wenn du bei Hunderttausenden gewesen wärst, hätte es einfach aufgegeben und das nicht gefunden? Ich habe dort ein paar verschiedene Fragen gestellt. Such dir was aus.
0:24:18 Mohit Kulamkolly: Nein, das ergibt Sinn. Tatsächlich war der Prozess für diese Schwachstelle oder das Finden dieser speziellen Instanz schwierig, weil wir keinen Quellcode dafür hatten. Wir hatten keine Symboltabelle, wir hatten nichts. Es ist ein kompletter Black-Box-Test, den wir durchgeführt haben. Das Besondere daran ist, dass bei solchen Schwachstellen mehrere Nuancen vorhanden sind, bevor man überhaupt zur Schwachstelle kommt. Was die KI zum Time-out angeht, ist es die Art, wie sie entworfen wurde, dass man mit vielen Gegenreaktionen konfrontiert sein wird, dass die ursprüngliche Hypothese funktionieren könnte oder eben nicht. Du solltest nicht nur darauf warten, dass eine Hypothese abgeschlossen ist, während die andere auf dich übergeht. Statt einer linearen Mode war es also größtenteils eine parallele Mode.
0:25:09 Mohit Kulamkolly: Agenten spinnen Subagenten nach Bedarf aus, um diese Ideologien zu erforschen, bis man den richtigen Ansatz findet oder findet. Das ist also der Grund, warum es meistens nicht abgelaufen ist. Ich glaube, sie lief ein paar Tage, um solche Schwachstellen zu finden, besonders wegen der Komplexität und Verfügbarkeit weniger Informationen. Aber ja, Subagenten haben da den Trick gewirkt.
0:25:34 Emily Wearmouth: Also werde ich jetzt ein wenig herauszoomen, und ich denke, es lohnt sich, hoffentlich haben die Zuhörer verstanden, dass diese beiden Artikel, die du veröffentlicht hast, absolut lesenswert sind. Deshalb fügen wir Details dazu, wo Sie mehr zu diesen Details lesen können, in den Shownotes. Aber lassen Sie uns für einen Moment von den genauen Experimenten, die Sie durchgeführt haben, herauszoomen und darüber nachdenken, was das im weiteren Kontext bedeutet und was das für einige unserer Zuhörer bedeutet, wenn sie über ihre eigene Umgebung nachdenken und vielleicht noch keinen Zugang zu all diesen Frontier-Modellen haben? Ich denke, das Erste, woran mein Gehirn denkt, ist, ob diese Art von Fähigkeit nicht exklusiv für Netskope ist. Es gibt eine breite Liste von Organisationen, die Zugang zu diesen Modellen haben, und selbst die Modelle, die nicht als Frontier-Modelle gelten, werden immer cleverer.
0:26:17 Emily Wearmouth: Wenn diese Technik Ihnen also hilft, Fehler in Ihrem Code und Ihren Systemen zu finden und diese verfügbar sind oder ähnliche Tools für jeden verfügbar sind, was bedeutet das dann für das durchschnittliche Sicherheitsteam, das vielleicht kein Forschungsteam wie Ihres hat und auf der empfangenden Seite von anderen Menschen ist, die diese Systeme nutzen, um diese Probleme anzugreifen und zu finden? Wenn Sie diese Herausforderung betrachten, der sich die Branche stellen muss, wie sehen Sie sie?
0:26:47 Mohit Kulamkolly: Ja, was letztlich passieren wird, ist, dass die Modelle immer günstiger werden, weil es sich auch in Sicherheitsfragen weiterentwickelt. Ich denke also, was passieren wird, ist, dass einige der anderen Modelle jetzt auch auf Open-Source-Open-Weight-Modelle zugreifen können, um diese Dinge zu erforschen. Was ich jedem Sicherheitsforschungsteam empfehlen würde, was auch immer es versucht und anfangen möchte, ist, diesen KIs die richtigen Werkzeuge zu geben. Und die richtigen Werkzeuge, die du der KI gibst, desto mehr wirst du überrascht sein und desto mehr kann sie alleine erkunden, um diese Dinge herauszufinden. Anstatt es also als komplexes Werkzeug zu betrachten, das nötig ist, um es mit einem anderen vorhandenen Werkzeug zu verbinden.
0:27:42 Mohit Kulamkolly: Angenommen, du brauchst einen MCP-Server, der verwendet werden muss, um ein Tool daran zu verbinden, aber dafür hast du keinen MCP-Server. Du musst es also von Grund auf neu schreiben und dann darauf aufbauen. Das ist also eine Lernkurve, die du vielleicht überwinden musst, um diese Seite zu erreichen. Stell dir das also so vor, als ob selbst der MCP-Server nur die APIs ist, die offengelegt werden, du verbindest ihn nur mit KI, das ist alles. Es ist also nur einfacher Code. Versuch das herauszufinden. Und wenn du dein Tool verbinden kannst, wenn nicht, kannst du dich mit den Tools verbinden, musst du anfangen, selbst zu schreiben oder KI nutzen. Auf diese Weise, sobald du anfängst, den Werkzeugen die sensorischen Dinge zu geben, die Augen, Nase, Ohren. Und sobald du das hast, sobald du all diese Informationen hast, beginnen die Werkzeuge zu verarbeiten oder die KI beginnt, die Informationen so zu verarbeiten, wie du es möchtest, und dann liefert sie dir bessere Ergebnisse.
0:28:37 Mohit Kulamkolly: Also ja, so sehe ich das.
0:28:40 Emily Wearmouth: Glauben Sie, dass ein solcher Ansatz die Art und Weise, wie Software- oder Technologieunternehmen ihre Software ausliefern, wesentlich verändern wird? Wird sich dadurch die Zeitlinien ändern? Wird das die Erwartungen oder die Kosten verändern? Was denken Sie, könnten diese Implikationen sein?
0:28:57 Mohit Kulamkolly: Ganz bestimmt. Also ja, wie gesagt, was passieren wird, ist, dass Sicherheitslücken immer billiger zu entdecken werden, je weiter die KI voranschreitet. Was also passieren wird, ist, dass die Reparatur teurer wird. Bei dem aktuellen Tarif liefern wir die Software aus. Die Behebung dieser Schwachstellen wird also teuer und dann schwerer umzusetzen. Wenn wir also so haben, wie Netskope das schon vor der Zeit hat, als KI es hatte, haben wir unser eigenes SDLC für die Entwicklung. Deshalb ist Software kein zweiter Gedanke. Es tut mir leid, die Sicherheit ist aber nicht die zweite Stelle. Es ist ein Gedanke, der zunächst von deinem Whiteboard kommt, wenn du anfängst, über ein Produkt selbst nachzudenken. Wenn Sie also diesen Ansatz verfolgen, bitten Sie die KI, ein Bedrohungsmodell für ein Produkt zu erstellen, direkt nachdem Sie ein PRD oder ein Produktanforderungsdokument erstellt haben.
0:29:54 Mohit Kulamkolly: Das allein gibt Ihnen eine Vorstellung davon, was Sie erwarten können, während Sie das Produkt selbst entwickeln. Also mehr Inhaltskontext für die KI – jedenfalls wird KI diese Sachen bauen. Sie können der KI mehr Kontext geben, damit solche Schwachstellen in der späteren Phase Ihrer Software nicht mehr existieren.
0:30:08 Emily Wearmouth: Das ist eine wirklich interessante Idee, denn durch diese Experimente hat man etwas, das bereits in all seiner Komplexität gebaut war, genommen und KI gebeten, Probleme zu finden. Aber du schlägst vor, dass du diese Systeme tatsächlich nutzen könntest, wenn du nur ein Produktkonzept und einige Skizzen hast, wie die Architektur aussehen könnte, und die KI-Systeme dazu bringen, Löcher in deinen Plänen zu finden, damit diese Sicherheitsstrenge wirklich von Anfang an läuft. Du musst keine Zeit und Mühe investieren, um etwas zu bauen, das vielleicht nicht funktioniert. Du kannst anfangen, Probleme zu finden, bevor sie existieren.
0:30:45 Mohit Kulamkolly: Genau, genau. Genau.
0:30:47 Emily Wearmouth: Daran hatte ich gar nicht gedacht. Wenn also ein Sicherheitsteam etwas tun will, und ich denke, speziell ein Sicherheitsteam, das für einen Teil einer digitalen Eigenschaft verantwortlich ist, könnte das daran liegen, dass es ein Anbieter ist oder daran, dass es private Anwendungen und private Elemente innerhalb seines Stacks baut. Wenn sie so etwas zum ersten Mal machen wollten, was ist der allererste Schritt, bei dem du befürchten könntest, dass sie sie überspringen könnten, dass du sie einfach zurückziehen möchtest? Sie haben ein wenig über einige Dinge gesprochen, die sie selbst anfangen könnten. Was willst du hochhalten, aber zuerst das hier machen?
0:31:26 Mohit Kulamkolly: Ja. Okay. Nein, das ergibt Sinn. Was ich besonders bei diesen Erkenntnissen empfinde, ist, dass KI, denken wir gar nicht erst an den halluzinierenden Teil. Angenommen, die KI findet alle Schwachstellen. Wenn die KI also 20.000 Schwachstellen finden kann, ist es nicht richtig, diese 20.000 Erkenntnisse Ihren Entwicklern vorzuwerfen und zu sagen: Bitten Sie sie, es einfach zu beheben. Das ist also das Einzige, worauf wir achten sollten. Schwachstellen zu finden ist das eine, aber ein Sanierungsplan dafür ist ein weiterer wichtiger Faktor. Bevor wir also überhaupt diese Schwachstellen einbauen, müssen Sie mit Ihrem Entwickler sprechen, um zu verstehen, wo wir die Schwachstellen betrachten sollten und welche Schlüsselfaktoren dort sind. Nur wenn man diese Synergie hat, sind diese Schwachstellen ebenfalls nützlich. Sonst stapelt es sich einfach auf Ihrer langen Liste von Schwachstellen als nicht behoben, 20.030.000 Stück.
0:32:26 Mohit Kulamkolly: Das ist also das Einzige, was ich im Kopf habe, bevor ich tiefer in diese ausgefallenen Werkzeuge einsteige oder beginne, sie zu benutzen.
0:32:34 Emily Wearmouth: Das ist ein guter Punkt. Also ja, bearbeite alle Details dessen, was du tust, und die richtige Strenge, Schutzmechanismen und Herangehensweise, aber überlege ein bisschen heraus und überlege, welchen Einfluss dein Programm auf andere haben wird, und fang nicht einfach an, die Warteschlange von jemand anderem um das 500-fache zu erhöhen, nur weil er dich dafür nicht mögen wird.
0:32:54 Mohit Kulamkolly:Genau.
0:32:56 Emily Wearmouth: Brillant. Nun, Mohit, vielen Dank, dass du heute mit mir darüber gesprochen hast. In dem Moment, als ich die Artikel gelesen habe, wusste ich, dass ich dich auf die Bühne bekommen muss, deshalb schätze ich es sehr, dass du dir die Zeit genommen hast. Und ich habe auch das Gefühl, dass dies nicht dein letztes Experiment ist. Wir sagten, es sei Phase eins und Phase zwei, und ich sehe am Glitzern in deinen Augen, dass vielleicht schon eine dritte Phase stattfindet. Wohin sollten unsere Zuhörer also gehen, um mit Ihrer Arbeit und den Entdeckungen, die Sie machen, Schritt zu halten?
0:33:23 Mohit Kulamkolly: Klar. Ja. Der Großteil dieser Arbeit wird auf dem Lens-Blog auf der Netskope-Website selbst dokumentiert. Und ja, falls es noch etwas anderes gibt, werden wir es auch auf den Community-Seiten von Netskope veröffentlichen. Aber ja, es werden noch mehr Dinge für diese Tests kommen.
0:33:41 Emily Wearmouth: Fabelhaft. Ich denke, wir müssen dich vielleicht wieder in den Podcast holen und davon hören, sobald sie passieren. Vielen Dank, Mohit.
0:33:47 Mohit Kulamkolly: Danke, Emily.
0:33:48 Emily Wearmouth: Sie haben den Security Visionaries Podcast gehört, und wenn Ihnen diese Folge gefallen hat, empfehle ich Ihnen auf jeden Fall, unseren Backkatalog durchzustöbern, den Sie auf einer Ihrer Lieblingspodcast-Plattformen finden können. Und unsere neueren Episoden sind auch auf YouTube verfügbar, falls ihr unsere lächelnden Gesichter sehen wollt, während wir mit euch sprechen. Also genießt das, und wir sehen uns beim nächsten Mal.
){kind=icon}
