Come rubare due milioni di dollari (impersonando un indirizzo IP)

In passato scrivevo relativamente spesso su questo blog, in particolare quando si verificavano eventi collegati ad argomenti discussi durante le mie lezioni di "Reti di Calcolatori" o "Computer Networks 2 and Principles of Cybersecurity". Da un pò di tempo scrivo molto più di rado. Motivi personali e professionali al tempo stesso mi rendono sempre più difficile trovare le motivazioni per farlo.

Di recente si sono però verificati due eventi talmente interessanti, almeno per me, che mi spingono a tentare di superare questa mia barriera interiore. Il primo è in questo post, forse nelle prossime settimane scriverò anche sul secondo evento.

Cosa è successo

Poche settimane fa sono stati rubati due milioni di dollari ai possessori di una cryptocurrency coreana per mezzo della impersonazione fraudolenta di un indirizzo IP (link): si invia un pacchetto IP verso un certo indirizzo IP; gli attaccanti manipolano l'infrastruttura di routing di Internet ("BGP hijack") e fanno in modo che i pacchetti diretti a quell'indirizzo IP arrivino agli attaccanti stessi invece che al nodo che ha quell'indirizzo.

Ribadisco:

• invio un pacchetto indirizzato a 130.186.27.50, l'indirizzo IP di esse3.units.it;
• con un "BGP hijack", il pacchetto non arriverebbe al "vero" server bensì ad un altro server scelto dagli attaccanti e che si trova chissà dove.

Perché è (spero) interessante

Questo evento è legato ad argomenti ai quali ho accennato di recente nelle lezioni di  "Computer Networks 2 and Principles of Cybersecurity" e che tratterò più in profondità in seguito:

• Attacco alla "supply chain" (attaccante inserisce malware in librerie).
• Attacco "Man In The Middle" (attaccante si trova "in mezzo" tra i due target e può quindi controllarne la comunicazione a proprio piacimento; operazione che può avvenire in molti modi ed a molti livelli di astrazione diversi).
• Attacco "Man In The Browser" (attaccante che opera nel browser del client, rendendo quindi del tutto inefficaci le garanzie di sicurezza crittografiche di HTTPS).

L'evento è particolarmente interessante perché combina questi temi con un tema la cui importanza è enorme ma ancora non sufficientemente nota: l'intrinseca "debolezza" di BGP, cioè del protocollo di routing usato in Internet. Il protocollo grazie al quale un pacchetto riesce a trovare la strada verso la propria destinazione tra i milioni e milioni di strade possibili (qui una descrizione estremamente sintetica e focalizzata del problema).

Come è stato fatto altre volte

Non è la prima volta che si verificano attacchi di questo genere (esempio 1, esempio 2). L'attacco funzionava in questo modo:

1. L'attaccante impersona l'indirizzo IP del name server (con un BGP hijack);
2. Il browser invia la richiesta DNS per tradurre il nome del cryptocurrency web server al vero indirizzo IP del name server;
3. La richiesta DNS arriva invece ad un name server controllato dall'attaccante (a causa del BGP hijack); l'attaccante risponde con una risposta DNS contenente l'indirizzo IP di un cryptocurrency web site identico a quello vero ma gestito dall'attaccante (questo web site avrà un indirizzo IP diverso da quello vero);
4. Il browser si collega quindi all'indirizzo IP appena ricevuto ed apre una connessione HTTPS (cioè HTTP su TLS) con il web server dell'attaccante; per dimostrare la propria identità, questo web server invia un certificato auto-firmato: nome vero del cryptocurrency web site ma chiave pubblica dell'attaccante; molti utenti ignari hanno accettato il certificato auto-firmato, quindi il browser ha completato l'apertura della connessione HTTPS.
   
   (chi ha familiarità con TLS sa che se l'attaccante inviasse il certificato "vero", quello cioè rilasciato da una certification authority e contenente la chiave pubblica del web server "vero", allora non potrebbe decrittare il traffico inviato dal browser; l'attaccante, infatti, non conosce la chiave privata del web server "vero")
5. L'utente vede la pagina di login, inserisce le proprie credenziali e le trasmette al web server dell'attaccante pensando di trasmetterle al web server "vero" (il browser sta mostrando il nome vero ed il lucchetto TLS).
6. L'attaccante usa quelle credenziali per collegarsi al cryptocurrency web site vero e fare l'equivalente di un "bonifico in uscita"; visto che le cryptocurrency hanno transazioni non reversibili in alcun modo e sono anonime, game over.

Come è stato fatto questa volta

Quello che è accaduto poche settimane fa è molto più complesso ed ingegnoso.

1. Il browser si collega con il vero cryptocurrency website, su HTTPS. Il contenuto del sito è esattamente quello che dovrebbe essere, non è stato manipolato dall'attaccante in alcun modo. Contiene tag html che indicano al browser di caricare alcune librerie Javascript da altri siti, su HTTPS.
2. Il browser si collega quindi con altri siti HTTPS per prelevare codice Javascript, come indicato dal cryptocurrency website.
3. L'attaccante impersona uno di questi siti: il browser si collega su HTTPS con un sito controllato dall'attaccante, preleva un codice Javascript che legge le credenziali inserite dall'utente e le invia all'attaccante stesso, chissà dove.

Risultato, complessivamente due milioni di dollari trafugati.

La cosa complicata è il punto 3: quando un browser deve prelevare codice Javascript su HTTPS, non accetta mai un certificato auto-firmato e non chiede all'utente se lo vuole accettare; si aspetta sempre di ricevere un certificato rilasciato da una certification authority. Quindi, come è stato possibile eseguire il punto 3? Facendo un BGP hijack sul traffico tra la certification authority e l'attaccante, come indicato qui di seguito.

Quando una certification authority riceve la richiesta di rilasciare un certificato per un certo nome, la richiesta viene validata in questo modo: la certification authority dice a chi ha inviato la richiesta "tu vuoi un certificato per esse3.units.it; per dimostrarmi che sei il legittimo proprietario di questo nome, devi mettere nella zona units.it il nome 56823juyauioo9.units.it con valore bxbbo99e47" (nome e valore scelti casualmente). La certification authority invierà poi una richiesta DNS per verificare l'esistenza di quella coppia nome-valore. Se quella coppia esiste, allora chi ha inviato la richiesta di emissione di un certificato per un certo nome è veramente il legittimo possessore di quel nome.

Quello che hanno fatto gli attaccanti in questo caso è stato un BGP hijack proprio su questo traffico. Gli attaccanti hanno richiesto un certificato per il nome vero del sito con lo script; hanno fatto un BGP hijack durante la validazione DNS sopra descritta e sono quindi riusciti ad ottenere un certificato per il nome vero e rilasciato da una certification authority (non necesssariamente la stessa che aveva certificato il sito vero; basta una certification authority qualsiasi).

Voilà.