Was passiert, wenn ein KI-Unternehmen Opfer einer Sicherheitslücke in der Software-Lieferkette wird?

Alle Beiträge

Am 20. März hat OpenAI das beliebte generative KI-Tool ChatGPT für einige Stunden lahmgelegt. Es später zugelassen dass der Grund für den Ausfall eine Sicherheitslücke in der Software-Lieferkette war, die ihren Ursprung in der Open-Source-In-Memory-Datenspeicherbibliothek hatte.Redis'.  

Aufgrund dieser Sicherheitslücke gab es ein Zeitfenster (zwischen 1 und 10 Uhr PST am 20. März), in dem Benutzer versehentlich auf die Chatverlaufstitel anderer Benutzer und möglicherweise offengelegte zahlungsbezogene Informationen wie Namen, E-Mail-Adressen und Zahlungsadressen zugreifen konnten , Kreditkartentyp und die letzten vier Ziffern der Zahlungskartennummer. 

Dabei handelte es sich um einen relativ kleinen Fehler, der schnell erkannt und behoben wurde. Angesichts der steigenden Beliebtheit von ChatGPT und anderen generativen LLM-Lösungen: Was könnten die Folgen einer gezielteren Lösung sein? Angriff auf die Software-Lieferkette?  

In diesem Artikel untersuchen wir, was genau am 20. März passiert ist und wie die Benutzerinformationen offengelegt wurden. Wir werden auch eine kurze imaginäre Reise in einen potenziell schwerwiegenderen Angriff unternehmen und sehen, welche Informationen offengelegt werden können und was getan werden kann, um solche Fälle zu verhindern. Wir schließen mit ein paar allgemeinen Themen ab Sicherheit der Software-Lieferkette Vorschläge, die unabhängig von der Software, an der Ihr Unternehmen arbeitet, relevant sein können. 

Folgendes ist passiert

Wie fast jedes andere Softwareunternehmen ist der Code von OpenAI zu einem nicht geringen Teil auf Open-Source-Bibliotheken und -Code angewiesen. In diesem Fall wurde der Fehler in der Open-Source-Bibliothek des Redis-Clients entdeckt. redis-py. Hier ist die Fehlerbeschreibung, wie sie im firmeneigenen Dokument erscheint erzählen:

  • OpenAI verwendet Redis, um Benutzerinformationen auf seinem Server zwischenzuspeichern, sodass nicht bei jeder Anfrage die Datenbank überprüft werden muss. 
  • Um diese Last auf mehrere Redis-Instanzen zu verteilen, werden Redis-Cluster verwendet. 
  • Die redis-py-Bibliothek wird als Schnittstelle zu Redis vom Python-Server des Unternehmens verwendet, der mit läuft Asyncio
  • Die Bibliothek unterhält einen gemeinsamen Pool von Verbindungen zwischen dem Server und dem Cluster und recycelt eine Verbindung, um sie nach Abschluss für eine andere Anfrage zu verwenden.
  • Bei Verwendung von Asyncio verhalten sich Anfragen und Antworten mit redis-py wie zwei Warteschlangen: Der Anrufer schiebt eine Anfrage an die eingehende Warteschlange, erscheint eine Antwort vom ausgehende Warteschlange, und gibt dann die Verbindung zum Pool zurück.
  • Angenommen, eine Anfrage wird abgebrochen, nachdem sie in die Eingangswarteschlange verschoben wurde, aber bevor die Antwort aus der Ausgangswarteschlange erscheint. In diesem Fall sehen wir unsere Fehler: Die Verbindung wird beschädigt und die nächste Antwort, die für eine nicht verwandte Anfrage abgerufen wird, kann in der Verbindung zurückgebliebene Daten empfangen. 
  • In den meisten Fällen führt dies zu einem nicht behebbaren Serverfehler und der Benutzer muss seine Anfrage erneut versuchen. 
  • In einigen Fällen stimmen die beschädigten Daten jedoch zufällig mit dem Datentyp überein, den der Anforderer erwartet hatte, und daher erscheint das, was aus dem Cache zurückgegeben wird, gültig, auch wenn es einem anderen Benutzer gehört.
  • Am Montag, dem 1. März, um 20 Uhr morgens pazifischer Zeit führte OpenAI versehentlich eine Änderung an seinem Server ein, die zu einem Anstieg der Abbrüche von Redis-Anfragen führte. Dies führte zu einer höheren Wahrscheinlichkeit als üblich, dass jede Verbindung fehlerhafte Daten zurückgab.

Dieser spezielle Fehler trat nur im Asyncio redis-py-Client für Redis Cluster auf und wurde seitdem durch gemeinsame Arbeit der OpenAI-Ingenieure und der Betreuer der Redis-Bibliothek behoben. 

Zur Erinnerung: Dieser Fehler könnte versehentlich den Suchtitel eines anderen aktiven Benutzers und einen Teil der Zahlungsinformationen dieses Benutzers offenlegen. Einige Benutzer geben ChatGPT jetzt die vollständige oder teilweise Kontrolle über ihre persönlichen Daten Finanzen, was die Offenlegung dieser Informationen möglicherweise katastrophale Folgen hätte.

Folgendes könnte passieren

In diesem Fall war der Software-Lieferkettenfehler, den OpenAi von der Open-Source-Bibliothek Redis geerbt hatte, relativ einfach und leicht zu beheben. Ich möchte Sie bitten, sich ein schwerwiegenderes Szenario vorzustellen, nämlich einen gezielten Angriff auf die Software-Lieferkette, ähnlich dem, den wir erlebt haben SolarWinds findet statt und bleibt über einen längeren Zeitraum, sagen wir Monate, unentdeckt.

Da Benutzer OpenAI jetzt für einen direkteren Zugriff auf ihr LLM bezahlen, könnte ein solcher Angriff möglicherweise die Kundeninformationen einschließlich ihrer Zahlungsdaten preisgeben. Aber das sind nicht wirklich die Informationen, an denen unsere hypothetische Hackergruppe interessiert ist. ChatGPT verfügt derzeit darüber 1.16 Milliarden Benutzer. Im März 1 wurde die Marke von 2023 Milliarde Nutzern überschritten. Diese Zahlen stellen einen Anstieg von fast 55 % von Februar 2023 bis März 2023 dar. Da mittlerweile zahlreiche Menschen generative KI für alles nutzen, von Kunst über Geschichtshausaufgaben bis hin zu Finanzen, könnte der uneingeschränkte Zugriff auf die Datenbank von OpenAI Potenzial offenbaren Erpressungsinformationen über nicht gezählte Benutzer. Der Black Mirror Die Folge „Shut Up and Dance“ (Staffel 3, Folge 3, 2016) liefert ein ziemlich fantasievolles Ergebnis dafür, dass solche expliziten Informationen in die Hände skrupelloser Menschen gelangen. Wenn Sie nach einer realeren Parallele suchen, ist die Ashley Madison Datenverletzung aus dem Jahr 2015 hatte teilweise schwerwiegende Folgen, von denen einige auch Jahre später noch relevant sind.

Gehen wir in unserem fantasievollen Hack noch etwas weiter und sagen, dass diese namenlose Hackergruppe nicht nur Zugriff auf die OpenAI-Datenbank erhalten kann, sondern auch die Ergebnisse für Anfragen beeinflussen kann. Können Sie sich das Potenzial vorstellen, das darin besteht, dass Millionen von Menschen gezielte, maßgeschneiderte Finanzberatung von einer Hackergruppe erhalten? Oder Sie erhalten von unserer mysteriösen Hackergruppe falsche Informationen zu Sicherheitsscans oder Codetests. Die Tatsache, dass ChatGPT jetzt auf das Internet zugreifen kann, macht es umso einfacher, Informationen, die auf den Servern von OpenAI ein- oder ausgehen, als normale, harmlose Daten zu verbergen.

Ich höre hier auf, aber ich denke, Sie erkennen den enormen potenziellen Schaden, den ein Software-Supply-Chain-Angriff auf ein erfolgreiches LLM anrichten kann.

So schützen Sie sich und Ihre Software-Lieferkette

Eines der ersten Dinge, die Sie tun können, um sich zu schützen, besteht darin, Ihr Misstrauen zu schärfen. Vertrauen Sie keinem Tool implizit, egal wie harmlos es erscheint, es sei denn, Sie können garantieren, dass Sie die volle Kontrolle darüber haben, was es tut, was es potenziell kann und auf welche Ressourcen es Zugriff hat. Die Option, eine Open-Source-Version von ChatGPT auszuführen örtlich kann Ihnen mehr Kontrolle über die Trainingsinformationen und die Zugriffsebene geben.

Als Softwareunternehmen, das das Potenzial aufmerksamer wahrnehmen möchte Risiken in der Software-Lieferkette Ich empfehle Ihnen, es sich anzusehen, da es über die verwendeten Open-Source-Pakete geerbt wird Scribes Lösung. Scribe hat eine Plattform entwickelt, die eine größere Transparenz Ihres gesamten SDLC in Bezug auf alle von Ihnen einbezogenen Pakete und übernommenen Pakete sowie alle Tests ermöglicht, die Sie unterwegs durchführen möchten. Die Plattform generiert eine SBOM für jeden Ihrer Builds und enthält alle gesammelten Sicherheitsinformationen für jeden Build an einem einzigen Ort. Es kann Ihnen auch sagen, ob Ihr Build mit SLSA bis Level 3 und mit NISTs SSDF kompatibel ist. Das neue Valint-Werkzeug auch ermöglicht es Ihnen, Verfassen Sie Ihre eigenen Richtlinien und wenden Sie sie auf jeden gewünschten Teil Ihrer Build-Pipeline an. Durch das Speichern aller Ihrer Sicherheitsinformationen an einem Ort, geordnet nach Builds im Laufe der Zeit, können Sie beobachten, wie sich Ihre Anwendung im Laufe der Zeit sowohl in Bezug auf ihre Abhängigkeiten als auch auf ihre Sicherheit verändert. 

Banner

Die Zukunft der KI 

KI wird bleiben, egal was wir tun. Das Ausmaß ihrer Einbindung in unser Alltagsleben ist Spekulation, aber allein auf der Grundlage der letzten sechs Monate scheint es sicher, dass wir vor einem möglichen Wendepunkt für die LLM-Technologie und ihre Anwendungen stehen. Da es bei der Erstellung von Code und kompletten Apps durch KI darum geht, die richtigen Eingabeaufforderungen in „natürlicher Sprache“ zu finden, stehen wir möglicherweise vor einer beispiellosen Flut von Anwendungen, die weder ordnungsgemäß getestet wurden noch über die richtigen Sicherheitsvorkehrungen zum Schutz beider Benutzer verfügen und die Menschen oder Unternehmen, die sie geschaffen haben. 

Später in diesem Monat wird Scribe eine veranstalten Webinar Wir beschäftigen uns speziell mit der Frage, ob Sie darauf vertrauen können, dass KI Ihnen beim Schutz Ihrer Software-Lieferkette hilft. Wenn Sie Fragen haben, die auf dem basieren, was Sie hier gelesen haben, wäre dies ein guter Ort und Zeitpunkt, diese zu stellen.

Da der Die Scribe-Plattform ist kostenlos Für bis zu 100 Builds pro Monat geeignet. Ich empfehle jedem von Ihnen, einem einzelnen Entwickler oder einem Unternehmen, es auszuprobieren und zu sehen, wie viele Ihrer Sicherheits- und Regulierungsanforderungen die Plattform erfüllt. Bis eines Tages ein wahrer Geheimdienst hinter unseren Bildschirmen auf uns hört, müssen wir andere Wege finden, um mit unserer eigenen Sicherheit umzugehen, und ich glaube, dass die Förderung von Sichtbarkeit als Vorläufer von Vertrauen ein guter Anfang ist.

Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.