Vercel bestätigt Sicherheitsverletzung, Hacker behaupten, gestohlene Daten zu verkaufen
(bleepingcomputer.com)- Vercel hat einen Sicherheitsvorfall mit unbefugtem Zugriff auf interne Systeme offiziell bestätigt und arbeitet derzeit mit Incident-Response-Experten sowie Strafverfolgungsbehörden zusammen
- Ursache der Kompromittierung war eine kompromittierte Google-Workspace-OAuth-App des Drittanbieter-AI-Tools Context.ai, wodurch ein Mitarbeiterkonto von Vercel übernommen wurde
- Die Angreifer verschafften sich durch Auflistung nicht sensibler (non-sensitive) Umgebungsvariablen zusätzliche Zugriffsrechte; diese Variablen waren unverschlüsselt gespeichert
- Ein Hacker, der sich als ShinyHunters ausgibt, behauptet in einem Hacking-Forum, Zugangsschlüssel, Source Code, Datenbankdaten, API-Schlüssel usw. zu verkaufen, und fordert 2 Millionen US-Dollar Lösegeld
- Vercel hat die Sicherheit der Open-Source-Projekte wie Next.js und Turbopack bestätigt und Kunden empfohlen, ihre Umgebungsvariablen zu prüfen und die Funktion für sensible Variablen zu aktivieren
Überblick über den Sicherheitsvorfall
- Vercel ist eine auf JavaScript-Frameworks spezialisierte Cloud-Hosting- und Deployment-Infrastrukturplattform, Entwickler von Next.js und Anbieter von serverlosen Funktionen, Edge Computing und CI/CD-Pipeline-Diensten
- In einer Sicherheitsmitteilung bestätigte das Unternehmen offiziell, dass es zu unbefugtem Zugriff (unauthorized access) auf interne Systeme gekommen ist
- Ein begrenzter Teil der Kunden war betroffen, der Dienst selbst war laut Unternehmen jedoch nicht beeinträchtigt
- Es wurden Incident-Response-Experten beauftragt und Strafverfolgungsbehörden informiert, während die Untersuchung weiterläuft
Angriffsweg und technische Details
- Die eigentliche Ursache des Vorfalls war die Kompromittierung der Google-Workspace-OAuth-App der Drittanbieter-AI-Plattform Context.ai
- Vercel-CEO Guillermo Rauch veröffentlichte zusätzliche Details auf X (früher Twitter)
- Die Angreifer übernahmen das Google-Workspace-Konto eines Vercel-Mitarbeiters über die Kompromittierung von Context.ai
- Anschließend eskalierten sie von diesem Konto aus ihre Berechtigungen in die Vercel-Umgebung
- Die Angreifer griffen auf Umgebungsvariablen zu, die als „nicht sensibel (non-sensitive)“ gekennzeichnet waren; diese Variablen wurden im Ruhezustand nicht verschlüsselt (not encrypted at rest) gespeichert
- Vercel speichert zwar die Umgebungsvariablen aller Kunden vollständig verschlüsselt im Ruhezustand (fully encrypted at rest) und verfügt über mehrschichtige Schutzmechanismen, doch als „non-sensitive“ markierte Variablen erwiesen sich als Schwachstelle
- Google-Workspace-Administratoren wird empfohlen, die folgende OAuth-App zu prüfen:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Behauptung der Hacker zum Datenverkauf
- Ein Bedrohungsakteur, der sich als ShinyHunters ausgibt, veröffentlichte in einem Hacking-Forum einen Beitrag über den Vercel-Vorfall und den Verkauf von Daten
- Zum Verkauf angeboten werden: Zugangsschlüssel, Source Code, Datenbankdaten, interner Deployment-Zugriff und API-Schlüssel (einschließlich NPM- und GitHub-Tokens)
- Als Beleg wurden Linear-Daten vorgelegt, außerdem wird behauptet, Zugriff auf zahlreiche Mitarbeiterkonten zu besitzen
- Bereits bekannte Bedrohungsakteure mit Verbindungen zur ShinyHunters-Gruppe bestritten gegenüber BleepingComputer, mit diesem Vorfall etwas zu tun zu haben
- Eine von den Angreifern geteilte Textdatei enthält 580 Datensätze zu Vercel-Mitarbeitern, bestehend aus Namen, Vercel-E-Mail-Adressen, Kontostatus und Aktivitäts-Zeitstempeln
- Ebenfalls geteilt wurde ein Screenshot, der das interne Vercel Enterprise Dashboard zeigen soll
- BleepingComputer konnte die Echtheit der Daten und Screenshots nicht unabhängig verifizieren
- In einer Telegram-Nachricht behauptete der Bedrohungsakteur, mit Vercel in Kontakt zu stehen und 2 Millionen US-Dollar Lösegeld (ransom) gefordert zu haben
Reaktion von Vercel und Empfehlungen an Kunden
- Die Sicherheit von Next.js, Turbopack und anderen Open-Source-Projekten wurde bestätigt
- Im Dashboard wurden eine Übersichtsseite für Umgebungsvariablen sowie eine verbesserte Benutzeroberfläche zur Verwaltung sensibler Umgebungsvariablen bereitgestellt
- Empfohlene Maßnahmen für Kunden:
- Umgebungsvariablen (environment variables) überprüfen
- Die Funktion für sensible Umgebungsvariablen (sensitive environment variable feature) aktivieren, um Verschlüsselung sicherzustellen, wenn Variablen nicht verwendet werden
- Falls erforderlich eine Secret Rotation durchführen
3 Kommentare
Hacker-News-Kommentare
Gerade wurde die Mitteilung aktualisiert, und wichtig erschien mir der Hinweis, dass der Vorfall mit der Kompromittierung einer Google-Workspace-OAuth-App eines Drittanbieter-AI-Tools begann.
Es wurden auch IOCs zur Unterstützung der Untersuchung veröffentlicht, mit dem Hinweis an Administratoren, sofort zu prüfen, ob diese App verwendet wurde.
Die OAuth-App ist
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, und der Originaltext ist in der Vercel-Sicherheitsmitteilung zu finden.Besonders auffällig war die Erklärung, dass durch das Auflisten von nicht sensiblen Umgebungsvariablen zusätzlicher Zugriff möglich wurde, und es wurde auch vermutet, dass es sich um eine hochentwickelte Gruppe handeln könnte, die durch AI stark beschleunigt wurde.
Trotzdem gab es bisher noch keine E-Mail-Benachrichtigung an die Nutzer, was ziemlich besorgniserregend war.
Ich verstehe, dass man den anderen nicht sofort direkt benennen will, aber wenn der Dienstname verborgen bleibt, wirkt es so, als würde das die Reaktion nur verzögern.
Heute ist es viel zu selbstverständlich geworden, statt auf einem stabilen Fundament aufzubauen einfach verschiedene Drittanbieter-Kombinationen zusammenzustöpseln, und entsprechend gibt es auch mehr Fehlerstellen.
Am Ende wurde wieder einmal deutlich, dass Sicherheit nur so stark ist wie das schwächste Glied, und insbesondere ein Business auf AI-Tools mit starkem Vibe-Coding-Charakter aufzusetzen, halte ich für ein klares Risiko.
Das ließ mich fragen, ob man diese Richtung wirklich weiter vorantreiben sollte und wie viel komplexer alles noch werden muss, bis man wieder umdenkt.
Wenn man sich die Analyse des von Claude Code empfohlenen Stacks ansieht, hatte ich den Eindruck, dass Claude Code das Web weiter vereinheitlicht, indem es standardmäßig bestimmte Anbieter und Frameworks empfiehlt.
Dieser Mangel an Vielfalt scheint im Ernstfall den Auswirkungsradius noch zu vergrößern.
Es wirkte fast so, als hätte sich das als Standardoption festgesetzt.
Als ich dann sagte, es solle ohne Node arbeiten, schrieb es sofort alles mit einem Python-Backend um und erklärte selbst, es habe die Abhängigkeiten in eine sparsamere Richtung reduziert.
Zur Einordnung: Das war nur ein Experiment für etwas, das ohnehin weggeworfen werden sollte, nicht etwa eine Empfehlung für Vibe Coding.
Letztlich ist es eine Frage der Nutzungsweise, und man sollte Entwickler besser dazu anleiten, Claude nicht die Entscheidungen abnehmen zu lassen.
Man kann sich beraten lassen, aber am Ende muss ein Mensch das Ganze kritisch prüfen; in dieser Hinsicht fühlt es sich nicht groß anders an als die Zusammenarbeit mit anderen Teammitgliedern.
Das Internet hatte diese Tendenz zwar schon immer, aber diesmal fühlt es sich etwas anders an.
Als jemand, der früher in einem Incident-Response-Team für Sicherheitsvorfälle war, konnte ich gut nachvollziehen, wie hart es das Team gerade haben muss.
Trotzdem wirkte die erste Mitteilung wie eine wirklich miserable Kommunikation.
Es wurde nicht gesagt, was genau passiert ist; stattdessen stand dort nur sinngemäß, es sei ernst genug gewesen, um Strafverfolgungsbehörden zu informieren, und die Handlungsanweisung für Kunden beschränkte sich auf „Prüfen Sie Ihre Umgebungsvariablen“.
Aus Kundensicht war aber viel zu unklar, was man damit eigentlich tun soll. Sollte man prüfen, ob die Werte noch vorhanden sind? Oder wie soll man feststellen, ob sie bereits abgeflossen sind?
Meiner Meinung nach hätte man sofort sagen müssen, dass Passwörter, Access Tokens und alle bei Vercel hinterlegten sensiblen Informationen rotiert werden sollen, und anschließend dazu anleiten müssen, Zugriffslogs sowie Auffälligkeiten bei Kundendaten zu auditieren.
Einer der Gründe, warum man teures Hosting bezahlt, ist schließlich die Erwartung, dass Sicherheit und Stabilität professionell gemanagt werden; selbst wenn man die anfängliche Unsicherheit berücksichtigt, wirkte das hier übermäßig absichtlich vage.
Falls jedoch geheime Werte wie API-Schlüssel, Tokens, DB-Zugangsdaten oder Signaturschlüssel nicht als sensitive markiert waren, solle man sie als potenziell offengelegt betrachten und vorrangig austauschen.
Die Quelle war die Incident-Seite, Stand meines Abrufs war 16:22 Uhr Eastern Time.
Ich bin seit über einem Jahr zahlender Kunde, und trotzdem erfahre ich das zuerst über einen News-Aggregator statt über eine Firmen-E-Mail — das ist schon absurd.
Mehr Kontext gibt es im HN-Thread und in der damaligen Reaktion.
Alles andere wirkt größtenteils wie eine Entscheidung, sich unnötig Probleme einzuhandeln.
Ich habe mich aber entschieden, mich auf diese Bequemlichkeit nicht mehr zu verlassen, und bin komplett von Render zu Linode gewechselt.
Früher habe ich bei Render über 50 Dollar im Monat bezahlt, jetzt liege ich bei 3 bis 5 Dollar, deshalb werde ich solche Hosting-Anbieter künftig wohl kaum noch einmal nutzen.
Als ich den Satz las, dass „Vercel nicht offengelegt hat, welches System kompromittiert wurde“, wirkte das selbst ohne Sicherheitsfachwissen wie eine ziemlich schwer nachvollziehbare Haltung.
Es entstand auch der Eindruck, dass sie mehr auf ihre eigene Verteidigung bedacht sind, als Kunden beim Verständnis der Auswirkungen zu helfen.
Wenn man zum Beispiel sagt, bei GitHub sei ein wenig bekanntes Subsystem X kompromittiert worden, hilft das unter Umständen praktisch nicht mehr als die bereits bekannte Aussage, dass „einige Kundenumgebungen kompromittiert wurden“.
Als ich erneut sah, dass der Mitteilung IOCs hinzugefügt wurden, war klar, dass die Information, dass dieser Vorfall mit der Kompromittierung einer Google-Workspace-OAuth-App begann, für die gesamte Community wichtig war.
Administratoren und Kontoinhaber sollten diese App-Kennung sofort prüfen; mehr Details standen in der Vercel-Mitteilung.
Ich nutze ein MacBook Pro mit Chrome 147.0.7727.56, und sobald ich oben links auf das Vercel-Logo klickte, ist Chrome sofort abgestürzt.
Das wirkte wie ein ziemlich interessanter Bug.
Es war irgendwie komisch-lustig, dass jetzt alle Berichte darüber lesen, dass Vercel möglicherweise kompromittiert wurde, und gleichzeitig anfangen, den Webseitenabsturz nachzustellen.
Natürlich kam mir auch der Gedanke, dass so ein kollektives Nachstellen unmöglich keine negativen Nebenwirkungen haben kann.
Ich habe sogar ein Video aufgenommen und dachte erst, uBlock Origin Lite könnte der Grund sein, aber auch ohne blieb alles stabil.
Wenn es reproduzierbar gewesen wäre, wäre das vielleicht sogar ein bisschen amüsant gewesen.
Das ging eine Zeit lang so und wurde schließlich behoben.
Allerdings trat der Absturz nicht mehr auf, nachdem ich die Vercel-Startseite einmal direkt per URL geöffnet hatte und dann auf das Logo klickte.
Dafür habe ich jetzt etwas Hemmungen, auf den Finish update-Button zu klicken.
Zur Einordnung habe ich auch den anderen HN-Thread und einige Posts auf X verfolgt.
In Theos erster Erwähnung hieß es, das wirke glaubwürdig, und im Folgepost, dass als sensitive markierte env vars sicher seien, während nicht markierte Werte vorsorglich ersetzt werden sollten.
In einem weiteren Post hieß es außerdem, dass diese Art von Hack bei jedem Host passieren könne, und in einer anderen Erwähnung wurde eine mögliche Verbindung zu ShinyHunters angesprochen.
Wenn es Werte sind, die zwingend ersetzt werden müssen, dann waren es doch von Anfang an sensible Informationen und sie hätten als sensitive markiert sein müssen, oder nicht?
Zum jetzigen Zeitpunkt schien dort inhaltlich noch nicht besonders viel Substanzielles dabei zu sein.
Solche Vorfälle führen mir wieder vor Augen, wie sehr sich das moderne Web-Ökosystem auf Single Points of Failure konzentriert.
Die bisherige Offenlegung wirkte auf mich vergleichsweise transparent, aber das Risikoprofil einer vollständigen Abhängigkeit von einem vollständig gemanagten PaaS muss ich neu bewerten.
Die Formulierung „eine begrenzte Zahl von Kunden“ ist technisch gesehen selbst dann zutreffend, wenn es 99 % sind, und klang deshalb ziemlich vage.
Ich fragte mich, ob das in Wirklichkeit eine Situation sein könnte, in der viele Kunden betroffen sind, aber man nur die großen Kunden, die nicht abspringen sollen, als Teilmenge bezeichnet.
Wenn man die Leute wirklich beruhigen kann, nennt man normalerweise konkrete Zahlen wie „weniger als 1 % der Nutzer“, aber das ist hier nicht passiert.
Deshalb dachte ich, dass entweder noch nicht genug Sichtbarkeit vorhanden ist oder die Zahlen nicht gefallen.
Trotzdem habe ich viel Verständnis dafür, wie hart das Reaktionsteam gerade arbeiten muss, und hoffe, dass künftig offener und transparenter kommuniziert wird.
Hier sieht man auch Hindi-Zeichen. In letzter Zeit kommt es ziemlich häufig vor, dass sich in koreanische Outputs – unabhängig davon, ob von OpenAI, Claude oder Google – Hindi mischt. Haben vielleicht Inder das Labeling der koreanischen Datensätze übernommen?
Chinesische Modelle mochte ich nicht, weil sich in ihre koreanischen Antworten Chinesisch mischte, aber in letzter Zeit mischen Frontier-Modelle ständig Hindi hinein, sodass meine Abneigung gegen chinesische Modelle eher geringer geworden ist.
Wenn ich Claude benutze, kommt oft Japanisch heraus. Gestern war das auch so.