La Rotta Rubata

// Il Lucchetto Verde Che Mentiva

La iena torna dall'apiario con le mani ancora appiccicose di propoli e un dubbio in testa. Se l'e' portato dietro per tutta la strada, lo capisco da come si siede.

"Andre, una cosa. Ho letto di uno che si e' fatto svuotare il portafoglio di criptovalute. Ma diceva che aveva controllato: indirizzo giusto, lucchetto verde, tutto in ordine. Com'e' possibile? Il lucchetto non vuol dire che sei sul sito vero?"

"Il lucchetto vuol dire che stai parlando in modo cifrato con chi ha dimostrato di controllare quel dominio. Il problema e' la parola 'controllare'."

"Cioe'?"

"Aprile 2018. Qualcuno dirotta il traffico verso i server DNS di Amazon. Non buca Amazon, non ruba una password. Convince mezzo internet che la strada piu' corta per arrivare a quei server passa da lui. Chi cercava MyEtherWallet finiva su una copia. Copia servita da un server che l'attaccante controllava, con un certificato che il browser accettava. Circa centocinquantamila dollari in Ethereum, spariti in un paio d'ore."

"E il lucchetto?"

"Quando controlli la strada verso un dominio, controlli anche le verifiche che una Certificate Authority fa su quel dominio. Le chiedi un certificato, lei ti manda a dimostrare che sei il proprietario rispondendo a una richiesta, e tu rispondi, perche' il traffico passa da te. Il certificato te lo firmano. Vero, valido, verde. Il lucchetto non ha mentito: ha certificato esattamente quello che vedeva. Vedeva te."

La iena posa la giacca. "Aspetta. Mi stai dicendo che chiunque puo' dire 'il pezzo di internet X passa da me' e gli altri ci credono?"

"In sostanza si'. Il protocollo che regge tutto il traffico tra le reti si chiama BGP e non ha un modo nativo per verificare chi dice la verita'. Si fida. Da sempre."

"E questo lo sanno tutti?"

"Chi fa reti si'. E ogni tanto qualcuno se ne dimentica e mezzo mondo resta senza YouTube per due ore."

Mi guarda con l'aria di chi ha appena deciso come passero' la serata. "Fammelo vedere. Non a parole. Voglio vedere il traffico che cambia strada."

Stanotte glielo faccio vedere. Senza toccare un solo router vero.

// Cos'e' Davvero Internet

"Prima di rubare una rotta, capiamo cos'e' una rotta."

Internet non e' una rete. E' circa settantacinquemila reti separate che hanno deciso di parlarsi. Ognuna si chiama Autonomous System, AS. Un operatore telefonico e' un AS. Un grande cloud e' un AS, spesso piu' di uno. L'universita', la banca, il datacenter: ognuno ha il suo numero, l'ASN. Google e' AS15169. Cloudflare e' AS13335.

Ogni AS possiede dei blocchi di indirizzi IP, i prefissi. Scritti come 104.16.0.0/13: un indirizzo di base e una lunghezza. La lunghezza dice quanti indirizzi ci sono dentro. Piu' il numero dopo la barra e' alto, piu' il blocco e' piccolo e specifico. Un /24 sono 256 indirizzi. Un /25 ne sono 128: meta' di quel /24, quindi piu' specifico.

"E come fa il mio pacchetto a sapere quale delle settantacinquemila reti tiene l'indirizzo che cerco?"

"Se lo raccontano. Ognuno urla ai vicini: 'i prefissi X, Y, Z stanno da me, per arrivarci passate di qui'. Il vicino gira il messaggio ai suoi vicini aggiungendo se stesso in fondo alla lista. Alla fine ogni router del mondo ha una mappa: per ogni prefisso, la catena di AS da attraversare per arrivarci. Quella catena si chiama AS_PATH. Il protocollo che si scambia questi annunci e' BGP, Border Gateway Protocol."

"La cosa che devi tenere a mente e' questa: quando AS100 annuncia 'questo prefisso e' mio', nessuno verifica che sia vero. Il vicino non ha un registro firmato da controllare. Riceve l'annuncio, applica le sue regole di preferenza, e se l'annuncio vince lo usa e lo ripropaga. La fiducia e' l'impostazione predefinita."

// Le Due Leve Per Rubare Una Rotta

"Ok, ma se AS100 dice 'il prefisso e' mio' e io dico la stessa cosa, chi vince?"

"Dipende, e la parola giusta e' proprio 'dipende'. Prima pero' ti tolgo un'idea sbagliata: non e' che il router mette i due annunci in gara e ne cestina uno. BGP sceglie una rotta migliore per ogni prefisso, separatamente. Se annuncio un prefisso diverso dal tuo, i due non si confrontano nemmeno. Convivono nella tabella, ognuno con la sua rotta."

La prima leva sfrutta proprio questo. La vittima annuncia 10.10.0.0/24. Io annuncio 10.10.0.0/25, meta' di quel blocco. Sono due prefissi diversi, quindi restano tutti e due nella tabella, uno accanto all'altro. Quando arriva un pacchetto per 10.10.0.5, pero', il piano di inoltro non guarda i percorsi: applica il longest prefix match e sceglie il prefisso piu' specifico che contiene quell'indirizzo. Il mio /25 e' piu' specifico del /24. Vince lui, e la lunghezza del percorso non c'entra niente. E' il sub-prefix hijack. Dove l'annuncio viene accettato e installato, il traffico e' mio. Non "ovunque per magia": dove qualcuno lo accetta. Filtri di prefisso, policy dell'operatore e RPKI lo possono fermare a monte.

La seconda leva serve quando non posso essere piu' specifico, per esempio perche' molti operatori scartano i /25 e la vittima annuncia gia' un /24. Allora annuncio lo stesso identico prefisso. Adesso i due si confrontano davvero, perche' sono la stessa rotta, e qui decide la policy di ogni singola rete. La lunghezza dell'AS_PATH e' solo uno dei criteri, e nemmeno il primo: prima viene il peso che l'operatore assegna a mano alle rotte, il LOCAL_PREF. Se falsifico il percorso per sembrare vicino all'origine posso vincere per la fetta di internet dove la policy mi da' ragione. E' il same-prefix hijack: non prende il mondo, prende un pezzo, e quale pezzo dipende da come ogni rete sceglie.

"Fammi capire se ho afferrato. Il piu' specifico vince anche se arriva da uno sconosciuto dall'altra parte del pianeta con un percorso lunghissimo, ammesso che qualcuno gli dia retta?"

"Esatto. E te lo mostro con quaranta righe di Python, cosi' vedi che non e' magia: e' il piano di inoltro che sceglie il prefisso piu' lungo."

// La Decisione, Smontata in Python

Prima di tirare su i router veri, riduco la scelta al suo osso. Ma serve tenere separati due piani. BGP sceglie una rotta migliore per ogni prefisso, e li' contano le policy dell'operatore, il peso delle rotte, la lunghezza dell'AS_PATH. Il piano di inoltro, invece, quando arriva un pacchetto guarda una cosa sola: tra i prefissi che contengono l'indirizzo, il piu' specifico. Il sub-prefix hijack vive tutto in questo secondo piano, e questo pezzo di codice lo modella.

Il file completo (best_route.py) stampa il dettaglio della scelta:

L'indirizzo 10.10.0.5 sta dentro tutti e due i blocchi. La rotta della vittima ha un percorso di due salti, quella dell'attaccante di quattro: piu' lunga, piu' lontana. Al piano di inoltro non interessa: guarda la lunghezza del prefisso, non quella del percorso, e il /25 e' piu' specifico. AS666 vince. Succede cosi' su ogni rete che ha accettato e installato tutte e due le rotte. Non su tutte per forza, ma su quelle si', e il codice che sceglie e' questa max per lunghezza del prefisso.

// Il Lab: Quattro Reti Su Un Portatile

"Bello il Python, ma volevo router veri."

"E router veri avrai. Solo che non tocchiamo internet. Costruiamo un internet in miniatura dentro il portatile."

Linux sa creare stack di rete separati e isolati, i network namespace. Ognuno e' una macchina a se': interfacce sue, tabella di routing sua. Li colleghiamo con cavi virtuali, le veth. Su ognuno facciamo girare bgpd di FRRouting, lo stesso demone BGP che gira in produzione su decine di migliaia di reti reali. Quattro namespace, quattro AS, un pezzo di internet che sta in RAM.

Lo script di setup crea i namespace, tira le veth, assegna gli IP e scrive la configurazione di ognuno. Il cuore e' la config di FRR: poche righe per dire a ogni AS con chi parla e cosa annuncia.

La configurazione BGP della vittima e' onesta e minima. Annuncia il suo /24 e nient'altro.

Il servizio della vittima vive su 10.10.0.5, e per capire dove finisce davvero il traffico faccio rispondere quell'IP con un banner: SERVER=VICTIM nel namespace della vittima, SERVER=ATTACKER in quello dell'attaccante. Avvio tutto, aspetto la convergenza, e dal client AS300 guardo la rotta e chiedo chi risponde.

Rete pulita. Il client arriva alla vittima passando dal transito, e sull'IP pubblico risponde il server vero. Adesso rompiamo.

// L'Annuncio Che Ruba Il Traffico

AS666 non fa niente di sofisticato. Non buca la vittima, non falsifica firme, non sfrutta CVE. Aggiunge una riga alla sua configurazione: annuncia un prefisso che non gli appartiene, e lo annuncia piu' specifico.

Ricarico la config di AS666 e riguardo dal client cosa succede a 10.10.0.5, che sta dentro il primo /25.

La rotta vera della vittima e' ancora li', nella tabella, accanto a quella dell'attaccante: prefissi diversi, non si sono fatti concorrenza. A cambiare e' il forwarding del transito, che per 10.10.0.5 ora sceglie il /25 e manda tutto ad AS666. Nota una cosa: il traceroute continua a chiudersi su 10.10.0.5, perche' l'attaccante impersona lo stesso IP. Da solo non ti direbbe niente. A svelare il dirottamento e' il banner, che adesso risponde SERVER=ATTACKER. Da qui l'attaccante fa quello che vuole: butta i pacchetti e la vittima sparisce, oppure risponde lui fingendosi il server, oppure li inoltra alla vittima vera restando nel mezzo. Leggerne il contenuto, pero', richiede anche di aggirare TLS, come col certificato fraudolento raccontato all'inizio. Il caso dell'inoltro silenzioso e' il piu' pericoloso, perche' il servizio continua a funzionare e nessuno si accorge di niente.

Rivediamolo al rallentatore, ma stavolta il router sei tu. Sei AS300, il client. Due annunci ti arrivano dal transito, tu installi entrambi, e a un certo punto devi inoltrare un pacchetto. Premi play e guarda dove finisce.

La iena si e' avvicinata allo schermo. "Ferma. Mi stai dicendo che il traceroute prima arrivava al server giusto e adesso arriva all'altro, e l'unica cosa che e' cambiata e' una riga in cui uno ha scritto un numero che non e' suo?"

"Una riga. E nessuno gliel'ha impedito, perche' nessuno controlla."

"E chi dovrebbe controllare?"

"Il vicino. AS200, il transito. Ha accettato l'annuncio di AS666 senza chiedersi se quel prefisso fosse davvero suo. La guerra vera si combatte in quel controllo che non ha fatto."

// Non E' Teoria: I Dirottamenti Veri

Il lab e' finto, i danni no. La stessa meccanica, applicata alla rete reale, ha una cronologia lunga e variata. Alcuni sono errori di configurazione, altri censura di stato finita fuori controllo, altri furti mirati.

Due pattern ricorrono. Gli errori di configurazione, i route leak, fanno danni enormi ma involontari: qualcuno ridistribuisce piu' di quello che dovrebbe e il traffico del mondo cambia strada per minuti. I furti mirati sono chirurgici: pochi prefissi, il tempo di ottenere un certificato o servire uno script, poi via. Se in questa lista il cripto pesa tanto, e' una questione di cronometro. Un dirottamento dura minuti e lascia tracce nei monitor globali, quindi rende solo se il bottino e' immediato e irreversibile. Una transazione su blockchain e' questo.

// La Difesa: Firmare Chi Possiede Cosa

"E allora la soluzione qual e'? Un registro firmato di chi possiede cosa, come dicevi tu?"

"Esatto, e esiste. Si chiama RPKI. Nel suo sistema, chi possiede gli indirizzi firma, tramite la delega che il Regional Internet Registry gli ha dato, una dichiarazione: 'il prefisso 10.10.0.0/24 puo' essere annunciato solo dall'AS100, e solo fino a lunghezza /24'. Il RIR e' la radice della catena di fiducia, non firma ogni singola dichiarazione. Quella dichiarazione firmata si chiama ROA, Route Origin Authorization."

Il router confronta ogni annuncio con le ROA e ne ricava un verdetto (RFC 6811): valid se origine e lunghezza combaciano, invalid se qualcuno annuncia un prefisso che non gli spetta o piu' specifico del consentito, not-found se non esiste ancora una ROA. Attento pero': RPKI marca, non butta. Cosa fare di un annuncio invalid resta una scelta di policy dell'operatore. La scelta sana, che ormai fanno in molti, e' scartarlo."

Nel lab la ROA della vittima direbbe 10.10.0.0/24, origine AS100, maxLength /24, e AS200 e' configurato per scartare gli invalid. Per farlo girare senza tirare su un intero validatore RTR, esprimo quella stessa decisione con un filtro esplicito in ingresso da AS666: nega ogni piu'-specifico del /24 della vittima. E' un'approssimazione della policy di scarto basata su ROV: il verdetto invalid sarebbe automatico, lo scarto va comunque configurato.

Il /25 dell'attaccante non entra piu' nella tabella di AS200: il transito torna a preferire il /24 della vittima, e sull'IP pubblico risponde di nuovo il server vero. La stessa riga che prima rubava tutto adesso non supera il primo vicino. In produzione il verdetto invalid arriva dalla ROA firmata invece che da un filtro scritto a mano, ma la decisione finale, buttare, resta la stessa.

Grandi reti lo fanno gia'. Cloudflare, Google, Amazon scartano le rotte invalid. Oltre meta' dei prefissi globali oggi ha una ROA. La direzione e' giusta, e negli ultimi anni l'adozione e' cresciuta parecchio.

// Perche' Non Basta

"Quindi problema risolto. Basta che tutti firmino."

"Meta' problema. RPKI verifica una cosa sola: chi e' l'AS di origine, l'ultimo della catena. Non verifica la catena in mezzo. E questo lascia aperta una porta grande."

Torniamo alla seconda leva, il same-prefix hijack. L'attaccante non annuncia AS666 come origine. Falsifica il percorso e ci mette in fondo l'AS100 vero della vittima. L'annuncio diventa 'il prefisso 10.10.0.0/24, origine AS100, e per arrivarci passate da me'. Per RPKI e' valid: origine giusta, lunghezza giusta. La firma controlla l'ultimo anello, e l'ultimo anello e' quello vero. Il fatto che l'attaccante si sia infilato nel mezzo, RPKI non lo vede.

Chiudere anche questa porta richiederebbe di firmare l'intero percorso, non solo l'origine. Esiste, si chiama BGPsec, e ogni router lungo la strada dovrebbe firmare il passaggio. Il problema e' pratico: serve capacita' di calcolo su ogni router, le garanzie complete richiedono adozione lungo tutto il percorso e con adozione parziale restano buchi di fiducia, e nessuno vuole rifare il parco macchine. Il risultato e' che l'adozione e' vicina allo zero. Sta emergendo un compromesso, ASPA, che valida i rapporti tra AS vicini senza firmare ogni salto, ma e' ancora agli inizi.

// Il Dubbio Dell'Apiario

La iena guarda lo schermo con il traceroute che, riga di configurazione dopo riga di configurazione, arriva prima al server giusto, poi al ladro, poi di nuovo al server giusto quando accendo la firma.

"Quindi il tizio del portafoglio. Il lucchetto era vero."

"Verissimo. Certificava che stava parlando in modo cifrato con chi aveva dimostrato di controllare il dominio. E in quei minuti chi controllava il dominio, agli occhi del mondo, era l'attaccante. La crittografia ha fatto il suo mestiere alla perfezione. Ha solo protetto la conversazione sbagliata."

"E la difesa e' firmare chi possiede gli indirizzi."

"Firmare l'origine, si'. E' il pezzo che stiamo mettendo a posto adesso, dopo trent'anni. Il pezzo del percorso e' ancora scoperto. Internet regge su un protocollo che si fida, e lo stiamo blindando un anello alla volta mentre continua a girare."

Si alza, riprende la giacca che sa ancora di arnie. "Andre, e poi sarei io quella che non si aggiorna. Domani metto in fila i miei di annunci."

"Tu non hai un AS."

"Non ancora."