Résumé

Un attaquant distant non authentifié peut obtenir le contrôle administratif total d'un équipement MikroTik RouterOS vulnérable en interagissant uniquement avec son service SSH. Aucun identifiant, aucune interaction utilisateur et aucun accès local ne sont nécessaires.

Une fois la policy complète obtenue, un attaquant dispose des mêmes privilèges qu'un administrateur RouterOS du groupe full : lecture et modification de l'intégralité de la configuration, création de comptes privilégiés et de portes dérobées, activation/désactivation de services, redirection ou interception du trafic, et utilisation de l'équipement comme point d'ancrage pour pivoter vers des réseaux internes.

Versions affectées

• Vulnérables : RouterOS 6.x et 7.0.0 jusqu'à 7.23.3 (l'ensemble des branches 6.x et 7.x jusqu'au correctif).
• Corrigées : RouterOS 7.23.4 et ultérieures.

Le problème a été validé sur les versions officielles CHR 6.49.20 et CHR 7.21.5 exécutées dans un laboratoire local basé sur QEMU (MikroTik Cloud Hosted Router), et confirmé en outre sur un petit nombre d'installations exposées à Internet atteintes lors d'une recherche de validation limitée (détails non divulgués ; aucune publication d'hôtes tiers).

Description technique

La vulnérabilité est une élévation de privilèges avant authentification dans le service SSH de RouterOS qui permet à un client SSH non authentifié d'atteindre une session de console RouterOS avec un masque de policy administrative complète.

Le mécanisme précis, les chemins de code affectés et toute valeur de déclenchement sont intentionnellement non divulgués afin d'empêcher toute reproduction. Seul l'effet de haut niveau est décrit : un client non authentifié peut obtenir une policy administrative complète sans identifiants valides.

Note sur la divulgation responsable : ce document ne publie intentionnellement pas de code d'exploitation, les valeurs de déclenchement spécifiques, ni de recette de reproduction pas à pas. Des captures d'écran de preuve de concept sont fournies (voir ci-dessous) ; aucun payload fonctionnel ni code source n'est publié.

Impact

Une attaque réussie confère à l'attaquant distant non authentifié l'intégralité des privilèges administratifs du groupe full sur le routeur. Conséquences observées et réalistes :

• Lecture/écriture complète de la configuration — extraction des pairs BGP/OSPF, des règles de pare-feu, des identifiants VPN, des secrets RADIUS/PPP, des certificats.
• Manipulation des comptes — création de nouveaux utilisateurs du groupe full et de portes dérobées, verrouillage des administrateurs légitimes.
• Abus de services — activation/désactivation de services, ouverture de brèches dans le pare-feu, proxy du trafic.
• Interception / redirection du trafic — détournement DNS, MITM sur le trafic routé, redirection du trafic de gestion ou des utilisateurs.
• Mouvement latéral — utilisation du routeur comme point de pivot vers les réseaux qu'il route, et récupération d'identifiants réutilisables ailleurs sur le réseau.
• Botnet / matière à DDoS — les routeurs entièrement contrôlés sont fréquemment recrutés dans des botnets de DDoS et de scan.

Parce que les équipements RouterOS se situent en bordure de réseau (passerelles, concentrateurs VPN, CPE d'opérateurs, routeurs d'entreprise), le rayon d'impact est généralement bien plus large que celui d'un simple hôte compromis.

Preuve de concept

Afin de préserver la sécurité de cet avis pour une diffusion publique, aucun code d'exploitation, aucune valeur de déclenchement et aucun script de reproduction ne sont publiés ici.

• Validation en laboratoire : confirmée sur MikroTik CHR 6.49.20 et 7.21.5 dans un laboratoire local QEMU/Docker. La preuve a démontré une action d'écriture (création puis suppression d'un utilisateur de policy full) impossible pour une session en lecture seule/non authentifiée — la policy admin complète a été obtenue avant authentification.

• Captures d'écran de preuve de concept :

  

  

Correctif

Mettre à jour RouterOS

Le problème est corrigé dans RouterOS 7.23.4 et ultérieures.

1. Sauvegardez d'abord votre configuration :

   root@kitploit:~

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

2. Mettez à jour via les canaux habituels :

   • Winbox / WebFig : System → Packages → Check for updates (ou téléversez le routeros-<version>.npk correspondant à l'architecture du routeur).
   • CLI : consultez le manuel à l'adresse https://help.mikrotik.com/docs/spaces/ROS/pages/47579159/Upgrade.

3. Après la mise à jour, vérifiez la version en cours d'exécution :

   root@kitploit:~

   /system resource print
   

4. Ne réactivez qu'ensuite SSH sur les interfaces externes (voir ci-dessous).

Préférez le correctif aux contournements. Les mises à jour de version sont le seul correctif complet. Les contournements ci-dessous réduisent l'exposition mais n'éliminent pas la faille sous-jacente.

Prévention et durcissement

Pour les équipements qui ne peuvent pas être mis à jour immédiatement — et en défense en profondeur pour ceux qui sont corrigés :

1. Restreindre l'exposition SSH au niveau du pare-feu. N'exposez pas SSH à Internet ni aux réseaux non fiables. N'autorisez que les adresses sources de confiance :

   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. Désactiver entièrement SSH là où il n'est pas nécessaire. Winbox, WebFig et l'API suffisent souvent pour la gestion ; demandez-vous si l'accès CLI distant doit être exposé :

   root@kitploit:~

   /ip service disable ssh
   

3. Exiger une authentification forte. Si SSH doit rester activé :

   • Utilisez l'authentification par clé SSH et désactivez l'authentification par mot de passe lorsque c'est possible : /user ssh-keys import user=<admin> public-key-file=<file>.
   • N'utilisez jamais de mots de passe vides ou par défaut (notamment le compte admin par défaut).
   • Imposez des mots de passe forts et faites-les tourner régulièrement.

4. Placer la gestion derrière un VPN / un réseau de gestion segmenté. Acheminez l'accès de gestion via un réseau de confiance ou un VPN plutôt qu'une exposition directe ; cela s'applique à SSH, Winbox (8291), WebFig/HTTP (80/443), l'API RouterOS (8728/8729) et tout port SSH personnalisé (3333, 2222, 8022 et autres re-mappages courants sont fréquemment utilisés).

5. Surveiller les indicateurs de compromission (voir Détection ci-dessous) et activer la journalisation des événements d'authentification et de configuration.

6. Maintenir le firmware à jour et s'abonner aux avis de sécurité MikroTik : https://mikrotik.com/support/security.

Détection

Signes qu'une tentative d'exploitation ou une exploitation de cette vulnérabilité a pu se produire sur un équipement :

• Modifications inattendues de la configuration : nouveaux utilisateurs (en particulier avec le groupe full), nouvelles règles de pare-feu ouvrant l'accès, services modifiés, comptes de porte dérobée inattendus.
• /system identity, paramètres DNS, ou règles de routage/pare-feu nouveaux ou modifiés que vous n'avez pas effectués.
• Activité SSH inhabituelle dans les journaux du routeur, comme des échecs d'authentification répétés ou des sessions ouvertes sans événement de connexion réussie correspondant.

Vérifications utiles sur un équipement en fonctionnement :

Avertissement

Ce document est publié à des fins défensives et éducatives — pour permettre aux administrateurs d'équipements MikroTik d'évaluer leur exposition, de vérifier l'état de correctif et de durcir leurs déploiements. Les détails d'exploitation sont intentionnellement non divulgués, et aucun exploit fonctionnel n'est publié. Ne testez que les systèmes que vous possédez ou que vous êtes autorisé à évaluer.