Atacantes de secuestro de DNS de Google

Question

Atacantes de secuestro de DNS de Google

#1 de daniel Azuelos (2 votos)

14

Como sabemos, el servidor DNS de Google (8.8.8.8) en los días 14 y 15 de marzo fue secuestrado en Sao Paulo. Y luego de este evento, BGPmon.org anunció una alerta .

Ahora,enunaasignacióndecurso,nospidenquebusquemoselnúmero AS del atacante. Para esta pregunta, he descargado archivos de volcado relacionados de routeviews.org y encontré esto relacionado mensajes:

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

Nuestro TA diría que el AS del atacante era 7908 (BT LATAM Venezuela, S.A). Pero en mi opinión no lo fue, porque en mi opinión no hay ventajas que pueda explotar el atacante si redirige el tráfico a su propio AS. A pesar de esto, no pude encontrar ningún mensaje de actualización originado por este AS en archivos de volcado. Por otra parte, en la imagen de arriba, el tiempo de ataque se anunció a las 17:23 y desde este momento en adelante, no pude encontrar ningún mensaje interesante en los archivos de volcado.

Mi pregunta es, ¿alguien puede decirme cuál es el número real de atacantes AS?

Gracias de antemano

attacks google dns routing

pregunta Hi I'm Frogatto 30.12.2014 - 18:37

fuente

1 respuesta

Lea otras preguntas en las etiquetas attacks google dns routing

Asegúrese de que los datos no permanezcan después de ser eliminados ¿Hay una manera para que un consumidor informe el incumplimiento de PCI?

score 2 · Answer 1

El AS real para alimentar una ruta falsa es cualquier AS a lo largo de la ruta AS:

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

ves en los 2 anuncios erróneos de ruta a:

8.8.8.8/32

Por lo tanto, todo el tráfico hacia 8.8.8.8/32 debe enrutarse desde este ataque hasta ASES:

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

Si el objetivo de este ataque es redirigir todo el flujo hacia Google a un servidor web atrapado de bobo que imita perfectamente a Google, entonces este bobo atrapado servidor debe estar dentro del control AS que está al final de esta ruta falsa. Es:

que pertenece a:

BT LATAM Venezuela, S.A.

Y claramente, la universidad de Oregón no tiene que enrutar su tráfico de Google a través de un caché ubicado en Venezuela.

Esto no es suficiente para diagnosticar que esto es un ataque real o, más bien, un error humano (pérdida de una ruta interna en los permitidos para transmitir a los vecinos BGP). Si este es un error humano, entonces el origen es más probablemente dentro de:

AS 7908

Pero si esto es un ataque, lo más probable es que esto se realice de forma remota y no puede ubicar su primer salto de acceso sin los registros de conexiones en el enrutador BGP dentro del AS 7908.