Attaccanti del dirottamento del DNS di Google

14

Come sappiamo Server DNS di Google (8.8.8.8) nel 14 e 15 marzo è stato dirottato a Sao Paulo. E in seguito a questo evento, BGPmon.org ha annunciato un avviso .

Ora,nell'assegnazionediuncorso,civienechiestoditrovareilnumero AS dell'attaccante. Io per questa domanda ho scaricato i file di dump relativi da routeviews.org e ho trovato questo relativo messaggi:

TIME: 03/15/14 17:23:56
TYPE: BGP4MP/MESSAGE/Update
FROM: 187.16.216.20 AS28571
TO: 187.16.216.223 AS6447
ORIGIN: IGP 
ASPATH: 28571 1251 20080 7908 
NEXT_HOP: 187.16.216.20 
ANNOUNCE 
   8.8.8.8/32 

TIME: 03/15/14 17:23:56
TYPE: BGP4MP/MESSAGE/Update
FROM: 187.16.218.21 AS52888
TO: 187.16.216.223 AS6447
ORIGIN: IGP
ASPATH: 52888 1251 20080 7908
NEXT_HOP: 187.16.218.21
ANNOUNCE
   8.8.8.8/32

Il nostro TA direbbe che l'AS dell'attaccante era 7908 (BT LATAM Venezuela, S.A). Ma secondo me non lo era, perché a mio avviso non ci sono vantaggi da sfruttare da parte dell'attaccante se egli reindirizza i traffici al proprio AS. Nonostante ciò, non sono riuscito a trovare alcun messaggio di aggiornamento creato da questo AS nei file di dump. D'altra parte, nella foto sopra, il tempo di attacco è stato annunciato 17:23 e da questo momento in poi non sono riuscito a trovare messaggi interessanti nei file di dettagli.

La mia domanda è: qualcuno può dirmi qual è il vero numero di aggressore AS?

Grazie in anticipo

    
posta Hi I'm Frogatto 30.12.2014 - 18:37
fonte

1 risposta

2

Il vero AS per alimentare un percorso falso è un AS lungo il percorso AS:

7908 --> 20080 --> 1251 --> |28571|
                            |52888| --> 6447

vedi i 2 annunci sbagliati del percorso per:

8.8.8.8/32

Quindi tutto il traffico verso 8.8.8.8/32 shoud può essere indirizzato da questo attacco AS:

|28571|
|52888| --> 1251 --> 20080 --> 7908

Se l'obiettivo di questo attacco è reindirizzare tutto il flusso verso Google a un web server intrappolato traballante che imita perfettamente Google, allora questo booby trapped server deve trovarsi all'interno del sotto controllo AS che è alla fine di questa rotta simulata. È:

7908

che appartiene a:

BT LATAM Venezuela, S.A.

E chiaramente l'università dell'Oregon non deve instradare il traffico di Google attraverso una cache situata in Venezuela.

Questo non è sufficiente per diagnosticare che si tratta di un attacco reale o piuttosto di un errore umano (perdita di una rotta interna su quelle consentite da trasmettere ai vicini BGP). Se questo è un errore umano, allora l'origine è la maggior parte probabilmente entro:

AS 7908

Ma se questo è un attacco, allora questo è probabilmente condotto in remoto e non è possibile localizzare il primo accesso senza i registri delle connessioni sul router BGP all'interno di AS 7908.

    
risposta data 10.08.2015 - 15:07
fonte

Leggi altre domande sui tag