Google DevSite: sessioni Flask falsificabili aprivano alla remote code execution

• Falla critica in Google DevSite: cookie Flask falsificabili portavano a esecuzione di codice remoto
• Colpiti siti per sviluppatori Google, tra cui developers.google.com e firebase.google.com
• Non serviva alcun account Google; corretta il 7 ottobre 2026, bounty da 90.000 dollari
• Per gli sviluppatori: niente pickle su dati esterni, segreti separati e sessioni lato server

Una vulnerabilità critica nella piattaforma condivisa DevSite di Google avrebbe permesso a un attaccante non autenticato di falsificare i cookie di sessione Flask e ottenere l’esecuzione di codice da remoto su diversi siti per sviluppatori dell’azienda. A segnalarla è il ricercatore Simon Koeck. Secondo quanto riportato, Google ha corretto il problema il 7 ottobre 2026, dopo la segnalazione ricevuta ad agosto, e ha riconosciuto al ricercatore 90.000 dollari attraverso il Vulnerability Reward Program.

I siti coinvolti

La falla riguardava il flusso OAuth usato dai siti di documentazione per sviluppatori di Google, tra cui developers.google.com, firebase.google.com, developer.android.com, source.android.com e docs.partner.android.com. Trattandosi di una piattaforma condivisa e non di un singolo sito, l’impatto potenziale era esteso a più proprietà web.

Come funzionava la catena di attacco

Il meccanismo di sessione standard di Flask firma i cookie per impedirne la modifica, ma non ne cifra il contenuto. Chiunque può leggerli, ma non alterarli senza la chiave di firma (SECRET_KEY).

Nel cookie emesso dall’endpoint OAuth di DevSite, però, c’era di più di un token CSRF e di un URL di ritorno. Decodificando il contenuto compresso, il ricercatore ha trovato un oggetto serializzato del flusso OAuth con client ID e client secret di Google OAuth. Il punto critico: lo stesso client secret era usato anche come chiave di firma delle sessioni Flask.

Chi otteneva un cookie poteva quindi ricavare il segreto, generare firme valide e creare sessioni false considerate affidabili dal server. Da sola, la falsificazione consentiva di alterare i valori della sessione. Il rischio di esecuzione di codice nasceva dalla gestione della callback OAuth: l’applicazione decodificava in Base64 l’oggetto del flusso e lo passava a pickle.loads() di Python. La documentazione di Python avverte che pickle non è sicuro con dati non fidati, perché un payload costruito ad hoc può eseguire codice durante il ripristino.

Con la chiave di firma, un attaccante poteva dunque inserire in una sessione valida un oggetto pickle manipolato, che il server avrebbe deserializzato eseguendo codice scelto da chi attaccava. Per raggiungere l’endpoint e ottenere il cookie non serviva alcun account Google.

La prova di concetto

Koeck non ha eseguito comandi di sistema sull’infrastruttura di Google. La dimostrazione ha usato un payload innocuo con ritardo temporale: le richieste risultavano rallentate esattamente del numero di secondi indicato nell’oggetto serializzato, a conferma che il server eseguiva la funzione Python scelta.

Come ha risposto Google

Secondo il ricercatore, Google ha:

• ruotato i client secret OAuth esposti;
• invalidato le sessioni firmate con quei segreti;
• separato i valori di SECRET_KEY di Flask dalle credenziali OAuth;
• spostato gli oggetti del flusso OAuth in uno storage lato server.

Indicazioni per gli sviluppatori

La fonte indica come approccio più sicuro un cookie che contenga solo un riferimento opaco alla sessione, con lo stato sensibile conservato sul server. Va inoltre eliminato pickle da qualsiasi percorso di dati su cui possano influire browser, utenti, partner o sistemi esterni. Un formato di soli dati come JSON, con validazione rigorosa dello schema, impedisce che la deserializzazione diventi esecuzione di codice.

La lezione è che una sessione firmata è affidabile solo se la chiave resta segreta e se l’applicazione non trasforma mai in oggetti eseguibili i dati controllati da un attaccante.

Fonte: Cyber Security News · Foto: Cyber Security News