Extracto: Un breve secuestro de BGP en 2025 demostró cómo la seguridad del enrutamiento puede fallar cuando los atacantes explotan las vulnerabilidades en la incorporación de proveedores.
Durante la sesión del Grupo de Interés Especial (SIG) de APNIC sobre Seguridad del Enrutamiento que formó parte de APRICOT 2026/APNIC 61, APNIC y LACNIC presentaron un estudio de caso sobre un secuestro de BGP que combinó un ataque técnico con ingeniería social. El incidente ocurrió en julio de 2025. Este artículo explica el incidente, la coordinación entre los Registros Regionales de Internet (RIR) y lo que esto implica para las ROA (Route Origin Authorizations) y las ASPA (Autonomous System Provider Authorizations).
(Acceso libre, no requiere suscripción)
El incidente
El primer informe llegó de un usuario que no podía enviar correos electrónicos. Los mensajes eran aceptados por el servidor, pero nunca llegaban al destinatario. Como esto ocurrió a altas horas de la noche, inicialmente se pensó que era un problema rutinario del sistema y el equipo planificó investigarlo al día siguiente. Un análisis más profundo mostró que parte del espacio de direcciones de LACNIC estaba siendo originado por redes que no estaban autorizadas para hacerlo.
El análisis mostró que el atacante falsificó el Número de Sistema Autónomo (ASN) de forma que la ruta anunciada por el AS del atacante no fuera marcada como inválida. Esta estrategia facilitó la propagación de los anuncios falsos. El atacante también redirigió el tráfico a través de un servidor upstream que posteriormente se confirmó que era otra víctima y no un cómplice.
Se produjeron tres breves eventos de secuestro:
El incidente
El primer informe llegó de un usuario que no podía enviar correos electrónicos. Los mensajes eran aceptados por el servidor, pero nunca llegaban al destinatario. Como esto ocurrió a altas horas de la noche, inicialmente se pensó que era un problema rutinario del sistema y el equipo planificó investigarlo al día siguiente. Un análisis más profundo mostró que parte del espacio de direcciones de LACNIC estaba siendo originado por redes que no estaban autorizadas para hacerlo.
El análisis mostró que el atacante falsificó el Número de Sistema Autónomo (ASN) de forma que la ruta anunciada por el AS del atacante no fuera marcada como inválida. Esta estrategia facilitó la propagación de los anuncios falsos. El atacante también redirigió el tráfico a través de un servidor upstream que posteriormente se confirmó que era otra víctima y no un cómplice.
Se produjeron tres breves eventos de secuestro:
2025‑07‑09 19:47 (UTC −3) por alrededor de 20 minutos
2025‑07‑10 20:34 (UTC −3) por alrededor de 15 minutos
2025‑07‑12 10:13 (UTC −3) por alrededor de cinco minutos
No se registró ninguna otra actividad. Este ASN tenía un historial de ataques similares en AFRINIC, ARIN, LACNIC y APNIC, lo que respalda la conclusión de que se trató de un ataque deliberado y no accidental.
El equipo también logró reconstruir parte de la infraestructura del atacante. Identificaron un servidor de correo electrónico, un servidor web y otro sistema que escuchaba en varios puertos, posiblemente una herramienta de escaneo o un honeypot.
La actividad mostraba claros indicios de reconocimiento. Los anuncios aparecieron en ráfagas de corta duración, en momentos aleatorios y solo llegaron a una pequeña parte de Internet. El atacante también dependía de una relación upstream falsificada para hacer fluir el tráfico. Estos comportamientos coincidían con otros ataques en los que los atacantes prueban hasta dónde se propagan rutas inválidas o sospechosas.
La investigación
LACNIC escaló el caso a APNIC, que a su vez se contactó con APJII/IDNIC, el Registro Nacional de Internet (NIR) de Indonesia, que había delegado el ASN. Los hallazgos fueron inesperados: el titular legítimo del ASN no tuvo ninguna participación. Se trataba de un pequeño proveedor de servicios de Internet con un upstream local y también fueron víctimas. Un actor malicioso se hizo pasar por ellos utilizando documentos falsificados y un nombre de dominio similar al de la organización real.
El atacante convenció a un proveedor upstream multinacional para que habilitara el tránsito para el ASN secuestrado (al que llamaremos “AS X”). Una vez que la sesión BGP estuvo activa, el atacante utilizó el AS X únicamente como tránsito e inyectó anuncios cortos desde varios ASN de origen falsificados detrás de él. Estas ráfagas duraban apenas unos minutos y desaparecían rápidamente, lo que dificultaba su rastreo.
La coordinación entre LACNIC, APNIC y APJII/IDNIC fue clave. Este esfuerzo conjunto permitió confirmar el fraude, identificar a la víctima upstream y demostró el valor de contar con rutas de escalamiento entre los RIR y los NIR.
Flujo del ataque
Figura 1: Esquema del proceso de suplantación de identidad y del proceso de aprovisionamiento del upstream. Fuente
La Figura 1 muestra al titular legítimo del ASN, al ASN secuestrado y al atacante utilizando documentos de identidad falsificados para solicitar tránsito a un proveedor multinacional. El proveedor habilita BGP y el atacante emite anuncios cortos y aleatorios utilizando el ASN secuestrado.
El atacante no eludió RPKI. Lo que hizo fue explotar la debilidad de los procesos de verificación de identidad implementados por el upstream. El proveedor multinacional no validó la identidad corporativa ni la propiedad del dominio del cliente antes de habilitar BGP, lo que permitió que se produjeran los anuncios no autorizados. Los secuestros resultantes se propagaron ampliamente debido a que la validación del origen de la ruta (ROV) no se implementa de manera uniforme y muchas redes aún aceptan rutas NotFound. Además, la presencia de valores excesivamente permisivos del parámetro MaxLength de las ROA aumentó la escala del incidente al permitir que prefijos más específicos parecieran válidos.
Resolución del incidente
APNIC, LACNIC, APJII/IDNIC y el titular legítimo del ASN confirmaron que la solicitud realizada al upstream era fraudulenta. El proveedor upstream dio de baja la sesión BGP. También estuvieron de acuerdo en que el incidente puede servir de ejemplo para la comunidad de seguridad del enrutamiento.
Los ponentes de la sesión también se disculparon con el pequeño ISP, que inicialmente había sido señalado como sospechoso hasta que la investigación confirmó que también era una víctima.
Lecciones sobre la seguridad del enrutamiento
Este incidente deja varias lecciones importantes que ponen de manifiesto oportunidades para reforzar las prácticas actuales de seguridad del enrutamiento.
Disciplina en el uso de MaxLength en las ROA
Valores amplios de MaxLength permiten que rutas no deseadas y más específicas validen bajo ROV. Los operadores deben:
Evitar valores amplios de MaxLength
Ajustar MaxLength según las necesidades operativas reales
Revisar las ROA periódicamente
Esta es una práctica recomendada general y no específica de este incidente.
ASPA y proveedores upstream no autorizados
ASPA puede prevenir relaciones upstream falsificadas. Si se hubiera desplegado ASPA, este ataque habría sido mucho más difícil de realizar. La aplicación de estas medidas depende de la política del operador y del soporte del enrutador.
Figura 2: Controles de seguridad del enrutamiento recomendados. Fuente
La Figura 2 destaca dos defensas clave: establecer valores precisos de MaxLength para las ROA y utilizar ASPA para prevenir proveedores upstream no autorizados.
El aprovisionamiento de proveedores upstream es un límite de seguridad
El ataque se enfocó en el proceso de habilitación de clientes que utilizan los grandes proveedores. Fortalecer este proceso es fundamental. Los proveedores deben:
Verificar los registros del RIR y del Registro de Enrutamiento de Internet (IRR)
Llamar a los contactos registrados para confirmar las solicitudes
Rechazar las cartas de autorización (LOA), que son fáciles de falsificar
Verificar los metadatos del dominio, incluidos la antigüedad, la similitud y los patrones de registro
Adoptar la validación ASPA a medida que esta funcionalidad esté disponible en las diferentes plataformas.
La coordinación entre múltiples partes es importante
Los incidentes de enrutamiento atraviesan fronteras organizacionales y regionales. La coordinación entre RIR, NIR, operadores y grupos de operadores de red (NOG) ayuda a confirmar identidades, identificar patrones y contener incidentes.
Conclusión
La seguridad del enrutamiento incluye más que el cifrado. Las ROA y ASPA reducen los riesgos técnicos, pero no detienen los ataques que explotan las verificaciones de identidad débiles. Una mayor disciplina en las ROA, la adopción de ASPA, una mejor verificación de la incorporación de usuarios y una coordinación continua en toda la comunidad de Internet reducirán la probabilidad de ataques similares. La combinación de controles de la capa de enrutamiento con verificaciones en la capa de identidad permitirá construir una Internet más resiliente.
