Lapsus$-Hacks: Stellungnahmen von Okta und Microsoft

[English]Gestern wurden gleich zwei Hacks von Big Playern der IT-Szene durch die Lapsus$-Gang bekannt. Die Gruppe reklamierte einen Hack des Authentifizierungsdiensts OKTA, was möglicherweise Kunden betrifft. Und Microsoft untersucht Berichte, nach denen 37 GByte an Daten (Quellcodes, Zertifikate etc.) von Microsoft Bing, Bing Maps, Cortana etc. durch die Lapsus$-Gruppe veröffentlicht wurden. Beide Firmen haben jetzt Stellungnahmen veröffentlicht.

Der Hack bei Okta

Gestern hatte ich im Artikel Authentifizierungsdienst OKTA durch Lapsus$ gehackt? berichtet, dass der US-Authentifizierungsdienst OKTA den Verdacht untersucht, dass man durch die Lapsus$-Gruppe gehackt worden sei. Inzwischen gibt es von David Bradbury, Chief Security Officer bei Okta, folgende Stellungnahme vom 22. März 2022 zum Hack.

Updated Okta Statement on LAPSUS$

The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers.

In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider. As part of our regular procedures, we alerted the provider to the situation, while simultaneously terminating the user's active Okta sessions and suspending the individual's account. Following those actions, we shared pertinent information (including suspicious IP addresses) to supplement their investigation, which was supported by a third-party forensics firm.

Following the completion of the service provider's investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer's laptop. This is consistent with the screenshots that we became aware of yesterday.

The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases. Support engineers do have access to limited data – for example, Jira tickets and lists of users – that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords.

We are actively continuing our investigation, including identifying and contacting those customers that may have been impacted. There is no impact to Auth0 customers, and there is no impact to HIPAA and FedRAMP customers.

We take our responsibility to protect and secure our customers' information very seriously. We are deeply committed to transparency and will communicate additional updates when available.

Es wird also angegeben, dass Okta als Dienst nicht nicht angegriffen wurde und weiterhin voll funktionsfähig sei. Es gäbe keine Korrekturmaßnahmen, die von unseren Kunden ergriffen werden müssten. Im Januar 2022 entdeckte Okta einen erfolglosen Versuch, das Konto eines Kundensupportingenieurs zu kompromittieren, der für einen Drittanbieter arbeitet. Es gab, laut Stellungnahmen, ein fünftägiges Zeitfenster zwischen dem 16. und 21. Januar 2022, in dem ein Angreifer Zugriff auf den Laptop eines Support-Technikers (nach meinen Informationen aus Costa Rica) hatte. Die Zeitangabe Januar 2021 deckt sich mit meinen Ausführungen im Artikel Authentifizierungsdienst OKTA durch Lapsus$ gehackt? – wobei mir unklar ist, wie die Aussage "erfolgloser Versuch, Konto zu kompromittieren" und "Zugriff auf den Laptop des Support-Technikers" zusammen passt. Und die Aussage Oktas, dass Lapsus$ keinen Zugriff auf den Dienst gehabt habe, ist mir Vorsicht zu genießen (Pfeifen im Wald). Die Lapsus$-Gruppe hat eine Gegendarstellung gepostet, die auf dieser Webseite zu finden ist.

Lapsus$ gibt an, einen Thin Client kompromittiert zu haben, so dass man Zugriff auf ein Super User Portal gehabt habe. Dort habe die Möglichkeit bestanden, die Kennwörter und Multi Factor Authentifizierung von 95% der Kunden zurückzusetzen. Da scheint also noch was zu kommen – die gesamten Screenshot der Lapsus$-Posts lassen sich auf dieser Webseite nachlesen.

Bei Bleeping Computer hat man die Erkenntnisse in diesem Artikel zusammen getragen – CloudFlare war einer der betroffenen Okta-Kunden. Die verwenden, laut deren Stellungnahme, Okta für die interne Authentifizierung. Da es den Anschein hatte, dass ein Okta-Support-Mitarbeiter mit Zugriff auf Dinge wie das Zurücksetzen eines Passworts für ein Okta-Kundenkonto kompromittiert worden war, hat CloudFlare wir beschlossen, alle Mitarbeiterkonten zu überprüfen, die seit dem 1. Dezember bis heute ihr Passwort zurückgesetzt oder ihre Multi-Faktor-Authentifizierung (MFA) in irgendeiner Weise geändert haben. Seit dem 1. Dezember 2021 hatten 144 Cloudflare-Mitarbeiter ihr Passwort zurückgesetzt oder ihre MFA geändert. CloudFlare hat für alle betroffenen Konten einen Passwort-Reset erzwungen und die Mitarbeiter über die Änderung informiert. Die CloudFlare-Stellungnahme ist ganz lesenswert.

In diesem Tweet hat jemand einen Quick-Check gepostet, wie Okta-Kunden testen können sollen, ob sie  durch diesen Hack kompromittiert wurden. Die Logs sind auf "Impersonation Grant"-Ereignisse zu überprüfen. Dies wird protokolliert, wenn jemand die Funktion "Okta-Support-Zugang" ausschaltet (diese sollte immer deaktiviert sein, es sei denn, sie wird JIT benötigt).

Stellungnahme von Microsoft

Gestern hatte ich zudem im Artikel Lapsus$ veröffentlicht angeblich Quellcode von Microsoft Azure, Bing und Cortana berichtet, dass die Lapsus$-Gruppe angibt, Daten und Quellcodes diverser Microsoft-Produkte erbeutet zu haben. Es soll sich um 37 GByte an Daten (Quellcodes, Zertifikate etc.) von Microsoft Bing, Bing Maps, Cortana etc. handeln, die nun durch die Lapsus$-Gruppe veröffentlicht werden. Microsoft hat nun ebenfalls Stellung bezogen, wie nachfolgender Tweet zeigt.

In diesem Artikel erklärt sich Microsoft recht länglich, wie die Lapsus$-Angreifer vorgehen. In der Textwüste findet sich dann der Hinweis, dass Lapsus$ behaupte, Zugriff auf Microsofts Repository gehabt und Daten abgezogen zu haben. Das "Beef" findet sich in folgender Passage:

Our investigation has found a single account had been compromised, granting limited access. Our cybersecurity response teams quickly engaged to remediate the compromised account and prevent further activity. Microsoft does not rely on the secrecy of code as a security measure and viewing source code does not lead to elevation of risk. The tactics DEV-0537 used in this intrusion reflect the tactics and techniques discussed in this blog. Our team was already investigating the compromised account based on threat intelligence when the actor publicly disclosed their intrusion. This public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact.

Die interne Untersuchung hat ergeben, dass ein einzelnes Konto kompromittiert wurde, das nur begrenzten Zugang gewährte. Microsofts Cybersecurity-Reaktionsteams hätten schnell gehandelt, um das kompromittierte Konto zu bereinigen und weitere Aktivitäten zu verhindern. Und Microsoft verlässt sich nicht auf die Geheimhaltung von Code als Sicherheitsmaßnahme, und die Einsicht in den Quellcode führt nicht zu einer Erhöhung des Risikos, so die Aussage aus Redmond. Sollten aber Entwickler-Zertifikate entwendet worden sein, wie es heißt, wäre das eher nicht so lustig, schätze ich mal. Die Kollegen von Bleeping Computer machen sich hier auch so ihre Gedanken.

Ähnliche Artikel:
Nvidia-Hack: Daten und Source-Code offen gelegt, Zertifikate gestohlen
Ubisoft durch Lapsus$-Cyber-Gang gehackt (März 2022)
Samsung bestätigt Hack, Quellcodes durch Lapsus$ geleakt
Authentifizierungsdienst OKTA durch Lapsus$ gehackt?
Lapsus$ veröffentlicht angeblich Quellcode von Microsoft Azure, Bing und Cortana