← cd ~/blog

MikroTrick: MikroTik-Router übernehmen — ohne Passwort, ohne Key, ohne Login

Was geschah

Anfang September warnte CERT Polska, dass Angreifer RouterOS-Schwachstellen zur Übernahme öffentlich erreichbarer MikroTik-Router nutzen — ohne zu sagen, welche Lücken die Kette bilden. Die nun veröffentlichte technische Analyse liefert beides: Die von CERT Polska MikroTrick getaufte Kette kombiniert eine SSH-State-Machine-Lücke (CVE-2026-67279) mit einer Argument-Injection im RouterOS-Login (CVE-2026-86060). Das Ergebnis ist so knapp wie unangenehm: vollständige administrative Kontrolle — ohne Passwort, ohne SSH-Key, ohne abgeschlossene Authentifizierung.

Die Patches (RouterOS 6.49.21, 7.23.4, 7.24.2) erschienen am 3. September. Spuren der Angriffe in Geräte-Logs datieren aber bereits auf den 2. September — die Kette wurde mindestens einen Tag vor dem Patch aktiv ausgenutzt. Am 10. September nahm die CISA CVE-2026-86060 in ihren Known-Exploited-Vulnerabilities-Katalog auf und bestätigte die Ausnutzung damit unabhängig.

Die Kette, Teil 1: Der Sprung über die Authentifizierung (CVE-2026-67279)

SSH ist eine Sequenzmaschine: erst die verschlüsselte Verbindung, dann die Authentifizierung des Users, erst danach — quittiert mit der Nachricht SSH_MSG_USERAUTH_SUCCESS — dürfen Client und Server Kanäle öffnen und Kommandos laufen lassen.

CVE-2026-67279 bricht diese Reihenfolge: Startet ein Client während der Authentifizierungsphase eine SSH-Schlüssel-Renegotiation, springt die verwundbare RouterOS-Implementierung nach Abschluss der Renegotierung direkt in die Kommandophase — ohne je die Identität des Clients zu bestätigen.

Für sich allein gibt der Bug keine Rechte und keine Session — aber er bringt einen unauthentifizierten Client in eine Phase, die ein abgeschlossenes Login voraussetzen würde. Die Tür ist offen, jetzt fehlt nur noch der Weg zum Admin.

Teil 2: Der Username, der keine Kennung ist (CVE-2026-86060)

RouterOS startet nach dem Login das Programm /nova/bin/login und übergibt ihm Username und Privilegienstufe als Kommandozeilen-Argumente — ungeprüft. Ein Wert, der mit einem Bindestrich beginnt, wird als Programmoption interpretiert, nicht als Name.

Der Angreifer sendet als Username schlicht -2. Das Login-Programm versteht das als Anweisung, Identität und Privilegienstufe von File-Deskriptor 2 zu lesen — also vom Terminal, das die SSH-Verbindung selbst angelegt hat. Und dorthin hat der Angreifer über den SSH-Kanal längst einen Nutzernamen seiner Wahl und den Wert für volle Administratorrechte geschrieben. Das Login-Programm übernimmt beides — und öffnet eine Konsole mit maximalen Privilegien.

Zwei Bugs, die einzeln beherrschbar klingen, verketten sich zur kompletten Übernahme: Die eine Lücke liefert die unauthentifizierte Position in der Kommandophase, die andere macht daraus admin-äquivalente Rechte.

Spuren in der Wildbahn

Die Kette hinterlässt eine markante Spur in den Logs: fehlgeschlagene Login-Versuche für den User -2. Solche Einträge tauchten im MikroTik-Forum schon am 2. September auf. Ein Diagnose-Report zeigt den kompletten Ablauf auf einem Gerät: abgewiesene Authentifizierung für -2, erzwungene Renegotiation, Sprung in die Kanalphase, dann ein exec-Request, der einen User ops mit vollen Privilegien anlegen wollte — dort crashte der SSH-Prozess vor Vollendung. Auf anderen Geräten wurde das ops-Konto erfolgreich erstellt. In einigen Fällen folgten die Erstellung von Diagnose-Dateien und Datenübertragungen zu einer Angreifer-IP — die Konfiguration wurde also vermutlich exfiltriert.

CERT Polens Indikatoren aus beobachteten Angriffen:

  • Username -2 in SSH-Login-Logs
  • Konto ops in der Gruppe mit vollen Privilegien
  • 82.192.72.4 — in erfolgreichen Angriffen beobachtet
  • 103.102.31.18 — in Ausnutzungsversuchen beobachtet

Zur Abgrenzung: Manche Berichte zogen eine dritte Lücke, CVE-2026-67276, in die Kette. CERT Polska widerspricht — das ist eine separate SSH-Schwachstelle (Fälschung eines RSA-Keys), die Accountname und Public Key des Opfers kennen muss und nur auf genau diesen einen Account Zugriff gibt.

Was zu tun ist

Voraussetzung der Kette ist ein von außen erreichbarer SSH-Dienst. MikroTiks Default-Konfiguration stellt SSH nicht ins Internet — gefährdet sind Administratoren, die ihre Firewall-Regeln geändert haben oder Geräte aus untrusted Netzen per SSH managen.

Patchen auf RouterOS 6.49.21, 7.23.4 oder 7.24.2 verhindert neue Angriffe — beseitigt aber keine Veränderungen, die ein Angreifer vorher hinterlassen hat. Nach dem Update:

  • Flagged-Status prüfen: /system/device-mode/print. Der Mechanismus erkennt aber nur ausgewählte Kompromittierungsspuren — sein Fehlen beweist nichts.
  • Auf unbekannte User, Skripte, Scheduler-Einträge, Tunnel, Proxies, unerwartete .rif-Dateien und unklare fetch-Aktivität prüfen.

Falls Indikatoren gefunden wurden: Gerät isolieren, Logs und Konfiguration sichern, auf Werkseinstellungen zurücksetzen und aus einer vertrauenswürdigen Konfiguration neu aufbauen. Alle Passwörter, Keys und Credentials ändern. Ein Backup vom kompromittierten Gerät nicht zurückspielen.

Die eigentliche Lektion

Zwei getrennte, einzeln unspektakuläre Bugs — eine Authentifizierungs-Sequenz, die sich aus dem Takt bringen lässt, und ein Argument-Handling, das Nutzernamen nicht validiert — ergeben kombiniert eine der praktischsten Router-Übernahmen der letzten Jahre. Wer Authentifizierung als Sequenz implementiert, muss jede Abweichung von der Sequenz als Angriff behandeln. Und für den Betrieb gilt altbekanntes, hier aber mit Zähnen: Management-Dienste gehören nicht ans Internet — der Default von MikroTik war diesmal die richtige Entscheidung.

Randnotiz mit Kontinuität: CERT Polska hat die Analyse mit KI-Modellen automatisiert — GPT-5.5-cyber und GPT-5.6-sol über das OpenAI-GTAC-Programm, daneben lokal gehostete Open-Weight-Modelle — und jeden Befund gegen echte RouterOS-Systeme verifiziert. Nach Click2Shell die nächste Meldung, in der KI-gestützte Sicherheitsforschung nicht der Kuriositäten-Kasten ist, sondern die Methode.

Quellen