LACNIC Blog > Enrutamiento > El objetivo del último secuestro de BGP fue un proveedor de software de alojamiento
El objetivo del último secuestro de BGP fue un proveedor de software de alojamiento
10/09/2026
Imagen asistida/creada por IA
El objetivo del último secuestro de BGP fue un proveedor de software de alojamiento
Por Doug Madory, director de análisis de Internet, Kentik
Este artículo se publicó originalmente en el Blog de Kentik
Resumen
Este artículo analiza los detalles técnicos del secuestro de BGP dirigido contra Softaculous Ltd., la empresa detrás del instalador automático Softaculous y de la plataforma de gestión de máquinas virtuales Virtualizor. El secuestro permitió que un atacante obtuviera de manera fraudulenta un certificado TLS y lo usara para distribuir una actualización maliciosa de Virtualizor a una parte de los clientes de la empresa.
Hace apenas unos días, se utilizó un secuestro de BGP como parte de un ataque contra el proveedor de software de alojamiento Softaculous Ltd., la empresa detrás del instalador automático Softaculous y de la plataforma de gestión de máquinas virtuales Virtualizor. En un artículo sobre el incidente, la empresa explica que un atacante combinó un “certificado TLS técnicamente válido” para sus dominios con un secuestro de BGP para distribuir un “paquete de actualización malicioso de Virtualizor” a un “pequeño número de instalaciones”. También recomienda a sus clientes seguir una serie de pasos para verificar si fueron afectados.
A continuación, analizamos con mayor detalle algunos de los aspectos técnicos de este incidente.
(Acceso libre, no requiere suscripción)
¿Cómo secuestró el atacante este espacio de direcciones IP?
A partir de las 20:57 UTC del 28 de agosto de 2026, ingresó un nuevo prefijo a la tabla de enrutamiento global. Se anunció el rango 162.55.80.0/24 a lo largo del AS path:
… 6204 62390 24940
Este rango incluía direcciones IP utilizadas para el endpoint de actualización del software de Softaculous, así como para su portal de clientes y facturación. Fue un secuestro más específico del rango 162.55.0.0/16, que normalmente origina Hetzner Online (AS24940). Es probable que la ruta se originara en el penúltimo AS del camino, NexonHost (AS62390), ya sea debido a un ataque o a que algún cliente aprovechó vulnerabilidades en su seguridad.
El secuestro también incluyó un AS path con un origen falsificado. Al añadir 24940 como el ASN situado más a la derecha del camino, el atacante consiguió que la ruta se considerara válida para RPKI por dos motivos: el ROA exigía que el origen fuera AS24940 y además permitía que la longitud de prefijo estuviera entre 24 y 16. Por lo tanto, los sistemas autónomos que descartan rutas no válidas para RPKI no tenían motivos para rechazarla.
¿Cómo secuestró el atacante este espacio de direcciones IP?
A partir de las 20:57 UTC del 28 de agosto de 2026, ingresó un nuevo prefijo a la tabla de enrutamiento global. Se anunció el rango 162.55.80.0/24 a lo largo del AS path:
… 6204 62390 24940
Este rango incluía direcciones IP utilizadas para el endpoint de actualización del software de Softaculous, así como para su portal de clientes y facturación. Fue un secuestro más específico del rango 162.55.0.0/16, que normalmente origina Hetzner Online (AS24940). Es probable que la ruta se originara en el penúltimo AS del camino, NexonHost (AS62390), ya sea debido a un ataque o a que algún cliente aprovechó vulnerabilidades en su seguridad.
El secuestro también incluyó un AS path con un origen falsificado. Al añadir 24940 como el ASN situado más a la derecha del camino, el atacante consiguió que la ruta se considerara válida para RPKI por dos motivos: el ROA exigía que el origen fuera AS24940 y además permitía que la longitud de prefijo estuviera entre 24 y 16. Por lo tanto, los sistemas autónomos que descartan rutas no válidas para RPKI no tenían motivos para rechazarla.
Como no existía ninguna ruta que compitiera contra 162.55.80.0/24, esta se propagó hasta donde lo permitieron otros mecanismos de filtrado. Además, al ser una ruta más específica, el tráfico con destino en este rango de IP la preferiría frente a la ruta legítima (162.55.0.0/16) porque los routers dan preferencia a la coincidencia con el prefijo más largo.
La siguiente visualización BGP de Kentik muestra la cronología del origen de 162.55.80.0/24. El gráfico muestra el porcentaje de puntos de observación de BGP que tenían 162.55.80.0/24 en sus tablas de enrutamiento a lo largo del tiempo y se puede interpretar como una medida de la propagación de la ruta.
La visualización permite seguir la presencia de 162.55.80.0/24 en la tabla de enrutamiento global. Tras aparecer por primera vez a las 20:57 UTC del 28 de agosto, la ruta se anunció y retiró varias veces de manera intermitente hasta que el verdadero AS24940 comenzó a anunciarla casi 12 horas después, a las 08:44 UTC del 29 de agosto. A las 14:10 UTC del día siguiente, el AS24940 había retirado su ruta.
La ruta de secuestro reapareció a las 19:55 UTC del 29 de agosto y volvió a anunciarse de forma intermitente hasta que, una vez más, el verdadero AS24940 intervino. A las 05:45 UTC del 30 de agosto, empezó a anunciar 162.55.80.0/24, momento en el que cesó el secuestro. Al momento de escribir este artículo, AS24940 sigue anunciando el prefijo 162.55.80.0/24.
Como muestra la visualización anterior, la ruta de secuestro se propagó algo menos que la ruta legítima, lo que indica que un filtrado de rutas evitó una mayor propagación. Aun así, la propagación del secuestro fue considerable y generó el riesgo de una redirección masiva del tráfico hacia 162.55.80.0/24.
¿Cómo consiguió el atacante un certificado TLS válido?
El secuestro de BGP por sí solo no era suficiente para llevar a cabo este ataque. Otra pieza fundamental era que el atacante obtuviera certificados TLS válidos. Esta misma vulnerabilidad ya se había explotado en el ataque de 2022 contra KLAYswap, una plataforma de intercambio de criptomonedas en línea con sede en Corea del Sur.
Sin embargo, irónicamente, KLAYswap y Kakao utilizaban TLS correctamente y no fue una vulnerabilidad de este protocolo lo que se aprovechó durante el ataque. En cambio, el ataque explotó la falsa confianza que TLS deposita en la infraestructura de enrutamiento. \ … \ Utilizando su secuestro de BGP, el atacante primero apuntó a la infraestructura de clave pública (PKI) y lanzó un ataque de intermediario (man-in-the-middle) contra el proceso de distribución de certificados. Solo después de obtener un certificado digital válido para el dominio objetivo, dirigió su ataque hacia usuarios reales al distribuir su archivo JavaScript malicioso a través de una conexión cifrada.
Imagen original: Henry Birge-Lee
La garantía de identidad que ofrece TLS depende de la confiabilidad del sistema de enrutamiento que dirige el tráfico utilizado para validar los certificados al lugar correcto. Para abordar esta vulnerabilidad, la autoridad de certificación pública Let’s Encrypt lleva varios años implementando la Corroboración de Emisión Multiperspectiva (MPIC).
En MPIC, una CA no valida el control de un dominio desde un único punto de observación (que podría ser suplantado por un secuestro BGP localizado). En cambio, realiza comprobaciones simultáneas desde varias ubicaciones geográficas y topológicamente diversas, y requiere el acuerdo de un quórum antes de emitir un certificado. Si el secuestro solo llega a algunos puntos de observación, la falta de acuerdo permite detectarlo.
Sin embargo, en este caso, dado que la ruta de secuestro era una ruta más específica y no tenía competencia, su propagación global creó un quórum completamente controlado por el atacante.
Prevención y detección
También en 2022, un secuestro de BGP atacó con éxito el servicio de criptomonedas Celer Bridge, alojado por AWS. En el artículo que escribí en ese momento, mencioné la práctica que seguía entonces AWS de utilizar ROA muy permisivas que permitían múltiples orígenes y prefijos “con tamaños desde un /10 hasta un /24” como un factor que limitaba la capacidad de validación de origen con RPKI para ayudar. En ese artículo, agregué:
Un enfoque alternativo para la creación de ROA sería hacer lo que han hecho otras redes como Cloudflare y Comcast: establecer el origen y la longitud máxima del prefijo para que sean idénticos a cómo se enruta el prefijo. Si bien este enfoque implica el costo adicional de actualizar una ROA cada vez que se modifica una ruta, también deja poco margen para que circulen versiones alternativas de la ruta.
AWS ahora utiliza coincidencias exactas en sus ROA, pero debemos tener cuidado de no sobreestimar las capacidades de ROV con RPKI para protegernos de un “adversario decidido” como este. Siempre hemos sabido que los atacantes pueden falsificar AS paths para lograr que un secuestro sea válido para RPKI. Pero si Hetzner Online hubiera utilizado ROA estrictas con longitudes de prefijo máximas que coincidieran con sus rutas, la circulación del secuestro se habría reducido significativamente, lo que habría permitido a MPIC evitar la emisión de certificados TLS válidos.
Al igual que en el caso del ataque contra Celer Bridge, monitorear el BGP podría haber alertado de que se estaba anunciando un nuevo /24 del espacio de direcciones de Hetzner Online, aunque el origen falsificado podría haber hecho que pareciera legítimo.
Sin embargo, la aparición de este nuevo prefijo /24 con un upstream inesperado de NexonHost (AS62390), debería haberse activado una alerta sobre esta anomalía. El detalle clave para distinguir esta alerta de la aparición de un nuevo peer de Hetzner Online habría sido que el nuevo origen fuera visible para la gran mayoría de los puntos de observación del BGP. En otras palabras, este nuevo prefijo estaba siendo transitado exclusivamente por este proveedor de alojamiento relativamente desconocido, una señal que podría haber llamado la atención del equipo de operaciones de red de Hetzner Online.
Conclusión
Aunque la validación de origen con RPKI ha contribuido significativamente a reducir los errores de enrutamiento, no está diseñada para evitar por completo un incidente como este. RPKI funciona reduciendo la propagación de errores de origen filtrados, que suelen deberse a errores involuntarios. También hemos visto los beneficios de ROV con RPKI durante los llamados secuestros “intencionales, pero también accidentales” como el bloqueo de Telegram en India ocurrido en junio. En cualquier caso, unas ROA más estrictas podrían haber permitido que la validación de origen con RPKI redujera la propagación de la ruta secuestrada a tal punto que MPIC podría haber evitado la emisión de un certificado TLS válido.
Este tipo de ataques contra la infraestructura subrayan problemas universales que no se limitan a las criptomonedas ni al software de alojamiento. Las empresas que buscan proteger sus infraestructuras expuestas a Internet deben desplegar un monitoreo sólido del BGP y el DNS, tanto para su infraestructura como para cualquier dependencia accesible desde Internet.
Las empresas deben rechazar las rutas inválidas para RPKI y, al mismo tiempo, crear ROA estrictas para su espacio de direcciones IP al incluir longitudes máximas de prefijo que coincidan con las longitudes de prefijo utilizadas en sus rutas. De hecho, la RFC 9319 Uso de maxLength en la infraestructura de clave pública de recursos (RPKI) considera una “mejor práctica actual” que las redes eviten por completo el uso del atributo maxLength en las ROA, salvo en determinadas circunstancias. Dejar el campo maxLength en blanco en una ROA tiene el mismo efecto que configurarlo para que coincida con el prefijo. Estas medidas pueden reducir significativamente la ventana de oportunidad para que un atacante vulnere su infraestructura de Internet.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
