Resumen

Un atacante remoto no autenticado puede obtener el control administrativo total de un dispositivo MikroTik RouterOS vulnerable interactuando únicamente con su servicio SSH. No se requieren credenciales, ni interacción del usuario, ni acceso local.

Una vez obtenida la política completa, un atacante tiene los mismos privilegios que un administrador de RouterOS del grupo full: leer y modificar toda la configuración, crear cuentas privilegiadas y puertas traseras, habilitar/deshabilitar servicios, redirigir o interceptar tráfico, y utilizar el dispositivo como punto de apoyo para pivotar hacia redes internas.

Versiones afectadas

• Vulnerables: RouterOS 6.x y 7.0.0 hasta 7.23.3 (toda la rama 6.x y 7.x hasta la corrección).
• Corregidas: RouterOS 7.23.4 y posteriores.

El problema se validó contra las versiones oficiales CHR 6.49.20 y CHR 7.21.5 ejecutándose en un laboratorio local basado en QEMU (MikroTik Cloud Hosted Router), y además se confirmó contra un pequeño número de instalaciones expuestas a Internet alcanzadas durante una investigación de validación limitada (detalles omitidos; no se publican hosts de terceros).

Descripción técnica

La vulnerabilidad es una escalada de privilegios preautenticación en el servicio SSH de RouterOS que permite a un cliente SSH no autenticado alcanzar una sesión de consola de RouterOS con una máscara de política administrativa completa.

El mecanismo específico, las rutas de código afectadas y cualquier valor de disparo se omiten intencionadamente para impedir su reproducción. Solo se describe el efecto de alto nivel: un cliente no autenticado puede obtener la política administrativa completa sin credenciales válidas.

Nota sobre divulgación responsable: este documento intencionadamente no publica código de explotación, los valores de disparo específicos ni una receta de reproducción paso a paso. Se proporcionan capturas de pantalla de la prueba de concepto (véase más abajo); no se publica ningún payload funcional ni código fuente.

Impacto

Un ataque exitoso otorga al atacante remoto no autenticado privilegios administrativos completos del grupo full en el router. Consecuencias observadas y realistas:

• Lectura/escritura completa de la configuración — volcar pares BGP/OSPF, reglas de firewall, credenciales VPN, secretos RADIUS/PPP, certificados.
• Manipulación de cuentas — crear nuevos usuarios del grupo full y puertas traseras, bloquear a administradores legítimos.
• Abuso de servicios — habilitar/deshabilitar servicios, abrir agujeros en el firewall, proxy de tráfico.
• Interceptación / redirección de tráfico — secuestro de DNS, MITM en tráfico enrutado, redirección del tráfico de gestión o de usuario.
• Movimiento lateral — usar el router como punto de pivote hacia las redes que enruta, y recuperar credenciales utilizables en otros puntos de la red.
• Material para botnets / DDoS — los routers con control total se reclutan con frecuencia en botnets de DDoS y escaneo.

Dado que los dispositivos RouterOS se sitúan en el borde de la red (puertas de enlace, concentradores VPN, CPE de ISP, routers empresariales), el radio de impacto suele ser mucho mayor que el de un único host comprometido.

Prueba de concepto

Para mantener este aviso seguro para su distribución pública, aquí no se publica código de explotación, ni valores de disparo, ni script de reproducción.

• Validación en laboratorio: confirmado en MikroTik CHR 6.49.20 y 7.21.5 en un laboratorio local con QEMU/Docker. La prueba demostró una acción de escritura (creación y posterior eliminación de un usuario con política full) que es imposible para una sesión de solo lectura/no autenticada — se obtuvo la política de administrador completa preautenticación.

• Capturas de pantalla de la prueba de concepto:

  

  

Corrección

Actualizar RouterOS

El problema está corregido en RouterOS 7.23.4 y posteriores.

1. Haga primero una copia de seguridad de su configuración:

   root@kitploit:~

   /system backup save name=backup-before-upgrade
   /export file=export-before-upgrade
   

2. Actualice a través de los canales habituales:

   • Winbox / WebFig: System → Packages → Check for updates (o suba el routeros-<version>.npk para la arquitectura del router).
   • CLI: consulte el manual en https://help.mikrotik.com/docs/spaces/ROS/pages/47579159/Upgrade.

3. Tras la actualización, verifique la versión en ejecución:

   root@kitploit:~

   /system resource print
   

4. Solo entonces considere volver a habilitar SSH en interfaces externas (véase más abajo).

Prefiera aplicar el parche antes que los workarounds. Las actualizaciones de versión son la única corrección completa. Los workarounds siguientes reducen la exposición pero no eliminan el fallo subyacente.

Prevención y endurecimiento

Para dispositivos que no puedan actualizarse de inmediato — y como defensa en profundidad para los ya corregidos:

1. Restrinja la exposición de SSH en el firewall. No exponga SSH a Internet ni a redes no confiables. Permita solo direcciones de origen confiables:

   root@kitploit:~

   /ip firewall filter
   add chain=input protocol=tcp dst-port=22 src-address=192.168.1.0/24 \
       action=accept place-before=1
   add chain=input protocol=tcp dst-port=22 action=drop place-before=2
   

2. Deshabilite SSH por completo donde no sea necesario. Winbox, WebFig y la API suelen ser suficientes para la gestión; considere si el acceso remoto por CLI debe exponerse en absoluto:

   root@kitploit:~

   /ip service disable ssh
   

3. Exija autenticación fuerte. Si SSH debe permanecer habilitado:

   • Use autenticación basada en claves SSH y deshabilite la autenticación por contraseña cuando sea posible: /user ssh-keys import user=<admin> public-key-file=<file>.
   • Nunca use contraseñas en blanco o predeterminadas (en particular la cuenta predeterminada admin).
   • Imponga contraseñas fuertes y rótelas con regularidad.

4. Coloque la gestión detrás de una VPN / red de gestión segmentada. Enrute el acceso de gestión a través de una red confiable o VPN en lugar de exponerlo directamente; esto aplica a SSH, Winbox (8291), WebFig/HTTP (80/443), la API de RouterOS (8728/8729) y cualquier puerto SSH personalizado (3333, 2222, 8022 y otros reasignaciones comunes se usan con frecuencia).

5. Vigile en busca de indicadores de compromiso (véase Detección más abajo) y habilite el registro de eventos de autenticación y configuración.

6. Mantenga el firmware actualizado y suscríbase a los avisos de seguridad de MikroTik: https://mikrotik.com/support/security.

Detección

Señales de que esta vulnerabilidad puede haber sido intentada o explotada en un dispositivo:

• Cambios inesperados en la configuración: nuevos usuarios (especialmente con grupo full), nuevas reglas de firewall que abren acceso, servicios modificados, cuentas de puerta trasera inesperadas.
• Nuevos o modificados /system identity, ajustes de DNS, o reglas de enrutamiento/firewall que usted no realizó.
• Actividad SSH inusual en los registros del router, como fallos de autenticación repetidos o sesiones abiertas sin un evento de inicio de sesión exitoso correspondiente.

Comprobaciones útiles en un dispositivo en ejecución:

Descargo de responsabilidad

Este documento se publica con fines defensivos y educativos — para permitir a los administradores de dispositivos MikroTik evaluar la exposición, verificar el estado de los parches y endurecer sus despliegues. Los detalles de explotación se omiten intencionadamente y no se publica ningún exploit funcional. Pruebe únicamente sistemas que posea o esté autorizado a evaluar.