GlassWorm-Malware kehrt zurück – diesmal über OpenVSX
Sicherheitsforschende haben eine neue Welle der GlassWorm-Kampagne dokumentiert, die das OpenVSX-Ökosystem (der Visual Studio Code Extension Marketplace) mit 73 manipulierten Extensions infiltriert hat. Das Besondere: Diese Erweiterungen funktionieren initial völlig harmlos.
Das "Sleeper"-Prinzip
Die Extensions verhalten sich nach der Installation unauffällig. Erst durch ein Update werden sie aktiviert und zeigen malicious Verhalten. Dieses Vorgehen ist gezielt darauf ausgerichtet, die anfängliche Sicherheitskontrolle zu umgehen und Entwickler in falscher Sicherheit zu wiegen.
Solche "Sleeper"-Taktiken sind im Supply-Chain-Bereich zunehmend verbreitet, da sie:
- Initial harmlose Aktivitäten nicht triggern
- User Reviews und automatische Scans überstehen
- Zeitverzögert zuschlagen und Ursache-Folge-Verbindungen erschweren
OpenVSX als Angriffsziel
OpenVSX ist ein Community-betriebener Alternative zum proprietären Microsoft Marketplace und wird von vielen Entwicklern als Standard-Registry genutzt. Dass diese Plattform ins Visier gerät, unterstreicht, dass Angreifer systematisch auf weniger überwachte Ökosysteme ausweichen.
Mögliche Angriffsziele
GlassWorm-Kampagnen haben historisch auf unterschiedliche Ziele abgezielt – von Credential-Harvesting bis zu Code-Injection. Die genaue Payload-Charakteristik wird noch analysiert, aber das Muster deutet auf umfassenden Code-Zugriff hin.
Was Entwickler tun sollten
- Extension-Audit: Alle installierten Extensions aus OpenVSX prüfen, besonders jüngere oder weniger bekannte
- Update-Prozesse überdenken: Nicht blind aktualisieren – bei kritischen Tools explizit Change-Logs prüfen
- Marketplace diversifizieren: Nicht nur auf eine Registry verlassen
- Monitoring: IDE-Aktivitäten loggen und auf unerwartete Netzwerk-Requests achten
Konsequenzen für das Ökosystem
Dieser Vorfall zeigt die strukturelle Schwachstelle dezentralisierter Extension-Märkte: Sie profitieren von Offenheit, sind aber anfälliger für Masseninfektionen als zentralisierte, strenger kontrollierte Systeme. OpenVSX müsste verstärkt auf Verhaltensanalysen bei Updates setzen – technisch anspruchsvoll, aber notwendig.
Die Incident Response dürfte sich auf die Identifikation und das Delist-Verfahren konzentrieren. Für betroffene Entwickler ist schnelle Deinstallation der kritische nächste Schritt.