Die Treuhandfalle in IA-Fähigkeiten: wenn ein scheinbar inokuliertes Geschick ein Tor zu Ihren Systemen wird

Eine Sicherheitsfirma, AIR, zeigte eine strukturelle Schwäche im "Skills"-Ökosystem für IA-Agenten: Sie schaffte ein scheinbar harmloses Geschick namens Brandingpage, er hat es in ein beliebtes Repository hochgeladen, um seine Sterne von GitHub zu erben, eine Anzeige auf Instagram veröffentlicht und, nach seinem Bericht, erreichte Zehntausende von Agenten - einschließlich einige registriert in Unternehmenskonten - ohne jeden Scanner markiert es als schädlich.

Der technische Trick, den sie ausgenutzt haben, ist einfach und alt in der Software-Sicherheit: der Scanner überprüft das Paket, das Ihnen geliefert wird (die Dateien, die mit der Fertigkeit kommen), aber die Fähigkeit kann auf externe Dokumentation oder Skripte, die in der Zeit der Installation heruntergeladen werden. AIR ließ zunächst einen Link zu legitimer Dokumentation, um die Überprüfung zu übergeben, und nachdem die Fähigkeit ausreichend verbreitet hatte, änderte sie den Linkinhalt auf Anweisungen, die ein Skript ausführen möchten. In seinem Test gab die Nutzlast nur Postadressen an Zähleinrichtungen zurück, aber der Vektor könnte dazu dienen, Dateien zu lesen, exfiltrierte Daten oder seitlich nach den Berechtigungen des Agenten bewegt haben.

Dies ist keine isolierte Überraschung: andere Forscherteams, wie Trail of Bits, haben gezeigt, wie Könnenscanner mit der gleichen Technik verspottet werden können, um den analysierten Inhalt von dem zu trennen, was der Agent tatsächlich in Laufzeit herunterlädt. Das Problem ist kein rechtzeitiger Fehler, sondern ein Vertrauen Modellausfall: Es wird angenommen, dass ein verifiziertes Geschick mit externen Anzeichen von Legitimität (Stern, erkanntes Repository, sauberes Scannen) harmlos bleibt, wenn es tatsächlich die Inhalte ändern kann, die es nach der Überprüfung läuft.

Die Auswirkungen auf Unternehmen und Sicherheitsbeamte sind klar und tiefgreifend. Ein Agent, der eine Fertigkeit betreibt, wirkt oft mit dem Kontext und den Berechtigungen des Benutzers oder einem automatisierten System; das bedeutet, dass ein schädliches oder manipuliertes Geschick eine Tür zu internen Ressourcen werden kann. Öffentliches Vertrauenssignal ersetzt nicht kontinuierliche technische Kontrollen.

Für Organisationen, die bereits Agenten eingesetzt haben, sollte die erste Priorität darin bestehen, zu identifizieren, welche Fähigkeiten in Unternehmenskonten installiert sind, zu überprüfen, welche externen Domains und URL konsultiert werden, und diejenigen zu blockieren oder zu vervierfachen, die nicht durch zentrale Kontrollen durchgeführt wurden. Die rechtzeitige Überprüfung zum Zeitpunkt der Installation reicht nicht aus; bei der Änderung der Remote-Ressourcen ist eine Überwachung und Überprüfung erforderlich.

In betrieblicher Hinsicht sollten Fähigkeiten als Software von Drittanbietern behandelt werden, nicht als Textfragmente. Dies erfordert Maßnahmen, die über den typischen statischen Scan hinausgehen: Klicken Sie auf Versionen(bei unterzeichneten nichtmutbaren Geräten oder bestimmten Verpflichtungen) verlangen, dass jeder ausführbare Code innerhalb des geprüften Pakets oder in einem nichtmutbaren Speicher (Releases with hash) zu gehen, das Prinzip anzuwenden weniger Privilegien und das Netzwerk von Agenten durch Proxy- oder DNS-Filter begrenzen, die Downloads von nicht genehmigten Domains vermeiden.

Marktplätze und Agentenplattform-Anbieter müssen auch technische Verantwortung übernehmen: nicht nur das gelieferte Paket, sondern auch die Domains und Endpunkte, die die Fertigkeit erklärt, Unterschriften und reproduzierbare Manifeste zu verlangen, automatische Re-Scan-Kontrollen beim Ändern externer Ressourcen anzubieten und dem Endbenutzer vor der Installation detaillierte Berechtigungen zur Verfügung zu stellen. Ohne diese Veränderungen wird sich das Ökosystem weiterhin auf zerbrechliche Signale wie GitHub-Stars oder ein zeitnahes Scanergebnis verlassen.

Nicht alles im AIR-Bericht kann ohne unabhängige Überprüfung auf den Grund des Briefes genommen werden: Die Zahl der "26.000 Agenten" und bestimmte absolute Kontrollszenarien sind Ansprüche des Unternehmens selbst, die auch einen in seiner Erklärung verwalteten Markt bekannt geben. Trotzdem. das Verfahren sie zeigten, und die strukturelle Schwäche, die sie aussetzt, werden auf der Grundlage früherer Tests und Fremdanalysen unterstützt.

Aus defensiver Sicht umfassen konkrete und erzielbare Empfehlungen: Auditing und Erfinder von installierten Fähigkeiten, Zentralisierung der Zulassung neuer Fähigkeiten in einem kontrollierten Einzelfenster, Anwendung von Inspektion und Sperrung von Egress, Notwendigkeit von unmutbaren und unterzeichneten Artefakten in Paketen, automatisch Neubewertung von Fähigkeiten gegen Änderungen ihrer externen URLs und Minimierung der Genehmigungen, die ein Können erhalten kann. Diese Maßnahmen beseitigen nicht das Risiko, sondern ändern die Angriffsdynamik und erhöhen die Betriebskosten für einen Angreifer.

Der Vorfall ist auch ein Aufruf an die Industrie: Lieferanten von Agenten und Markplätzen müssen ihre kontinuierlichen Validierungsprozesse verbessern und Werkzeuge für Organisationen zur Durchsetzung der Sicherheitspolitik bereitstellen. In der Zwischenzeit sollten Sicherheitsausrüstung und IT-verantwortliche sich nicht auf öffentlich sichtbare Metriken als Ersatz für die technische Kontrolle verlassen. Um weiter über technische Risiken und Software-Sicherheitsaudits zu erfahren, bieten Ressourcen wie der Trail of Bits Blog ausführliche Analysen an https: / / blog.trailofbits.com, und Versorgungskettensicherheitsprojekte wie OWASP enthalten Leitlinien für diesen Zusammenhang https: / / owasp.org.