In questo articolo Indice dei contenuti 2 sezioni
Una vulnerabilità Google nascosta nell’infrastruttura che gestisce la documentazione per gli sviluppatori ha permesso di dimostrare una catena di attacco capace di arrivare fino all’esecuzione di codice remoto sui server dell’azienda. A scoprirla è stato il ricercatore di sicurezza Simon Koeck, che ha ricostruito il problema analizzando con pazienza il sistema di autenticazione e il modo in cui venivano gestite le sessioni degli utenti.
La criticità non nasceva da un singolo errore di configurazione, di quelli che si correggono con un clic. Era piuttosto il risultato di più scelte progettuali che, messe insieme, finivano per compromettere l’integrità dei dati ricevuti dal server. Ogni tassello preso da solo sembrava innocuo, ma sommati formavano una porta d’ingresso piuttosto larga.
Il caso pesa ancora di più perché coinvolge componenti condivisi da diversi servizi del gruppo. Big G ha riconosciuto il valore del lavoro con un premio economico, assegnato dopo aver valutato con attenzione la portata tecnica della segnalazione e il suo impatto potenziale.
Come funzionava la falla nei cookie Flask
Tutto parte dal flusso OAuth di DevSite. Studiandolo, Koeck si è imbattuto in un cookie di sessione generato da Flask, il framework Python su cui si basa l’applicazione. Il contenuto del cookie era leggibile e includeva informazioni legate al processo di autenticazione, compreso un client_secret associato a OAuth. Già questo non era il massimo, però il vero guaio stava altrove. Quella stessa credenziale veniva infatti riutilizzata come chiave per firmare le sessioni.
Una sovrapposizione del genere indeboliva l’intero meccanismo di verifica. Una volta recuperato il segreto, il ricercatore è riuscito a creare cookie con firme valide, modificando a piacimento i dati che il server riteneva affidabili. La situazione si faceva ancora più seria perché una parte delle informazioni contenute nella sessione era serializzata con pickle, un formato Python che può eseguire operazioni nel momento in cui i dati vengono deserializzati.
Il nodo cruciale si trovava proprio nel passaggio tra il controllo della sessione e la ricostruzione dell’oggetto. Potendo falsificare il cookie, diventava possibile inviare al server un payload costruito ad arte e arrivare a una chiamata a pickle.loads(). Per provarlo senza lanciare comandi distruttivi in un ambiente di produzione, Koeck ha scelto una strada prudente e ha usato un payload che introduceva semplicemente un ritardo controllato nella risposta. Le misurazioni hanno confermato che il codice veniva davvero eseguito sulla macchina remota.
Quali servizi erano esposti e come è intervenuta Google
Il problema non si limitava alla pagina esaminata dal ricercatore. La piattaforma DevSite condivide infatti componenti tra diversi portali dedicati agli sviluppatori, tra cui developers.google.com, firebase.google.com e developer.android.com. Secondo la ricostruzione, la chiave recuperata consentiva di generare sessioni accettate anche dagli altri domini che poggiano sulla stessa infrastruttura.
La vicenda offre anche un insegnamento sui formati di serializzazione. Pickle mette a disposizione funzionalità molto potenti, ma non è pensato per elaborare dati che soggetti esterni potrebbero manipolare senza adeguate garanzie. Nei sistemi di autenticazione tenere separate le credenziali, ridurre al minimo le informazioni salvate nei cookie e trattare con cautela tutto ciò che arriva dal browser sono decisioni architetturali che incidono direttamente sulla sicurezza complessiva.
Sul fronte delle contromisure, l’intervento descritto nel rapporto prevede la rotazione delle credenziali esposte, l’adozione di chiavi di firma indipendenti per le diverse installazioni e l’eliminazione degli oggetti sensibili dai dati controllabili dal client. Stando alla cronologia fornita dal ricercatore, la correzione è stata completata prima della pubblicazione dell’analisi. Per la segnalazione Google ha riconosciuto a Koeck una ricompensa pari a circa 77.000 euro.
Fonte: TecnoAndroid