Il Centro nazionale tedesco di ricerca per la sicurezza informatica ATHENE ha trovato un modo per compromettere uno dei meccanismi base utilizzati per proteggere il traffico Internet fra grandi infrastrutture.
Tale meccanismo, chiamato Resources Public Key Infrastructure (RPKI), è stato progettato per impedire ai criminali informatici o agli aggressori governativi di deviare il traffico su Internet, instradando pacchetti verso indirizzi IP sbagliati. Tali reindirizzamenti sono sorprendentemente comuni su Internet, ad esempio per spionaggio o anche semplicemente a causa di configurazioni errate.
Un recente esempio di cosa comporta una violazione di questo meccanismo è quanto accaduto a Twitter: nel marzo scorso parte del traffico del sito era stato dirottato su dei server in Russia, per circa 45 minuti. In quel caso, il problema sembra sia stato un errore di configurazione di un Internet Service Provider (ISP). Il problema ha coinvolto le tabelle di routing del protocollo Border Gateway Protocol (BGP), che possono essere modificate o i cui pacchetti di risposta possono essere intercettati e modificati. La soluzione, ora rivelatasi problematica, è stata per l’appunto quella di sviluppare il sistema RPKI di certificazione di tali tabelle.
Il team di ATHENE ha dunque dimostrato che gli aggressori possono bypassare completamente il meccanismo di sicurezza senza che gli operatori di rete interessati siano in grado di rilevarlo. Ma per comprendere la portata dell’attacco occorre considerare anche il ruolo del Border Gateway Protocol (BGP).
Indice degli argomenti
Cos’è e come funziona il protocollo RPKI
La Resources Public Key Infrastructure (RPKI) mira a prevenire i dirottamenti permessi da BGP, in fase di risoluzione di un dominio (il tutto avviene fra DNS). Sia per proteggersi da errori di configurazione benigni sia da dirottamenti volontari.
RPKI è stato standardizzato da IETF (RFC6480) nel 2012 dopo anni di lavoro. Il Department of Homeland Security (DHS) e il National Institute of Standards and Technology (NIST) hanno lavorato sulla sicurezza del protocollo BGP, per quasi un decennio (Durand, 2020 & NIST, 2016).
È stato però solo quando Amazon e altre grandi aziende tecnologiche sono salite a bordo che la sicurezza di BGP è diventata una priorità nel settore, portando alla prima versione del protocollo (che ora è alla versione 2).
Lo scopo è impedire a qualsiasi rete su Internet di rivendicare blocchi di indirizzi IP che non le appartengono legittimamente. Il protocollo RPKI utilizza certificati firmati digitalmente (normali X509v3) per confermare che un blocco di indirizzi IP specifico appartiene effettivamente alla rete specificata. Come per qualsiasi struttura PKI, è fondamentale fidarsi della Certificate Authority (CA) direttamente connessa e di quelle che fanno parte della gerarchia.
Gerarchia di certificazione RPKI (fonte A.Gurtov et al.).
I problemi legati al trust management nelle soluzioni PKI sono noti da anni, e l’architettura RPKI prende le contromisure necessarie stabilendo una precisa gerarchia di CA. Si noti comunque che in questa particolare PKI, la CA che emette il certificato, essendo un ISP, non ha il compito di verificare il diritto legale del soggetto di affermare una particolare identità. Rispetto alla figura sopra riportata, i problemi iniziano a presentarsi a livello del National Internet Registry (NIR).
Il ruolo del Border Gateway Protocol
Il BGP è il protocollo tramite il quale gli ISP di una specifica regione geografica individuano e si connettono con gli ISP di altre aree, quindi un protocollo chiave nella gestione della rete globale. Il sistema esiste dalle origine della rete Internet, e di quell’epoca “d’oro” eredita un approccio “innocente”: le tabelle di routing del protocollo non sono sottoposte a particolari controlli. In genere, un provider ISP imposta delle tabelle BGP per “annunciare” che la propria rete, nota come “sistema autonomo” nel linguaggio BGP, è il percorso corretto per inviare e ricevere traffico a reti specifiche.
Con la crescita di Internet, il problema del BGP è divenuto evidente. Una configurazione errata in un paese può rapidamente creare problemi di routing a cascata.
Nel 2008, ad esempio, YouTube è rimasto indisponibile su tutta la rete Internet a seguito di una modifica apportata da un ISP in Pakistan alle tabelle di routing BGP. L’ISP aveva cercato di bloccare YouTube all’interno del Pakistan, ma non è stato attento nell’implementare il cambiamento. In quel caso i pacchetti inviati a YouTube passavano tramite il Pakistan. Cosa peraltro curiosa visto che il governo pakistano aveva appena attivato un blocco sul sito YouTube.
In realtà la Pakistan Telecom aveva appena creato delle regole di routing per instradare il traffico del blocco di indirizzi IP dei server YouTube verso il nulla (black hole). Tuttavia, le informazioni di routing sono state propagate da Pakistan Telecom al suo ISP, PCCW di Hong Kong, che a sua volta le ha propagate nel resto del mondo.
Come conseguenza qualsiasi pacchetto dati verso YouTube, in tutto il mondo, venne rediretto verso il black hole impostato dalla Pakistan Telecom.
Un altro caso noto è accaduto a marzo 2022 ai danni del sito coreano per lo scambio di criptovaluta KLAYSlap, ed ha portato al furto di 2 milioni (KLAYswap è un sistema web di scambio e trading di criptovalute). Senza entrare nei dettagli, anche in questo caso gli aggressori hanno sfruttato il dirottamento del protocollo BGP.
In questo particolare caso l’attacco al protocollo BGP è avvenuto in due distinte fasi:
- Nella prima è stata intercettata la comunicazione fra il sito vittima e la Certification Authority che forniva i certificati per la connessione TLS. L’avversario tramite dirottamento del traffico BGP ha potuto fingere di essere il sito KLAYslap ricevendo il certificato al suo posto.
- Nella seconda fase, sempre dirottando le richieste BGP verso un IP sotto il suo controllo ha potuto fornire al sito vittima una componente Javascript malevola, che ha svolto transazioni verso un conto controllato dall’attaccante.
Alcuni errori di configurazione BGP, tuttavia, si ritiene che siano avvenuti intenzionalmente anche per motivazioni di guerra cibernetica. Nel 2013, ad esempio, enormi blocchi di traffico Internet appartenenti a istituzioni finanziarie, agenzie governative e fornitori di servizi di rete con sede negli Stati Uniti, sono stati ripetutamente dirottati in località Russe, o più recentemente in Cina.
Il sospetto è che l’azione sia stata intenzionale per reindirizzare il traffico, in modo da poterlo monitorare o modificare, prima di passarlo alla destinazione finale. La conclusione è che il BGP sia stato a lungo un protocollo fragile, nonostante il suo ruolo fondamentale per il funzionamento della rete.
Per questa motivazione era stata introdotta da Internet Engineering Task Force (IETF) la soluzione Resources Public Key Infrastructure (RPKI). I problemi di hijack (dirottamenti) del traffico BGP, noti da tempo, e quelli nuovi emersi ora per RPKI, sono importanti anche a seguito dell’attuale scenario di tensione geopolitica, dove le azioni di ISP nazionali possono essere guidate da interessi ostili e non semplici errori.
L’attacco Stalloris
Uno dei primi risultati della ricerca citata ad inizio articolo è che solo il 40% di tutti i blocchi di indirizzi IP abbia un certificato RPKI e solo il 27% di tutte le reti li verifichi. Un dato che è anche possibile dedurre anche tramite il sito RPKI monitor del NIST.
Quindi una scarsa penetrazione della soluzione che espone larghe fette della rete internet ai problemi di hijack del traffico del protocollo BGP detti sopra.
Non solo però, la struttura è vulnerabile anche ad attacchi DDoS. Se una rete non riesce a trovare un certificato per un blocco di indirizzi IP, assume che non esista. Per consentire comunque traffico Internet, la rete semplicemente ignora la mancanza di informazioni RPKI per i blocchi di indirizzi IP colpiti.
Le decisioni di routing si basano, in questo caso, esclusivamente su informazioni non protette, come avveniva prima della introduzione della RKPI. Il team di ATHENE è stato in grado di dimostrare sperimentalmente che un utente malintenzionato possa creare esattamente questo scenario e disabilitare RPKI senza che ci siano evidenze del problema, nemmeno all’interno della rete i cui certificati vengono ignorati.
L’attacco chiamato “Stalloris” richiede che l’attaccante controlli un punto di pubblicazione RPKI (i.e., attori statali guidati da interessi ostili) o che sia in grado di effettuare un temporaneo DoS (vedi figura precedente) per impedire la ricezione dei certificati.
Stalloris effettua il downgrade di RPKI provocando la perdita di pacchetti in un intervallo di tempo specifico, sincronizzato con l’intervallo di aggiornamento delle relying party (i.e., un ISP). Ciò fa sì che la relying party rinunci alla convalida RPKI quando esegue decisioni di routing in BGP.
Overview dell’attacco (fonte: ATHENE).
Conclusioni
Indipendente dalle specifiche vulnerabilità del protocollo RPKI, va comunque detto che in generale, in un mondo che sta pesantemente andando verso soluzioni trust no one, le soluzioni PKI siano tendenzialmente vulnerabili, perché basate su un modello di fiducia (ad esempio quello alla base del concetto di Certification Authority) corruttibile da grandi attori e che nessuna gerarchia di CA può completamente risolvere.
Questo è problematico, specialmente nel momento in cui le minacce possono provenire da attori statali (i.e., ed essere guidate dal conflitto o da motivazioni geopolitiche) che gestiscono le infrastrutture di connessione.
