Por Doug Madory, Director de Análisis de Internet en Kentik
Originalmente publicado en Kentik Blog el 4 de enero de 2024
Resumen
El 3 de enero del 2024, Orange España, el segundo operador móvil más grande de España, sufrió una caída importante del servicio de Internet. Esta caída fue un hecho sin precedentes debido al uso de RPKI —un mecanismo diseñado para proteger la seguridad del enrutamiento de Internet— como herramienta para la denegación del servicio. En este artículo, profundizamos en esta caída del servicio de Internet y la forma única en que fue manipulado RPKI.
El 3 de enero del 2024, el segundo mayor operador de telefonía móvil de España, Orange España, experimentó una caída a nivel nacional que duró varias horas. ¿La causa? Una contraseña comprometida y un sistema de enrutamiento cada vez más robusto. Resulta que la herramienta de defensa favorita de los operadores (RPKI) puede ser un arma de doble filo.
Utilizando una contraseña que encontró en una filtración pública de credenciales robadas, un hacker pudo iniciar sesión en el portal de RIPE NCC como Orange España utilizando la contraseña “ripeadmin”. ¡Uy! Una vez que ingresó al sistema, el hacker empezó a modificar la configuración de RPKI de Orange España, con lo cual muchas de sus rutas BGP dejaron de ser válidas para RPKI.
Como se demostró en nuestro análisis anterior, el despliegue de la validación de origen RPKI ha llegado al punto en el que la propagación de una ruta se reduce a la mitad o menos cuando se determina que no es válida para RPKI. Normalmente, este es el comportamiento deseado, pero cuando en una configuración de RPKI se cargan datos erróneos de forma intencional, el espacio de direcciones puede quedar inalcanzable, convirtiéndose efectivamente en una herramienta para la denegación de servicio.
(Acceso libre, no requiere suscripción)
Utilizando los datos agregados de NetFlow de Kentik, observamos la caída del servicio (ilustrada más arriba) como una gran disminución del volumen de tráfico entrante a Orange España (AS12479) entre las 14:20 UTC (15:20 hora local) y las 18:00 UTC (19:00 hora local). Sin embargo, hubo algunos desarrollos antes de esta ventana de tiempo, así como algunos efectos persistentes, en los cuales profundizaremos a continuación.
¿Qué fue lo que pasó?
Ya sabemos que se produjo la caída y cómo lo logró el atacante. Ahora rastrearemos la secuencia de los eventos utilizando datos RPKI archivados de RPKIviews.
Utilizando los datos agregados de NetFlow de Kentik, observamos la caída del servicio (ilustrada más arriba) como una gran disminución del volumen de tráfico entrante a Orange España (AS12479) entre las 14:20 UTC (15:20 hora local) y las 18:00 UTC (19:00 hora local). Sin embargo, hubo algunos desarrollos antes de esta ventana de tiempo, así como algunos efectos persistentes, en los cuales profundizaremos a continuación.
¿Qué fue lo que pasó?
Ya sabemos que se produjo la caída y cómo lo logró el atacante. Ahora rastrearemos la secuencia de los eventos utilizando datos RPKI archivados de RPKIviews.
La historia empieza a las 09:28 UTC del 3 de enero, cuando alguien (presumiblemente el atacante) comenzó a juguetear con la publicación y revocación de los ROA para rangos de direcciones IP pertenecientes al operador de telefonía móvil español. Después, a las 09:42 UTC, publicaron tres nuevos ROA para los rangos IP de Orange España con un impacto material.
Dado que 93.117.88.0/22, 93.117.88.0/21 y 149.74.0.0/16 ya eran originados por AS12479, estas rutas no se vieron afectadas. Sin embargo, 149.74.0.0/16 tenía bastantes anuncios más específicos que ahora iban a ser evaluados como no válidos en el contexto de RPKI debido a que la longitud máxima de prefijo configurada era 16.
Minutos más tarde, quizás al darse cuenta de esto, alguien publicó un montón de otros ROA para tener en cuenta los anuncios más específicos de 149.74.0.0/16. Estos tenían el origen correcto (AS12479) y, por lo tanto, todos estos anuncios más específicos se volvieron válidos. Todos menos uno, claro está.
Usando la visualización BGP de Kentik, podemos comparar el impacto en la alcanzabilidad (también conocida como propagación) para dos anuncios más específicos adyacentes de 149.74.0.0/16. Como se muestra a continuación, 149.74.172.0/22 fue la ruta omitida en esa nueva publicación de ROA. Durante más de cuatro horas, su alcanzabilidad cayó a tan solo el 20 % de nuestras fuentes de información BGP.
Por el contrario, el resto de los anuncios más específicos se parecían a 149.74.168.0/22 a continuación: la alcanzabilidad cayó breve y parcialmente entre la primera y la segunda publicación de los ROA antes mencionadas.
Si bien durante varios minutos estos prefijos no fueron válidos para RPKI, solo experimentaron una caída parcial de su alcanzabilidad debido a demoras en el tiempo necesario para propagar globalmente los ROA, tal como se documenta en una investigación reciente sobre el tema. El acto de borrar una ruta recientemente inválida para RPKI no es instantáneo.
RPKI como un arma
Después, el atacante fue un paso más allá al crear ROA con un origen distinto al de Orange España. Casi al mismo tiempo que se publicaron esos otros ROA que cubrían los anuncios más específicos de 149.74.0.0/16, se crearon cuatro nuevos ROA para el espacio IP de Orange España con un origen deliberadamente incorrecto (AS49581).
Agregar el ROA falso para 149.74.0.0/16 no tuvo ningún efecto porque el atacante antes había creado un ROA con el origen correcto (AS12479). Siempre que un ROA coincida, una ruta se considera válida en el contexto de RPKI.
145.1.240.0/20 y 1.178.232.0/21 solo quedaron invalidados brevemente antes de que el atacante publicara los ROA con los orígenes correctos.
Solo 62.36.0.0/16 (ilustrado a continuación) y sus numerosos anuncios más específicos resultaron inválidos para RPKI y su alcanzabilidad se redujo durante la caída del servicio por causa de los ROA con orígenes falsos.
Hasta este momento, las acciones del atacante han llevado a la creación de un par de rutas no válidas para RPKI y algunos problemas menores de alcanzabilidad, pero la interrupción más grande aún estaba por llegar.
No fue hasta alrededor de las 14:20 UTC (15:20 hora local) que las cosas se pusieron feas. El atacante apretó el acelerador y publicó cuatro ROA más con orígenes falsos. Dos de los ROA eran /12 que cubrían más de mil rutas originadas por AS12479, todas ellas invalidadas para RPKI debido a la publicación de los siguientes ROA:
Fue entonces cuando la gráfica de tráfico que aparece al comienzo de esta nota empezó a caer en picada. La cantidad de rutas enrutadas globalmente originadas por AS12479 cayó de alrededor de 9200 a 7400, ya que los operadores de backbone que rechazan las rutas no válidas para RPKI dejaron de transportar una gran parte del espacio IP de Orange España.
Alcanzabilidad de 145.1.232.0/21 durante la peor parte de la caída.
Las cosas no empezaron a volver a la normalidad hasta poco antes de las 18:00 UTC (19:00 hora local). Los ingenieros del segundo operador móvil más grande de España recuperaron el control de su cuenta de RIPE NCC y empezaron a publicar nuevos ROA para permitir el restablecimiento del servicio.
Si bien RPKI se empleó como un instrumento central de este ataque, no debe interpretarse como la causa de la caída del servicio, como tampoco culparíamos a un enrutador si un adversario consiguiera las credenciales de inicio de sesión y comenzara a deshabilitar las interfaces.
Parece que antes del 3 de enero, la cuenta de RIPE NCC del operador móvil español nunca había creado un ROA (aunque otras partes de Orange habían creado algunos en su nombre). Si antes Orange España no le prestaba demasiada atención a RPKI, ahora seguramente lo hace.
Aunque el servicio ya se restableció, aún queda mucho trabajo de limpieza por hacer. Al momento de escribir esta nota, más de mil rutas originadas por AS12479 aún no son válidas, principalmente debido a la longitud máxima de prefijo configurada en los ROA para los dos /12. Entre ayer y hoy, la cantidad de direcciones IPv4 únicas originadas por AS12479 se redujo de 7 millones a 5 millones, y algunos ROA falsos con origen AS49581 todavía están en circulación.
Una de las más de mil rutas recientemente no válidas para RPKI todavía originadas por AS12479.
Quisiera recordarles a los ingenieros que están limpiando los ROA que la longitud máxima de prefijo es un campo opcional y que puede dejarse vacío, lo que hace que RPKI solo analice el origen del ROA. Esto se publicó recientemente como una mejor práctica actual.
RIPE NCC, el RIR responsable de gestionar la asignación y el registro de recursos numéricos de Internet (direcciones IP y ASN) en Europa, ha iniciado una investigación sobre el incidente.
Esperamos que este incidente sirva como una llamada de atención para otros proveedores de servicios de que su cuenta en el portal del RIR es crítica y debe protegerse con algo más que una simple contraseña.
Las opiniones expresadas por los autores de este artículo son propias y no necesariamente reflejan las opiniones de LACNIC.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
