Dirottamento BGP e certificato TLS falso colpiscono Softaculous

Un dirottamento BGP è stato usato per aiutare un attacco a un fornitore di software per l'hosting. BGP, il Border Gateway Protocol, è il sistema che permette alle reti su Internet di comunicarsi reciprocamente quali blocchi di indirizzi possono raggiungere. Softaculous Ltd, l'azienda dietro l'auto-installer Softaculous e la piattaforma Virtualizor per la gestione di macchine virtuali (versioni software di un computer che girano su un server fisico), ha descritto come un aggressore abbia combinato un dirottamento di questo tipo con un certificato TLS tecnicamente valido per consegnare un pacchetto di aggiornamento malevolo di Virtualizor a un piccolo numero di installazioni. L'azienda ha consigliato ai clienti di seguire una sequenza di passaggi per verificare se fossero stati colpiti. L'analisi tecnica è di Doug Madory, Head of Internet Analysis di Infoblox, ed è stata pubblicata originariamente sul blog di Kentik.

Come il dirottamento ha preso gli indirizzi

Alle 20:57 UTC del 28 agosto 2026 un nuovo prefisso è entrato nella tabella di routing globale. Un prefisso è un blocco di indirizzi Internet scritto in forma abbreviata; questo, 162.55.80.0/24, copriva gli indirizzi usati dall'endpoint di aggiornamento software di Softaculous così come il suo sito client e di fatturazione. È stato annunciato lungo un AS path che recita ? 6204 62390 24940. Un AS path è la lista delle reti che una rotta attraversa, scritta come numeri chiamati Autonomous System Numbers (ASN). L'annuncio era una parte più specifica del blocco più grande 162.55.0.0/16, che normalmente è originato da Hetzner Online (AS24940). La rotta probabilmente ha avuto origine con la penultima rete nel percorso, NexonHost (AS62390), sia perché quella rete è stata compromessa sia perché un cliente ha approfittato di lacune nella sua sicurezza.

Perché sembrava legittimo

Il percorso portava anche un'origine falsificata. Aggiungendo 24940 come numero più a destra, l'aggressore ha fatto apparire la rotta RPKI-valida. RPKI, la Resource Public Key Infrastructure, è un sistema di record firmati che dichiarano quale rete è autorizzata ad annunciare quali indirizzi. La rotta è passata per due motivi: la Route Origin Authorization di Hetzner (ROA, il record firmato stesso) richiedeva AS24940 come origine, e permetteva che la lunghezza del prefisso fosse ovunque tra /24 e /16. Le reti che rifiutano le rotte RPKI-invalide non avevano quindi motivo di scartarla. Poiché non esisteva nessun'altra rotta per 162.55.80.0/24 che potesse competere, l'annuncio si è diffuso fin dove le politiche di filtraggio lo permettevano. I router preferiscono sempre la corrispondenza più specifica disponibile, quindi il traffico destinato a quell'intervallo di indirizzi è stato attirato verso la rotta dirottata invece di seguire la vera 162.55.0.0/16.

Quanto è durato

La visualizzazione BGP di Kentik, che mostra la quota di punti di osservazione BGP (punti di osservazione indipendenti sparsi per Internet) che avevano 162.55.80.0/24 nelle loro tabelle di routing nel tempo, traccia la cronologia. Dal momento in cui la rotta è apparsa per la prima volta alle 20:57 UTC del 28 agosto, ha pulsato on e off diverse volte fino a quando il vero AS24940 ha iniziato ad annunciare il prefisso stesso quasi 12 ore dopo, alle 08:44 UTC del 29 agosto. Entro le 14:10 UTC del giorno successivo AS24940 lo aveva ritirato di nuovo. Il dirottamento è tornato alle 19:55 UTC del 29 agosto e ha pulsato ripetutamente finché AS24940 è intervenuto ancora una volta, annunciando 162.55.80.0/24 alle 05:45 UTC del 30 agosto, momento in cui il dirottamento è stato ritirato. Al momento della scrittura AS24940 stava ancora annunciando il prefisso. Il grafico mostra la rotta dirottata propagarsi leggermente meno ampiamente di quella legittima, prova che un certo filtraggio delle rotte l'ha limitata, ma la propagazione è stata comunque sostanziale e ha creato il potenziale per un diffuso dirottamento del traffico.

Perché un dirottamento di routing da solo non bastava

L'aggressore aveva bisogno anche di un certificato TLS valido. TLS è la crittografia che protegge una connessione e prova anche l'identità di un sito web. La stessa debolezza è stata sfruttata nell'attacco del 2022 a KLAYswap, un exchange di criptovalute online in Corea del Sud. Nel loro post su quell'incidente, Henry Birge-Lee e i suoi colleghi di Princeton hanno scritto che KLAYswap e Kakao usavano correttamente TLS e che non è stata sfruttata alcuna falla nel protocollo TLS stesso; invece l'attacco ha abusato della falsa fiducia che TLS ripone nell'infrastruttura di routing. L'avversario ha prima puntato il suo dirottamento sulla PKI (public key infrastructure, il sistema di autorità di certificazione che emettono certificati) e ha eseguito un attacco man-in-the-middle sul processo di distribuzione dei certificati. Solo dopo aver ottenuto un certificato digitale valido per il dominio target si è rivolto agli utenti reali, servendo un file JavaScript malevolo su una connessione cifrata. Il loro post si intitolava "Attackers exploit fundamental flaw in the web's security to steal $2 million in cryptocurrency".

La garanzia di identità di TLS è affidabile solo quanto il sistema di routing che porta il traffico di validazione dei certificati nel posto giusto. Per affrontare questo, l'autorità di certificazione pubblica Let's Encrypt usa da diversi anni la Multi-Perspective Issuance Corroboration (MPIC). Con MPIC, un'autorità di certificazione non valida il controllo di un dominio da un singolo punto di osservazione, che un dirottamento BGP localizzato può falsificare. Controlla da diverse posizioni di rete geograficamente e topologicamente diverse allo stesso tempo e richiede che un quorum sia d'accordo prima che un certificato venga emesso, così un dirottamento che raggiunge solo alcuni punti di osservazione viene individuato dal disaccordo tra gli altri. In questo caso, poiché la rotta dirottata era una rotta più specifica non contestata, la sua propagazione globale ha creato un quorum interamente controllato dall'aggressore.

Cosa hanno mostrato incidenti precedenti

Nel 2022 un dirottamento BGP ha preso di mira anche Celer Bridge, un servizio di criptovalute ospitato da AWS. Nel post che Madory scrisse all'epoca, citò la pratica allora di AWS di usare ROA molto permissive, che permettevano origini multiple e prefissi di dimensioni da un /10 fino a un /24, come fattore che limitava la capacità della RPKI Route Origin Validation di aiutare. Suggerì un'alternativa: fare ciò che reti come Cloudflare e Comcast hanno fatto e impostare l'origine e la lunghezza massima del prefisso per corrispondere esattamente a come il prefisso è instradato. Questo approccio costa il carico di aggiornare una ROA ogni volta che una rotta cambia, ma lascia poco spazio a versioni alternative di una rotta per circolare. AWS ora fa corrispondenze esatte sulle sue ROA.

Madory è attento a non sopravvalutare la RPKI Route Origin Validation (ROV), la pratica di controllare le rotte rispetto ai record firmati, come difesa contro un avversario determinato. Gli aggressori possono falsificare gli AS path per rendere i dirottamenti RPKI-validi. Anche così, se Hetzner Online avesse usato ROA rigorose con lunghezze massime di prefisso che corrispondevano alle sue rotte, la circolazione del dirottamento sarebbe stata grandemente ridotta, il che a sua volta avrebbe permesso a MPIC di impedire l'emissione di un certificato TLS valido.

Anche il rilevamento sarebbe stato possibile. Come con l'attacco a Celer Bridge, il monitoraggio BGP avrebbe potuto avvisare Hetzner che un nuovo /24 del suo spazio di indirizzi veniva annunciato, anche se l'origine falsificata avrebbe potuto farlo sembrare legittimo. Quando quel nuovo /24 è apparso con un upstream inaspettato, NexonHost (AS62390), un avviso avrebbe dovuto attirare l'attenzione sull'anomalia. Il dettaglio che l'avrebbe distinto dall'apparizione di un semplice altro peer di Hetzner Online è che il nuovo upstream è stato visto dalla stragrande maggioranza dei punti di osservazione BGP: il prefisso era transitato esclusivamente da questo provider di hosting relativamente sconosciuto.

Cosa dovrebbe trarre il settore

La RPKI ROV ha ridotto in modo significativo gli incidenti di routing, ma non è progettata per prevenire completamente un incidente come questo. Funziona riducendo la propagazione di mis-origination trapelate, che tipicamente comportano errori innocenti, e i suoi benefici sono stati visti anche nei cosiddetti dirottamenti "intenzionali, ma anche accidentali", come il blocco di Telegram in India a giugno. ROA più rigorose avrebbero potuto permettere alla RPKI ROV di limitare la rotta dirottata abbastanza da far bloccare il certificato a MPIC.

Attacchi all'infrastruttura come questi evidenziano problemi che non sono limitati alle criptovalute o al software di hosting. Le aziende che mettono in sicurezza la loro infrastruttura rivolta a Internet dovrebbero implementare un monitoraggio BGP e DNS robusto, osservando sia i propri sistemi sia qualsiasi dipendenza basata su Internet da cui dipendono. Dovrebbero rifiutare le rotte RPKI-invalide e creare ROA rigorose per il loro spazio di indirizzi, con lunghezze massime di prefisso che corrispondono alle lunghezze di prefisso che le loro rotte usano effettivamente. RFC 9319, The Use of MaxLength in the Resource Public Key Infrastructure, afferma che è una best current practice per le reti evitare del tutto l'attributo maxLength nelle ROA, tranne in certe circostanze; lasciare il campo maxLength vuoto ha lo stesso effetto di impostarlo per corrispondere al prefisso. Questi passaggi riducono significativamente la finestra di opportunità per un aggressore.

In un aggiornamento dopo la pubblicazione del suo post, Madory ha notato che Hetzner ha cambiato la ROA per 162.55.0.0/16 per includere un maxLength di 16, rimuovendo la possibilità di un simile attacco a un sotto-prefisso in futuro. Hetzner ha fatto lo stesso per le ROA che coprono 213.133.96.0/19 e 213.239.192.0/18, che prima permettevano un maxLength di 24 e ora permettono rispettivamente 19 e 18. Anche dopo quei tre fix, 50 delle ROA di AS24940 mostravano ancora lo stesso schema: 78.46.0.0/15 è instradato come un /15 ma la sua ROA permette fino a /24, un divario di 9, e la maggior parte dei blocchi /16 permette similmente /24 quando solo il /16 stesso è instradato. Il rafforzamento è quindi parziale, e lo stesso problema di maxLength persiste in gran parte dello spazio di indirizzi della rete. Separatamente, Bryton Herdes di Cloudflare ha fatto notare che Hetzner ha aggiunto un record ASPA, una lista firmata che enumera quali reti sono autorizzate a trasportare traffico per AS24940. Con quel record in atto, le reti che controllano ASPA dovrebbero essere in grado di rifiutare istantaneamente le rotte il cui AS path include un upstream di AS24940 che non è nella lista, come AS62390 in questo incidente.

Per i proprietari di siti web, la lezione è che sia il percorso che il vostro traffico prende sia le risoluzioni dei nomi su cui il vostro personale e i visitatori fanno affidamento valgono la pena di essere osservati. Nessuno può annullare un dirottamento di routing dal lato client, ma mantenere la risoluzione DNS privata e cifrata, come fa un servizio come AEU DNS, impedisce che le risoluzioni dei nomi vengano silenziosamente osservate o alterate lungo il percorso verso il resolver, che è la parte di questa catena che un proprietario di sito può effettivamente controllare.