- Am 31. Mai 2024 erlitt das Cloud-Unternehmen Snowflake ein massives Datenleck.
- Hacker bestätigten gegenüber Hudson Rock, dass sie sich über eine Infostealer-Infektion Zugang verschafft hatten.
- Die Hacker verkauften Daten mehrerer großer Unternehmen, darunter Ticketmaster und die Banco Santander, in einem russischsprachigen Cybercrime-Forum.
Methode des Angriffs
- Die Hacker meldeten sich mit gestohlenen Zugangsdaten beim ServiceNow-Konto eines Snowflake-Mitarbeiters an.
- Sie umgingen OKTA, erzeugten Session-Tokens und exfiltrierten große Datenmengen.
- Die Hacker behaupten, dass rund 400 Unternehmen betroffen seien.
Weitere Belege
- Die Hacker teilten Forschern von Hudson Rock eine CSV-Datei, die den Zugriff auf Snowflake-Server belegen soll.
- Die Datei dokumentiert mehr als 2.000 Kundeninstanzen im Zusammenhang mit den europäischen Servern von Snowflake.
Ziel der Hacker
- Die Hacker fordern von Snowflake 20 Millionen US-Dollar und wollen im Gegenzug die Daten zurückgeben.
- Das Unternehmen reagierte nicht darauf.
Zunahme von Infostealer-Infektionen
- Seit 2018 haben Infostealer-Infektionen um 6000 % zugenommen und sich zu einem wichtigen initialen Angriffsvektor entwickelt.
- Sie werden genutzt, um Cyberangriffe wie Ransomware, Datenexfiltration, Kontoübernahmen und Unternehmensspionage durchzuführen.
Meinung von GN⁺
- Bedeutung von Cybersicherheit: Dieser Vorfall zeigt, dass Unternehmen Cybersicherheit ernster nehmen müssen. Besonders wichtig ist der Umgang mit Zugangsdaten von Mitarbeitern.
- Bedrohung durch Infostealer: Infostealer verbreiten sich extrem schnell, und Unternehmen müssen entsprechende Gegenmaßnahmen vorbereiten.
- Reaktionsstrategie: Im Fall eines Angriffs sind schnelle Reaktionen und Strategien zur Schadensbegrenzung notwendig. Die späte Reaktion von Snowflake vergrößerte den Schaden.
- Sicherheitsschulungen: Es ist wichtig, Sicherheitstrainings für Mitarbeiter zu verstärken, um das Bewusstsein für den Umgang mit Zugangsdaten und für Phishing-Angriffe zu schärfen.
- Alternative Lösungen: Es kann sinnvoll sein, andere Cloud-Speicherlösungen mit ähnlichen Funktionen wie Snowflake in Betracht zu ziehen, etwa AWS S3 oder Google Cloud Storage.
1 Kommentare
Meinungen auf Hacker News
Die aktuell verlinkte URL wird per 302-Redirect auf
/umgeleitet. @dang, es wäre wohl besser, sie durch den Archiv-Link unten zu ersetzenhttps://web.archive.org/web/20240531140540/https://www.hudso...
Allerdings ist es ebenfalls ein interessantes Signal, dass Hudson Rock den Blogpost entfernt hat; man sollte also nicht einfach auf den Archiv-Link umstellen und weitermachen. Was hat sich geändert?
Nachtrag: Snowflakes offizielle Antwort scheint praktisch alle zentralen Behauptungen des ursprünglichen Artikels zu bestreiten. Es könnte sein, dass Hudson Rock auf eine unehrliche Quelle hereingefallen ist und den Beitrag entfernt hat, nachdem ihnen der Fehler klar wurde
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Hier ist Felipe von Snowflake. Snowflakes aktueller Stand zu diesem Thema ist hier zu finden: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Falls es Neuigkeiten gibt, werden wir diese URL laufend aktualisieren
Der Satz von Snowflake „Ähnlich wie bei den betroffenen Kundenkonten haben wir Hinweise gefunden, dass der Bedrohungsakteur persönliche Zugangsdaten für ein Demo-Konto eines ehemaligen Snowflake-Mitarbeiters erlangt und darauf zugegriffen hat. Es gab keine sensiblen Daten“ liest sich jedoch so, als halte Snowflake Hudson Rocks Darstellung für falsch. Ist dieses Verständnis korrekt?
Der Snowflake-Beitrag dagegen klingt so, als seien Zugangsdaten von Kundenkonten geleakt worden, und damit sei es das gewesen; es habe keinen Zugriff auf ein zentrales Konto oder andere Konten gegeben. Zur Nutzung von Mitarbeiterkontodaten ohne Zwei-Faktor-Authentifizierung steht dort nichts
Es ist klar, dass Snowflake für alle internen Mitarbeiter-Zugangsdaten Zwei-Faktor-Authentifizierung verlangen würde. Früher konnten Kunden, wenn sie wollten, für den Login auf ihre eigenen Daten einfach nur Benutzername/Passwort einrichten und auch ohne Zwei-Faktor-Authentifizierung zugreifen
Die Screenshots der Chat-Logs sind wirklich beeindruckend. Dieses Unternehmen behauptet, mit einem echten Kriminellen zu kommunizieren, und dieser Kriminelle sagt, wenn man dieses Unternehmen genutzt hätte, hätte das geholfen, den Einbruch zu verhindern
Deshalb habe ich meine Einschätzung zur Vertrauenswürdigkeit dieses Unternehmens angepasst
Hudson Rock scheint das aufgegriffen und die Geschichte aufgeblasen zu haben, als sei der Einbruch größer gewesen, als er tatsächlich war. Ich frage mich auch, ob der Hacker zuerst zu Hudson Rock gegangen ist oder ob Hudson Rock einfach die erste Firma war, die darauf eingestiegen ist
„Sie hätten Schutz von Hudson Rock kaufen sollen, dann hätte man diesen Vorfall verhindern können“
„Stimmt, das hätte definitiv geholfen“
„Glückwunsch. Ihr Unternehmen hat ein überraschendes Informationssicherheits-Audit bestanden und ist Opfer von Ransomware geworden.“
[...]
Enthaltene Leistungen: 1) vollständige Unterstützung bei der Entschlüsselung 2) Nachweis der Datenlöschung 3) Sicherheitsbericht zu den gefundenen Schwachstellen 4) Zusicherung, die Daten nicht zu veröffentlichen oder zu verkaufen 5) Zusicherung, künftig keine Angriffe mehr durchzuführen
Am Ende ist es eben nur eine Security-Consulting-Firma, von der man nicht wusste, dass man sie auf der Gehaltsliste hat
Nebenbei: Als ich mir ansah, was sie als Nachweis der Datenlöschung liefern, war es wortwörtlich nur die Standardausgabe von
rm -vrf data. Ich verstehe, dass es unmöglich ist, die Abwesenheit von etwas zu beweisen, und dass das Opfer keine Verhandlungsmacht hat, aber diese Inszenierung gefällt mir ziemlich gutSelbst wenn es echt ist, hätte es dem gesunden Menschenverstand entsprochen, die Hudson-Rock-Nachrichten wegzulassen. Diese Firma ist auf meiner mentalen Blacklist gelandet
Nach der Formulierung des Täters zu urteilen, scheint Snowflake das System so entworfen zu haben, dass ein einziges Administratorkonto die volle Kontrolle über alles hat.
Dass Snowflake in seiner Mitteilung vom 31. Mai erklärte, man untersuche einen „branchenweiten identitätsbasierten Angriff“, der „einige Kunden“ betroffen habe, verleiht den Berichten über Ticketmaster und Santander zusätzlich Glaubwürdigkeit.
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Wenn der Bedrohungsakteur es richtig angestellt hätte, könnte dies zu einem der größten Datenlecks aller Zeiten werden.
Die Daten scheinen aus dem Snowflake-Konto dieser Person zu stammen, das für Demos für Kunden oder potenzielle Kunden genutzt wurde. Es ist möglich, dass Kunden Zugriff auf Teile echter Daten gewährt haben, damit sie in Demos verwendet werden konnten, aber das ist weit entfernt von uneingeschränktem Zugriff auf die Snowflake-Datenbanken der Kunden selbst.
Gut möglich, dass der Hacker gefälschte, aber plausibel wirkende Demodaten abgezogen hat und den Unterschied nicht kennt.
Ein einzelner Sales Engineer betreut mehrere Accounts. Snowflake-Sales-Engineers bauen normalerweise nicht in Kundenumgebungen, sondern richten Demo-Konten mit 400 Dollar Guthaben ein, die jeder erstellen kann. Da Demo-Konten nach einiger Zeit ablaufen, werden ständig neue erstellt.
Sales Engineers bauen innerhalb der von ihnen erstellten Demo-Konten und zeigen sie Kunden. Nach 30 Tagen sperrt Snowflake das Konto, wenn keine Kreditkarte hinterlegt ist, und löscht später die Demo-Instanz samt Daten.
Für die Arbeit kann ein Kunde Daten aus seiner eigenen Snowflake-Instanz mit der vom Sales Engineer erstellten Demo-Instanz teilen oder diesem Snowflake-Sales-Engineer per SSO Zugriff gewähren.
In beiden Fällen geht es eher darum, dass Organisationen ihre Sicherheitslage nicht restriktiv genug handhaben. An diesem Angriff ist nichts Neues, außer dass man einen fleißigen Sales Engineer und Kunden gefunden hat, die den Berechtigungsumfang von Mitarbeitern/Auftragnehmern/Gästen nicht sauber begrenzt haben.
Interessanterweise gibt es auf der ersten Seite auch eine benachbarte Geschichte darüber, dass Pegasus gegen eine osteuropäische NGO eingesetzt wurde. Das Least-Privilege-Prinzip ist wichtig, aber Gerätesicherheit ebenfalls.
https://news.ycombinator.com/item?id=40535912
Ich bin kein Snowflake-Mitarbeiter, habe aber viel mit Snowflake und dessen Sales-Engineering-Organisation zusammengearbeitet.
Wenn Sales Engineers mit Kunden Demos erstellen, bauen sie Vorführumgebungen mit einem 400-Dollar-Snowflake-Demo-Konto, das jeder anlegen kann. Um eine Demo zu erstellen, gewährt der Kunde diesem Sales Engineer Zugriff, und der Sales Engineer übernimmt einige Daten in die Demo-Umgebung und arbeitet damit. Auch die von Hudson Rock veröffentlichten Umgebungsnamen stützen das.
Aus meiner Sicht ist das ein Prozessproblem: Der Kunde hat die ID der Person, mit der Daten geteilt wurden, nicht auslaufen lassen, und der Bedrohungsakteur hat die Zugangsdaten gestohlen. Da es kein Exploit einer Schwachstelle ist, ist daran nichts Neues.
Und Hudson Rock: Glückwunsch, dass ihr öffentlich offengelegt habt, wer betroffen war, weil sich Malware auf seinem Computer befand. Das ist nicht anders, als wenn man einem Auftragnehmer Zugangsdaten gibt und diese gestohlen werden. Ziemlich üble Aktion.
Snowflake muss damit rechnen, dass Zugangsdaten eines Sales Engineers gestohlen werden können; diese Zugangsdaten können Multi-Faktor-Authentifizierung umgehen und laufen dem Artikel zufolge nicht ab. Das sind Strike 1, 2 und 3.
Snowflakes Sicherheitspraktiken haben eine Situation geschaffen, in der Kunden dazu verpflichtet oder zumindest ermutigt werden, Snowflake-Mitarbeitern Zugriff auf breite Datensätze zu geben. Strike 4.
Kunden tragen ebenfalls Verantwortung dafür, zu weitreichende Zugriffe vergeben zu haben, aber Snowflake trägt die Verantwortung dafür, kein besseres System geschaffen zu haben, das solchen Zugriff unnötig macht, oder diesen transitiven Zugriff zumindest besser zu überwachen und zu kontrollieren.
Sobald ein solches Konto Zugriff auf Kundendaten erhält, ist es kein „Demo-Konto“ mehr. Es ist ein echtes Konto mit tatsächlich sehr wertvollen Daten und sollte entsprechend behandelt werden.
Nachtrag: Snowflake behauptet, das betreffende Demo-Konto habe keinen Zugriff auf Kundendaten gehabt und sei auch nicht die Quelle des Lecks gewesen; das widerspricht der Behauptung des Angreifers.
„Stellen Sie sich vor, Sie hätten Zugriff auf eine Prospecting-Plattform mit Hunderttausenden kompromittierten Unternehmen weltweit und aktiven Schwachstellen, die Sie in Kunden verwandeln können.“
Ich habe einige Unternehmen dieser Art gesehen und mit ihnen zu tun gehabt; das sind ziemlich billige Taktiken, und technisch ist das weder besonders anspruchsvoll noch aufwendig.
In der offiziellen Antwort von Snowflake steht Folgendes:
„Wir gehen davon aus, dass dies das Ergebnis einer laufenden, branchenweiten identitätsbasierten Angriffskampagne ist, die darauf abzielt, Kundendaten zu erlangen. Unsere Untersuchung zeigt, dass diese Angriffe mit Benutzer-Anmeldedaten von Kunden durchgeführt werden, die durch nicht zusammenhängende Cyberbedrohungsaktivitäten offengelegt wurden. Bislang sehen wir keine Hinweise darauf, dass diese Aktivitäten durch eine Schwachstelle, Fehlkonfiguration oder bösartige Aktivität innerhalb des Snowflake-Produkts verursacht wurden.“
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Der Artikel scheint auf privat gestellt worden zu sein, ist aber in der Wayback Machine noch vorhanden: https://web.archive.org/web/20240531140540/https://www.hudso...
Dieser Beitrag behauptet, dass der Ticketmaster-Vorfall vor ein paar Tagen in Wirklichkeit Teil eines deutlich größeren Hacks war, der über gestohlene Anmeldedaten eines Snowflake-Mitarbeiters mehr als 400 Unternehmen betraf.
Im Moment wirkt das wie eine große Story, über die nur hudsonrock.com berichtet. Von Hudson Rock höre ich zum ersten Mal – weiß jemand, ob das eine vertrauenswürdige Quelle ist?
Mehrere Accounts wurden von Reddit-Moderatoren und -Admins gesperrt. Persönlich halte ich sie nicht für eine seriöse oder glaubwürdige Quelle.
https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
Snowflake scheint zu sagen, dass es nicht ihre Schuld ist, sondern die der Kunden.
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Wenn https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... nicht komplett erfunden ist, stellt Snowflake die Fakten etwas weniger ehrlich dar.
Die Formulierung „Unsere Untersuchung zeigt …“ ist unklar: Meinen sie ihre eigene Untersuchung oder allgemeine Sicherheitsforschung? Auch die Aussage, man sehe die Ursache nicht in einer Schwachstelle, Fehlkonfiguration oder bösartigen Aktivität innerhalb des Snowflake-Produkts, zählt mögliche Szenarien auf und verneint sie, lässt aber geschickt aus, wie es tatsächlich passiert ist.
Wenn man Hudson Rock glaubt, wurde Snowflake von dem böswilligen Akteur kontaktiert; sie wussten also vermutlich ziemlich genau, wie es dazu kam.
Dort heißt es, die Angriffe seien „mit Benutzer-Anmeldedaten von Kunden durchgeführt“ worden, „die durch nicht zusammenhängende Cyberbedrohungsaktivitäten offengelegt wurden“. Wenn das nicht erfunden ist, gehen sie offenbar davon aus, dass die Anmeldedaten anderswo erlangt wurden.
Am Ende fordern sie Kunden auf, ihre Kontoeinstellungen zu überprüfen; das zielt also darauf ab, die Verantwortung von sich wegzuschieben. Allerdings sind die aktuellen Quellen ein Unternehmen, das angeblich gehackt wurde, und ein Unternehmen, das den Vorfall nutzt, um sein eigenes Produkt zu bewerben, während es dreist einen Mitarbeiter doxxt. Man sollte wohl auf weitere Details warten.
Der Hacker behauptet, sie hätten nicht einmal die Refresh Tokens ablaufen lassen; falls das stimmt, wäre das ein riesiges und offensichtliches Problem.
Der Artikel scheint mit der Überschrift „Hunderte Kunden kompromittiert“ nicht besonders konsistent zu sein.
Erstens scheinen die lift/okta-Passwörter nur Zugriff auf das ServiceNow-Portal zu erlauben, nicht auf Kundenkonten. Das Problem mit den Refresh Tokens scheint daher auf das ServiceNow-Portal beschränkt zu sein und nichts mit der Offenlegung von Daten in tatsächlichen Snowflake-Kundenkonten zu tun zu haben.
Zweitens zeigt der Screenshot, wonach Konten von 10 Unternehmen kompromittiert wurden, vier verschiedene Snowflake-Konto-Anmeldedaten, von denen eines wie ein persönliches Demo-Konto aussieht. Damit ließen sich also höchstens etwa drei kompromittierte Kunden erklären; Details zu weiteren betroffenen Kunden gibt es nicht.
Selbst wenn man annimmt, dass alle Anmeldedaten für alle Kunden kompromittiert wurden, an denen der Sales Engineer gearbeitet hat, läge die Zahl der betroffenen Kunden vermutlich im niedrigen zweistelligen Bereich. Denn jedes Kundenkonto hätte dem Sales Engineer individuell Zugriff gewähren müssen.
Aus einem Refresh-Token-Problem im internen Okta-Portal abzuleiten, dass alle Snowflake-Kunden kompromittiert seien, ist ein großer Sprung; dieses Problem ist mit keinem Snowflake-Kundenkonto verknüpft.