Breve historia de los mayores incidentes de BGP en Internet
01/09/2023
Por Doug Madory – Director de análisis de Internet en Kentik
Originalmente se publicó en el blog de Kentik
Resumen
Empezando por la fuga del AS7007 de 1997, este artículo analiza los incidentes de BGP más notables y significativos en la historia de Internet, desde fugas de BGP que interrumpieron el tráfico hasta secuestros de BGP para robar criptomonedas.
En el verano del 2022, me uní a un equipo de expertos en BGP organizado por el Grupo de Asesoramiento Técnico sobre Internet de Banda Ancha (BITAG) para redactar un informe exhaustivo sobre la seguridad de la infraestructura de enrutamiento de Internet. La sección de la que fui principalmente responsable abordaba la historia de los incidentes de BGP más notables, un tema sobre el que he escrito extensamente a lo largo de mi carrera en la industria de Internet.
Lo que sigue es una versión editada de mi perspectiva sobre los incidentes de BGP más memorables que se han producido en Internet. Henry Birge-Lee de Princeton fue el autor principal de gran parte de la sección sobre los ataques a los servicios de criptomonedas.
Incidentes de seguridad de enrutamiento BGP
Los incidentes de seguridad en BGP pueden ser problemáticos por diferentes razones. En algunos casos, simplemente interrumpen el flujo legítimo de tráfico de Internet, mientras que en otros pueden provocar el desvío de las comunicaciones, lo que representa un riesgo de seguridad por intercepción o manipulación. Los incidentes de enrutamiento ocurren con cierta regularidad y su impacto operativo puede ser muy variable. En esta nota abordaré algunos incidentes específicos que han demostrado la variedad y gravedad de las amenazas a la estabilidad y la seguridad del sistema de enrutamiento de Internet.
Interrupciones y ataques provocados por incidentes de BGP
En la jerga de BGP, el término “fuga de rutas” se refiere de forma general a un incidente de enrutamiento en el que uno o más anuncios de BGP se propagan entre sistemas autónomos (AS) de una manera que no era la deseada. Estos incidentes suelen ocurrir por accidente, pero un actor malicioso también puede intentar camuflar un ataque intencional bajo la apariencia de un accidente.
En el 2016, la RFC 7908 introdujo una taxonomía más compleja para las fugas de rutas, pero aquí solo me referiré a dos categorías principales de errores: errores en el origen y errores en el AS path.
- Un error al origen se produce cuando un AS origina (es decir, anuncia con su ASN como origen) un nuevo anuncio de una ruta a un bloque de direcciones IP sobre el cual no tiene el control legítimo, y así solicita el tráfico destinado a esas direcciones IP.
- Un error AS path ocurre cuando un sistema autónomo se inserta como un intermediario ilegítimo en la ruta de reenvío de tráfico dirigido a un destino diferente.
Esta distinción es importante porque los dos tipos de error requieren diferentes estrategias de mitigación.
¿Cuál es la diferencia entre un secuestro de BGP y una fuga de rutas?
En general, la frase “secuestro de BGP” connota una intención maliciosa, mientras que se supone que una “fuga de rutas” es accidental. Para complicar las cosas, hay incidentes de BGP que involucran componentes tanto intencionales como accidentales y otros que simplemente no sabemos si fueron intencionales o no. Los expertos en el tema tienen distintas opiniones sobre lo que constituye una fuga de rutas versus un secuestro de BGP.
Errores en el origen
Podría decirse que el incidente del AS7007 ocurrido en abril de 1997 fue la primera gran disrupción de Internet provocada por una fuga de rutas. En este incidente, un error de software hizo que un router anunciara una gran parte de los rangos de direcciones IP presentes en la tabla de enrutamiento global como si hubieran sido originados por el AS7007. Esta fuga de origen se vio agravada por el hecho de que las rutas eran más específicas (more-specifics, es decir, rangos de direcciones IP más pequeños) y, por lo tanto, tenían mayor prioridad según el algoritmo de selección de ruta de BGP.
Otro factor que contribuyó al grado de disrupción fue el hecho de que las rutas filtradas persistieron incluso después de que al router que originó el problema lo desconectaron de Internet. Durante la fuga, una gran parte del tráfico de Internet fue redirigida al AS7007, donde saturó los equipos de esa red y fue descartado.
Poco después del incidente del AS7007, se produjo una fuga masiva desde el AS701, que en aquel entonces era UUNet. En este incidente, el AS701 originó todo el espacio IPv4 contenido en 128.0.0.0/9 desagregado en bloques /24, alterando el flujo de tráfico a una gran parte de la tabla de enrutamiento global.
En los años siguientes, se produjeron otras fugas de origen igualmente grandes que alteraron la comunicación por Internet. Estos incidentes incluyen la fuga de Turk Telecom ocurrida en diciembre del 2004, la fuga de China Telecom de abril de 2010 y la fuga de Telecom Malaysia de junio del 2015. Cada una de estas disrupciones duró menos de una hora y aparentemente afectó bloques de direcciones sin ningún patrón determinado.
Las fugas de origen a gran escala como las descritas se han vuelto menos frecuentes en los últimos años gracias al aumento de la automatización de la configuración de los routers en las redes de topología central. Para informar la configuración defensiva de los routers se utilizan dos metodologías que compiten entre sí, RPSL y RPKI. En ambos casos, la información que permite relacionar los bloques de direcciones IP con los números de sistema autónomo (ASN) autorizados para originarlos es pública, y la mayoría de los grandes operadores de redes destilan esta información para crear “listas de filtrado”, que bloquean la incorporación de los anuncios de rutas BGP que no pasan este filtrado en las tablas de enrutamiento locales.
Los errores en el origen también pueden incluir incidentes que no fueron totalmente accidentales, mejor conocidos como secuestros de BGP. Quizás el secuestro de BGP más famoso haya sido el incidente ocurrido en febrero del 2008 que involucró a la empresa estatal de telecomunicaciones de Pakistán, PTCL y YouTube. En este caso, el gobierno de Pakistán ordenó que se bloqueara el acceso de los ciudadanos pakistaníes a YouTube debido a un video que consideró antiislámico.
Diagrama del secuestro de YouTube por parte de Pakistan Telecom en el 2008 (fuente)
Para implementar el bloqueo, PTCL anunció rutas más específicas de las rutas BGP de YouTube para secuestrar intencionalmente el tráfico de Pakistán al servicio de streaming de video. Una vez secuestrado, el objetivo de PTCL era enviar el tráfico a un agujero negro, evitando que los pakistaníes pudieran acceder a YouTube. Pero las cosas empeoraron cuando PTCL transmitió estas rutas a sus proveedores de tránsito internacional, quienes propagaron las rutas al mundo entero, bloqueando así YouTube para una gran parte de la Internet global.
Desde el secuestro de PTCL-YouTube, se han producido otros casos de manipulación de tráfico localizado implementados por fugas de rutas a Internet. En el 2017, Rostelecom, la empresa de telecomunicaciones estatal rusa, filtró un conjunto curioso de rutas, entre ellas las de las principales instituciones financieras.
Durante la censura de Internet tras el golpe militar en Myanmar de 2021 y la censura de las redes sociales en Rusia tras su invasión de Ucrania, las empresas de telecomunicaciones de cada uno de estos países intentaron bloquear el acceso a Twitter al usar un secuestro de BGP para redirigir el tráfico a un agujero negro. En cada caso, la ruta secuestrada en forma intencional se propagó por Internet en forma no intencional y afectó a los usuarios de Twitter fuera de los países donde se originó el problema.
Visualización preparada por Ventik del secuestro ruso de BGP que afectó a Twitter en febrero de 2022 (fuente)
En el 2008, algunos investigadores describieron cómo se podría manipular BGP para implementar un ataque de intermediario (man-in-the-middle attack) a través de Internet. El primer caso documentado de un ataque de intermediario basado en BGP como el descrito en el 2008 se descubrió en el 2013. Este ataque se originó en Bielorrusia y su blanco fueron las redes de las principales empresas de tarjetas de crédito estadounidenses y los gobiernos de todo el mundo.
Diagrama de desvío de tráfico debido al ataque de intermediario basado en BGP del 2013 (fuente)
En agosto de 2013 y durante un período de seis días, el proveedor de servicios de spyware Hacking Team realizó secuestros de BGP en nombre del Grupo de Operaciones Especiales de la Policía Militar Nacional Italiana. Esto se conoció por documentos que se filtraron cuando la propia red de Hacking Team fue hackeada.
Por último, en el 2018, la empresa de seguridad Backconnect defendió públicamente un secuestro de BGP que admitió haber realizado para recuperar el control de un servidor de botnet responsable de haber implementado ataques DDoS. Los investigadores luego descubrieron que la empresa de mitigación de ataques DDoS había estado implicada en numerosos secuestros de BGP previos y había estado utilizando un servicio de alquiler de DDoS para impulsar su negocio.
Errores en el AS path
No en todos los incidentes de enrutamiento el perpetrador especifica su propio ASN como el origen de la ruta errónea. En noviembre del 2018, MainOne, una gran empresa de telecomunicaciones en Nigeria, filtró rutas recibidas de varios de sus peers —entre ellos las principales redes de entrega de contenido— a sus proveedores de tránsito upstream.
Uno de los proveedores de tránsito de MainOne, China Telecom, no filtró estos anuncios erróneos, los incorporó en sus propias tablas de enrutamiento y procedió a propagarlos a sus numerosos clientes y peers. El resultado fue que una parte significativa del tráfico de Internet destinado a las redes de las víctimas se desvió a través de China. Poco después, MainOne confirmó que la fuga fue provocada por una configuración incorrecta de los routers. A pesar del error, el tráfico desviado aún podría haber sido objeto de intercepción o manipulación.
En junio del 2019, Allegheny Technologies filtró miles de rutas aprendidas de un proveedor de tránsito (DQE Communications) a otro, Verizon. Las rutas filtradas por Allegheny incluían rutas más específicas que habían sido generadas por un optimizador de rutas empleado por DQE. El resultado fue que estas rutas más específicas se propagaron por Internet y desviaron cantidades significativas de tráfico a Allegheny, lo que provocó una grave disrupción.
Diagrama de la fuga de rutas de Allegheny Technologies de junio del 2019 (fuente)
Por último, durante un período de más de dos años, China Telecom filtró rutas de la red Asia-Pacífico de Verizon aprendidas a través de un AS peer en común de Corea del Sur. El resultado fue que una parte del tráfico de Internet de todo el mundo destinado a Verizon Asia-Pacífico se desvió a través de China continental. Sin esta fuga, China Telecom solo habría estado en el camino hacia Verizon Asia-Pacífico para el tráfico procedente de sus clientes en China. Además, en el 2017, durante diez días Verizon pasó sus rutas de Estados Unidos a China Telecom a través del peer en común de Corea del Sur, lo que provocó que una parte del tráfico de Internet local dentro de Estados Unidos se desviara a través de China continental.
Diagrama de la fuga de China Telecom de las rutas de Verizon en el 2017 (fuente)
En cada uno de estos incidentes, los orígenes de las rutas filtradas no se modificaron, lo que significa que cualquier mecanismo de seguridad de BGP basado en la verificación del origen de las rutas no hubiera funcionado.
Dado que la filtración de Allegheny involucró a rutas más específicas, la validación de origen de rutas (ROV) de RPKI podría haber resultado útil si Verizon la hubiera empleado para filtrar rutas en el momento de la fuga. Los prefijos más específicos tienen una longitud mayor y hubieran sido rechazados por exceder la longitud máxima establecida en RPKI, como fue el caso de las rutas de Cloudflare afectadas.
En general, estos tipos de fugas son más difíciles de mitigar que las fugas de origen y solo se pueden abordar analizando y filtrando los AS paths de las rutas BGP. Hay diferentes propuestas técnicas tales como ASPA (Autonomus System Provider Authorization) que están en discusión, pero hoy en día no existe ningún mecanismo para eliminar este tipo de incidentes de Internet.
Ataques contra servicios de criptomonedas
Esta sección se enfoca en los incidentes de BGP intencionales (todos por fugas de origen), ya que permitieron ataques más grandes que lograron robar criptomonedas, un objetivo particularmente lucrativo.
En el 2014, se usaron secuestros de BGP para interceptar comunicaciones no protegidas entre los mineros y los pools de minería de Bitcoin. Esto permitió que un atacante obtuviera bitcoins que deberían haberse asignado al pool de minería. Si bien este incidente sirve como ejemplo de un secuestro de BGP dirigido a la comunicación detrás de escena de la minería de criptomonedas, algunos ataques más recientes han utilizado BGP para atacar a las criptomonedas con un enfoque más directo: robar a los usuarios de billeteras de criptomonedas en línea.
En el 2018, algunos atacantes emplearon un secuestro de BGP para redirigir el tráfico al servicio de DNS autoritativo de Amazon. Habiendo secuestrado el tráfico de DNS, el atacante respondió consultas de DNS para la billetera de criptomonedas “myetherwallet.com” con una dirección IP maliciosa. Los usuarios que recibían esta respuesta errónea del DNS eran dirigidos a un sitio web “myetherwallet.com” impostor. Algunos usuarios ingresaron sus credenciales para iniciar una sesión, y estas credenciales fueron robadas por el atacante junto con el contenido de sus billeteras de criptomoneda.
Diagrama de los secuestros de BGP y DNS dirigidos a myetherwallet.com (fuente)
Si bien las medidas de seguridad para DNS más avanzadas (por ejemplo, DNSSEC) podrían haber evitado este ataque, la principal protección implementada era el protocolo TLS (Transport Layer Security), que requiere que todas las conexiones estén cifradas. Cuando TLS establece una conexión cifrada, el servidor debe presentar un certificado válido que avale la identidad del servidor. Dado que MyEtherWallet usó TLS, a los usuarios que fueron dirigidos al sitio impostor se les presentó una advertencia destacada que decía que su conexión podía estar bajo ataque. A pesar de ello, muchos usuarios pasaron por alto la advertencia y el atacante logró hacerse de 17 millones de dólares en la criptomoneda Ethereum.
Si bien el ataque del 2018 fue bastante eficaz y demostró la viabilidad de los ataques BGP a gran escala contra las criptomonedas, también dejó a la vista algunos aspectos positivos. En particular, la comunicación (al menos en teoría) seguía protegida por el protocolo TLS, lo que llevó a la advertencia de seguridad. En la mayoría de los casos, el comportamiento correcto para una conexión TLS cuando obtiene un certificado que no es de confianza consiste en descartar la conexión, y las versiones más recientes de Firefox no permiten que los usuarios hagan clic más allá de una advertencia de los certificados TLS. Además, si el sitio web hubiera utilizado DNSSEC para proteger su tráfico de DNS, el ataque no hubiera sido exitoso.
Sin embargo, ambas tecnologías de seguridad fueron completamente superadas por un ataque contra el intercambio de criptomonedas coreano KLAYswap que se produjo en el 2022. Como Henry Birge-Lee de Princeton describió en su publicación, el ataque contra KLAYswap explotó varias vulnerabilidades de la aplicación web de intercambio de criptomonedas de KLAYswap.
Diagrama del ataque contra KLAYswap (fuente)
Los atacantes usaron BGP para secuestrar la dirección IP de un servidor que pertenecía a Kakao Corp donde estaba alojado un fragmento específico de código JavaScript utilizado por la plataforma KLAYswap. El objetivo del atacante era servir una versión maliciosa de este archivo de código que, en última instancia, haría que los usuarios de la plataforma KLAYswap transfirieran —sin saberlo— su criptomoneda a la cuenta del atacante.
Sin embargo, al igual que MyEtherWallet, KLAYswap y Kakao Corp usaban TLS, por lo que, si el atacante presentaba un certificado válido para completar la conexión TLS, el código del atacante no se cargaría. Esto no detuvo al atacante, quien usó un ataque conocido en la comunidad de investigación donde, después de lanzar el ataque inicial, le solicitó a una autoridad de certificación (CA) confiable (las entidades que firman los certificados TLS) un certificado para el nombre de dominio del servidor de Kakao Corp donde se alojaba el archivo JavaScript.
Las CA tienen que operar bajo reglas diseñadas para evitar la emisión de certificados maliciosos, que requieren que la CA verifique que la parte que solicita el certificado tenga el control de los nombres de dominio indicados en el certificado. Uno de los métodos de verificación aprobados consiste en ponerse en contacto con el servidor del dominio a través de una conexión HTTP sin cifrar y verificar la presencia de un contenido específico solicitado por la CA. Esto no se puede hacer a través de una conexión cifrada y autenticada, ya que puede que la parte que solicita el certificado lo esté haciendo por primera vez.
Durante el ataque, cuando la CA fue a verificar la propiedad del dominio, su solicitud fue enrutada al servidor del atacante por causa del secuestro de BGP. Esto hizo que la CA creyera equivocadamente que el atacante era el propietario legítimo del dominio y que le emitiera un certificado al atacante. Después, el hacker completó el ataque utilizando este certificado para establecer una conexión “autenticada” con los usuarios de KLAYswap y distribuir su código malicioso. En un período de varias horas, le robaron dos millones de dólares a los usuarios de KLAYswap.
Este ataque es particularmente notable porque involucra un ataque BGP que logró explotar un sistema que cumplía con las mejores prácticas actuales en materia de seguridad. Incluso las defensas más agresivas de capa de aplicación como DNSSEC y un mejor comportamiento frente a un error del certificado TLS no habrían podido prevenir este ataque, ya que el adversario no manipuló ninguna respuesta del DNS y distribuyó su código malicioso a través de una conexión cifrada confiable. En el ecosistema web actual, hay millones de otros sitios web —incluso los que siguen las mejores prácticas— que son vulnerables a este tipo de ataque.
En agosto del 2022, el servicio de criptomoneda Celer Bridge fue blanco de un ataque mediante secuestro de BGP que usó entradas falsas en AltDB, una alternativa gratuita a las bases de datos de los IRR, así como anuncios BGP falsificados. Al modificar subrepticiamente el contenido de AltDB, el atacante pudo engañar a un proveedor de tránsito para que creyera que un pequeño centro de hosting en el Reino Unido podía ofrecer servicio de tránsito al espacio de direcciones perteneciente a Amazon Web Services, que alojaba la infraestructura de Celer Bridge. Después, el atacante falsificó el AS path de sus anuncios para que incluyeran un ASN de Amazon como origen, burlando así la validación de origen RPKI. El secuestro permitió al atacante redirigir fondos en criptomonedas a una cuenta que él mismo controlaba.
Ocupación de direcciones IP
La discusión anterior se centró principalmente en las disrupciones o las implicaciones de seguridad del enrutamiento incorrecto de direcciones IP que estaban en uso activo (es decir, enrutadas) en el momento de la fuga o el secuestro. Sin embargo, hay actores maliciosos que anuncian rangos de direcciones IP que normalmente no son enrutadas y que no les pertenecen con el fin de evadir listas de bloqueo basadas en direcciones IP y complicar la atribución. A este fenómeno se le suele llamar “ocupación de direcciones IP” o IP squatting, pero dado que involucra anuncios BGP no autorizados, a veces también se conoce como secuestro de BGP.
Dado que no existen medidas legales o técnicas eficaces que impidan esta práctica, una persona puede anunciar rangos de direcciones IP previamente no utilizados que pertenecen a otros hasta que las redes en Internet tomen medidas para bloquearlos por este mal comportamiento. En julio del 2018, una red a la que luego se le llamó la “Fábrica de secuestros de BGP” fue eliminada de Internet gracias a un esfuerzo colectivo. Sin embargo, estas soluciones no son muy habituales y no se puede contar con ella para mantener a raya esta práctica.
Pensamientos finales
Originalmente redactados para el Informe de BITAG sobre la seguridad del enrutamiento, los párrafos precedentes solo analizan los incidentes más notables de los múltiples incidentes —accidentales o no— que han involucrado a BGP a lo largo de los años. Esta extensa lista de incidentes refuerza el argumento de que las redes deben tomar en serio la seguridad del enrutamiento e implementar medidas para protegerse a sí mismas o a otras partes de Internet.
Como mínimo, recomendamos usar una solución de monitoreo de BGP para asegurarnos de recibir alertas cuando un incidente como los aquí descritos afecte el espacio de direcciones IP que pertenece a nuestra empresa u organización. Además, recomendamos implementar validación de origen RPKI al crear autorizaciones de origen de ruta (ROA) para nuestro espacio de direcciones IP y configurar nuestros enrutadores para que rechacen las rutas no validadas por RPKI.
Para conocer otras acciones recomendadas para mejorar la seguridad del enrutamiento, se pueden consultar las Normas Mutuamente Acordadas para la Seguridad de Enrutamiento (MANRS), que se autodefine como una “iniciativa global que ayuda a reducir las amenazas más comunes al enrutamiento”.
En los últimos diez años hemos logrado un enorme progreso. Por ejemplo, hace muchos años que no experimentamos una fuga de origen a gran escala, y eso no es casual. Muchos ingenieros de muchas empresas han trabajado para mejorar la higiene general del enrutamiento y todos nos beneficiamos de ese trabajo. Sin embargo, todavía queda mucho por hacer antes de poder decir que hemos asegurado el protocolo de enrutamiento BGP, por lo que debemos continuar avanzando en esta tarea compleja y difícil.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.