MikroTrick : quand un exposant RSA oublié et un nom d'utilisateur interdit ouvrent les RouterOS sans mot de passe

Rapport CTI technique du 7 septembre 2026

Résumé exécutif

CERT Polska a publié le 5 septembre 2026 six vulnérabilités affectant MikroTik RouterOS, dont deux notées CVSS 9.2 qui, combinées, donnent à un attaquant non authentifié le contrôle administratif complet d'un routeur dont le service SSH est joignable depuis Internet. L'équipe polonaise a baptisé cet enchaînement MikroTrick. Les attaques ne sont pas théoriques : CERT Polska confirme des compromissions réelles depuis au moins le 2 septembre, avec une adresse source identifiée et un marqueur de post-exploitation constant, la création d'un compte hautement privilégié nommé ops.

La première faille, CVE-2026-67276, tient à une comparaison incomplète de clé publique RSA lors de l'authentification SSH : RouterOS vérifie le type et le modulus mais ignore l'exposant, ce qui permet de forger une signature valide en connaissant seulement le modulus public d'un utilisateur autorisé. La seconde, CVE-2026-86060, est une injection d'arguments dans le chemin de login SSH déclenchée par un nom d'utilisateur commençant par un caractère interdit, qui réécrit le masque de politique RouterOS de la session. Les correctifs sont disponibles en 6.49.21, 7.23.4, 7.24.2 et 7.25beta3. MikroTik a pour la première fois envoyé une notification push aux téléphones des utilisateurs de son application mobile, signe de l'urgence estimée par le constructeur.

Chronologie

Date	Événement
2 septembre 2026	Date du changelog de la 7.25beta3. Premières exploitations réussies observées par CERT Polska depuis l'IP `82.192.72.4`
3 septembre 2026	Annonce publique par MikroTik des correctifs initiaux et de la beta
5 septembre 2026	Publication de l'avis CERT Polska, des six identifiants CVE et du nom MikroTrick. Notification push MikroTik aux utilisateurs de l'application mobile
5 septembre 2026	Sortie de la 7.23.5 long-term corrigeant une régression DHCPv6 introduite en 7.23.4, tout en conservant le correctif de sécurité
6 septembre 2026	Reprise par The Hacker News, qui note l'absence de décompte de victimes et d'identification de l'attaquant
7 septembre 2026	Aucun ajout au catalogue CISA KEV à la date de rédaction

Fiche vulnérabilité

CVE-2026-67276 | CVSS 9.2 | RouterOS, serveur SSH

Composant affecté : RouterOS de 6.0.0 à 6.49.20, de 7.0.0 à 7.23.3, de 7.24 à 7.24.1.
Classification : CWE-347, vérification incorrecte de signature cryptographique.

RouterOS associe une requête d'authentification SSH par clé publique à une clé autorisée en comparant le type d'algorithme et le modulus RSA, mais pas l'exposant public. Le point critique se situe ensuite dans le flux de vérification : la signature est validée avec la clé fournie par le client, pas avec la clé stockée côté serveur. Les deux comportements pris isolément seraient discutables, ensemble ils annulent l'authentification.

Un attaquant qui connaît le nom du compte et le modulus n de sa clé autorisée construit une clé publique (n, e=1). Avec e=1, l'opération de vérification RSA s^e mod n se réduit à s mod n, donc toute valeur s égale à l'encodage PKCS#1 attendu passe la vérification sans qu'aucune clé privée n'entre en jeu. Le modulus n'est pas un secret : il se lit dans le fichier de clé publique exporté, il transite en clair lors d'une tentative d'authentification, et il est fréquemment publié dans les dépôts de configuration ou les inventaires d'infrastructure.

Les privilèges obtenus sont ceux du compte visé, ce qui suffit rarement pour un compte de lecture seule, mais suffit toujours pour enchaîner.

Conditions d'exploitation : service SSH RouterOS joignable, connaissance d'un nom d'utilisateur configuré pour l'authentification par clé et du modulus RSA associé.
PoC disponible : pas de code d'exploitation publié par CERT Polska, qui indique explicitement limiter sa description. Des travaux de rétro-ingénierie sur les paquets corrigés circulent depuis la publication des correctifs, et l'équipe polonaise cite cette reconstruction communautaire comme raison de publier plus tôt que prévu.
Patch : 6.49.21, 7.23.4 (ou 7.23.5), 7.24.2, 7.25beta3.

CVE-2026-86060 | CVSS 9.2 | RouterOS, chemin de login SSH

Composant affecté : mêmes plages de versions.
Classification : CWE-88, neutralisation incorrecte des délimiteurs d'arguments dans une commande.

Le helper de login RouterOS ne rejette pas correctement les noms d'utilisateur débutant par un caractère interdit. Le nom traverse la couche d'appel et se retrouve interprété comme un argument de ligne de commande plutôt que comme une donnée. Résultat : le masque de politique RouterOS attaché à la session est modifié, et la session obtient les privilèges administratifs complets.

Les traces laissées dans les journaux valident cette lecture. CERT Polska publie deux lignes de log observées chez les victimes :

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

Le nom d'utilisateur -2 n'est pas un identifiant, c'est le vecteur : un argument numérique négatif que le helper consomme comme option. La deuxième ligne montre le résultat, la création d'un compte par une session dont l'identité est justement cette chaîne d'injection.

Conditions d'exploitation : une session SSH non authentifiée doit pouvoir atteindre le helper de login. Aucun identifiant préalable requis.
PoC disponible : non publié par CERT Polska.
Patch : identique aux versions ci-dessus.

Les quatre autres CVE de la série

CVE	CWE	Composant	Effet
CVE-2026-67277 (CVSS 8.8)	CWE-306	bandwidth-test	Connexion « related » acceptée avant authentification de la session primaire. Avec `random-data=false`, fuite de la queue non initialisée d'un buffer paquet noyau. Un intervalle de taille inversé non vérifié provoque un underflow entier, une sortie fragmentée anormalement grande et un redémarrage du noyau
CVE-2026-67278	CWE-347	Validation X.509	Signatures RSA/PKCS#1 v1.5 malformées acceptées. Le magasin de confiance contient une racine à `e=3`, ce qui permet de forger un intermédiaire de confiance à partir du seul certificat public de la racine et d'émettre des certificats pour des noms arbitraires
CVE-2026-67279	CWE-841	Serveur SSH	Après un rekey demandé par le client, le serveur passe au protocole de connexion sans qu'aucune authentification n'ait été tentée. Un client non authentifié ouvre un canal de session et envoie une requête `exec`, ce qui permet de créer, écraser et reconstruire des fichiers dans l'espace de noms géré, y compris les fichiers de support contenant configuration et données de diagnostic
CVE-2026-67281	CWE-824	WebFig, `/jsproxy`	Une session nouvellement allouée conserve un pointeur de principal non initialisé utilisé pour l'autorisation fichier. En préparant l'allocateur, un attaquant non authentifié fait déréférencer ce pointeur avec des droits suffisants, puis remonte l'arborescence via des composants `..` dans une URI chiffrée pour lire des fichiers appartenant à root, dont les magasins de configuration contenant des identifiants

Ni CERT Polska ni MikroTik n'indiquent explicitement quelles deux vulnérabilités composent la chaîne observée. La lecture proposée ici, CVE-2026-67276 pour l'accès puis CVE-2026-86060 pour l'élévation, s'appuie sur les scores CVSS identiques de 9.2 attribués à ces deux failles, sur la mention explicite d'un accès SSH nécessaire, et sur la forme des traces -2 publiées. C'est une inférence technique, pas une attribution constructeur.

Diagramme de la chaîne d'attaque

Chaîne d'exploitation MikroTrick

Reconstruction à partir des descriptions CVE de CERT Polska et des marqueurs de journalisation publiés. Sources : CERT Polska, avis CVE, CERT Polska, alerte exploitation.

Analyse technique

Étape 1 : cartographie de la surface exposée

RouterOS écoute par défaut sur le port 22 pour SSH, 80 et 443 pour WebFig, 2000 pour bandwidth-test. Sur les équipements grand public livrés avec le pare-feu par défaut intact, ces ports de gestion sont bloqués depuis l'extérieur. Ce sont donc les déploiements opérateurs, les routeurs de bordure d'entreprise, et surtout les appareils dont l'administrateur a ouvert SSH « le temps d'une intervention » qui composent la population réellement atteignable. Le repérage se fait sans finesse : la bannière SSH de RouterOS est distinctive et se collecte par scan de masse.

Étape 2 : récupération du modulus RSA

CVE-2026-67276 demande deux éléments, un nom de compte et un modulus. Le nom se devine (admin, ops, backup, conventions de nommage internes). Le modulus se récupère de plusieurs manières : fichiers .pub versionnés dans un dépôt d'infrastructure, exports de configuration RouterOS partagés dans des tickets ou des forums, ou observation d'une tentative d'authentification légitime sur un segment réseau contrôlé. Rien ici ne relève du secret cryptographique, ce qui explique que la faille se traduise directement en exploitation de masse.

Étape 3 : forgeage de la clé à exposant unitaire et ouverture du canal

L'attaquant présente une clé (n, e=1). RouterOS compare type et modulus, trouve une correspondance, puis vérifie la signature avec la clé présentée. La primitive de vérification devient une identité et laisse passer une signature construite arbitrairement. Le canal SSH s'ouvre au nom du compte visé. Dans les journaux de la cible, cette étape ressemble à une authentification par clé réussie et normale, ce qui la rend peu détectable par les règles génériques de détection de bruteforce.

Étape 4 : injection d'arguments et élévation en administrateur

L'attaquant ouvre ensuite une session dont le nom d'utilisateur commence par un caractère interdit, du type -2. Le helper de login consomme la chaîne comme option, le masque de politique de la session est réécrit avec l'ensemble des droits, et la session dispose des permissions administratives complètes. C'est cette étape qui laisse dans le journal la ligne login failure for user -2, un échec apparent qui masque un succès d'élévation.

Étape 5 : persistance par compte privilégié

La post-exploitation observée est simple et bruyante : création d'un compte nommé ops avec des privilèges élevés. La ligne user <name> added by ssh:-2@<ip> en est la signature directe. Un opérateur qui reconstruit un routeur sans auditer la table des utilisateurs réintroduit la porte dérobée avec sa sauvegarde. C'est précisément la raison pour laquelle CERT Polska insiste sur la reconstruction à partir d'une configuration de référence vérifiée, jamais sur la restauration d'un backup complet de l'appareil compromis.

Le mécanisme « Flagged » introduit dans les versions corrigées scanne la configuration au démarrage, désactive les entrées suspectes reconnues et pose un marqueur. Il faut le lire pour ce qu'il est : un filet à mailles larges. CERT Polska précise que l'absence de marqueur ne prouve rien, et que sa présence n'établit pas non plus laquelle des six failles a servi.

Indicateurs de compromission

Type	Valeur
IP source (exploitation réussie confirmée)	`82.192.72.4`
IP source (tentatives sur la chaîne)	`103.102.31.18`
Compte créé	`ops`, avec privilèges élevés
Journal RouterOS	`login failure for user -2 from <ip> via ssh`
Journal RouterOS	`user <name> added by ssh:-2@<ip>`
État système	Marqueur `flagged` dans la sortie de `/system/device-mode/print`
Configuration	Utilisateurs, scripts, tâches de scheduler, serveurs proxy et tunnels non reconnus

MITRE ATT&CK

Aucune cartographie officielle n'accompagne l'avis CERT Polska. Le tableau ci-dessous est une lecture technique de la chaîne décrite, pas une attribution éditeur.

Tactique	Technique	ID	Justification
Reconnaissance	Active Scanning: Scanning IP Blocks	T1595.001	Identification des RouterOS exposant SSH par balayage Internet
Initial Access	Exploit Public-Facing Application	T1190	Exploitation de CVE-2026-67276 sur le service SSH exposé
Defense Evasion	Valid Accounts	T1078	La session ouverte se présente comme une authentification par clé légitime du compte visé
Privilege Escalation	Exploitation for Privilege Escalation	T1068	CVE-2026-86060 réécrit le masque de politique de la session
Persistence	Create Account: Local Account	T1136.001	Création du compte `ops` privilégié
Credential Access	Unsecured Credentials: Credentials In Files	T1552.001	CVE-2026-67281 expose les magasins de configuration contenant des identifiants
Collection	Data from Local System	T1005	CVE-2026-67279 permet la reconstruction des fichiers de support contenant configuration et diagnostics
Impact	Service Stop	T1489	CVE-2026-67277 provoque un redémarrage du noyau RouterOS

Remédiation : checklist opérationnelle

Mettre à jour RouterOS vers 6.49.21, 7.23.4, 7.24.2 ou 7.25beta3. Sur la branche long-term, préférer 7.23.5, qui corrige une régression DHCPv6 de la 7.23.4 tout en conservant le correctif de sécurité.
Immédiatement après la mise à jour, exécuter /system/device-mode/print et relever la valeur du marqueur flagged, puis lire les journaux à la recherche du message critique de compromission.
Auditer la table des utilisateurs. Tout compte ops non documenté, ou tout compte à privilèges élevés absent de l'inventaire, doit être traité comme une porte dérobée active.
Rechercher dans les journaux les chaînes user -2 et ssh:-2@. Étendre la recherche à l'ensemble de la rétention disponible, pas seulement aux dernières 48 heures.
Inspecter la configuration au-delà des comptes : scripts, tâches du scheduler, serveurs proxy, tunnels, règles de redirection. La post-exploitation observée est basique, mais rien ne garantit qu'elle soit exhaustive.
Si la mise à jour ne peut pas être appliquée tout de suite, restreindre l'accès à SSH, WWW, WWW-SSL et au serveur bandwidth-test aux seuls réseaux d'administration de confiance. Mesure de réduction de surface, pas correctif.
Sur les appareils non corrigés, ne pas initier de connexion TLS sortante et ne pas utiliser les clients SSH intégrés /system ssh et /system ssh-exec, en raison de CVE-2026-67278 et CVE-2026-67279 côté client.
En cas de suspicion de compromission : isoler l'équipement, exporter journaux et configuration avant tout reset, ne pas effacer le marqueur flagged avant la fin de l'analyse, ne pas redémarrer avant d'avoir collecté les artefacts.
Restaurer les paramètres d'usine puis reconstruire à partir d'une configuration de référence vérifiée. Ne jamais restaurer une sauvegarde complète provenant de l'appareil suspect.
Renouveler tous les secrets manipulés par l'équipement : mots de passe des comptes locaux, clés SSH autorisées, secrets IPsec, communautés SNMP, identifiants RADIUS.
Côté détection réseau, considérer que l'étape d'accès initial ressemble à une authentification par clé réussie. Les règles utiles portent sur la création de comptes et sur les noms d'utilisateur commençant par un tiret, pas sur le volume de tentatives d'authentification.