LastPass-Hack über privaten PC eines Entwicklers

Sicherheit (Pexels, allgemeine Nutzung)[English]Der Anbieter LastPass wurde ja 2022 Opfer eines Hacks, bei dem Angreifer Zugriff auf seine Infrastruktur. Erst hieß es, die Entwicklungsumgebung sei "nur gehackt worden". Dann kam schrittweise das Ausmaß des Angriffs und eines zweiten Angriffs auf den Cloud-Dienst zur Verwaltung von Passwörtern heraus. Nun hat der Anbieter weitere Informationen offen gelegt, wie es zum 2. Hack kommen konnte. Der Angriff gelang wohl über einen kompromittierten Privat-PC eines Entwicklers, der als einer von vier Personen Zugriff auf die privaten Schlüssel des Unternehmens hatte.


Anzeige

Der LastPass-Hack

LastPass ist ein Dienst zur Speicherung seiner Passwörter und Zugangsdaten für Online-Konten – wobei diese Daten in einem Vault genannten Daten-Tresor in der Cloud abgelegt werden. Der Anbieter musste im August 2022 einen Sicherheitsvorfall melden, bei der die Entwicklungsumgebung gehackt wurde (siehe LastPass Sicherheitsvorfall: Entwicklungsumgebung gehackt (25. August 2022)). Die Angreifer hatten, so LastPass, vier Tage Zeit, sich im internen IT-Netzwerk umzusehen (siehe Links am Artikelende).

Im November 2022 wurde bekannt, dass LastPass Kundendaten nach dem Hack eines Cloud-Speicherdiensts entwendet werden konnten. am 20. Dez. 2022 gestand der Anbieter den nächsten Sicherheitsvorfall ein. Dem Angreifer war es gelungen, die verschlüsselte Vault-Datenbank mit den Nutzerdaten abzuziehen (siehe LastPass sagt, dass Hacker die verschlüsselte Vault Datenbank mit Nutzerdaten abgezogen haben). So langsam kommt nur heraus, dass der Hack über eine Verkettung unschöner Umstände möglich war.

Neue Erkenntnisse zum Hack

In einer neuen Veröffentlichung legt LastPass nun offen, wie der Hack gelingen konnte. Die Vermutung, dass mit dem ersten Hack im Augst 2022 Informationen erbeutet wurden, die für den zweiten Angriff benutzt werden konnten, bestätigt sich. Die Untersuchung ergab, dass der Bedrohungsakteur nach dem ersten Vorfall, der am 12. August 2022 endete, zu einer neuen Reihe von Erkundungs-, Aufzählungs- und Exfiltrationsaktivitäten überging, die auf die verwendete Cloud-Speicherumgebung ausgerichtet waren und sich vom 12. August 2022 bis zum 26. Oktober 2022 erstreckten.

Konkret war es so, dass beim ersten Hack verschlüsselte Zugangsdaten eines LastPass-Mitarbeiters erbeutet wurden. LastPass setzte zwar die Konten zurück und aktivierte auch die Protokollierungs- und Überwachungsfunktionen für Zugriffe. Aber die Angreifer verwendeten nun eine andere Taktik und kompromittierten den privaten PC eines LastPass-DevOps-Entwicklers, um dort einen KeyLogger zu installieren.

Insgesamt gab es nur vier DevOps-Entwickler bei LastPass, die Zugriff auf einen hochgradig eingeschränkter Satz gemeinsam genutzter Ordner in einem LastPass Passwortmanager-Tresor hatten. Der Ordner wurde von DevOps-Ingenieuren genutzt, um administrative Aufgaben in diesen Umgebungen durchzuführen.

Um den privaten PC des DevOps-Entwickler zu kompromittieren, wurde dessen System durch ein Mediensoftwarepaket eines Drittanbieters ausgenutzt. Über dieses Paket war eine Remote-Code-Ausführung möglicht, so dass ein Keylogger installiert werden konnte. Dadurch war der Angreifer in der Lage, das Master-Passwort des Mitarbeiters bei der Eingabe zu erfassen, und zwar, nachdem sich der Mitarbeiter mit MFA (Zweifaktor-Authentifizierung) authentifiziert hatte. Dadurch erhielt der Angreifer Zugriff auf den LastPass-Unternehmenstresor des DevOps-Ingenieurs.

Addendum: Gemäß einem arstechnica Artikel, der eine anonyme Quelle zitiert, war das angegriffene Media Software Paket Plex (siehe auch folgende Kommentare). Plex hatte selbst einen Netzwerk-Hack, wobei unklar ist, ob es eine Verbindung gibt.

Der Bedrohungsakteur exportierte dann die nativen Einträge des Unternehmenstresors und den Inhalt der freigegebenen Ordner. Diese enthielten die verschlüsselten sicheren Notizen mit Zugriffs- und Entschlüsselungsschlüsseln, die für den Zugriff auf die AWS S3 LastPass-Produktionsbackups, andere Cloud-basierte Speicherressourcen und einige damit verbundene kritische Datenbanksicherungen erforderlich waren. Damit hatten die Angreifer wohl den Jackpot und somit Zugriff auf die AWS S3-Cloud-Strukturen.

Auf Grund dieses Sachverhalts war es für die Forensik, die durch Mandiant-Spezialisten durchgeführt wurden, schwierig, die Details des Hacks nachzuvollziehen. Im aktuellen Beitrag beschreibt LastPass, welche Maßnahmen man alles ausgeführt habe, um die Sicherheit des Systems zu gewährleisten. Das Problem war aber, dass das Kind bereits beim ersten Hack in den Brunnen gefallen war und dann durch den Hack des privaten PCs des DevOps-Entwicklers erneut ins Wasser geworfen wurde. Brian Krebs schreibt in folgendem Beitrag:


Anzeige

LastPass hat weitere Details zu den beiden Einbrüchen im vergangenen Jahr bekannt gegeben, die auf denselben Angreifer zurückzuführen sind.

Es gibt hier eine Menge zu entpacken, aber dieses Detail über den Angriff auf einen LastPass DevOps-Mitarbeiter auf dessen Heimcomputer ist etwas ernüchternd.

Um dann die Kernaussagen aus obigem Text zu derivieren. Hätte der DevOps-Entwickler nur einen isolierten PC für den Zugriff auf die LastPass-Cloud-Struktur genutzt und keine weitere Software installiert, wäre der zweite Hack wohl nicht möglich gewesen.

LastPass Hack

Die Frage für LastPass-Benutzer ist nun, ob die erbeuteten Daten aus dem Passwort-Safe noch sicher sind. Diese liegen in der erbeuteten Datenbank in verschlüsselter Form vor. Mit der verwendeten Verschlüsselung (Password-Based Derivation Function 2, PBKDF2) ist dies auf den ersten Blick sehr schwierig, die Verschlüsselung zu knacken. Aber Sicherheitsforscher wiesen darauf hin, dass die Zahl der eingestellten Passwort-Iterationen für PBKDF2 eventuell entscheidend ist.

LastPass bietet eine Anleitung zur Überprüfung dieser Einstellung und verwendet einen Wert 100.100 als Standardeinstellung. Aber Nutzer berichten, dass sie dort den Wert 5.000 konfiguriert haben, manche setzten den Wert auf 500. Es gibt sogar Leute, die dort den Wert 1 für eine Wiederholung vorgegeben haben. Die Konten mit sehr geringen Werten für die PBKDF2 Passwort-Iterationen sind nun dem Risiko ausgesetzt, dass der Kennwort-Safe geknackt wird. Dann wären die Angreifer im Besitz aller Zugangsdaten dieses Benutzers.

Unter dem Strich ist es ein ziemlicher Schlamassel, der den Anbieter und seine Nutzer getroffen hat. Der Anbieter hat vermeidbare Sicherheitsrisiken in seinen Prozessen geduldet – die Nutzer haben ggf. zusätzlich für eine Schwächung der Passwort-Verschlüsselung gesorgt.

Ähnliche Artikel:
LastPass Sicherheitsvorfall: Entwicklungsumgebung gehackt (25. August 2022)
LastPass bestätigt: Angreifer hatten vier Tage Zugriff auf interne Systeme
LastPass-Kundendaten nach Hack eines Cloud-Speicherdiensts abgezogen (Nov. 2022)
LastPass sagt, dass Hacker die verschlüsselte Vault Datenbank mit Nutzerdaten abgezogen haben


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

15 Antworten zu LastPass-Hack über privaten PC eines Entwicklers

  1. Jonas92 sagt:

    Den Weg über den privaten PC finde ich schon fast Hollywoodreif, hier muss ja neben Hackfähigkeiten noch weiter "recherchiert" worden sein, damit man auf den privaten Computer eines Entwickler-Mitarbeiters kommt. Dass kann unmöglich der Hacker alleine gewesen sein, der selber wohl lieber still aus seinem Keller über seine "digitalen" Fähigkeiten agiert.

    Auf der anderen Seite zeigt sich auch hier, dass MFA nicht so sicher ist und man neben MFA auch nur die Anmeldung von "bekannten" oder besser konformen Geräten / Netzwerken / IP-Ranges in Kombination mit MFA erlauben sollte. Gerade bei so hochprivilegierten Entwicklern ein Muss und eigentlich stelle ich mir das so auch als Standard bei solchen Unternehmen vor.

    Man selber denkt immer "wao, die großen Unternehmen haben die finanziellen Mittel um jede "geile" Sicherheitssoftware bei Ihnen einzusetzen, wo man selber nur mit den Ohren schlackern würde".

    Aber dann zeigen solche Fälle einem, dass diese großen Unternehmen auch nur mit Wasser kochen und auch "schlampen" / man selber gar nicht so schlecht aufgestellt ist, wenn man sich einfach drum kümmert.

    Gruß Jonas

    • Jan sagt:

      Dein Absatz zu MFA ist so nicht richtig. MFA hat das ganze wunderbar abgesichert, der Angreifer hat aber alle Informationen nach der Authentifizierung lokal auf dem System abgezogen. MFA war hier nicht das Problem und hätte auch mit Deinen vorgeschlagenen Verbessearungen nix gebracht. Im Prinzip wurde dem Angreifer alles aufgeschlossen und er musste sich nur noch bedienen…

      Gruß,
      Jan

      • Jonas92 sagt:

        Hey Jan,
        ich lese aus dem Artikel heraus, dass "nur" ein Keylogger auf dem
        privaten Computer des Entwicklers installiert worden ist.

        Er hat dadurch auch das Masterpasswort mitlesen können.
        Aber worüber hat sich dann der Angreifer auf den
        Unternehmenstresor aufgeschaltet?

        Über den kompromittierten Computers des Entwicklers? -> Aber es war doch "nur" ein Keylogger installiert oder muss man davon
        ausgehen, dass nicht nur ein Keylogger auf dem privaten Computers des Entwicklers aktiv war? Womöglich RAT.
        Dann stimmt natürlich deine Einschätzung, da wohl der private Computer des Entwicklers in den Kreis der konformen Geräte / erlaubte Netzwerke
        zählte. & das war wohl der Fehler.

        Ansonsten hätte man die direkte Anmeldung an den Unternehmenstresor bei einem nicht konformen/bekanntem DrittGerät (Hier der PC/ die Umgebung des "Hackers") unterbunden,
        auch wenn das korrekte Masterpasswort vom Hacker verwendet wird.

      • RG sagt:

        Richtig, wobei zudem Lokation vom anfragenden Client immer geprüft & bei Verdachtsänderung explizit gemeldet sowie Bestätigung angefordert wird.

    • PeterL sagt:

      Erschreckend, dass selbst die IT-Branche kein Mobile Device Management durchsetzt und Mitarbeiter mit unsicheren Privatrechnern auf die Kronjuwelen zugreifen lässt.

  2. Luzifer sagt:

    PW haben auf fremden Rechnern/Cloud nix verloeren! Real simple!
    Wenn schon dann liegt das in einem Büchlein bei mir im Tresor analog! Da kann kein Hacker dran! Einbruch ja das könnte er, dann müsste er aber noch handwerklich geschickt sein und den Tresor knacken können (und sind wir ehrlich IT Cracks und Handwerk ;-P)… tja da ist dann nur ein klitzekleines Problem: der käme nur im Leichensack wieder raus… da meine 2 Mastino Neapolitaner Rüden Hackfleisch aus dem Einbrecher machen wenn er nicht ruhig an der Wand steht bis die Polizei kommt.

  3. JohnRipper sagt:

    Der Mitarbeiter ist hoffentlich jetzt ein Ex-Mitarbeiter.

    Microsoft Empfehlungen sehen schon immer Administrative Hosts (Jump Boxes) vor. Früher war die Empfehlung sogar eine gesonderte Domäne für Admins und deren Jump Boxes mit minimalsten Rechten.

    Und was war alles noch von Zeiten von Full-Onprem.

    Was für Versager.

  4. ibbsy sagt:

    Da das geschilderte Szenario wirklich beschämend ist, finde ich es umso beeindruckender, dass das Unternehmen dies so detailliert skizziert!

    Und dass sie es tun, lässt darauf schließen, dass sie sich überlegt haben, wie zahlreich genau diese Fehler in anderen Unternehmen gemacht werden und offenbar die wahrhaft optimistische Hoffnung hegen, dass sie durch die Offenlegung andere davor bewahren, ebenfalls kompromittiert zu werden.

    Das läßt tief blicken!

  5. DerManu sagt:

    Kleiner Hinweis: PBKDF2 ist eine Schlüsselableitungsfunktion auf Basis einer Streuwertfunktion. Oder anders gesagt: Das ist keine Verschlüsselung. Damit leitet man aus dem Hauptpasswort eines Benutzers einen Schlüssel (Geheimnis) ab, der zum ver- und entschlüsseln mit AES verwendet wird. PBKDF2 verschlüsselt nichts und ist nebenbei veraltet.

  6. Gerd sagt:

    Kann wer erklären, wie es möglich war trotz MFA Zugriff zum LastPass-Unternehmenstresor zu erlangen? Lief der Angriff dann auch über den PC des Mitarbeiters? Oder war hier nur der Zugriff zum PC mit MFA abgesichert und nicht der Zugriff zum Unternehmenstresor?

  7. M.D. sagt:

    Es wundert doch extrem, dass LastPass es den Nutzern gestattet hat, die Zahl der Iterationen auf Werte unterhalb 10.000 zu setzen. Die Default-Einstellung ist aktuell wohl 600.000.

    Wieso akzeptiert LastPass den Wert 1? Es ist doch offensichtlich, dass das nur Leute machen, die nicht wissen, was sie da tun. Und diese sollte man besser vor ihrer eigenen Dummheit schützen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.