MikroTrick: dos fallos de RouterOS permiten tomar el control de routers MikroTik expuestos

Una cadena de vulnerabilidades en RouterOS de MikroTik permite que un atacante con solo acceso de red al servicio SSH de un router tome el dispositivo por completo, y el exploit ya no es teórico. CERT Polska, el equipo nacional de respuesta a incidentes informáticos de Polonia, encontró seis fallos en RouterOS, coordinó su divulgación con MikroTik y confirmó el 5 de septiembre que dos de ellos se combinan en ataques reales. El equipo dio un nombre a la cadena: MikroTrick.

Lectura relacionada: Un bypass de autenticación del Rejetto HFS hallado por IA atrae intentos de explotación · Google corrige CVE-2026-58704, una vulnerabilidad de día cero del módem de Pixel explotada activamente.

Ambos fallos en el centro de la cadena tienen una puntuación CVSS de 9.2. MikroTik publicó los arreglos antes de la divulgación pública, primero el 3 de septiembre en RouterOS versiones 6.49.21, 7.23.4 y 7.24.2, además de la compilación 7.25beta3. La CISA añadió los dos fallos de RouterOS a su catálogo de vulnerabilidades explotadas conocidas el 10 de septiembre, dando a las agencias civiles federales hasta el 13 de septiembre para parchear o documentar controles compensatorios. El mismo lote incluyó ConnectWise ScreenConnect y JFrog Artifactory.

La escala del conjunto de objetivos es la parte que debería detener a cualquier lector. La Shadowserver Foundation contó unos 122.500 dispositivos MikroTik con SSH accesible desde internet en una sola ventana de escaneo de 24 horas el 5 de septiembre. Esa cifra no es un recuento de dispositivos vulnerables, porque no se comprobó la versión. Es un recuento de dispositivos que respondían en el puerto que la cadena de ataque necesita.

Qué hacen los dos fallos

La primera mitad de MikroTrick, registrada como CVE-2026-67276, es un bypass de autenticación en el servidor SSH de RouterOS. Al validar la clave pública RSA de un usuario, RouterOS comparaba solo una parte de la clave: su tipo y su módulo público. No comparaba la clave completa, así que ignoraba el exponente público.

La distinción suena académica hasta que se considera lo que permite. Un atacante que conoce un nombre de usuario y el módulo de la clave autorizada de ese usuario puede construir un par de claves distinto que comparta el módulo, fijar su exponente público en 1 y producir una firma que RouterOS acepta. No hace falta ninguna clave privada, porque el servidor nunca comprobó la parte de la clave que habría hecho imposible la falsificación.

La segunda mitad, CVE-2026-86060, eleva el punto de apoyo que otorga el bypass hasta el control administrativo total. RouterOS gestionaba mal los nombres de usuario SSH que empezaban con un carácter que debería haber rechazado. Un valor manipulado como -2 llegaba a un ayudante de inicio de sesión heredado que leía el guion inicial como el comienzo de una opción de línea de comandos en lugar de como un nombre de usuario literal. Al proporcionar un nombre de usuario con esa forma, un atacante podía alterar la máscara de políticas de confianza del router y terminar con una sesión con todos los privilegios.

Ninguno de los dos fallos requiere contraseña, una cuenta válida ni interacción del propietario del dispositivo. El par solo necesita que SSH sea accesible, que es justo como lo dejan muchos administradores para gestionar un router situado en un lugar incómodo.

Un tercer fallo y tres más

CERT Polska divulgó seis problemas en total. El tercero más grave es CVE-2026-67277, un fallo de autenticación ausente en el servicio bandwidth-test, o btest. Una conexión no autenticada podía entrar en un estado reservado a los usuarios que han iniciado sesión. Combinado con una fuga de datos no inicializados de un búfer de paquetes del kernel y un desbordamiento negativo de entero en la validación del tamaño, esto puede exponer memoria del kernel o provocar un reinicio del dispositivo.

Tres fallos de menor gravedad completan el conjunto: un problema en el cliente SSH, una debilidad de validación de firmas en el tratamiento de certificados X.509 y un fallo de revelación de información en la interfaz WebFig. Ninguno forma parte de la cadena de toma de control observada, pero amplían la superficie sobre la que los administradores deben razonar.

Los rastros que dejaron los atacantes

CERT Polska vinculó la intrusión confirmada a artefactos concretos. Los registros de RouterOS de los dispositivos atacados contienen entradas parecidas a un fallo de inicio de sesión del usuario -2, seguidas de un alta de usuario atribuida a ssh:-2@ y a la dirección del atacante. La agencia también señaló una cuenta con altos privilegios inexplicable llamada ops como indicio de explotación exitosa.

Los ataques que pudo confirmar, incluida la creación de esa cuenta ops, provinieron de 82.192.72.4, una dirección de un rango de Leaseweb, activa al menos desde el 2 de septiembre, tres días antes del aviso público. Una segunda dirección, 103.102.31.18, se usó en intentos de explotación. El payload observado en los sistemas comprometidos era un binario BusyBox de arquitectura MIPS muy parecido a una versión oficial de BusyBox de 2010, distribuido junto a scripts de Python y de shell, según la nota de investigación de la Cloud Security Alliance. Reutilizar una herramienta pública de hace una década en lugar de malware a medida apunta a la velocidad por encima del sigilo, en línea con un escaneo a escala de internet y no con una lista de objetivos elegidos a mano.

El calendario es incómodo. La explotación estaba en marcha el 2 de septiembre. MikroTik publicó los arreglos el 3 de septiembre. La divulgación pública llegó el 5 de septiembre. Durante varios días existió una toma de control sin autenticación funcional contra dispositivos que no tenían ningún número CVE que buscar ni ningún aviso que leer.

Por qué el equipamiento de borde y gestión sigue recibiendo fuego

RouterOS es un habitual en el borde de la red. Los proveedores de servicios de internet, las pequeñas y medianas empresas y los aficionados a las redes lo usan porque el hardware es barato y las opciones de configuración son profundas. Esas mismas cualidades hacen atractivos los dispositivos: están en el perímetro, todo lo que hay detrás confía en ellos y a menudo se instalan una vez y luego se dejan solos.

Esa combinación ya se ha visto antes. Una encuesta de Censys de 2023 citada por la nota de la CSA contó casi 450.000 hosts que todavía exponían interfaces de configuración de RouterOS vulnerables meses después de un parche crítico anterior. Los dispositivos en los que nadie inicia sesión son también dispositivos que nadie parchea según un calendario, lo que alarga la ventana en la que un fallo conocido sigue siendo útil para un atacante.

La comparación con las historias de GitLab y Artifactory de esas mismas semanas es ilustrativa. En cada caso el software vulnerable estaba dentro del perímetro, guardaba credenciales o controlaba el tráfico, y se parcheaba a un ritmo más lento que las aplicaciones expuestas a internet que suelen recibir más atención. Los planos de gestión son de confianza por diseño. Quien alcanza uno hereda buena parte de esa confianza.

Las salvedades que conviene recordar

El bypass de autenticación de MikroTrick es grave, y su alcance práctico es más estrecho de lo que sugiere la puntuación CVSS por sí sola. La clave falsificada tiene que compartir un módulo con una clave autorizada real, lo que significa que el atacante necesita conocer ese módulo. Las claves reutilizadas en una flota de dispositivos, publicadas por accidente o generadas con parámetros débiles lo hacen más fácil. La nota de la CSA informa de que la técnica se reprodujo de forma fiable contra claves RSA generadas con un exponente público bajo, mientras que las claves con el exponente habitual 65537 no eran uniformemente susceptibles. Las organizaciones deberían leer eso como un motivo para inventariar y regenerar las claves SSH autorizadas en los dispositivos RouterOS, y como un motivo para no dar por hecho que todo router expuesto es trivialmente explotable.

La segunda salvedad se refiere a la comprobación de intrusión del fabricante. RouterOS ahora escanea su configuración al arrancar, desactiva las entradas sospechosas reconocidas, escribe un mensaje crítico en el registro y marca el dispositivo como Flagged. CERT Polska es explícito en que este mecanismo detecta solo rastros seleccionados. La ausencia de la marca no es prueba de que un dispositivo esté limpio. Los administradores deberían tratar la marca como una señal entre varias, no como un certificado de buena salud.

Qué deberían hacer ahora los administradores

La guía de CERT Polska es directa, y el orden importa.

• Actualiza RouterOS de inmediato a 6.49.21, 7.23.4, 7.24.2 o la compilación 7.25beta3. Primero parchea; el resto es triaje.
• Si una actualización inmediata es imposible, desactiva SSH, WWW/WWW-SSL y el servidor bandwidth-test, o restringe cada uno a redes de gestión de confianza. Evita iniciar conexiones TLS desde un dispositivo sin parchear o usar su cliente SSH integrado contra hosts no confiables.
• Comprueba la salida de /system/device-mode/print en busca de la marca Flagged y revisa /system history y la lista de usuarios en busca del artefacto -2, de una cuenta ops inesperada u otros inicios de sesión desconocidos.
• Inspecciona la configuración en busca de usuarios, scripts, tareas del programador, servidores proxy y túneles desconocidos.
• Trata como comprometido cualquier dispositivo con la marca Flagged, cambios de configuración inexplicables o scripts no reconocidos. Aíslalo, conserva sus registros y su configuración, reconstruyelo desde una configuración conocida y buena y rota las contraseñas, claves y otros secretos. No restaures a ciegas una copia de seguridad completa de un dispositivo sospechoso.

Qué hay que vigilar

La pregunta inmediata es la adopción. Los arreglos están disponibles y la explotación está documentada, pero la población en riesgo es grande y lenta de mover. El recuento de Shadowserver sugiere que el número de dispositivos con SSH abierto está en los cientos de miles, y el plazo de la CISA solo se aplica a las agencias federales. Es probable que las pruebas de intrusión vayan por detrás del parcheo, porque un dispositivo reconstruido en el sitio sin inspección puede arrastrar consigo a un intruso.

Un segundo hilo que merece seguimiento es cómo se encontraron los fallos. CERT Polska atribuye el descubrimiento a Sławomir Rozbicki y a los modelos GPT-5.5-cyber y GPT-5.6-sol, usados dentro de un laboratorio basado en agentes bajo supervisión de los investigadores. Si la investigación asistida por modelos sigue encontrando cadenas como esta en el firmware de borde, la presión sobre los fabricantes para acortar la distancia entre un arreglo privado y una guía pública útil crecerá, no disminuirá.

Imagen de portada: «MikroTIK hAP Lite and RouterBOARD 750» de Stacatto, Wikimedia Commons, CC BY-SA 4.0.