Der Tresor hielt. Der Weg hinein war ein anderer.

LastPass wurde in diesem Monat erneut angegriffen. Das, wovor sich alle sträuben, ist nicht passiert. Kein Tresor wurde geknackt. Kein Master-Passwort ist abhandengekommen. Die verschlüsselten Geheimnisse blieben unangetastet. LastPass bestätigte, dass die eigenen "Produkte, Dienste und Infrastruktur nicht betroffen" waren und die Kundentresore "sicher blieben". [1]

Die Angreifer kamen dem Tresor nie nahe. Sie gingen durch einen Anbieter hinein.

Hier die Kette, denn der Mechanismus ist der eigentliche Punkt. Am 11. Juni verschaffte sich eine Gruppe, die sich Icarus nennt, Zutritt zu Klue, einer Plattform für Marktinformationen, die @LastPass intern nutzte. Der Einstieg erfolgte laut @HuntressLabs, die am Vorfall gearbeitet haben: "ein seit langem ungenutzter API-Zugang, der ursprünglich für ein aufgegebenes Prototyp einer Integration durch einen Drittanbieter angelegt worden war." [2] Ein Schlüssel für ein Projekt, das es nicht mehr gab, für einen Zweck, an den sich niemand erinnerte – weiterhin aktiv. Von Klue aus brachten sie Schadcode ein, der die OAuth-Token abgriff, die Klue für seine Kunden hielt: die dauerhaften Berechtigungen, mit denen es im Auftrag dieser Unternehmen @salesforce, Slack, HubSpot und mehr lesen durfte. Eines dieser Tokens gehörte LastPass. Damit lasen die Angreifer das Salesforce-CRM von LastPass. Namen, E-Mail-Adressen, Telefonnummern, Anschriften, Inhalte von Support-Fällen. Dann die Erpressungsnachricht. Zahlen, oder es landet auf der Leak-Seite.

LastPass war nicht der Einzige in der Reichweite. Huntress, Recorded Future, Tanium, Jamf, BeyondTrust. Sicherheitsunternehmen, die meisten davon. Leute, die das beruflich machen.

Das gehört aber auch gesagt: Die Kryptografie von LastPass hat genau das getan, was sie versprochen hat. Der Tresor ist nicht die Geschichte. Die Geschichte ist eine Art Geheimnis, die kaum jemand als Geheimnis behandelt: das langlebige Token in einer SaaS-Integration, der Sie einmal zugestimmt und danach nie wieder angesehen haben. Es läuft nicht ab. Es weiß nicht, dass es gestohlen wurde. Es gewährt weit mehr als den Grund, für den es angelegt wurde – und gewährt es still weiter, bis sich ein Mensch daran erinnert, es abzuschalten. Meist erinnert sich niemand.

Das ist die Verschiebung. Das Bedrohungsmodell ging von "können sie den Tresor knacken" zu "wie viele vergessene Schlüssel stecken in Türen, die Sie nicht mehr beobachten". Ein toter Zugang aus einem aufgegebenen Prototyp genügte, um an die Kundendaten mehrerer Unternehmen zu kommen. Die Mathematik war nie der schwache Punkt. Die Verstreutheit war es.

Genau dieses Versagen sollte ein Zugangsdatensatz ablehnen, wenn er darauf ausgelegt ist. Ein Geheimnis, das Clavitor ausstellt, ist kurzlebig und eng begrenzt. Es wird für genau einen Vorgang vermittelt, läuft von selbst ab und ist an die Maschine gebunden, die es verwendet hat, und dieser zugeordnet. Ein solches Token kann nicht zu dem werden, was hier den Schaden angerichtet hat: eine vergessene Berechtigung, lange nachdem sich jemand an ihre Existenz erinnerte, abgegriffen und von fremder Infrastruktur aus abgespielt, ohne dass irgendetwas sie einem Akteur zuordnet. Es ist verschwunden, bevor es gefunden werden kann, und es ist nie über seine eine Aufgabe hinausgegangen.

Eine Grenze sollte klar benannt werden. Clavitor verwaltet die Zugangsdaten, die es hält, nicht die dauerhafte OAuth-Berechtigung, die Sie an die Plattform eines Anbieters übergeben haben. Dieses Token liegt in deren System, unter deren Kontrollen, und kein Tresor greift hinein, um es für Sie ablaufen zu lassen. Was sich ändert, ist alles im Zuständigkeitsbereich von Clavitor. Es weigert sich, der Ort zu sein, an dem ein nie ablaufendes Geheimnis still liegen kann. Die Disziplin, deren Fehlen Klue öffnete (kurze Laufzeiten, enger Geltungsbereich, echte Zuordnung), ist hier Voreinstellung und keine Einstellung, an die sich jemand erinnern sollte.

Was bleibt, ist eine unbequeme Frage. Wie viele aktive Tokens liegen bei Anbietern, die Sie vor einem Jahr eingebunden haben und seither nicht mehr bedacht haben?

Wir haben die Handvoll Eigenschaften zusammengestellt, die ein Zugangsdatensatz haben sollte, bevor Sie ihm irgendetwas anvertrauen. [3]

Clavitor (@clavitorai) ist der Tresor für Zugangsdaten von KI-Agenten – und gegen sie. clavitor.ai

Quellen

[1] BleepingComputer, "LastPass confirms data breach in Klue supply chain attack" — @BleepinComputer

[2] Befunde zum Vorfall von Huntress, berichtet über Help Net Security, "Klue breach lead to Salesforce data theft, Huntress affected" — @HuntressLabs, @helpnetsecurity

[3] The Ten Rules of Credential Management (X-Artikel, originalsprachlich) — @clavitorai