Attacchi contro BGP.
Queste violazioni possono derivare dai seguenti attacchi al protocollo BGP.
BGP funziona in base al protocollo TCP, in ascolto sulla porta 179. Pertanto, il protocollo BGP è vulnerabile agli attacchi TCP di cui abbiamo parlato in precedenza.
Attacco confidentiality violations (violazione della privacy). Come accennato in precedenza, i dati di instradamento BGP vengono trasmessi in chiaro, il che consente di intercettare facilmente le informazioni (Questo perché la riservatezza dei dati di instradamento non è un requisito comune).
Attacco replay (riproduzione). BGP non include misure per impedire il riutilizzo dei messaggi intercettati.
Attacco di inserimento messaggi. BGP non include la protezione dall'inserimento di messaggi. Tuttavia, poiché BGP utilizza il protocollo di trasporto TCP, con l'organizzazione della connessione completata, l'inserimento di messaggi da parte di un nodo esterno richiederà una previsione accurata dei numeri di sequenza (tale previsione è possibile, ma piuttosto difficile per buone implementazioni TCP) o l'intercettazione delle sessioni.
Attacco message deletion (eliminazione dei messaggi). BGP non include la protezione contro l'eliminazione dei messaggi. Ancora una volta, tali attacchi sono molto difficili per le implementazioni TCP di alta qualità, ma non possono essere completamente esclusi.
Attacco di modifica dei messaggi. BGP non include la protezione dalla modifica dei messaggi. Una modifica sintatticamente corretta senza modificare la dimensione dei dati TCP sarà generalmente impercettibile.
Attacco Man-in-the-middle (attacchi che coinvolgono l'uomo). BGP non include difese contro gli attacchi MITM. BGP non utilizza l'autenticazione dei partner e tali attacchi diventano un «giocattolo per bambini».
Attacco denial of service (attacchi ai servizi). Sebbene i falsi dati di instradamento possano fungere da attacco DoS su un sistema finale che tenta di trasmettere dati attraverso la rete e la rete in generale, alcuni tipi di informazioni false possono creare attacchi DoS sul protocollo BGP stesso. Ad esempio, l'annuncio di un numero elevato di percorsi più specifici (Prefissi più lunghi) può comportare un aumento del traffico BGP e delle dimensioni delle tabelle di routing che risultano inaccettabili per il sistema.
Riassumendo quanto descritto in questa sezione, va notato che la presenza di rischi è dovuta a tre principali vulnerabilità:
la mancanza di un meccanismo integrato per proteggere l'integrità e la pertinenza dei dati, l'autenticazione dei partner per il passaggio dei messaggi;
la mancanza di un meccanismo di verifica delle credenziali AS per le informazioni annunciate da Nlri (Network Layer Reachability Information);
la mancanza di un meccanismo per garantire la validità degli attributi delle rotte annunciate da AS.
Semplice BGP hijacking.
Di solito BGP hijacking assomiglia a questo: AS, che non possiede un prefisso, inizia ad annunciarlo (il prefisso di qualcun altro), aplinks/peer lo accettano e inizia a diffondersi su Internet. Lo accettano per il motivo che non esiste un filtraggio dei prefissi all'incrocio (o si tratta di un errore di configurazione o è così inteso (perché è molto difficile costruire un filtro prefisso all'incrocio con operatori molto grandi a causa di vari motivi, non è importante per questo articolo)). Uno degli esempi più importanti di recente è quando Rostelecom (AS12389) ha iniziato ad annunciare i prefissi di Mastercard (AS26380), Visa e alcune altre organizzazioni finanziarie (secondo la versione ufficiale, a seguito di un guasto del software). Come apparivano questi annunci, puoi vedere nella storia di bgplay (visualizza tramite web, json (archivio)), eccone uno su uno dei collezionisti RIPE (il prefisso 216.119.216.0 / 24 appartiene a Mastercard (AS26380)):
"source_id": "05-193.203.0.185",
"path": [
6939,
12389
],
"community": [],
"target_prefix": 216.119.216.0/24
Ed ecco come appariva il vero annuncio:
"source_id": "05-193.203.0.63",
"path": [
6720,
8447,
32787,
26380,
26380,
26380
],
"community": [
"1120:1"
],
"target_prefix": 216.119.216.0/24
Cioè, in questo caso, Rostelecom ha annunciato il prefisso direttamente dal suo AS (l'ultimo AS in AS-PATH – 12389). Il problema potrebbe essere evitato se gli APLINK e i peer di Rostelecom filtrassero i prefissi da Rostelecom costruendo Prefissi su AS-SET e / o convalidando i prefissi su Roa RPKI. La costruzione di prefissi tra operatori di grandi dimensioni spesso non viene eseguita e anche RPKI non ha implementato tutto (ma ci sono progressi). Tale dirottamento può teoricamente essere fatto da chiunque, ma solo se il prefisso annunciato «perde» attraverso almeno un APLINK/PIR. Di solito, i grandi operatori russi impostano i prefiltri verso i loro clienti, e quindi i piccoli AS (operatori di piccole/medie dimensioni, alcuni host e alcune aziende) non possono quasi sempre commettere un simile attacco (ma di nuovo, tutto dipende dalla regione / paese / operatore specifico).
Tuttavia, gli aggressori trovano ancora luoghi (APLINK) in cui il filtraggio non è configurato (nel 2017, il leader nel dirottamento era il Brasile) ed eseguono un attacco / dirottamento di indirizzi IP (spesso tali eventi cadono nelle notizie
nastri), per una maggiore efficienza, gli attacchi possono annunciare Prefissi più specifici (con una maschera più lunga) rispetto al vero originale. Passiamo ora alla variante di attacco, in cui né la convalida ROA RPKI né i prefissi costruiti su AS-SET vengono salvati.
BGP hijacking con L'aggiunta di AS vittima al tuo AS-SET.
Considera il seguente scenario.
Un utente malintenzionato ottiene AS e indirizzi IP (in effetti, tecnicamente non ha bisogno di indirizzi IP, piuttosto, sono solo per non sollevare domande).
Un utente malintenzionato si connette a vari operatori di grandi dimensioni e IX'am (minimo-almeno un operatore o IX), indicando come fonte di dati sui Prefissi annunciati non solo il suo AS, ma il suo AS-SET (Questa è una pratica normale per l'interoperabilità (anche quando in una relazione client-uplink) o per l'inclusione su IX'ah)). Nel caso normale, viene specificato AS-SET, non solo AS, quando l'implicazione è che il client non è un deadlock, ma che lui stesso ha (o avrà) client con bgp e le sue reti.
L'attaccante dopo un po ' aggiunge as della vittima al suo AS-SET e inizia ad annunciare il suo prefisso attraverso se stesso, ad es. l'AS-PATH annunciato assomiglia a questo: «As_compilatore As_compilatore As_compilatore As_compilatore As_compilatore As_compilatore As_compilatore As_compilatore As_compilatore as_compilatore as_compilatore». In termini di prefissi costruiti automaticamente e in termini di RPKI, questo è un annuncio perfettamente valido, quindi entrambi i meccanismi di protezione non funzioneranno qui.
Il prefisso Pro-annunciato inizia a competere con l'annuncio reale (annuncio della vittima), da qualche parte vincerà e colpirà la tabella di routing, perderà da qualche parte e non colpirà (l'annuncio della vittima rimarrà lì). Dipende da quanti uplink e da quanti IX stanno usando l'attaccante. Quando un utente malintenzionato si connette a qualche AS come client, al suo interno vincerà (il più delle volte) la vittima a scapito di un local-pref più grande (a meno che la vittima non sia un client dello stesso APLINK, quindi AS-PATH vincerà la vittima se non fa prepend), ad es. un utente malintenzionato deve connettersi al maggior numero possibile di uplink con il proprio AS-set per massimizzare l'efficacia del proprio attacco.
Inoltre, l'attaccante deve connettersi al numero massimo di IX's, perché di solito i deadlock AS espongono il più grande local-pref su IX's e se il prefisso della vittima non partecipa a IX, perderà l'annuncio dell'attaccante nelle tabelle di routing dei deadlock AS.
In teoria, questo è un attacco piuttosto forte, ma fortunatamente in pratica sorgeranno le seguenti limitazioni.
È necessario emettere una persona giuridica, almeno una, ma in realtà, molto probabilmente, sarà richiesta in diversi paesi.
È necessario concludere contratti con gli operatori, IX's, quasi sempre effettuare un pagamento per la connessione, con LIR/RIR.
Alcuni operatori non costruiscono Prefissi AS-SET automaticamente, hanno bisogno di scrivere lettere per questo. Un amministratore esperto sospetterà qualcosa se l'AS-SET di un'azienda sconosciuta appare improvvisamente come ampiamente conosciuta.
Una volta effettuato l'attacco, l'attrezzatura utilizzata (se ospitata in un data center) verrà probabilmente sequestrata in caso di apertura di un procedimento penale.
I prefissi di diversi operatori / IX vengono aggiornati in momenti diversi, quindi sarà necessario analizzare chi aggiorna quando, anche questo non è il lavoro più semplice.
Possibili misure di protezione.
Teoricamente, per proteggersi da un tale attacco, è necessario avere il maggior numero possibile di collegamenti con gli operatori (meglio client, perché su di essi local-pref sopra) e IX's. Cioè, fare la stessa cosa che farebbe un utente malintenzionato. Naturalmente, in pratica è estremamente difficile da implementare e richiederà risorse significative. Questo metodo è rilevante solo per i servizi che forniscono servizi di sicurezza delle informazioni su base professionale.
Se si dispone di un sito web, utilizzare un record CAA con un lavoro account (se il provider di certificati SSL lo supporta; letsencrypt lo supporta) (vedere RFC6844). In questo caso, l'utente malintenzionato non sarà in grado di scrivere il certificato (a meno che non sia in grado di modificare il record CAA).
In teoria, l'implementazione onnipresente di BGPsec dovrebbe eliminare un tale attacco, ma il suo destino non è ancora compreso (in pratica, non ancora applicato o usato molto raramente).
Implementazione della verifica alternativa AS_PATH (senza BGPsec) (finora questo è un progetto che risolve il problema descritto nel caso in cui venga implementato ovunque).
Il divieto di aggiungere in modo incontrollato l'AS di qualcun altro al proprio AS-SET (senza il permesso del proprietario DELL'AS) potrebbe ridurre la possibilità di tali attacchi nelle regioni in cui gli AS-set vengono utilizzati per filtrare alle giunzioni. Ora non esiste un tale divieto.
Infatti, per la maggior parte dei lettori, l'unico consiglio applicabile per loro è il n.2 (per quanto riguarda l'uso di account in un record CAA) e in parte il n. 1 nel contesto della scelta di un hoster con una buona connettività. Allo stesso tempo, è necessario ricordare i possibili attacchi al servizio DNS in cui si ospitano i record (ma questa è una domanda separata e ci sono molti materiali su di esso).
È difficile da catturare torproject.org.
L'attaccante deve risolvere due problemi:
reindirizzare il traffico verso il pubblico di destinazione (CA - che riceverà un sito falso);
genera certificato.
Introduttivi:
$ dig torproject.org CAA +short
128 issuewild "\;"
0 iodef "mailto:torproject-admin@torproject.org"
128 issue "globalsign.com"
128 issue "letsencrypt.org"
$ dig torproject.org +short
95.216.163.36
138.201.14.197
Come puoi vedere, C'è un record CAA, puoi ottenere un certificato da letsencrypt, non c'è associazione ALL'account nel record CAA, il che significa che il compito è teoricamente risolto da un utente malintenzionato. Indirizzi IP del dominio torproject.org di proprietà del famoso hosting Hezner.
Supponiamo che la CA dell'attaccante sia i clienti di un operatore russo. Hezner non è un cliente di operatori russi(ma ha peering con grandi-direttamente o tramite IX's). Per consentire a un utente malintenzionato di reindirizzare il traffico CA a se stesso, il modo più semplice è diventare un cliente di questo operatore e vincere semplicemente con una pref locale più alta. Qui tutto è particolarmente semplice e chiaro.
Per ottenere un certificato in letsencrypt, è necessario che il provider in cui letsencrypt ospita inizi a indirizzare il traffico all'attaccante, non a Hezner (AS24940). letsencrypt parlerà in indirizzi diversi per IP americani ed europei, ma vediamo quanto sarà difficile influenzare il traffico con acme-v02.api.letsencrypt.org/2.19.125.202 è andato all'host dell'attaccante. Qui ci troviamo di fronte al fatto che letsencrypt è ospitato nel CDN Akamai, che ha un'ottima connettività in tutto il mondo (presente nella maggior parte dei principali IX, ha giunzioni diritte con un gran numero di giocatori importanti). Akamai non ha un LG pubblico, in linea di principio c'è UN'API per i clienti con cui fare traceroute/ping, ma anche senza un LG pubblico si può dare un'occhiata a peering db per valutare la portata della loro presenza. Allo stesso modo, puoi guardare hezner. Non è difficile vedere che entrambi gli AS hanno una presenza sullo stesso IX, da qui si può concludere che con una probabilità vicina a uno, i prefissi AS Hezner (AS24940) nella tabella Akamai (AS20940) sono visibili con AS_PATH 24940. Ciò significa che se un utente malintenzionato tenta di comunicare tramite alcuni prefissi IX di Hezner, perderanno su AS_PATH con questi annunci di Hezner (perché in AS_PATH sarà AS dell'attaccante). Una possibile soluzione potrebbe essere quella di organizzare un peering «diretto» tra l'attaccante e Akamai (se Akamai è d'accordo e se ci sarà un local-pref superiore a quello agli incroci con IX's).
Per riassumere, aggiungendo l'AS di qualcun altro al tuo AS-SET è possibile causare un significativo degrado del sito web torproject.org (per un gran numero di clienti, ma non per tutti nel caso generale), ma l'acquisto di un certificato SSL torproject.org in letsencrypt, molto probabilmente fallirà a causa della buona connettività tra il vero originale (Hezner) e il CDN utilizzato da letsencrypt (Akamai). Tuttavia, in altri casi in cui sono presenti as di transito tra l'hosting del sito della vittima e l'autorità di certificazione e sono presenti in AS_PATH, il rischio di ottenere un certificato con il metodo descritto aumenta in modo significativo.
Oleg Petukhov, avvocato nel campo del diritto internazionale e della protezione dei dati personali, specialista nel campo dell'informazione sicurezza, protezione delle informazioni e dei dati personali.
Canale Telegram: https://t.me/protezionedelleinformazioni
Gruppo in telegramma: https://t.me/protezionedelleinformazioni1
Sito: https://legascom.ru
E-mail: online@legascom.ru
#protezionedelleInformazioni #sicurezzadelleinformazioni
