Es ist ein offenes Geheimnis: GitHub und sein Mutterkonzern Microsoft haben aktuell ein massives Sicherheitsproblem. Die jüngste Bestätigung, dass Angreifer Zugriff auf GitHubs interne Repositories erlangt haben, ist nicht nur ein weiterer Sicherheitsvorfall – er ist das direkte Resultat einer vernachlässigten Sicherheitskultur in den hauseigenen Entwickler-Ökosystemen.
Der Vorfall: Ein vergiftetes Werkzeug
GitHub gab bekannt, dass ein Angreifer durch die Kompromittierung eines Mitarbeiter-Geräts auf interne Repositories zugreifen konnte. Die Ursache? Eine verseuchte VS-Code-Extension. Ein Entwickler installierte ein malicious Add-on aus dem offiziellen Visual Studio Code Marketplace, wodurch der Angreifer Zugriff auf den Rechner und somit auf interne GitHub-Systeme erlangte. Der Vorfall führte zum Diebstahl von Quellcode aus internen Repositories – die Angreifer sprechen von 3.800 betroffenen Repositories, was mit GitHubs eigener Einschätzung übereinzustimmen scheint.
Die Ironie könnte größer nicht sein: Microsofts Plattform GitHub wurde gehackt, weil ein Microsoft-Mitarbeiter eine Microsoft-Erweiterung aus dem von Microsoft betriebenen Marketplace installierte. Ein Umstand, der in der Community für helle Empörung und Spott sorgt.
Der VS Code Marketplace als unsicheres Wildwest
Der eigentliche Skandal liegt nicht in der Tatsache, dass ein Mitarbeiter gehackt wurde, sondern im Zustand des VS Code Marketplaces. Seit Jahren wird dieser von Entwicklern und Sicherheitsforschern als rechtsfreier Raum kritisiert. Typo-Squatting, also das Veröffentlichen bösartiger Erweiterungen unter ähnlichen Namen wie beliebte Original-Extensions, ist dort an der Tagesordnung. Beschwerden an versteckte E-Mail-Adressen verhallen oft ungehört.
Sicherheitsforscher von Unternehmen wie Socket, die regelmäßig solche Malware-Wellen aufdecken, fühlen sich von Microsoft im Stich gelassen. Obwohl Socket und andere oft schneller sind als die Plattformbetreiber, gibt es keinen direkten "Kill-Switch" oder automatisierte Prozesse, um bekannte Malware sofort aus dem Verkehr zu ziehen. Stattdessen müssen Forscher oft auf Umwege gehen, um Vorfälle zu melden. Socket kürzlich eine 60-Millionen-Dollar-Finanzierungsrunde mit einer Bewertung von einer Milliarde Dollar – ein klares Zeichen dafür, wie groß der Bedarf an Security im Package-Management mittlerweile ist. Dass Microsoft hier nicht längst aufgerüstet hat, ist ein Versäumnis mit Folgen.
Die Nx-Console-Lücke: Nur 18 Minuten reichen aus
Laut einer detaillierten Analyse des Security-Unternehmens Aikido war die betroffene Extension höchstwahrscheinlich eine kompromittierte Version der beliebten "Nx Console". Diese Erweiterung verfügt über 2,2 Millionen Installationen und trägt sogar das "Verified Publisher"-Badge von Microsoft – ein Gütesiegel, das offensichtlich wenig Aussagekraft hat.
Die bösartige Version war nur für 18 Minuten auf dem Marketplace verfügbar, bevor sie entfernt wurde. Doch diese Zeitspanne reichte aus. Der Angriff nutzte einen gestohlenen GitHub-Token eines Nx-Mitwirkenden, der aus einer früheren Supply-Chain-Attacke stammte. Dies offenbart das wahre Ausmaß der aktuellen Bedrohungslage: Die Angreifer sitzen auf einem gewaltigen Berg an gestohlenen Credentials. Sie werten diese Datenmengen aktuell nur langsam aus und werden in den kommenden Wochen und Monaten immer wieder neue Tokens testen und angreifen. Selbst wenn aktuelle Lücken geschlossen werden, bleiben die alten Tokens in den Händen der Angreifer.
Das Problem mit npm und "Trusted Publishing"
Der Vorfall bei den internen Repositories ist nur die Spitze des Eisbergs. Parallel dazu kämpft GitHub mit massiven Supply-Chain-Attacken auf npm. Als Reaktion auf jüngste Angriffe (wie den Tanstack-Vorfall) widerrief npm alle granularen Access-Tokens, die Two-Factor-Authentication umgingen, und verwies auf "Trusted Publishing" als Lösung.
Doch das ist eine gefährliche Illusion. Trusted Publishing bindet das Veröffentlichen von Packages an spezifische GitHub-Actions-Workflows. Das Problem: Wenn Angreifer über Cache-Poisoning in GitHub Actions diese Workflows manipulieren – etwa durch das Ausnutzen falscher Trigger wie pull_request_target statt pull_request –, funktioniert Trusted Publishing nicht als Schutzschild, sondern als Einfallstor. Die Aussage, Trusted Publishing löse das Problem, ist daher sachlich falsch und eine Beleidigung für die Entwickler, die aktuell Opfer dieser Angriffe werden.
Fazit: Eine Kultur der Nachlässigkeit
GitHub hat derzeit keinen CEO, die Uptime war in der jüngeren Vergangenheit miserabel, und die Security-Infrastruktur rund um npm und den VS Code Marketplace ist ein Flickwerk. Der aktuelle Hack der internen Repositories ist kein Zufallstreffer, sondern das Resultat einer nachlässigen Sicherheitskultur. Solange Microsoft seine eigenen Marktplätze nicht sauber moderiert, bekannte Schwachstellen in GitHub Actions nicht konsequent schließt und Security-Forschern nicht die Werkzeuge an die Hand gibt, um schnell zu reagieren, werden solche Vorfälle zur Regel. Entwickler müssen sich darauf einstellen, dass das Vertrauen in die Lieferkette weiter erodiert – und dass die eigenen Endgeräte durch die Werkzeuge infiziert werden können, die sie täglich zur Arbeit nutzen.
