Ein Klick auf einen präparierten Link in einem öffentlichen Repository kann innerhalb von Sekunden alle deine privaten Repositories kompromittieren. Ein Angreifer könnte Code lesen, ändern oder Push-Requests in deinem Namen ausführen. Das ermöglicht eine kürzlich entdeckte Sicherheitslücke in der browserbasierten Version von Visual Studio Code (VSCode), die der Sicherheitsforscher Ammar Askar veröffentlicht hat.
Was ist github.dev und warum ist es ein Ziel?
GitHub bietet mit github.dev eine praktische Funktion. Du kannst aus jedem Repository die URL von github.com auf github.dev ändern oder über das Menü auswählen. Du öffnest dann eine schlanke Version von VSCode im Browser. Diese Web-App kann auf alle Dateien des Repositories zugreifen – auch auf private – und ermöglicht Pull Requests, Commits und mehr. GitHub sendet ein OAuth-Token an github.dev, das dem Browser-Zugriff die vollen Rechte deines Kontos gibt. Dieses Token ist nicht auf das eine Repository beschränkt, sondern erlaubt Lese- und Schreibzugriff auf alle Repositories, auf die du Zugriff hast. Ein Angreifer, der an dieses Token gelangt, hat die Kontrolle über deine komplette GitHub-Präsenz. Die Schwachstelle setzt hier an.
Die Sicherheitsarchitektur von VSCode-Webviews
VSCode verwendet für die Darstellung von Inhalten wie Markdown-Vorschauen oder Jupyter-Notebooks sogenannte Webviews. Das sind Iframes mit einer eigenen Herkunft (vscode-webview://...), die vom Hauptfenster (vscode-file:// oder im Browser entsprechend) getrennt sind. So soll verhindert werden, dass schädlicher Code aus dem Webview auf die Node.js-APIs oder die VSCode-internen Funktionen zugreifen kann. Standardmäßig ist jede Kommunikation zwischen den beiden Fenstern nur über die window.postMessage()-API erlaubt. Das ist eine solide Maßnahme – wenn sie konsequent angewendet wird.
Der Fehler: Tastatureingaben werden ungefiltert weitergereicht
Es gibt eine Ausnahme für die Benutzererfahrung. Wenn du dich in einem Webview befindest und eine Tastenkombination wie Strg+Umschalt+P (Befehlspalette) drückst, erwartest du, dass die Aktion auch im Webview funktioniert. VSCode löst das, indem es standardmäßig einen Event-Handler namens did-keydown im Webview registriert. Dieser lauscht auf Tastatureingaben und leitet sie als Nachricht an das Hauptfenster weiter. Das Problem: Es gibt keine Prüfung, ob die Tastatureingaben tatsächlich vom Benutzer oder von einem Skript innerhalb des Webviews stammen. Ein Angreifer, der JavaScript im Webview ausführen kann – zum Beispiel über eine manipulierte Jupyter-Notebook-Zelle – kann also beliebige Tastatureingaben simulieren.
Der Angriffsablauf im Detail
Um die Lücke für eine Token-Exfiltration zu nutzen, mussten mehrere Hürden überwunden werden. Mit simulierten Tasten kann man die Befehlspalette öffnen und mit Pfeiltasten navigieren, aber Text lässt sich nicht eingeben – der Eingabefokus liegt auf einem HTML-Input-Element, das nicht auf programmatische Tastenevents reagiert. Also nutzt Askar einen anderen Trick: VSCode hat eine Standard-Tastenkombination Strg+Umschalt+A, die die primäre Schaltfläche einer Benachrichtigung bestätigt. Wenn das Webview eine Benachrichtigung auslöst, die zur Installation einer empfohlenen Erweiterung auffordert, kann der Angreifer diese mit Strg+Umschalt+A akzeptieren.
Die nächste Hürde: Seit VSCode 1.97 gibt es einen Vertrauensmechanismus für Verlage (Publisher). Bei der ersten Installation einer Erweiterung eines unbekannten Herausgebers erscheint ein Dialog, der die Zustimmung erfordert. Der Angreifer kann diesen Dialog nicht per Tastendruck bestätigen, weil die Schaltfläche „Publisher vertrauen & installieren“ nur auf direkte Klick-Events reagiert – nicht auf programmatische Tastatureingaben. Hier kommt eine andere VSCode-Funktion ins Spiel: lokale Arbeitsbereichserweiterungen. In einem vertrauenswürdigen Arbeitsbereich (github.dev-Arbeitsbereiche sind immer vertrauenswürdig) können Erweiterungen direkt aus dem Verzeichnis .vscode/extensions installiert werden, ohne den Publisher-Vertrauenscheck zu durchlaufen. Der Angreifer muss also lediglich eine eigene Erweiterung in das Repository des Opfers packen.
Ein weiteres Problem: Die Web-Version von VSCode erwartet Erweiterungen von vscode-cdn.net und schlägt bei lokalen Dateien eine Content Security Policy (CSP)-Verletzung. Askar umgeht das, indem er die Erweiterung so konfiguriert, dass sie selbst eine neue Tastenkombination (Strg+F1) definiert, die den Befehl workbench.extensions.installExtension aufruft – und diesen Befehl so parametrisiert, dass die Publisher-Prüfung übersprungen wird. Nachdem die lokale Erweiterung installiert ist und die neue Tastenkombination aktiv wird, simuliert das Angreifer-Skript ein weiteres Tastendruck-Ereignis für Strg+F1. Daraufhin wird die eigentliche bösartige Erweiterung installiert, die das OAuth-Token ausliest und an den Angreifer sendet.
Der Proof-of-Concept und was du tun kannst
Askar hat einen funktionierenden Proof-of-Concept veröffentlicht. Der Link führt direkt auf ein Jupyter-Notebook in github.dev. Nach einem Klick siehst du eine Statusmeldung, und innerhalb weniger Sekunden werden deine privaten Repositories und dein Token in einem Informationsfenster angezeigt. Wenn du den PoC selbst ausprobierst, solltest du anschließend die Erweiterung deinstallieren und die cookies/local storage von github.dev löschen, da die bösartige Erweiterung sonst auf allen github.dev-Seiten aktiv bleibt. Falls du noch nie github.dev genutzt hast, erscheint vor dem ersten Laden ein Anmeldedialog. Wenn du in diesem Moment den Link nicht klickst, sondern die Seite schließt, bist du sicher.
Was VSCode gut gemacht hat und was fehlt
Der Forscher meldete die Lücke verantwortungsvoll, und sie wurde innerhalb kurzer Zeit geschlossen. Die Version von github.dev erhielt einen Patch, der die Weitergabe von Tastatureingaben aus Webviews einschränkt. Die grundsätzliche Architektur bleibt anfällig, ähnliche Fehler könnten in Zukunft auftreten. Die Desktop-Version von VSCode ist ebenfalls betroffen, allerdings ist der Angriff dort schwieriger, da der Angreifer das Opfer erst dazu bringen muss, das Repository zu klonen und das Notebook zu öffnen.
Was das für dich bedeutet
Die Sicherheitslücke zeigt, wie ein kleiner Kompromiss bei der Benutzerfreundlichkeit schwerwiegende Konsequenzen haben kann. Sei vorsichtig mit Links, die dich auf github.dev öffnen, insbesondere wenn sie auf Jupyter-Notebooks oder andere interaktive Inhalte verweisen. Lösche regelmäßig die Browserdaten für github.dev, wenn du es nicht aktiv nutzt. Ein Klick kann ausreichen, um die Kontrolle über deine gesamte GitHub-Identität zu verlieren.
Quelle: blog.ammaraskar.com
