Rangos vulnerables (los seis): [7.24, 7.24.2), [7.0.0, 7.23.4), [6.0.0, 6.49.21).

Mecanismo de CVE-2026-67276

1. RouterOS compara el blob de clave pública SSH presentado con la clave autorizada del usuario por (tipo de clave, módulo) — el exponente no se compara.
2. La verificación de firma usa la clave proporcionada por el cliente, es decir, el exponente del blob del atacante.
3. Presentar {ssh-rsa, e=1, n=víctima} hace que sig^1 mod n == sig, por lo que la "firma" válida es simplemente EMSA-PKCS1-v1_5(hash, authdata) — calculable por cualquiera que conozca el módulo público de la víctima. No se necesita clave privada.
4. Resultado: un canal de comandos SSH como el usuario objetivo.

Precondiciones (el mínimo de la propia divulgación): nombre de usuario objetivo + el módulo RSA público autorizado de ese usuario.

Información mínima necesaria para reproducir

1. Objetivo: cualquier RouterOS en los rangos vulnerables, con SSH accesible (laboratorio: imagen CHR en QEMU con KVM; hardware real equivalente).
2. Nombre de usuario de una cuenta con una clave RSA autorizada.
3. El módulo RSA n de esa clave autorizada (de un .pub filtrado/capturado, registros de aprovisionamiento, o --modulus-hex). Esta es la única entrada cercana a un secreto; la clave privada nunca es necesaria.
4. Comportamiento del servidor confirmado por la divulgación (el defecto en sí, de CERT PL): coincidencia = (tipo, n), verificación del exponente = proporcionado por el cliente.
5. Un cliente que pueda presentar un blob de clave arbitrario y bytes de firma arbitrarios (paramiko + hook ForgeKey — OpenSSH estándar no puede).
6. Algoritmo de firma que el servidor acepta (ssh-rsa en 6.x, rsa-sha2-256 también en 7.x).

Archivos

• forge_67276.py — primitiva: análisis de clave pública OpenSSH, codificador EMSA RFC 8017, constructores de blob/firma falsificados, verificador de referencia RFC 8017.
• selftest.py — prueba local, sin router: codificador idéntico byte a byte a OpenSSL (mediante inversión de firma real), la firma falsificada verifica con e=1 y NO con 65537, simulación completa de la forma de cable RFC 4252 §7. Las 15 comprobaciones PASAN.
• poc_67276.py — cliente paramiko que realiza la omisión (fijación de algoritmo por conexión; se requiere --lab-i-own-this-target).
• console_setup.py — preparación única de CHR a través de telnet serie de qemu (obtener clave de la víctima mediante 10.0.2.2, importar para admin, habilitar ssh).
• sanity_real_key.py — control: la autenticación normal de clave pública debe tener éxito primero.
• victim_rsa / victim.pub — par de claves "víctima" desechable generado de 2048 bits; excluido deliberadamente de Git.

Configuración local

Laboratorio (aprovisionado en [email protected])

• Kali x86_64, QEMU 11.0.1 + KVM, /root/mikrotrick-lab/, puente del host br0 (192.168.100.1/24) con taps tap0-tap3; dnsmasq en br0 con concesiones por MAC.

• Estado previsto del invitado: NIC e1000, IP de invitado estática, contraseña de admin labpass123, y clave de la víctima importada para admin. Los cambios forzados de contraseña en el primer inicio de sesión se gestionaron por SSH (bootstrap_password.py lee el diálogo) o mediante sendkey del monitor QEMU (mon_type.py) — la consola serie de CHR está muerta por defecto; la consola VGA solo es legible mediante screendump del monitor.
• Túnel desde el Mac: ssh -N -L 2222:192.168.100.11:22 -L 2223:192.168.100.12:22 -L 2224:192.168.100.13:22 -L 2225:192.168.100.14:22 [email protected]

Re-ejecución (ejemplo, VM3):

Resultados observados (revalidación independiente del 2026-09-06)

Para el par 7.x, la línea base de clave real tiene éxito en ambas versiones, la autenticación SSH none es rechazada, una falsificación con módulo incorrecto es rechazada por 7.23.3, y la falsificación con módulo correcto tiene éxito solo en 7.23.3. Esta es una comparación válida de vulnerable frente a parcheado.

El invitado 6.49.21 no fue aprovisionado como se documenta durante la revalidación independiente: admin permaneció caducado, /user ssh-keys print detail estaba vacío, y una solicitud SSH none sin credenciales ejecutó comandos. Claves RSA reales no relacionadas y claves e=1 con módulo incorrecto también parecieron tener éxito. Reaprovisionar este invitado y verificar que none y una clave no relacionada son rechazados antes de usarlo como control parcheado.

Matiz de versión: en 6.49.20 la coincidencia del lado del servidor rechaza el blob e=1 (/log ssh,debug: can't find matching key for user: admin) — la omisión del exponente divulgada no fue observable en el comparador de 6.x aunque el rango general de CERT lista [6.0.0, 6.49.21). Confirmado vulnerable: 7.23.3. Confirmado parcheado: 7.23.4. El estado actual del laboratorio 6.49.21 no prueba ningún resultado. La actividad en la naturaleza de MikroTrick también apuntó a dispositivos 7.x.

Hallazgo de formato de cable (RFC 8332): la cadena de tipo interna del blob permanece ssh-rsa incluso para algoritmos de firma rsa-sha2-256/512; el algoritmo de firma va solo en el campo de algoritmo externo. Ignorar esto hace que el servidor se desconecte a mitad de userauth (error de análisis del blob) — observado tanto en 6.x como en 7.x. El ForgeKey del PoC maneja esto, y --exp-enc aligned|canonical alterna el ancho del mpint e=1 (1 vs 3 bytes). En 7.23.3 AMBOS anchos autentican — el comparador analiza el exponente y realmente ignora su valor. En 6.49.20 NINGUNO autentica (can't find matching key) — ver el matiz de versión anterior. Los volcados hexadecimales de paquetes del lado del servidor /system logging add topics=ssh,debug + /log print sacaron a la luz todo esto.

Valores SHA-256 del archivo de imagen fuente utilizados por este laboratorio:

Notas defensivas (CERT PL)

• Parchear de inmediato: 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21.
• Interino: restringir SSH/WWW/bandwidth-test a redes de gestión de confianza; evitar SSH/TLS iniciado por RouterOS desde dispositivos sin parchear.
• IOCs: líneas de registro login failure for user -2 via ssh, user <name> added by ssh:-2@<ip>; usuario desconocido con altos privilegios ops; marcador /system/device-mode/print "Flagged" (indica compromiso, su ausencia no prueba nada). IPs de atacantes observadas: 82.192.72.4, 103.102.31.18.

Fuentes

• Aviso de CERT PL: https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
• Página CVE de CERT PL: https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
• Boletín de MikroTik (2026-09-03): https://mikrotik.com/supportsec/september-2026-vulnerability/
• Mecanismo "Flagged": https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode#flagged-status