Zusammenfassung

Ein nicht authentifizierter Remote-Angreifer kann vollständige administrative Kontrolle über ein verwundbares MikroTik-RouterOS-Gerät erlangen, indem er ausschließlich mit dessen SSH-Dienst interagiert. Es sind keine Anmeldedaten, keine Benutzerinteraktion und kein lokaler Zugriff erforderlich.

Sobald die vollständige Policy erlangt wurde, verfügt ein Angreifer über dieselben Rechte wie ein RouterOS-Administrator der Gruppe full: Lesen und Ändern der gesamten Konfiguration, Anlegen privilegierter Konten und Backdoors, Aktivieren/Deaktivieren von Diensten, Umleiten oder Abfangen von Datenverkehr sowie Nutzung des Geräts als Ausgangspunkt, um in interne Netzwerke vorzudringen.

Betroffene Versionen

• Verwundbar: RouterOS 6.x und 7.0.0 bis 7.23.3 (der gesamte 6.x- und 7.x-Zweig bis zum Fix).
• Behoben: RouterOS 7.23.4 und neuer.

Das Problem wurde gegen die offiziellen CHR 6.49.20- und CHR 7.21.5-Releases validiert, die in einem lokalen QEMU-basierten Labor (MikroTik Cloud Hosted Router) liefen, und zusätzlich gegen eine kleine Anzahl internetexponierter Installationen bestätigt, die während begrenzter Validierungsforschung erreicht wurden (Details zurückgehalten; keine Veröffentlichung von Drittanbieter-Hosts).

Technische Beschreibung

Die Schwachstelle ist eine Pre-Authentication-Privilegienausweitung im RouterOS-SSH-Dienst, die es einem nicht authentifizierten SSH-Client ermöglicht, eine RouterOS-Konsolensitzung mit einer vollständigen administrativen Policy-Maske zu erreichen.

Der konkrete Mechanismus, die betroffenen Codepfade und etwaige Auslösewerte werden absichtlich zurückgehalten, um eine Reproduktion zu verhindern. Es wird nur der übergeordnete Effekt beschrieben: Ein nicht authentifizierter Client kann ohne gültige Anmeldedaten die vollständige administrative Policy erlangen.

Hinweis zur verantwortungsvollen Offenlegung: Dieses Dokument veröffentlicht absichtlich keinen Exploit-Code, keine konkreten Auslösewerte und keine schrittweise Reproduktionsanleitung. Proof-of-Concept-Screenshots werden bereitgestellt (siehe unten); es wird kein funktionierender Payload oder Quellcode veröffentlicht.

Auswirkung

Ein erfolgreicher Angriff verleiht dem nicht authentifizierten Remote-Angreifer vollständige administrative Rechte der Gruppe full auf dem Router. Beobachtete und realistische Folgen:

• Vollständiges Lesen/Schreiben der Konfiguration — Auslesen von BGP/OSPF-Peers, Firewall-Regeln, VPN-Anmeldedaten, RADIUS/PPP-Secrets, Zertifikaten.
• Kontomanipulation — Anlegen neuer Benutzer der Gruppe full und Backdoors, Aussperren legitimer Administratoren.
• Dienstmissbrauch — Aktivieren/Deaktivieren von Diensten, Öffnen von Firewall-Lücken, Proxying von Datenverkehr.
• Abfangen / Umleiten von Datenverkehr — DNS-Hijacking, MITM bei geroutetem Datenverkehr, Umleiten von Management- oder Benutzerdatenverkehr.
• Laterale Bewegung — Nutzung des Routers als Sprungpunkt in die von ihm gerouteten Netzwerke und Wiedererlangung von Anmeldedaten, die anderswo im Netzwerk verwendet werden können.
• Botnetz-/DDoS-Material — Router mit vollständiger Kontrolle werden häufig in DDoS- und Scanning-Botnetze eingebunden.

Da RouterOS-Geräte am Netzwerkrand sitzen (Gateways, VPN-Konzentratoren, ISP-CPE, Unternehmensrouter), ist der Schadensradius in der Regel deutlich größer als bei einem einzelnen kompromittierten Host.

Proof of Concept

Um diesen Advisory sicher für die öffentliche Verbreitung zu halten, werden hier kein Exploit-Code, keine Auslösewerte und kein Reproduktionsskript veröffentlicht.

• Laborvalidierung: bestätigt auf MikroTik CHR 6.49.20 und 7.21.5 in einem lokalen QEMU/Docker-Labor. Der Nachweis zeigte eine Schreib-Aktion (Erstellung und anschließende Entfernung eines Benutzers mit full-Policy), die für eine schreibgeschützte/nicht authentifizierte Sitzung unmöglich ist — die vollständige Admin-Policy wurde pre-auth erlangt.

• Proof-of-Concept-Screenshots:

  

  

Fix

RouterOS aktualisieren

Das Problem ist in RouterOS 7.23.4 und später behoben.

1. Sichern Sie zuerst Ihre Konfiguration:

   root@kitploit:~

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

2. Aktualisieren Sie über die üblichen Kanäle:

   • Winbox / WebFig: System → Packages → Check for updates (oder laden Sie die routeros-<version>.npk für die Architektur des Routers hoch).
   • CLI: siehe das Handbuch unter https://help.mikrotik.com/docs/spaces/ROS/pages/47579159/Upgrade.

3. Überprüfen Sie nach dem Upgrade die laufende Version:

   root@kitploit:~

   /system resource print
   

4. Erst danach sollten Sie erwägen, SSH auf externen Schnittstellen wieder zu aktivieren (siehe unten).

Patchen ist Workarounds vorzuziehen. Versionsupdates sind die einzige vollständige Behebung. Die folgenden Workarounds reduzieren die Exposition, beseitigen aber nicht den zugrunde liegenden Fehler.

Prävention und Härtung

Für Geräte, die nicht sofort aktualisiert werden können — und als Defense-in-Depth für gepatchte Geräte:

1. Beschränken Sie die SSH-Exposition an der Firewall. Setzen Sie SSH nicht dem Internet oder nicht vertrauenswürdigen Netzwerken aus. Erlauben Sie nur vertrauenswürdige Quelladressen:

   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. Deaktivieren Sie SSH vollständig, wo es nicht benötigt wird. Winbox, WebFig und die API sind für die Verwaltung oft ausreichend; überlegen Sie, ob Remote-CLI-Zugriff überhaupt exponiert werden muss:

   root@kitploit:~

   /ip service disable ssh
   

3. Erfordern Sie starke Authentifizierung. Wenn SSH aktiviert bleiben muss:

   • Verwenden Sie SSH-Schlüssel-basierte Authentifizierung und deaktivieren Sie nach Möglichkeit die Passwort-Authentifizierung: /user ssh-keys import user=<admin> public-key-file=<file>.
   • Verwenden Sie niemals leere oder Standard-Passwörter (insbesondere das Standard-admin-Konto).
   • Erzwingen Sie starke Passwörter und rotieren Sie diese regelmäßig.

4. Setzen Sie die Verwaltung hinter ein VPN / segmentiertes Management-Netzwerk. Leiten Sie Management-Zugriff über ein vertrauenswürdiges Netzwerk oder VPN statt über direkte Exposition; dies gilt für SSH, Winbox (8291), WebFig/HTTP (80/443), die RouterOS-API (8728/8729) und alle benutzerdefinierten SSH-Ports (3333, 2222, 8022 und andere häufig verwendete Umbelegungen).

5. Überwachen Sie auf Kompromittierungsindikatoren (siehe Erkennung unten) und aktivieren Sie die Protokollierung von Authentifizierungs- und Konfigurationsereignissen.

6. Halten Sie die Firmware aktuell und abonnieren Sie MikroTik-Sicherheitshinweise: https://mikrotik.com/support/security.

Erkennung

Anzeichen dafür, dass diese Schwachstelle auf einem Gerät versucht oder ausgenutzt wurde:

• Unerwartete Konfigurationsänderungen: neue Benutzer (insbesondere mit full-Gruppe), neue Firewall-Regeln, die Zugriff öffnen, geänderte Dienste, unerwartete Backdoor-Konten.
• Neue oder geänderte /system identity, DNS-Einstellungen oder Routing-/Firewall-Regeln, die Sie nicht vorgenommen haben.
• Ungewöhnliche SSH-Aktivität in Router-Logs, wie wiederholte Authentifizierungsfehler oder Sitzungen, die ohne entsprechendes erfolgreiches Login-Ereignis geöffnet wurden.

Nützliche Prüfungen auf einem laufenden Gerät:

Haftungsausschluss

Dieses Dokument wird für defensive und Bildungszwecke veröffentlicht — um Administratoren von MikroTik-Geräten zu ermöglichen, die Exposition zu bewerten, den Patch-Status zu überprüfen und ihre Deployments zu härten. Ausnutzungsdetails werden absichtlich zurückgehalten, und es wird kein funktionierender Exploit veröffentlicht. Testen Sie nur Systeme, die Ihnen gehören oder für deren Bewertung Sie autorisiert sind.