Wenn der Sicherheitsvorfall eines Anbieters zu Ihrem wird: Lehren aus dem Klue-Vorfall

Es gibt eine unbequeme Wahrheit, mit der jedes Sicherheitsteam früher oder später konfrontiert wird: Der Sicherheitsvorfall, der Ihnen am meisten schadet, muss sich nicht einmal innerhalb Ihrer eigenen Systeme ereignen. Sie können Ihren Code patchen, Ihre Secrets regelmäßig rotieren und Ihre Perimeter absichern – und trotzdem eines Morgens feststellen, dass ein Vorfall eingetreten ist, weil ein System betroffen ist, das Ihnen nicht gehört.

So lässt sich der Vorfall rund um Klue beschreiben. Die Plattform für Marktinformationen wird von zahlreichen Unternehmen für Wettbewerbsanalysen genutzt. Nach den öffentlich bekannt gegebenen Informationen kompromittierte ein Angreifer das Backend von Klue und nutzte diesen Zugang, um in die verbundenen Systeme von Klue-Kunden vorzudringen – darunter auch Salesforce-Umgebungen, die diese Kunden in die Plattform integriert hatten. Auch andere Sicherheitsanbieter wie Recorded Future, Tanium, Huntress und Jamf waren betroffen und haben öffentlich über den Vorfall informiert. Es lohnt sich, genauer hinzusehen, denn der Ablauf zeigt anschaulich, wie moderne Software-as-a-Service- (SaaS-)Ökosysteme kompromittiert werden können.

Der Ablauf des Vorfalls

Den bisher veröffentlichten Informationen zufolge lief die Angriffskette ungefähr so ab:

Der Angreifer verschaffte sich zunächst mit einem älteren Zugangsschlüssel Zugriff auf Klue. Dieser wurde Berichten zufolge irgendwann für einen Integrationsprototyp erstellt, der später aufgegeben wurde, aber nie deaktiviert worden war. Der Zugang bestand also weiter, obwohl das Projekt, für das er eingerichtet worden war, längst beendet war. Ein Angreifer fand den Schlüssel – und er funktionierte noch.

Von dort aus gelangte der Angreifer zu dem Teil der Klue-Infrastruktur, der die Plattform mit den Tools der Kunden verbindet. Für diese Verbindungen werden OAuth-Tokens genutzt: dauerhafte Berechtigungen, mit denen Klue im Auftrag der Kunden Daten aus Systemen wie Salesforce lesen und in diese schreiben kann. Der Angreifer schleuste Code ein, der diese Tokens abfangen sollte. Mit den Tokens musste er nicht mehr in jedes Kundenkonto einzeln eindringen. Er konnte sich als das entdeckte Dienstkonto authentifizieren, mithilfe des in der Integration hinterlegten Secrets direkt die Customer-Relationship-Management-Daten (CRM-Daten) der Kunden abfragen und anschließend exfiltrieren. Es folgten Erpressungsversuche.

Lässt man die Einzelheiten beiseite, bleibt ein bekanntes Muster: ein schwaches Glied, geliehene Schlüssel und ein Schadensradius, der sich auf alle nachgelagerten verbundenen Systeme erstreckt. Ein einzelner Sicherheitsvorfall blieb nicht auf ein Unternehmen begrenzt. Er breitete sich weiter aus.

Ein Hinweis zu Snyk

Im Sinne der Transparenz, die wir von jedem Anbieter erwarten, möchten wir offen sein: Snyk gehörte zu den Organisationen, die vom Klue-Vorfall betroffen waren. Unsere Untersuchung zeigt, dass sich die Auswirkungen nach aktuellem Kenntnisstand hauptsächlich auf geschäftliche Datenfelder in den Salesforce-Umgebungen beschränkten. Dazu gehörten geschäftliche Kontaktinformationen von Kunden sowie ausschließlich Titel und Beschreibung einer begrenzten Anzahl von Kunden-Supportfällen. Die Inhalte der Supportfälle waren nicht betroffen, ebenso wenig die Produkte von Snyk. Unsere Fähigkeit, unsere Kunden zu unterstützen, war nicht beeinträchtigt.

Nach der Benachrichtigung deaktivierten wir die Klue-Integration in Salesforce, leiteten eine eigene Untersuchung ein und bezogen die zuständigen Stellen ein. Den aktuellen Status und die neuesten Informationen finden Sie unter status.snyk.io oder im Snyk Trust Center. Wir halten beide Seiten auf dem Laufenden, während unsere Untersuchung weitergeht.

Wenn Sie über unsere eigene Situation hinaus eine Sache mitnehmen, dann diese: Prüfen Sie, welche Schlüssel Sie vergeben haben – und welche Sie längst vergessen haben.