Resumen

  • La ruta no autorizada para 162.55.80.0/24 conservó AS24940 como origen aparente y quedó clasificada como válida por RPKI bajo un ROA que permitía llegar a /24.
  • Virtualizor reconstruyó la difusión mediante 368 pares de RIPE RIS, pero las respuestas del atacante no pasaron por sus registros y el proveedor no pudo producir una lista definitiva de instalaciones afectadas.
  • El control ausente es un comprobante local de consumo de actualización que una versión solicitada, manifiesto firmado, hash del paquete, clave admitida, verificación y resultado de instalación o reversión.

La cifra más grande de un informe de incidente suele adquirir una autoridad que no merece. En este caso es 368. Virtualizor afirma que los 368 pares del conjunto de observación RIPE RIS transportaron la ruta secuestrada en algún momento. Es una medida importante de alcance en la topología. No es un censo de clientes, de solicitudes de actualización, de descargas terminadas ni de máquinas comprometidas.

Separar esas poblaciones es el núcleo del caso. Los colectores de BGP registran caminos. La autoridad de certificación registra una emisión. La infraestructura del atacante ve las conexiones desviadas. Cada servidor que ejecuta Virtualizor decide localmente qué hacer con el archivo recibido. El incidente atravesó las cuatro superficies, pero ninguna conserva por sí sola un relato completo de las demás.

LACNIC publicó el 10 de septiembre de 2026 una versión en español del análisis de Kentik. Esa decisión convierte el episodio en una señal actual para la comunidad regional, no en un incidente operado por el registro. La propia página aclara que las opiniones pertenecen a los autores y no necesariamente a LACNIC. Conviene mantener la atribución exacta: LACNIC difunde el caso, Kentik interpreta la ruta y Virtualizor declara el impacto sobre su producto.

Una ruta válida para una pregunta limitada

Aproximadamente a las 20:57 UTC del 28 de agosto apareció 162.55.80.0/24 con el tramo final 6204 62390 24940. El /24 era más específico que el 162.55.0.0/16 anunciado normalmente por Hetzner. Allí donde un router aceptaba ambos caminos, la coincidencia con el prefijo más largo llevaba el tráfico hacia la nueva ruta.

El atacante no sustituyó el origen aparente. Colocó AS24940, el de Hetzner, al final del AS path. El ROA que cubría el espacio autorizaba ese origen y una longitud de hasta /24. La validación de origen, por tanto, podía devolver el estado RPKI Valid. Comprobó que el prefijo y el último AS coincidían con la autorización publicada; no comprobó que los saltos anteriores fueran auténticos.

RFC 9319 estudia precisamente el secuestro de subprefijo con origen falsificado. Si un ROA no mínimo autoriza longitudes que el titular no anuncia, un adversario puede añadir el origen legítimo al final del camino y ocupar el subprefijo vacío. La práctica recomendada de usar ROA mínimos reduce esta superficie. No convierte la validación de origen en BGPsec ni firma cada relación de tránsito.

Por eso la palabra «válida» necesita siempre su objeto. Válido para origen no significa camino autorizado, proveedor ascendente aprobado, servidor legítimo ni contenido confiable. AS62390 podía aparecer antes del origen aparente sin que esa relación recibiera una autenticación de RPKI. La precisión semántica protege el valor de la herramienta: RPKI hizo la verificación para la que fue diseñada, y el ataque aprovechó lo que esa verificación no cubre.

Virtualizor sitúa el incidente entre las 20:57 UTC del 28 de agosto y aproximadamente las 06:10 UTC del día 30. Describe dos oleadas activas con una pausa cercana a once horas. También cuenta unas 10.600 retiradas de ruta. Una tabla de diez minutos no es, por ello, una película continua. El proveedor advierte que las instantáneas alineadas con los volcados completos cada ocho horas son las más fiables y que el intenso flap puede ocultar pares entre esos cortes.

El resultado de 368 sobre 368 contiene otra condición temporal. Todos los pares vieron la ruta alguna vez; no la vieron todos simultáneamente. En el máximo de una oleada activa, la ruta atravesó cerca del 72 % del conjunto completo de 368 pares. Incluso ese porcentaje es un proxy de topología, no un recuento de bytes. Un par que representa a una gran red y otro que representa a un participante pequeño ocupan una fila cada uno. El dato debe conservar su denominador para seguir siendo útil.

El certificado hizo creíble el destino equivocado

La desviación alcanzó también el proceso de validación de dominio. Virtualizor sostiene que el atacante obtuvo un certificado TLS técnicamente válido para varios nombres de la familia Softaculous, incluidos puntos usados en la distribución de software. Un cliente enviado al servidor del atacante podía establecer una conexión cifrada sin recibir un aviso de certificado. El canal protegía la conversación con el destino proporcionado por BGP; no recuperaba el destino que el editor había pretendido.

La corroboración de emisión desde múltiples perspectivas, MPIC, existe para elevar el coste de esta maniobra. La autoridad consulta desde varios lugares remotos y exige acuerdo, de modo que una falsedad visible sólo en una región produzca discrepancias. Desde el 15 de junio de 2026, los requisitos pertinentes del CA/Browser Forum exigen al menos cuatro perspectivas remotas y corroboración distribuida en por lo menos dos regiones de servicio de registros de Internet. Let’s Encrypt ha explicado que una única trayectoria de validación puede ser engañada por un secuestro o redirección.

Que se emitiera un certificado no convierte MPIC en decoración. La lectura de Kentik es más incómoda y más concreta: una ruta más específica sin competidor se propagó con amplitud suficiente para mostrar el mismo servidor falso a un quórum. Las perspectivas múltiples detectan una mentira local porque no todos observan lo mismo. Si la mentira adquiere alcance casi común, el quórum puede coincidir. ROA estrictos, detección de prefijos nuevos, controles del camino y perspectivas de certificación diversas reducen riesgos distintos.

El servidor legítimo no puede registrar al servidor atacante

Virtualizor dice haber confirmado la entrega del paquete malicioso a un pequeño número de instalaciones, descrito también como un puñado de servidores. Al mismo tiempo reconoce que no puede elaborar una lista definitiva. Las respuestas fueron servidas por el sistema del atacante y nunca llegaron a los logs propios.

Esta ausencia no es una contradicción. Un log web registra las solicitudes que alcanzan el servidor que lo escribe. En un desvío exitoso, una línea ausente puede significar que el cliente no hizo la solicitud o que otro servidor la respondió. La infraestructura legítima pierde visibilidad precisamente cuando el adversario gana el tráfico. Consultar de nuevo el registro central no resuelve una transacción en la que ese registro nunca participó.

La rutina de actualización hace más costosa esa falta. La documentación de Virtualizor dice que, salvo que se desactive la función, el producto se actualiza automáticamente cada 24 horas. Un administrador también puede iniciar el proceso desde el panel o la línea de comandos. Para medir el impacto haría falta saber qué instalaciones consultaron durante las horas activas, cuáles atravesaron un intervalo desviado, cuáles terminaron la descarga, cuáles aceptaron el archivo y cuáles lo ejecutaron. Los 368 pares no contienen esas respuestas.

El aviso añade un fallo decisivo: los clientes de actualización todavía no verificaban criptográficamente los paquetes. El proveedor promete incorporar firma de código para todos ellos. Esa es la reparación preventiva básica. Un actualizador con privilegios debe comprobar metadatos firmados, hash, versión, canal y clave autorizada, y debe detenerse si la prueba falla. TLS no puede ser el único aval de un binario que va a ejecutarse como parte del plano de administración.

Sin embargo, una firma y un comprobante cumplen funciones diferentes. La firma permite rechazar en el futuro un paquete que no procede de una clave aceptada. El comprobante permite reconstruir qué hizo una máquina. Incluso con firma, un investigador necesitará saber si el cliente pidió la versión prevista, recibió otro hash, aceptó una clave luego revocada, bloqueó la instalación, quedó a medias o ejecutó una reversión.

El comprobante que debe vivir en la instalación

Cada intento de actualización debería producir una constancia pequeña y resistente a la alteración. Debe incluir canal y versión solicitada, hora de la solicitud, hash del manifiesto firmado, hash del paquete, clave o umbral de claves aceptado, resultado de la verificación y desenlace local: rechazo, cuarentena, instalación, error o rollback. Toda revocación, aviso de incidente o paquete de reparación posterior debería apuntar a esa constancia.

No hace falta entregar a internet una lista de clientes. El operador puede conservar el comprobante, identificar su flota con un seudónimo y revelar únicamente la evidencia necesaria. El proveedor podría ofrecer un acuse opcional que recibe una prueba ciega o seudónima y devuelve un sello temporal. Un gran host agrega sus comprobantes dentro de su dominio. Un operador pequeño exporta el de la máquina al abrir un caso de soporte. La privacidad limita la recopilación; no obliga a aceptar el vacío.

La utilidad del mecanismo está en la unión de dos afirmaciones. El registro de lanzamientos del proveedor establece qué manifiesto, paquete y claves fueron autorizados. El registro del operador establece qué recibió y decidió una instalación concreta. Si el adversario controla ruta y servidor web, pero no la clave, queda constancia del rechazo. Si una clave se revoca después, se identifica la población que la aceptó. Si aparece un fallo del verificador, el hash permite localizar exactamente qué paquete pasó.

También ordena el lenguaje del incidente. Ver la ruta en un par RIPE indica exposición de red. Hacer una solicitud durante una ventana desviada crea oportunidad de entrega. Completar la descarga demuestra adquisición. Instalar demuestra ejecución. Encontrar el servicio malicioso u otro indicador demuestra compromiso. Cada paso reduce una población distinta. Llamar «afectados» a todos por igual sólo oculta lo que aún no se sabe.

La respuesta del proveedor fue útil, pero llegó sin recibos

La defensa más fuerte debe entrar en el balance. Virtualizor publicó el indicador, pidió rotar y limitar credenciales, recomendó revisar accesos y conservar pruebas, notificó el certificado para su revocación, reconstruyó el episodio de rutas y anunció firma de paquetes. Kentik y LACNIC explicaron por qué los ROA mínimos y la vigilancia importan, sin atribuir a la validación de origen una autenticación completa del camino.

La crítica, entonces, no consiste en exigir una certeza imposible a partir de logs ajenos. Consiste en reconocer que el ecosistema no había diseñado una prueba portátil en el punto de decisión. Cuando el atacante respondió, el servidor legítimo quedó fuera de la transacción. La evidencia independiente posible estaba en la instalación. Pedir comprobaciones a todos los operadores es la precaución correcta bajo incertidumbre; también cuantifica el coste de no saber a quién avisar.

El próximo informe maduro debería alinear tres libros. El de rutas anota perspectiva, camino y tiempo. El de lanzamientos anota manifiesto, paquete, versión y claves autorizadas. El de instalaciones anota la decisión local. Ninguno puede sustituir a otro. Su unión permite pasar de una alerta para toda la base de usuarios a una lista de reparación limitada y justificable.

Fuentes