! VS Code-Erweiterungen: der Angriff, der 3.800 interne Repositories ausgesetzt

GitHub hat bestätigt, dass ein Gerät eines Mitarbeiters mit einer bösartigen Erweiterung von Visual Studio Code die Exfiltration von Hunderten oder Tausenden von internen Repositories erlaubt; die Figur, die zirkuliert - um 3.800 interne Repositorys- fällt "direktional" mit der internen Bewertung, die das Unternehmen bisher getan hat. GitHub sagt, dass es die vergiftete Version der Erweiterung des Marktplatzes entfernte, den betroffenen Endpunkt isolierte und die Reaktion auf Vorfälle initiierte, und im Moment hat keine Beweise gefunden, dass Kundendaten außerhalb dieser internen Repositorien beeinträchtigt wurden ( GitHubs Erklärung)

Parallel dazu hat ein Schauspieler, der als TeamPCP identifiziert wird, angebliche Muster der Beute veröffentlicht und versucht, den Verkauf von Daten in kriminellen Foren zu verhandeln, eine Taktik, die wir bereits mit Angriffen auf die Software-Versorgungskette gesehen haben. Diese Episode zeigt wieder zwei gleichzeitige Realitäten: Die Entwicklungstools sind jetzt ein hochauflösender Angriffsvektor und die Angreifer nutzen weiterhin das Vertrauen, das die Teams in Drittanbietererweiterungen und Ergänzungen setzen.

VS Code-Erweiterungen sind sehr nützlich für Entwickler, aber auch gefährlich, wenn sie Gewinde sind: in den letzten Jahren haben mehrere Fälle von Plugins mit Millionen von Downloads erschienen, die Anmeldeinformationen, gefilterte lokale Dateien oder implementierte Malware als Kryptomineros. Dass eine einzige böswillige Erweiterung den Weg zur Exfiltration von internen Repositories öffnen kann, bestätigt, dass die Angriffsfläche nicht nur der Code selbst ist, sondern die Werkzeuge, mit denen Sie arbeiten. Um zu verstehen, wie das Ökosystem funktioniert und die zu ergreifenden Vorkehrungen, Microsoft hält offizielle Dokumentation der Marketing und Erweiterungen in VS Code ( VS Code Market Dokumentation)

Welche praktischen Konsequenzen hat dies für Unternehmen und Entwickler? Kurzfristig muss jede Organisation mit direkten Integrationen oder Abhängigkeiten der betroffenen Repositorys Risiken eingehen: Eigentumscode, Bereitstellungsskripte, eingebettete Token oder interne Dokumentation könnten beeinträchtigt werden. Obwohl GitHub die Intrusion noch nicht öffentlich zuschreibt oder den vollen Umfang bestätigt, prudence zwingt diesen Vorfall als ernste Sicherheitslücke behandelt und unverzüglich handeln.

Operationelle Empfehlungen, die bereits umgesetzt werden sollten: Überprüfen und Verdrehen von Anmeldeinformationen und Token mit Zugang zu internen Repositorien und verwandten Systemen; Audit GitHub Aufzeichnungen und Netzwerkprotokolle zur Identifizierung von Klonen, atypischen Zugriffen oder Massenübertragungen; zwingen Sie die Regeneration von persönlichen und Service-Schlüsseln, wenn es Zweifel gibt; und halten Sie die Endpunkte, die mit EDR-Lösungen oder forensic-Analyse betroffen sind isoliert und analysiert. GitHub bietet Tools und Dokumentationen für Tokenmanagement, Audit-Aufzeichnungen und geheimes Scannen, die in diese Prozesse einbezogen werden sollten ( tokens management in GitHub)

Mittel- und langfristig sollten Organisationen die Kontrolle über die Entwicklungsumgebung erhöhen: Erweiterungs-Installationsrichtlinien (allowlist / denylist) umsetzen oder lokale Anlagen in Maschinen untersagen, die Zugang zu kritischen Repositorien haben; Entwicklungsumgebungen auf isolierte Container oder Schreibtische verschieben; das Prinzip des kleinen Privilegs in Tokens und Repository-Zulassungen anwenden und das Scannen von Geheimnissen in Commits und Artefakten automatisieren. Darüber hinaus ist es unerlässlich, IDE und Endpunkttelemetrie mit internen Detektionssystemen zu integrieren, um seltsame Verhaltensweisen von Erweiterungen und Prozessen zu erkennen.

Für einzelne Entwickler ist die praktische Empfehlung extrem vorsichtig: Installieren Sie nur Erweiterungen von Editoren, die von verifizierten Autoren gut gepflegt werden, überprüfen Sie den Quellcode der Erweiterung, wenn möglich, überprüfen Sie, welche Berechtigungen Sie anfordern und bevorzugen Anwendungen in isolierten Umgebungen bei der Arbeit mit empfindlichen Repositories. Die Community und Lieferanten müssen mehr Sicherheit im Markt verlangen: Erweiterungssignaturen, strengere automatisierte Validierung und Transparenz auf den Einheiten und Telemetrie der Plugins.

Dieser Vorfall erinnert daran, dass die Sicherheit der modernen Software die Sicherheit der Werkzeuge umfasst, die sie produzieren. Unternehmen, Plattformanbieter und Entwickler haben unterschiedliche, aber komplementäre Rollen: Plattformen müssen die Überprüfung und den Vertrieb von Erweiterungen verschärfen, und Organisationen müssen davon ausgehen, dass die Aufgabe des Entwicklers ein kritisches Gut ist, das Kontrollen so streng erfordert, wie sie auf Produktionsinfrastrukturen angewendet werden. Für diejenigen, die sich vertiefen wollen, wie man Risiken in der Software-Versorgungskette abmildern kann, ist es angebracht, spezialisierte Ressourcen und Community-Führer zur Verfestigung von Lieferketten zu lesen (z.B. öffentliche Projekte und Empfehlungen in der OWASP- und Lieferantensicherheitsdokumentation). OWASP - Lieferkettenangriffe.