Plages vulnérables (toutes les six) : [7.24, 7.24.2), [7.0.0, 7.23.4), [6.0.0, 6.49.21).

Mécanisme de la CVE-2026-67276

1. RouterOS fait correspondre le blob de clé publique SSH présenté à la clé autorisée de l'utilisateur par (type de clé, module) — l'exposant n'est pas comparé.
2. La vérification de signature utilise la clé fournie par le client, c'est-à-dire l'exposant du blob de l'attaquant.
3. Présenter {ssh-rsa, e=1, n=victime} rend sig^1 mod n == sig, donc la « signature » valide est simplement EMSA-PKCS1-v1_5(hash, authdata) — calculable par quiconque connaît le module public de la victime. Aucune clé privée nécessaire.
4. Résultat : un canal de commande SSH en tant qu'utilisateur cible.

Conditions préalables (le minimum de la divulgation elle-même) : nom d'utilisateur cible + module RSA public autorisé de cet utilisateur.

Informations minimales nécessaires pour reproduire

1. Cible : tout RouterOS dans les plages vulnérables, SSH accessible (laboratoire : image CHR dans QEMU avec KVM ; matériel réel équivalent).
2. Nom d'utilisateur d'un compte avec une clé RSA autorisée.
3. Le module RSA n de cette clé autorisée (à partir d'un .pub divulgué/capturé, d'enregistrements de provisionnement, ou --modulus-hex). C'est la seule entrée quasi-secrète ; la clé privée n'est jamais nécessaire.
4. Comportement serveur confirmé par la divulgation (le défaut lui-même, du CERT PL) : correspondance = (type, n), vérification de l'exposant = fourni par le client.
5. Un client capable de présenter un blob de clé arbitraire et des octets de signature arbitraires (paramiko + hook ForgeKey — OpenSSH standard ne le peut pas).
6. Algorithme de signature accepté par le serveur (ssh-rsa sur 6.x, rsa-sha2-256 également sur 7.x).

Fichiers

• forge_67276.py — primitive : analyse de clé publique OpenSSH, encodeur EMSA RFC 8017, constructeurs de blob/signature contrefaits, vérificateur de référence RFC 8017.
• selftest.py — preuve locale, sans routeur : encodeur identique octet par octet à OpenSSL (via inversion de signature réelle), signature contrefaite vérifiée à e=1 et PAS à 65537, simulation complète de la forme filaire RFC 4252 §7. Les 15 vérifications PASSENT.
• poc_67276.py — client paramiko effectuant le contournement (épinglage d'algorithme par connexion ; --lab-i-own-this-target requis).
• console_setup.py — préparation CHR ponctuelle via telnet série qemu (récupération de la clé victime via 10.0.2.2, import pour admin, activation ssh).
• sanity_real_key.py — témoin : l'authentification par clé publique normale doit réussir d'abord.
• victim_rsa / victim.pub — paire de clés « victime » jetable générée de 2048 bits ; délibérément exclue de Git.

Configuration locale

Laboratoire (provisionné sur [email protected])

• Kali x86_64, QEMU 11.0.1 + KVM, /root/mikrotrick-lab/, pont hôte br0 (192.168.100.1/24) avec taps tap0-tap3 ; dnsmasq sur br0 avec baux par MAC.

• État invité prévu : NIC e1000, adresse IP invitée statique, mot de passe admin labpass123, et clé victime importée pour admin. Les changements de mot de passe forcés à la première connexion ont été pilotés via SSH (bootstrap_password.py lit le dialogue) ou le moniteur QEMU sendkey (mon_type.py) — la console série de CHR est morte par défaut ; la console VGA n'est lisible que via le screendump du moniteur.
• Tunnel depuis le 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]

Ré-exécution (exemple, VM3) :

Résultats observés (revalidation indépendante du 2026-09-06)

Pour la paire 7.x, la référence de clé réelle réussit sur les deux builds, l'authentification SSH none est rejetée, une contrefaçon à module erroné est rejetée par 7.23.3, et la contrefaçon à module correct réussit uniquement sur 7.23.3. C'est une comparaison valide vulnérable-versus-corrigé.

L'invité 6.49.21 n'a pas été provisionné comme documenté lors de la revalidation indépendante : admin est resté expiré, /user ssh-keys print detail était vide, et une requête SSH none sans identifiants a exécuté des commandes. Des clés RSA réelles sans rapport et des clés e=1 à module erroné ont donc également semblé réussir. Re-provisionner cet invité et vérifier que none et une clé sans rapport sont rejetés avant de l'utiliser comme témoin corrigé.

Nuance de version : sur 6.49.20, la correspondance côté serveur rejette le blob e=1 (/log ssh,debug : can't find matching key for user: admin) — l'omission d'exposant divulguée n'était pas observable dans le matcher de 6.x bien que la plage globale du CERT liste [6.0.0, 6.49.21). Confirmé vulnérable : 7.23.3. Confirmé corrigé : 7.23.4. L'état actuel du laboratoire 6.49.21 ne prouve aucun résultat. L'activité MikroTrick dans la nature ciblait également les appareils 7.x.

Constat de format filaire (RFC 8332) : la chaîne de type interne du blob reste ssh-rsa même pour les algorithmes de signature rsa-sha2-256/512 ; l'algorithme de signature ne va que dans le champ d'algorithme externe. Ignorer cela fait déconnecter le serveur en plein userauth (erreur d'analyse du blob) — observé sur 6.x et 7.x. Le ForgeKey du PoC gère cela, et --exp-enc aligned|canonical bascule la largeur mpint de e=1 (1 contre 3 octets). Sur 7.23.3, LES DEUX largeurs s'authentifient — le matcher analyse l'exposant et ignore réellement sa valeur. Sur 6.49.20, AUCUNE ne s'authentifie (can't find matching key) — voir la nuance de version ci-dessus. Les hexdumps de paquets /system logging add topics=ssh,debug + /log print côté serveur ont révélé tout cela.

Valeurs SHA-256 de l'archive d'images source utilisées par ce laboratoire :

Notes défensives (CERT PL)

• Corriger immédiatement : 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21.
• En attendant : restreindre SSH/WWW/bandwidth-test aux réseaux de gestion de confiance ; éviter les SSH/TLS initiés par RouterOS depuis des appareils non corrigés.
• IOC : lignes de journal login failure for user -2 via ssh, user <name> added by ssh:-2@<ip> ; utilisateur inconnu hautement privilégié ops ; marqueur /system/device-mode/print « Flagged » (indique une compromission, son absence ne prouve rien). IP d'attaquants observées : 82.192.72.4, 103.102.31.18.

Sources

• Avis CERT PL : https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
• Page CVE CERT PL : https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
• Bulletin MikroTik (2026-09-03) : https://mikrotik.com/supportsec/september-2026-vulnerability/
• Mécanisme « Flagged » : https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode#flagged-status