giovedì 20 agosto 2020

App vulnerabile scoperta da uno studente (non dei nostri...)

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...

martedì 14 aprile 2020

Reti di Calcolatori 2 ed eventi di cronaca...

I corsi di "Reti di Calcolatori" e "Reti di Calcolatori II e Principi di Sicurezza Informatica" sono, credo, interessanti anche perché hanno molti agganci con l'esperienza quotidiana di utilizzo di Internet e dei dispositivi informatici in genere.

In questo semestre sto tenendo il corso di "Reti II". La quantità di eventi legati agli argomenti del corso che ho visto nelle ultime settimane è stata davvero molto grande. Riporto alcuni di questi eventi qui sotto.

Numeri di sequenza su 32 bit in TCP

L'implementazione di TCP deve associare un numero di sequenza ad ogni byte trasmesso. I numeri di sequenza sono rappresentati su 32 bit.

Abbiamo detto che il codice deve essere in grado di confrontare correttamente tra di loro valori che superano il massimo valore rappresentabile su 32 bit. Ad esempio, se viene trasmesso il byte 1000 e poi il byte 1002, è facile per il ricevente capire che il secondo deve seguire il primo: 1002 è più grande di 1000. Ma se viene trasmesso il byte numero 2^32-1 e poi il byte numero 1, capire che il secondo deve seguire il primo non è per niente facile, in quanto 1 è (molto) più piccolo di 2^32-1. Il codice di TCP deve cioè essere in grado di gestire correttamente gli overflow dei numeri di sequenza, in quanto se si trasmette una quantità elevata di dati in una connessione allora l'overflow si verifica di sicuro.

Poche settimane fa la Boeing ha informato che i loro aerei 787 devono essere spenti completamente (!) ogni 51 giorni: non hanno tenuto conto del problema dell'overflow nelle letture dei sensori quindi potrebbero verificarsi dei problemi "potenzialmente catastrofici"...

Controllo della congestione in TCP

L'implementazione di TCP regola dinamicamente la velocità di trasmissione in modo da tentare di prevenire situazioni di "congestione", situazioni cioè in cui il traffico che TCP inietta in Internet in un certo momento è eccessivo per la capacità che ha Internet in quel momento.

Abbiamo detto che esistono moltissimi algoritmi per il "congestion control" e che questo è un settore in cui la ricerca è ancora molto attiva. Non è stato infatti ancora individuato un algoritmo in grado di fornire prestazioni ottimali in scenari molto diversi tra loro: ogni algoritmo ha prestazioni ottime con alcune tecnologie di rete e non tanto ottime con altre tecnologie (ovviamente questa è una semplificazione "da bar").

All'ultimo NSDI (17th USENIX Symposium on Networked Systems Design and Implementation) sono stati presentati vari algoritmi per il controllo della congestione in TCP, tra i quali uno proposto da un gruppo dell'MIT e specializzato per le reti della telefonia cellulare. Una descrizione informale può essere trovata qui.

Raccolta di NTLM hash per offline guessing di password

Tutti i sistemi Windows usano il protocollo di autenticazione NTLM.

Abbiamo detto che un attaccante può forzare un client ad eseguire il protocollo NTLM in modo da osservare il traffico generato dal client ed usare tale traffico per tentare di indovinare la password del client.

Un software per videoconferenze utilizzato moltissimo in questo periodo di quarantena, specialmente negli USA, rende molto semplice fare attacchi di questo genere.

Password in vendita nei forum

Abbiamo detto che i database username-password sono spesso in vendita sui forum, per così dire, "specializzati".

E' stato trafugato il database username-password proprio di uno di questi forum. Chi la fa l'aspetti.

Password memorizzate in chiaro

Abbiamo detto che nei database username-password queste ultime non, ripeto, non devono essere memorizzate in chiaro per nessun motivo. Devono essere memorizzate in un formato non invertibile (e computazionalmente complesso da calcolare).

Altrimenti in caso di furto del database succede quello che è successo al provider di posta elettronica email.it che ha fatto una figura davvero barbina: 600.000 (seicentomila) password in chiaro. No comment. Con tutti i messaggi email. No comment. Ovviamente in vendita nei forum.

Rischi pratici delle VPN

Le VPN sono un ottimo strumento difensivo.

Abbiamo detto che, in pratica, le VPN hanno limitazioni durante la fase di creazione della VPN e in presenza di eventuali vulnerabilità (errori) sui server VPN.

Da alcuni mesi sono in corso numerose campagne di attacco che si basano, appunto, su vulnerabilità dei server VPN. Una è questa, che ha preso di mira agenzie governative cinesi.

Le prossime settimane

Parleremo degli attacchi ai siti HTTPS ed in particolare dei problemi che ci sono quando HTTPS coesiste con HTTP. Un esempio interessante di questi problemi è stato enfatizzato di recente per la app TikTok usata da moltissimi utenti: i server video sono su HTTP quindi i contenuti possono essere manipolati da un network attacker senza problemi. Un altro che mi è parso incredibile è relativo a Netflix: i cookie di autenticazione sono su HTTPS ma è molto facile indurre un browser o una app a trasmetterli su HTTP e quindi, se si riesce ad osservare il traffico, a trafugarli.

Parleremo di vulnerabilità delle applicazioni web, tra le quali il cross-site scripting (XSS). Una molto interessante è stata resa pubblica di recente, in un "customer portal that provides real-time information to terminal operators on the status of shipments into and out of a marine container terminal". Recentemente ne sono state rese pubbliche un bel pò anche nei plugin di WordPress ma questa non è una notizia.

Parleremo anche delle vulnerabilità in generale, ma queste sono davvero troppe per potere essere citate...