Un bug di Visual Studio Code permette il furto dei token GitHub con un clic

Un semplice clic su un collegamento potrebbe bastare per compromettere un account GitHub dotato di accesso a repository privati, capacità di scrittura sul codice e gestione di progetti aziendali. È la conclusione di una ricerca pubblicata da Ammar Askar, sviluppatore e ricercatore di sicurezza, che ha analizzato una vulnerabilità presente in Visual Studio Code e nelle versioni web dell’editor, incluse github.dev e vscode.dev.

La questione assume un peso particolare se si considera che GitHub rappresenta uno dei pilastri della collaborazione software mondiale e che i token di accesso costituiscono spesso una chiave universale verso codice sorgente, infrastrutture cloud e processi CI/CD. La sottrazione di token continua a essere una delle tecniche più efficaci per ottenere accessi non autorizzati a repository e servizi associati.

Come funziona github.dev e perché il token GitHub è così prezioso

Il sito github.dev permette di aprire un repository direttamente nel browser attraverso una versione alleggerita di Visual Studio Code. L’esperienza appare simile a quella dell’applicazione desktop: navigazione del codice, modifica dei file, creazione di commit e gestione delle pull request.

Dietro questa comodità si nasconde però un elemento particolarmente sensibile: un token OAuth che GitHub trasferisce all’ambiente web per consentire all’utente di operare sui repository. Il punto critico evidenziato dalla ricerca è che il token non risulta limitato al singolo repository aperto: chi riuscisse a impossessarsene potrebbe ottenere accesso a tutti i repository per i quali l’utente dispone di autorizzazioni.

Per uno sviluppatore individuale il danno potrebbe tradursi nella perdita di codice privato. Per un’organizzazione il rischio cresce rapidamente: repository interni, configurazioni, workflow automatizzati, segreti applicativi e script operativi potrebbero finire nelle mani di un attaccante.

Il modello di sicurezza delle WebView di Visual Studio Code

Visual Studio Code utilizza componenti chiamati WebView per mostrare contenuti dinamici all’interno dell’interfaccia: estensioni, notebook interattivi e numerosi plugin fanno affidamento su questo meccanismo. Microsoft ha progettato le WebView con una serie di restrizioni volte a impedire l’esecuzione arbitraria di codice JavaScript.

Secondo quanto documentato da Askar, tuttavia, la vulnerabilità scoperta consentiva a un aggressore di ottenere l’esecuzione di codice all’interno dell’ambiente editor, superando le limitazioni imposte dal modello di isolamento delle WebView.

La vittima apre un collegamento che punta a un notebook ospitato su github.dev. Attraverso il bug di sicurezza, il contenuto del notebook riesce a eseguire codice JavaScript non autorizzato. A questo punto inizia una seconda fase: l’installazione automatica di una estensione capace di accedere alle funzionalità interne dell’editor. L’estensione recupera il token GitHub associato alla sessione e lo utilizza per interrogare le API della piattaforma.

Il proof of concept pubblicato da Askar effettua una chiamata verso l’endpoint API dedicato all’elenco dei repository dell’utente: il risultato compare direttamente nell’interfaccia, insieme al token sottratto, dimostrando l’avvenuta compromissione. In uno scenario reale un malware potrebbe inviare il token verso un server remoto senza mostrare alcun segnale evidente. Da quel momento l’attaccante potrebbe leggere repository privati, creare commit, modificare configurazioni oppure distribuire codice malevolo attraverso progetti legittimi.

Il furto del token GitHub rappresenta soltanto una delle possibili conseguenze della vulnerabilità. La ricerca mostra infatti come un attaccante possa ottenere l’installazione di estensioni arbitrarie all’interno dell’ambiente VS Code eseguito nel browser. Una capacità di questo tipo amplia notevolmente la superficie d’attacco disponibile e apre la strada a scenari che vanno oltre la semplice sottrazione delle credenziali di accesso ai repository.

Come ridurre il rischio di compromissione dei token GitHub

La principale contromisura suggerita dal ricercatore appare relativamente semplice per gli utenti di github.dev. Eliminare cookie, dati locali e dati di archiviazione del sito costringe la piattaforma a richiedere nuovamente l’autenticazione e interrompe alcune delle condizioni necessarie per l’attacco.

Una buona pratica consiste nell’applicare il principio del privilegio minimo: i moderni Personal Access Token permettono di limitare autorizzazioni e ambiti operativi. Quando possibile conviene utilizzare token con scadenza breve e permessi circoscritti.

Anche il monitoraggio assume un ruolo importante: GitHub offre strumenti di rilevamento delle credenziali esposte e sistemi di secret scanning che aiutano a individuare token pubblicati accidentalmente nei repository. Questi controlli non impediscono il furto di un token attivo, ma possono ridurre sensibilmente il tempo di esposizione.

Perché il ricercatore ha scelto di condividere subito i dettagli della vulnerabilità

La pubblicazione della vulnerabilità non ha seguito il classico schema della responsible disclosure. Askar spiega apertamente le ragioni della sua scelta nella sezione “Why Full Disclosure?”, dove ripercorre alcune precedenti esperienze con il Microsoft Security Response Center (MSRC). Secondo il ricercatore, una vulnerabilità segnalata in passato sarebbe stata corretta senza che gli venisse attribuito formalmente il merito della scoperta e senza che Microsoft la classificasse come un problema di sicurezza significativo.

Askar sostiene che quell’episodio abbia influenzato il suo approccio verso le future segnalazioni riguardanti Visual Studio Code. Nel post afferma di aver maturato la convinzione che il processo di gestione delle vulnerabilità adottato per VS Code non offra incentivi adeguati ai ricercatori indipendenti e che alcuni problemi sono sottovalutati durante la fase di analisi iniziale.

La decisione di pubblicare un proof-of-concept completo nasce proprio da questa valutazione. L’autore ritiene che la divulgazione pubblica rappresenti uno dei pochi strumenti a disposizione della comunità di ricerca per attirare l’attenzione su difetti che, a suo giudizio, potrebbero non ricevere la necessaria priorità all’interno dei normali processi di segnalazione.

Proprio di recente Microsoft aveva dichiarato guerra ai ricercatori che pubblicano exploit relativi a falle zero-day che non siano state precedentemente notificate seguendo i canali canonici di responsible disclosure.