Un secuestro de rutas BGP distribuye una actualización maliciosa de Virtualizor
Índice de contenidos
Claves de la noticia
- El desvío afectó al prefijo 162.55.80.0/24 entre el 28 y el 30 de agosto y alcanzó el punto de actualización de Virtualizor.
- El paquete añadió una clave SSH de administrador, un servicio persistente de systemd y una cuenta no autorizada.
- Virtualizor recomienda revisar todos los servidores, rotar credenciales API y auditar persistencia porque no existe una lista definitiva de instalaciones afectadas.
Atacantes desviaron durante unas 33 horas el tráfico destinado a Softaculous y entregaron una actualización alterada de Virtualizor. La cadena combinó una ruta BGP más específica, un certificado TLS válido y paquetes sin firma para obtener persistencia con privilegios de administrador en servidores reales.
Una ruta más específica ganó al anuncio legítimo
Internet decide cómo alcanzar redes mediante BGP, un protocolo basado en anuncios entre sistemas autónomos. Los atacantes anunciaron 162.55.80.0/24, un bloque de 256 direcciones contenido dentro del /16 habitual de Hetzner. Los routers prefieren la ruta más específica, por lo que parte del tráfico siguió el nuevo camino aunque el anuncio amplio legítimo continuara visible. La operación empezó el 28 de agosto a las 20:57 UTC y terminó el día 30 a las 06:10.
El recorrido publicado pasó por Nexon Host y Zet.net antes de propagarse. Una autorización RPKI con longitud máxima estricta habría permitido marcar la ruta como inválida, y los operadores que aplican validación de origen podrían haberla rechazado. El caso muestra que la seguridad del encaminamiento depende de dos participantes: el titular debe publicar autorizaciones correctas y las redes intermedias deben filtrar anuncios que no coinciden.
TLS protegió la conexión con el servidor equivocado
El candado del navegador no garantizó que el servidor perteneciera al proveedor esperado. Tras controlar temporalmente la ruta y responder desde las direcciones desviadas, los atacantes obtuvieron un certificado válido para el dominio. TLS confirmó que el interlocutor poseía el control exigido en ese momento; no pudo distinguir si ese control procedía de un secuestro de encaminamiento.
La lección no es que TLS sea inútil, sino que dos sistemas de confianza fallaron de manera compatible. La validación de dominio asume que llegar a la dirección correcta es suficiente, mientras BGP no autentica de forma universal el origen. Registros de transparencia, restricciones de emisión y RPKI reducen ventanas, pero el control decisivo para una actualización seguía faltando: una firma del fabricante comprobada por el cliente.
El paquete instaló persistencia como administrador
La actualización alterada se ejecutó con privilegios elevados. Los indicadores descritos incluyen una clave añadida a la cuenta root, Java 17 cuando no estaba presente, un payload guardado en la caché de la máquina virtual Java y un servicio llamado java-jre-update. También apareció la cuenta proxyuser y se observó un inicio SSH desde una dirección atribuida al operador malicioso.
Un proveedor de alojamiento informó de cinco hipervisores comprometidos entre 34 revisados. Esa muestra confirma daño real, pero no permite estimar una tasa global. Tampoco demuestra automáticamente que las máquinas virtuales de clientes o bases de datos fueran modificadas. Cada operador debe conservar evidencias, revisar conexiones salientes, usuarios, claves y tareas programadas antes de reconstruir servidores o declarar que el analizador no encontró nada.
La firma de paquetes habría cortado la cadena
Virtualizor distribuía actualizaciones sin una firma criptográfica que el cliente verificase contra una clave independiente. Por eso, un paquete entregado por un servidor con ruta y certificado aparentemente válidos podía ejecutarse. Una firma separa transporte de autoría: aunque DNS, BGP o TLS sean engañados, el atacante todavía necesitaría la clave privada de lanzamiento para producir un artefacto aceptado.
El fabricante dice que el firmado forma parte del trabajo futuro, pero los operadores necesitan además rotación de claves, publicación reproducible y un procedimiento de revocación. Firmar código malicioso desde un sistema de compilación comprometido no ayuda. La defensa completa protege el origen, aísla la construcción, registra hashes y obliga al agente de actualización a rechazar cualquier paquete que carezca de una cadena válida.
La respuesta exige algo más que ejecutar un escáner
El parche 9 incorpora un analizador con indicadores conocidos y Virtualizor aconseja rotar claves API, restringirlas por dirección y contactar con soporte ante un positivo. Es un comienzo, no una certificación de limpieza. Un atacante con acceso root puede alterar registros o instalar mecanismos distintos. Servidores expuestos durante la ventana deben tratarse como potencialmente comprometidos hasta revisar memoria, discos, accesos y sistemas vecinos.
Para proveedores españoles, la prioridad es identificar versiones y horas de actualización, preservar evidencias y valorar obligaciones de notificación bajo las normas aplicables. La reconstrucción desde imágenes confiables puede ser más segura que eliminar archivos señalados. El incidente une infraestructura de Internet y cadena de software: corregir solo Virtualizor deja el riesgo de rutas, y publicar RPKI sin firmar paquetes mantiene otro camino hacia el mismo privilegio.
