Twitch, 31.000 token OAuth esposti: l’estensione JeetBot trasformava il proxy in furto di sessione

🛡️ Executive Summary

• Twitch Enhanced Viewer | JeetBot inoltrava ai proxy dell’operatore il token OAuth di circa 31.000 utenti Chrome e Firefox.
• Il token consentiva accesso a chat, whisper e funzioni dell’account senza conoscere password né superare nuovamente il secondo fattore.
• Le versioni precedenti inviavano esplicitamente i token a endpoint dedicati; quelle recenti li inserivano direttamente nelle URL indirizzate ai proxy.

Circa 31.000 utenti Twitch hanno utilizzato un’estensione Chrome e Firefox che inoltrava il loro token OAuth di sessione a infrastrutture proxy controllate dallo stesso operatore del servizio. La ricerca di Socket riguarda Twitch Enhanced Viewer | JeetBot, componente presentato come utility per bloccare pubblicità, forzare lo streaming a 1080p, aggirare limitazioni regionali e raccogliere automaticamente i channel point. Le funzioni promesse esistevano realmente, ed è proprio questo a rendere il caso più significativo della classica estensione palesemente fraudolenta: per far funzionare il proxy, il componente intercettava traffico Twitch autenticato e trasferiva una credenziale molto più potente di quanto servisse per riprodurre il video. Il confine violato non è quindi semplicemente quello della privacy, ma quello tra una funzione legittima del browser e il possesso della sessione autenticata dell’utente.

JeetBot era disponibile su Chrome e Firefox con oltre 30.000 installazioni

La ricerca tecnica pubblicata dal Socket Threat Research Team identifica l’estensione con ID Chrome pnhhdhhcadcjfckjhpmjneldiegbojfb e identificativo Firefox [email protected]. Al momento dell’analisi risultavano circa 30.000 utenti sul Chrome Web Store e 552 su Firefox Add-ons. Il componente non si limitava a imitare una funzione utile: bloccava effettivamente gli annunci Twitch, permetteva di forzare la qualità a 1080p, prometteva region unlocking e automatizzava la raccolta dei punti dei canali. Per implementare alcune di queste capacità instradava le richieste delle playlist video Twitch attraverso proxy controllati dall’operatore. Il problema nasceva dal modo in cui veniva costruita quella richiesta: insieme all’URL del flusso, le versioni correnti della serie 85.x aggiungevano il token OAuth dell’account come parametro auth della query. Il proxy riceveva quindi non soltanto una richiesta necessaria alla riproduzione dello stream, ma una credenziale bearer associata all’account Twitch. Il comportamento ricorda una dinamica già osservata nelle 19 estensioni Chrome ed Edge capaci di rubare wallet, credenziali e sessioni attraverso componenti apparentemente utili: il browser non viene necessariamente sfruttato attraverso una vulnerabilità, perché è l’utente stesso a installare software dotato delle capacità necessarie per osservare la sessione.

Il token rubato non era quello necessario soltanto allo streaming

La distinzione tecnica più importante riguarda quale token venisse prelevato. Twitch utilizza credenziali differenti per scopi differenti e l’estensione disponeva già dei parametri necessari per accedere allo stream video attraverso le richieste usher.ttvnw.net. JeetBot, invece, intercettava anche l’header Authorization utilizzato dal client Web ufficiale di Twitch e lo trasferiva dal content script al background worker dell’estensione. Il codice recuperava quindi il token OAuth grezzo e lo validava persino contro l’endpoint ufficiale di Twitch prima di utilizzarlo.

Socket sottolinea che si tratta di una credenziale di sessione account-scoped, non di un token limitato alla visualizzazione del flusso video. Chi possiede quel valore può agire come la sessione autenticata: accedere alle chat, inviare o leggere whisper, interagire con impostazioni dell’account e utilizzare i channel point secondo i privilegi associati. La password non deve essere nuovamente conosciuta e la presenza della 2FA non impedisce l’abuso di una sessione già autenticata. È lo stesso motivo per cui il furto di cookie e token ha progressivamente acquistato valore nel cybercrime: rubare ciò che dimostra che l’autenticazione è già avvenuta può essere più conveniente che sottrarre direttamente password e OTP.

Leggi anche: 108 estensioni Chrome rubavano sessioni Telegram e token OAuth Google direttamente dal browser

Le versioni precedenti inviavano direttamente i token a endpoint dedicati

La ricostruzione storica rende difficile interpretare l’esposizione come un semplice errore implementativo. Nelle versioni 4.x, inclusa la 4.8 distribuita nel gennaio 2026, JeetBot utilizzava endpoint esplicitamente denominati set-token. Il worker acquisiva il token, lo inseriva in una richiesta JSON e lo inviava attraverso POST verso il proxy principale oppure verso due infrastrutture di backup ospitate su Deno. Il codice manteneva inoltre memoria dell’ultimo token trasmesso e introduceva un cooldown di cinque secondi per evitare invii troppo frequenti.

Le versioni successive non utilizzano più il medesimo endpoint. Dopo il salto di numerazione dalla serie 7.2.6 alla 85.2.2, avvenuto il 20 maggio, il token è stato invece inserito direttamente nelle URL inoltrate ai proxy attraverso il parametro &auth=. Dal punto di vista della sicurezza il cambiamento non elimina il problema. Al contrario, l’inserimento di una credenziale all’interno della query string significa che il token può finire direttamente nei log HTTP del proxy, nei sistemi di osservabilità o in qualsiasi ulteriore componente che registri la URL completa.

Questa evoluzione è importante perché distingue il caso dalla semplice richiesta eccessiva di permessi. Il componente aveva una logica specifica per acquisire, conservare e trasferire il token. La privacy policy collegata all’estensione dichiarava invece che il software non raccoglieva, archiviava o trattava dati degli utenti, mentre la sezione sulla sicurezza dei dati del Chrome Web Store affermava che lo sviluppatore non avrebbe raccolto o utilizzato quelle informazioni.

Dieci canali russi erano esclusi dall’invio del token

Socket ha individuato nel codice un’altra anomalia: una lista codificata di dieci canali Twitch di lingua russa per i quali il token veniva rimosso dalla richiesta prima di passare attraverso il proxy. Tra questi compaiono streamer e figure note nell’ecosistema Counter-Strike. Per tutti gli altri canali, invece, il comportamento predefinito prevedeva l’inoltro della credenziale.

La presenza di questa allowlist non dimostra da sola la finalità precisa dell’operazione, ma mostra che il trattamento del token non era uniforme né tecnicamente inevitabile. Il software era perfettamente capace di effettuare il proxying senza trasferire la credenziale per determinati canali. Il fatto che quella protezione fosse applicata soltanto a un insieme specifico rafforza quindi la conclusione che l’invio generalizzato dei token non derivasse da un requisito intrinseco del servizio di streaming. L’infrastruttura è riconducibile a JeetBot, servizio commerciale in lingua russa che vende automazione per Twitch, Kick e VK-Live. Socket collega i domini utilizzati dall’estensione a tre indirizzi IP e rileva che lo stesso operatore controllava lato server il catalogo dei proxy ai quali il browser poteva essere indirizzato. Il sito attribuisce pubblicamente l’attività a Popov Aleksandr Alekseevich; questo costituisce un’identificazione dichiarata dall’infrastruttura commerciale e non deve essere confuso automaticamente con un’attribuzione criminale personale.

Il caso mostra perché un’estensione può bypassare password e 2FA senza violare Twitch

La superficie di attacco più interessante non è Twitch. Non risulta infatti necessario sfruttare una vulnerabilità della piattaforma, compromettere i suoi server o spezzare OAuth. JeetBot operava dopo l’autenticazione, nel punto in cui il browser possiede già le credenziali necessarie per rappresentare l’utente. È un modello particolarmente efficace perché l’estensione vive nello stesso ambiente nel quale vengono generate e utilizzate le sessioni. Quando dispone dei permessi sufficienti può osservare richieste, manipolare pagine, modificare destinazioni e trasferire informazioni senza che per forza venga eseguito un classico malware esterno al browser. Il rischio era già emerso con le 737 estensioni VPN e proxy che instradavano il traffico Chrome attraverso una singola infrastruttura controllata: il proxy è esso stesso un confine di fiducia, perché tutto ciò che viene instradato verso di esso diventa potenzialmente osservabile dall’operatore. Nel caso Twitch la situazione è ancora più delicata. Non viene trasferito soltanto traffico di navigazione: una credenziale bearer valida attraversa deliberatamente l’infrastruttura del servizio terzo. Questo riduce fortemente il valore protettivo della password complessa o dell’autenticazione a più fattori. La 2FA protegge il processo di autenticazione; non può impedire che una credenziale prodotta dopo quell’autenticazione venga copiata da software già presente all’interno del browser.

Rimuovere l’estensione non basta se il token è già stato inoltrato

Socket raccomanda agli utenti che hanno installato Twitch Enhanced Viewer | JeetBot di rimuovere immediatamente l’estensione da Chrome o Firefox e successivamente disconnettere tutte le sessioni Twitch e autenticarsi nuovamente. Il secondo passaggio è essenziale: cancellare l’estensione impedisce ulteriori acquisizioni, ma non rende automaticamente inutilizzabile una credenziale precedentemente trasferita. La revoca delle sessioni costringe Twitch a invalidare i token esistenti. Per i team aziendali il caso offre un’indicazione ancora più generale. Un’estensione dotata di autorizzazioni sugli host di un servizio autenticato e contemporaneamente capace di comunicare con proxy di terze parti deve essere trattata come una potenziale superficie di esposizione delle credenziali. Socket mappa l’attività alle tecniche MITRE ATT&CK T1176 Browser Extensions, T1539 Steal Web Session Cookie, T1557 Adversary-in-the-Middle e T1071.001 Web Protocols. Non è sufficiente quindi inventariare soltanto gli eseguibili installati sugli endpoint. Le estensioni sono codice persistente, vengono spesso aggiornate automaticamente e operano all’interno di una delle applicazioni nelle quali si concentra la maggior quantità di identità già autenticate dell’intera workstation.

Continua con:

• PEEP trasforma Chrome ed Edge in backdoor persistenti e usa il browser per rubare cookie e sessioni
• Rust e Firefox sotto attacco: 77 estensioni collegate al furto di wallet e credenziali

Il browser è diventato un deposito di identità e le estensioni ne ereditano il valore

Il caso JeetBot mostra perché la sicurezza delle estensioni non può più essere trattata come un problema marginale del browser. Un utente autenticato su Twitch, Google, Microsoft, exchange, wallet Web3 o piattaforme aziendali porta nel browser una quantità crescente di credenziali temporanee che rappresentano direttamente la propria identità. Non è necessario rubare la password quando è possibile acquisire il token che certifica che quella password è già stata verificata. JeetBot rende il problema ancora più evidente perché la funzione che giustificava l’installazione era reale. L’utente otteneva effettivamente blocco degli annunci, proxy e altre utilità Twitch. Il comportamento malevolo non sostituiva la funzione legittima: viaggiava insieme ad essa, sfruttando precisamente la posizione privilegiata necessaria per implementarla. È questa la parte più difficile da intercettare attraverso il semplice buon senso dell’utente. L’estensione era disponibile negli store, aveva migliaia di installazioni e svolgeva il lavoro promesso. Il rischio si trovava nel flusso dati nascosto dietro quella funzione: una richiesta video diventava il veicolo con cui una credenziale di sessione lasciava il browser. Nel nuovo modello di sicurezza del Web, quindi, verificare da dove proviene un’estensione non basta. Bisogna capire quali pagine può leggere, quali richieste può modificare e soprattutto verso quali server esterni può trasferire ciò che vede. Perché quando il browser contiene la sessione, controllare il browser significa sempre più spesso controllare direttamente l’account.