Pochi giorni fa uno studente del Politecnico di Milano ha reso pubbliche alcune vulnerabilità che ha scoperto nella app usata dai trasporti pubblici di Milano (ATM, Azienda Trasporti Milanesi da non confondere con Automatic Teller Machine, cioè i bancomat).
Queste vulnerabilità rendevano possibile l'uso (fraudolento) di biglietti di altri utenti. Conoscendo l'indirizzo email con il quale un utente si era registrato nella app ATM, era cioè possibile usare i biglietti acquistati da quell'utente.
In estrema sintesi, la app conteneva una password unica per tutte le installazioni, cablata nel codice della app; tale password veniva usata per autenticare le richieste inviare al server (e garantirne l'integrità); non c'era però nessun meccanismo per autenticare l'utente della app. Di conseguenza, se un utente "Pippo" inviava una richiesta in cui affermava di essere l'utente "Pluto", il server non aveva modo di autenticare l'utente, quindi il server inviava a "Pippo" tutte le informazioni di "Pluto", biglietti compresi. Il server poteva solo verificare che la richiesta era stata inviata da una app legittima.
Lo studente ha notificato ATM della vulnerabilità con il procedimento eticamente appropriato ("responsible disclosure") e la app è stata corretta.
La tecnologia usata nella versione corretta è parte del programma del corso di "Reti di calcolatori II e principi di sicurezza informatica" (ogni installazione della app memorizza un token generato dal server ed associato allo username; tale token deve essere inviato al server in ogni richiesta; il server verifica autenticità e integrità di tale token facilmente, in quanto il token è stato firmato dal server stesso).
La demo che deve essere svolta per il corso fornisce tutti gli strumenti per (tentare di) rilevare vulnerabilità come quelle sopra descritte: si analizza il traffico generato dalla app usando un proxy specializzato; il che è possibile poiché la app non realizza certificate pinning, quindi accetta di collegarsi con qualsiasi server HTTPS (quindi anche il nostro proxy). Il post dello studente mostra anche come ha estratto la password dal codice della app; questa parte non è trattata nel corso.
Un errore di progetto come quello della app ATM è molto grave. Devo dire però di non essere molto sorpreso. Nella mia limitata esperienza, ho visto molti sviluppatori software che purtroppo partono, più o meno implicitamente, da un presupposto sbagliatissimo: "il software lato client non può essere modificato, quindi dobbiamo essere pronti a gestire solo i messaggi che ci può inviare il client legittimo".
Mi chiedo quante altre app sviluppate nel nostro paese hanno problemi analoghi. Mi vengono in mente un pò di app interessanti da provare...
Commenti