GitHub bestätigt Kompromittierung von 3.800 Repositories über bösartige VSCode-Erweiterung
(bleepingcomputer.com)- Rund 3.800 interne GitHub-Repositories wurden kompromittiert, nachdem ein Mitarbeiter eine bösartige VS Code-Erweiterung installiert hatte; nach aktuellem Stand ist das Ausmaß des Abflusses auf interne Repositories begrenzt
- GitHub entfernte die trojanisierte Erweiterung aus dem VS Code Marketplace, isolierte infizierte Endpunkte und leitete umgehend Maßnahmen zur Incident Response ein
- TeamPCP behauptet, Zugriff auf den GitHub-Quellcode und auf rund 4.000 private Code-Repositories zu haben, und fordert für die gestohlenen Daten mindestens 50.000 US-Dollar
- VS Code-Erweiterungen sind Plug-ins, die über den offiziellen Store installiert werden, doch bereits in der Vergangenheit wurden Erweiterungen entdeckt, die Zugangsdaten stehlen, Krypto-Miner oder Ransomware-Funktionen enthalten oder Kryptowährungen entwenden
- GitHub erklärte, es gebe keine Hinweise auf eine Verletzung von Kundendaten außerhalb der betroffenen Repositories; die Plattform wird von mehr als 180 Millionen Entwicklern genutzt
GitHub bestätigt den Vorfall und reagiert
- GitHub hat bestätigt, dass rund 3.800 interne Repositories kompromittiert wurden, nachdem ein Mitarbeiter eine bösartige VS Code-Erweiterung installiert hatte
- Die namentlich nicht genannte trojanisierte Erweiterung wurde aus dem VS Code Marketplace entfernt, und die kompromittierten Geräte wurden abgesichert
- In einem Post auf X erklärte GitHub, man habe „eine Kompromittierung eines Mitarbeitergeräts im Zusammenhang mit einer verseuchten VS Code-Erweiterung erkannt und blockiert“, die bösartige Erweiterungsversion entfernt, Endpunkte isoliert und sofort die Incident Response eingeleitet
- Nach aktueller Bewertung ist der Umfang der Aktivität auf den Abfluss interner GitHub-Repositories begrenzt, wobei die von den Angreifern behauptete Größenordnung von etwa 3.800 Repositories weitgehend mit den Untersuchungsergebnissen übereinstimmt
- GitHub hatte BleepingComputer bereits am Vortag mitgeteilt, dass man die Behauptung eines unbefugten Zugriffs auf interne Repositories untersucht, und ergänzte, es gebe keine Hinweise darauf, dass Kundendaten außerhalb der betroffenen Repositories kompromittiert wurden
Behauptungen von TeamPCP und Risiken von VS Code-Erweiterungen
- Die Hackergruppe TeamPCP behauptet im Cybercrime-Forum Breached, Zugriff auf den GitHub-Quellcode und auf „rund 4.000 private Code-Repositories“ zu haben, und verlangt für die gestohlenen Daten mindestens 50.000 US-Dollar
- TeamPCP erklärte, es handle sich „nicht um Ransomware“ und man habe kein Interesse daran, GitHub zu erpressen; nach dem Verkauf an einen einzigen Käufer wolle die Gruppe die gespeicherten Daten löschen
- TeamPCP wurde bereits mit groß angelegten Supply-Chain-Angriffen auf Entwickler-Code-Plattformen in Verbindung gebracht, darunter GitHub, PyPI, NPM, Docker
- TeamPCP wird auch mit der „Mini Shai-Hulud“-Supply-Chain-Kampagne in Verbindung gebracht, die jüngst auch zwei OpenAI-Mitarbeiter betroffen haben soll
- VS Code-Erweiterungen sind Plug-ins, die über den offiziellen Store VS Code Marketplace installiert werden, um dem Code-Editor von Microsoft Funktionen hinzuzufügen oder Tools zu integrieren
- Im VS Code Marketplace wurden schon mehrfach bösartige Erweiterungen entdeckt, die Entwickler-Zugangsdaten und sensible Daten stehlen
- Im vergangenen Jahr wurden VSCode-Erweiterungen mit insgesamt 9 Millionen Installationen wegen Sicherheitsrisiken entfernt; zudem infizierten 10 als legitime Entwickler-Tools getarnte Erweiterungen Nutzer mit dem XMRig-Kryptominer
- Später tauchte eine bösartige Erweiterung mit grundlegenden Ransomware-Funktionen im VS Code Marketplace auf, und der Bedrohungsakteur WhiteCobra registrierte 24 Erweiterungen zum Diebstahl von Kryptowährungen
- Im Januar dieses Jahres leiteten zwei als KI-basierte Coding-Assistenten beworbene bösartige Erweiterungen mit 1,5 Millionen Installationen Daten von infizierten Entwickler-Systemen an Server in China weiter
- Die GitHub-Cloud-Plattform wird derzeit von mehr als 4 Millionen Organisationen, 90 % der Fortune 100 und mehr als 180 Millionen Entwicklern genutzt; sie tragen zu mehr als 420 Millionen Code-Repositories bei
1 Kommentare
Hacker-News-Kommentare
Es wäre schön, wenn das Unternehmen hinter VSCode, das Unternehmen hinter NPM und das Unternehmen hinter GitHub sich einmal zusammensetzen und eine Lösung für dieses Problem finden könnten
Zeigt perfekt, warum der Comic mit dem Microsoft-Organigramm so zutreffend ist
https://bonkersworld.net/organizational-charts
Es lag ganz sicher nicht an einem Mangel an Warnungen vor diesem offensichtlichen Risiko
https://github.com/microsoft/vscode/issues/52116
Microsoft ist auch das Unternehmen hinter NuGet
Wenn man sich anschaut, was sie vor einem Jahr gemacht haben: Sie haben in NuGet präventiv rund 700 Pakete entfernt, die sich am Ende als Fehlalarme herausstellten
Das Richtige zu tun ist nicht einfach
Kein Witz, solche Ökosysteme sind von Grund auf wie leicht kompromittierbare Müllhalden gebaut
Wenn es ein vollständig offenes Ökosystem ist, in dem Beiträge nicht streng geprüft werden, ist es diesen Problemen zwangsläufig ausgesetzt
Wenn dir das nicht gefällt, nutze keine Editor-Erweiterungen und verwende stattdessen einen ordentlich auditierten Editor
Erweiterungen oder node-, PyPI-Pakete zu verwenden, ohne sie genau zu prüfen, bedeutet, technische Schulden anzuhäufen
Man nimmt Risiken in Kauf, um schneller zu liefern, und muss sie später kontrolliert zurückzahlen oder damit klarkommen, wenn die Zinsen fällig werden
VS-Code-Erweiterungen waren schon lange beängstigend und ein allzu offensichtlicher Angriffsvektor
In VSCode ploppen ständig Hinweise auf, man solle eine Erweiterung installieren, weil sie angeblich ein bestimmtes Dateiformat erkennt, und bei diesen Erweiterungen ist es ungefähr fifty-fifty, ob sie einem Unternehmen gehören oder irgendeinem einzelnen Entwickler
Selbst unter Erweiterungen mit Millionen Installationen gibt es welche, die auf den ersten Blick wie offizielle Unternehmens-Erweiterungen aussehen
Inzwischen versuche ich nur noch Erweiterungen zu installieren, die offiziell einem Unternehmen gehören, aber selbst dann ist es bitter, dass man sich nicht sicher sein kann, nicht doch hereingelegt zu werden
Dieses Problem geht weit über VS Code hinaus
Alle Erweiterungen und jeder ausführbare Code haben dasselbe Problem
Es gab auch den Fall bei Disney, wo ein Mitarbeiter gehackt wurde, weil er ein BeamNG-Mod mit Malware installiert hatte
Unternehmen, die Sicherheit ernst nehmen, sollten die Installation von Software streng einschränken
Zum Beispiel indem intern nur npm-Pakete und Plugins aus vorab genehmigten Repositories installiert werden dürfen
Ich bin bei Sublime geblieben, auch wenn ich dafür von VSCode-Süchtigen oft verspottet wurde
Es ist befriedigend zu sehen, wie Leute, die unkritisch glaubten, „VSCode ist perfekt“, nun damit auf die Nase fallen
Ich bin bei VSCode-Erweiterungen ähnlich paranoid vorsichtig geworden
Ich erinnere mich noch an Zeiten, in denen man in IDEs wie Brackets, JetBrains, Sublime Text oder Bluefish nur ein paar vertrauenswürdige Erweiterungen für die Entwicklungsarbeit brauchte
Heute wirkt es so, als hätte irgendjemand oder irgendein Unternehmen für jede noch so kleine Aufgabe eine eigene Erweiterung gebaut
Jetzt versuche ich, mit möglichst wenigen Erweiterungen möglichst viel zu erledigen
Und ich will gleichzeitig auch den Rest meines Codes von GitHub wegbekommen
Von einem Anbieter, der auf die Idee kam, alle paar Sekunden Screenshots des Desktops zu machen, OCR darüber laufen zu lassen und die Ergebnisse unverschlüsselt als Klartext auf der Festplatte zu speichern, kann man genau dieses Niveau an Software-Sicherheit erwarten
Und obendrein wollen all diese Erweiterungen auch noch automatische Updates
Noch erstaunlicher ist, dass die Hacker ein lang genuges Zeitfenster der Verfügbarkeit gefunden haben, um das überhaupt zu tun
Für alle, die den Witz nicht verstanden haben: Seit der Übernahme durch Microsoft hat GitHub zunehmend Schwierigkeiten, sich selbst stabil zu betreiben
Zuletzt wurde das mit mehr Downtime noch schlimmer und war sogar Thema in den Nachrichten
Vorheriger verwandter Thread:
GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - Mai 2026, 321 Kommentare
Ich frage mich, ob die nx-console-Erweiterung, die mich gestern erwischt hat, kompromittiert war
Das Timing scheint fast identisch zu sein
Siehe https://github.com/nrwl/nx-console/security/advisories/GHSA-...
Ich hoffe, Microsoft nimmt das zum Anlass, ein ausdrückliches Berechtigungssystem für VS-Code-Erweiterungen hinzuzufügen und auch die Sicherheit von Dev-Containern zu verbessern
Hoffentlich führt das vielmehr dazu, dass Nutzer, in diesem Fall Entwickler und Maintainer, ihre Abhängigkeit von Microsoft reduzieren und insbesondere damit aufhören, Sicherheit an Microsoft auszulagern
Es ist jetzt Zeit, von vscode wegzukommen
Ich habe keine großen Erwartungen
Dieses Issue ist seit 2018 offen: https://github.com/microsoft/vscode/issues/52116
VS Code wurde auf Electron gebaut, und Electron hatte oder hat einen SUID-Sandbox-Helfer, was die Sandboxing-Frage unerquicklich macht
Denn innerhalb einer Sandbox lässt sich ein SUID-Binary nicht einfach ausführen
Sandboxing unter Linux ist eine extrem schwierige Aufgabe
Einem Webbrowser SUID Root zu geben war früher ein Scherz, mit dem man ahnungslose Nutzer aufzog, und der schlimmste vorstellbare Sicherheitsfehler
Es gibt zwar etwas Performance-Overhead, aber das ist nicht das Ende der Welt
Vielleicht übersehe ich etwas Offensichtliches, aber 3.800 Repositories klingt trotzdem erstaunlich
Ich hätte nicht gedacht, dass es so viele sind
Wie andere schon gesagt haben, ist das nur ein Teil davon
Ich bin in einem mittelgroßen Tech-Unternehmen, und allein eine GitHub-Organisation hat über 7.500 Repositories
Wir haben zwei Organisationen, also kommen wir locker auf über 10.000
Natürlich ist das meiste alt, aufgegeben, Sandbox-Zeug oder private Tools
Bei GitHub würde es mich nicht überraschen, wenn sie 100.000 oder noch mehr interne Repositories hätten
Ich habe einmal in einem Unternehmen gearbeitet, das über fünf oder sechs GitHub-Organisationen hinweg mindestens 5.000 Repositories hatte, und in Perforce lag noch mehr Code
Es gab sicher alte Experimente, aber das Unternehmen war in vielen Bereichen aktiv, und manche Abteilungen hatten kein Problem damit, zur Lösung eines Problems gleich noch einen weiteren Service zu bauen
Die alten Sachen meiner Abteilung haben wir definitiv archiviert
Wir hatten acht Repositories, und für drei Leute fühlte sich selbst das schon nach genug an
Uber hatte zeitweise 8.000 Repositories bei 2.000 Engineers - https://highscalability.com/lessons-learned-from-scaling-ube...
Ich habe früher bei einem Lebensmitteleinzelhändler gearbeitet
Am ersten Tag dachte ich, von außen sehe das wie eine simple Website aus, also wie kompliziert könne es schon sein
Dann stellte sich heraus, dass die Bestell-Website das Ergebnis von mehr als 300 Repositories war, die zusammenliefen
Das war weniger, als GitHub bei diesem Vorfall verloren hat
Je größer der Maßstab, desto mehr Arbeit braucht es, um die Dinge einfach zu halten
Einer der Punkte, die ich bei GitHub als Mitarbeiter immer gut fand, war, dass große Teile des Unternehmens tatsächlich auf GitHub selbst laufen
Auch nichttechnische Teams haben oft eigene Repositories, um Dokumente/SOPs/Designs usw. zu organisieren, so wie klassische Wissensunternehmen SharePoint verwenden
Es gibt viele Arten, etwas Open Source zu machen
Man sollte das Skript nicht offen mit dem eigenen Benutzerkonto ausführen, sondern anonym über ein Plugin hochladen, das Scraping mit nutzlosen Funktionen kombiniert
Zum Beispiel mit einer Funktion, die sagt, ob eine bestimmte Fließkommazahl gerade ist
Natürlich gibt es solche Zahlen nicht
Dann führt man es aus und gibt sich anschließend als Opfer aus
„Gestern haben wir eine Kompromittierung eines Mitarbeitergeräts im Zusammenhang mit einer kontaminierten VS-Code-Erweiterung erkannt und blockiert. Wir haben die bösartige Version der Erweiterung entfernt, den Endpoint isoliert und sofort mit der Incident Response begonnen.“
Toll, dass sie die Erweiterung entfernt haben
Machen sie das erst, nachdem ihre eigenen Mitarbeiter infiziert wurden?
Und warum nennen sie den Namen der Erweiterung nicht?