MikroTrick : faille MikroTik RouterOS activement exploitée

Un routeur peut afficher la bonne version de RouterOS et rester compromis.

C’est le point le plus important de l’alerte MikroTrick qui touche MikroTik RouterOS. Le 5 septembre 2026, CERT Polska a confirmé l’exploitation active d’une chaîne de deux vulnérabilités SSH permettant de prendre le contrôle complet d’un équipement sans authentification lorsque son service SSH est accessible depuis un réseau public.

MikroTik avait publié des versions corrigées deux jours plus tôt, le 3 septembre. La mise à jour est indispensable, mais elle ne permet pas à elle seule d’affirmer qu’un routeur exposé avant la correction est resté sain. Il faut aussi rechercher les signes de compromission, examiner la configuration et, au moindre doute sérieux, traiter l’équipement comme un incident de sécurité.

Toutes les vulnérabilités réseau ne justifient pas le même traitement. Certaines exigent déjà un compte administrateur, une position locale ou une configuration rare. Ici, le signal est plus fort : le CERT national polonais a observé et confirmé des attaques dans la nature.

Le scénario le plus préoccupant concerne les routeurs qui acceptent des connexions SSH depuis Internet ou depuis un autre réseau non fiable. La première faille permet de contourner l’authentification par clé dans certaines conditions. La seconde manipule les privilèges de la session au moyen d’un nom d’utilisateur spécialement construit. Leur combinaison conduit à une session disposant des droits administrateur complets.

Un routeur ainsi compromis ne sert pas seulement à modifier quelques règles. Il se trouve à un endroit stratégique : il voit les flux, porte des tunnels, distribue parfois DNS et DHCP, applique le filtrage et relie les sites. Un attaquant peut donc chercher à maintenir un accès, détourner du trafic, créer un proxy, ajouter un tunnel ou préparer une attaque contre le reste du système d’information.

MikroTik précise que la configuration par défaut bloque l’administration SSH depuis Internet et que la majorité des configurations ne sont pas directement exposées. Cette nuance est importante : il ne faut pas déclarer tous les routeurs MikroTik compromis. Elle ne réduit toutefois pas l’urgence de l’inventaire, car les règles d’administration ont souvent été adaptées au fil des installations, des dépannages et des changements de prestataire.

La version cible dépend de la branche déjà utilisée. Il ne faut pas migrer un équipement de production vers une branche bêta simplement parce que son numéro est plus élevé.

Après le redémarrage, contrôlez la version réellement chargée avec /system package print. Le guide officiel de mise à niveau RouterOS recommande également de mettre à niveau le firmware RouterBOOT après RouterOS, avec /system routerboard upgrade, puis d’effectuer le redémarrage nécessaire. Cette opération doit rester intégrée à une fenêtre de maintenance, surtout pour un site distant où une perte d’accès demanderait une intervention sur place.

Sur un parc important, un pilote très court reste utile pour vérifier le retour des interfaces, des VLAN, des tunnels, du routage et de la supervision. Mais l’exploitation active exclut d’étaler cette phase pendant plusieurs semaines : le pilote doit préparer un déploiement rapide, pas devenir un prétexte pour différer le correctif.

CERT Polska a publié six CVE. La chaîne SSH activement exploitée est la priorité, mais elle ne constitue pas l’unique raison de mettre à jour.

Cette diversité change la réponse. Fermer uniquement SSH réduit le risque associé à MikroTrick, mais ne remplace pas la mise à jour : WebFig, le serveur de test de bande passante et les connexions sortantes de RouterOS sont également concernés par le lot.

Les versions corrigées ajoutent un mécanisme de détection au démarrage. RouterOS examine la configuration, désactive certains éléments considérés comme suspects et positionne l’équipement en état Flagged.

Le premier contrôle consiste à consulter :

Une ligne flagged: yes doit être traitée comme une compromission potentielle. MikroTik indique alors que certaines fonctions sensibles sont restreintes, notamment les générateurs de trafic, le sniffer et la création d’éléments liés aux tâches planifiées, aux proxys ou à plusieurs types de tunnels.

Ne désactivez pas immédiatement ce statut pour retrouver un fonctionnement normal. La commande qui remet flagged=no efface un signal utile et demande une confirmation physique ou un redémarrage à froid. Avant cela, il faut comprendre ce qui a déclenché l’alerte et conserver les éléments nécessaires à l’analyse.

CERT Polska cite aussi plusieurs indicateurs observés lors des attaques :

La présence d’un compte fortement privilégié nommé ops constitue un autre signal. Les attaques réussies étudiées provenaient notamment de l’adresse 82.192.72.4, tandis que 103.102.31.18 a été associée à des tentatives.

Ces éléments sont des indicateurs, pas une signature exhaustive. Une adresse peut changer, un compte peut être renommé et les journaux locaux peuvent être incomplets. CERT Polska insiste donc sur un point essentiel : l’absence de statut Flagged ou de ces traces ne démontre pas l’absence de compromission.

Sur un équipement sans alerte apparente, la revue doit au minimum couvrir :

Quelques commandes de lecture permettent de commencer le contrôle :

Ces sorties peuvent contenir des informations sensibles. Elles ne doivent pas être copiées intégralement dans un ticket public ou un canal de discussion largement accessible. Si l’équipement présente un indicateur, utilisez une procédure d’acquisition adaptée pour préserver journaux et configuration.

Le meilleur point de comparaison reste une configuration de référence connue et datée. Sans baseline, une règle légitime ajoutée il y a six mois et un changement malveillant récent peuvent se ressembler. Une gestion centralisée des exports, des différences de configuration et des journaux d’équipements réseau raccourcit fortement cette enquête.

Dans ce cas, la priorité n’est plus une simple maintenance logicielle.

Cette logique rejoint celle de toute correction de vulnérabilités sur un équipement de sécurité : la version installée est une preuve de correction, pas une preuve rétroactive d’intégrité.

Les compensations doivent rester temporaires et très courtes.

Une règle de pare-feu n’efface pas la vulnérabilité. Elle réduit la surface accessible pendant que l’équipe prépare la correction. Elle doit avoir une date d’expiration et être vérifiée depuis le point de vue d’un réseau non fiable.

MikroTrick rappelle une règle simple : l’interface d’administration d’un routeur ne devrait pas être un service Internet ordinaire.

Dans une architecture saine, SSH, WinBox et WebFig sont joignables uniquement depuis un réseau d’administration, un VPN ou un bastion. Les comptes sont nominatifs ou dédiés, les privilèges sont limités, les services inutiles sont désactivés et les journaux sortent de l’équipement vers une destination protégée.

Il faut aussi prévoir le jour où l’accès distant ne répond plus. Pour un routeur de site, cela signifie documenter le contact local, l’alimentation, le câblage WAN, le chemin de secours et les conditions d’un retour arrière. Une mise à jour urgente devient beaucoup moins risquée lorsque cette préparation existe déjà.

Enfin, l’inventaire doit relier chaque équipement à sa version, son canal de mises à jour, son exposition, sa configuration de référence et son responsable. Sans ces informations, la question « quels MikroTik devons-nous corriger aujourd’hui ? » devient une enquête alors qu’elle devrait être une requête.

La gravité de MikroTrick ne tient pas seulement à son score de 9,2. Elle vient de la combinaison de trois réalités : une administration SSH accessible depuis Internet, une prise de contrôle sans authentification et des attaques confirmées.

La réponse doit donc suivre deux pistes en parallèle. La première ferme l’accès : mise à jour immédiate et suppression de l’administration publique. La seconde cherche ce qui a pu se passer avant : statut Flagged, journaux, comptes, scripts, tunnels, proxys et différences de configuration.

Le mauvais résultat serait un parc affichant RouterOS 7.24.2 mais conservant un compte, un script ou un tunnel créé avant la correction. Le bon résultat est un équipement corrigé, reconstruit si nécessaire, administré depuis un chemin privé et surveillé à partir d’une référence connue.

Vous exploitez des routeurs MikroTik sur plusieurs sites et devez vérifier rapidement versions, exposition et configurations ? BoucheCousue peut vous accompagner pour construire l’inventaire, prioriser les corrections et organiser une reprise contrôlée des équipements suspects.