Forscher von ReversingLabs haben eine Schwachstelle in der Integritaet des Visual Studio Code Marketplace aufgezeigt: Nach einem Hard Delete koennen Erweiterungsnamen erneut von Dritten registriert werden. Anlass war die Entdeckung des boesartigen Add-ons ahbanC.shiba, das funktional mit bereits im Maerz 2025 beobachteten Varianten ahban.shiba und ahban.cychelloworld uebereinstimmt. Das Risiko: Vertraute Namen lassen sich kapern, um Anwendern manipulierte Pakete als legitime Erweiterungen zu praesentieren.
Analyse der Malware-Kette: Loader, PowerShell und Erpressung
Laut ReversingLabs agieren alle drei Erweiterungen als Loader, die eine PowerShell-Nutzlast von einem entfernten Server nachladen. Diese Nutzlast verschluesselt Dateien im Desktop-Ordner testShiba und startet eine Erpressungsroutine mit Zahlungsforderung in Shiba Inu-Tokens. Das Verhalten deutet auf eine fruehe Entwicklungsphase des Schadcodes hin, zeigt aber bereits, wie niedrig die Einstiegshuellen fuer Supply-Chain-Angriffe in der VS-Code-Oekosystem sind.
Identitaetsmodell in VS Code: Wie Name-Reuse Brandjacking ermoeglicht
Erweiterungen in VS Code werden eindeutig durch die Kombination <publisher>.<name> identifiziert. Laut Microsoft-Dokumentation muss das Feld name kleingeschrieben, ohne Leerzeichen und innerhalb des Marktplatzes eindeutig sein (Quelle). Die untersuchten boesartigen Pakete unterschieden sich lediglich im Publisher, waehrend der eigentliche Name identisch blieb.
ReversingLabs zeigt: Nach dem vollstaendigen Loeschen (Hard Delete) eines Pakets kann derselbe Name durch einen anderen Publisher erneut belegt werden. Dieses Verhalten tritt nicht auf, wenn Autoren eine Depublikation vornehmen, ohne die Artefakte zu entfernen. Die Wiederverwendung eroefnet ein Fenster fuer Brandjacking und erhoeht die Wahrscheinlichkeit, dass unter bekannten Bezeichnungen neue, potenziell schaedliche Inhalte veroeffentlicht werden.
Vergleich mit Paket-Oekosystemen: PyPI als Referenz
Ein aehnliches Problem wurde in der Vergangenheit auch im Python Package Index (PyPI) beobachtet: Nach der Entfernung eines Projekts konnten Namen erneut registriert werden, wenn sich die Dateinamen der Distributionen unterschieden. Mit PEP 541 hat PyPI jedoch einen Mechanismus etabliert, um missbrauchte oder verwaiste Namen zu sperren bzw. kontrolliert zu ueberschreiben. Nach Erkenntnissen von ReversingLabs existiert im Visual Studio Code Marketplace bislang kein vergleichbares Verfahren zur Quarantaene oder dauerhaften Sperrung auffaelliger Namensraeume.
Risiken fuer Entwickler und Unternehmen: Name-Squatting, Typosquatting, Austauschangriffe
Die Wiederverwendung von Namen foerdert Name-Squatting, Typosquatting und den unbemerkten Austausch von Erweiterungen bei Suche und automatischer Installation. Wird ein populaeres Add-on aus rechtlichen, Moderations- oder Betriebsgruenden entfernt, kann der Name kurzfristig durch Angreifer neu belegt werden. Solche Pakete koennen im Editor erweiterte Berechtigungen anfordern, Terminal-Kommandos ausfuehren oder Nutzlasten aus dem Netz nachladen – typische Bausteine einer Supply-Chain-Kompromittierung.
Praxisbeispiel aus dem Marketplace
Nutzer treffen auf ein vertrautes Erweiterungslabel und installieren es, ohne den geaenderten Publisher oder das Publikationsdatum zu pruefen. Das Ergebnis: Ein neues Paket gelangt in die Entwicklungsumgebung, das als Loader fungiert, PowerShell missbraucht und Daten verschluesselt – hier demonstriert durch die testShiba-Dateien mit anschliessender Krypto-Forderung.
Massnahmen: Plattform-Haertung und betriebliche Schutzkonzepte
Fuer Plattform und Oekosystem: Namen geloeschter Erweiterungen automatisiert reservieren oder in Quarantaene setzen; Namensraeume mit Missbrauchshistorie blockieren; Publisher staerker verifizieren; deutliche Warnhinweise bei Re-Registrierung frueher verwendeter Namen anzeigen; einen transparenten Ownership-Verlauf bereitstellen.
Fuer Organisationen: Allowlists vertrauenswuerdiger Publisher/Erweiterungen fuehren; Abhaengigkeiten an Publisher-ID und exakte Versionen pinnen; interne Proxy-/Mirror-Kataloge nutzen; Installation und Netzaktivitaet der IDE kontinuierlich monitoren; EDR/AV-Richtlinien einsetzen, um PowerShell-Missbrauch zu unterbinden.
Fuer Entwickler und Maintainer: statt endgueltig zu loeschen besser depublizieren; verifizierte Publisher-Accounts verwenden; Fingerprints (Name, Publisher, Hash) dokumentieren; Nutzer bei Aenderung des Distributionskanals fruehzeitig informieren.
Der Fall ahbanC.shiba fuehrt vor Augen, wie unklare Regeln zur Namensvergabe eine reale Angriffsoberflaeche in Entwickler-Oekosystemen schaffen. Betreiber des VS Code Marketplace sollten Namensreserven, Verifikationsprozesse und Missbrauchssperren nach dem Vorbild von PyPI priorisieren. Teams und Entwickler koennen durch saubere Governance, Pinnen auf Publisher-IDs und kontinuierliches Monitoring das Risiko von Brandjacking und Loader-Ketten deutlich senken. Weitere Details und kontinuierliche Updates liefern die Dokumentation von Microsoft zum Veroeffentlichen von Erweiterungen sowie die Analysen von ReversingLabs (Blog).
