MikroTrick: Zwei RouterOS-Lücken erlauben Angreifern die Übernahme exponierter MikroTik-Router

Eine Kette von Schwachstellen in MikroTiks RouterOS erlaubt es einem Angreifer, der lediglich Netzwerkzugriff auf den SSH-Dienst eines Routers hat, das Gerät vollständig zu übernehmen, und der Angriff ist keine Theorie mehr. CERT Polska, das nationale Team für Computersicherheitsvorfälle in Polen, fand sechs Fehler in RouterOS, stimmte die Offenlegung mit MikroTik ab und bestätigte am 5. September, dass zwei davon in laufenden Angriffen kombiniert werden. Das Team gab der Kette einen Namen: MikroTrick.

Zum Weiterlesen: Von KI entdeckter Authentifizierungs-Bypass in Rejetto HFS zieht Ausnutzungsversuche nach sich · Google schließt CVE-2026-58704, eine aktiv ausgenutzte Zero-Day-Lücke im Pixel-Modem.

Beide Fehler im Zentrum der Kette tragen einen CVSS-Wert von 9,2. MikroTik lieferte die Korrekturen noch vor der öffentlichen Offenlegung aus, zuerst am 3. September in RouterOS in den Versionen 6.49.21, 7.23.4 und 7.24.2, dazu der Entwicklungsbuild 7.25beta3. Die CISA nahm die beiden RouterOS-Schwachstellen am 10. September in ihren Katalog bekannter ausgenutzter Schwachstellen (KEV) auf und setzte Bundesbehörden eine Frist bis zum 13. September, um zu patchen oder kompensierende Kontrollen zu dokumentieren. Derselbe Vorgang betraf ConnectWise ScreenConnect und JFrog Artifactory.

Das Ausmaß der Zielgruppe ist der Punkt, der einen innehalten lassen sollte. Die Shadowserver Foundation zählte am 5. September in einem einzigen 24-Stunden-Scanfenster rund 122.500 MikroTik-Geräte, deren SSH aus dem Internet erreichbar war. Diese Zahl ist keine Zählung anfälliger Geräte, denn es wurde keine Versionsprüfung vorgenommen. Sie zählt Geräte, die auf genau jenem Port antworteten, den die Angriffskette benötigt.

Was die beiden Fehler bewirken

Die erste Hälfte von MikroTrick, geführt als CVE-2026-67276, ist eine Umgehung der Authentifizierung im SSH-Server von RouterOS. Bei der Prüfung des RSA-Public-Keys eines Nutzers verglich RouterOS nur einen Teil des Schlüssels: seinen Typ und den öffentlichen Modul. Den vollständigen Schlüssel verglich es nicht, sodass der öffentliche Exponent unberücksichtigt blieb.

Der Unterschied klingt akademisch, bis man betrachtet, was er erlaubt. Ein Angreifer, der einen Benutzernamen und den Modul des zugehörigen autorisierten Schlüssels kennt, kann ein anderes Schlüsselpaar konstruieren, das sich diesen Modul teilt, seinen öffentlichen Exponenten auf 1 setzen und eine Signatur erzeugen, die RouterOS akzeptiert. Ein privater Schlüssel ist nicht nötig, weil der Server gerade jenen Teil des Schlüssels nie prüfte, der eine Fälschung unmöglich gemacht hätte.

Die zweite Hälfte, CVE-2026-86060, hebt den Fuß, den die Umgehung verschafft, auf vollständige administrative Kontrolle. RouterOS ging mit SSH-Benutzernamen falsch um, die mit einem Zeichen begannen, das es hätte ablehnen müssen. Ein konstruierter Wert wie -2 erreichte einen alten Login-Helfer, der den führenden Bindestrich als Beginn eines Kommandozeilen-Flags statt als wörtlichen Benutzernamen las. Indem der Angreifer einen so geformten Benutzernamen angab, konnte er die vertrauenswürdige Policy-Maske des Routers verändern und zuletzt eine voll privilegierte Sitzung erlangen.

Keiner der beiden Fehler verlangt ein Passwort, ein gültiges Konto oder eine Interaktion des Geräteeigentümers. Das Paar braucht nur erreichbares SSH, und genau so lassen es viele Administratoren, um einen Router zu verwalten, der an einer unhandlichen Stelle steht.

Ein dritter Fehler und drei weitere

CERT Polska legte insgesamt sechs Probleme offen. Das drittschwerste ist CVE-2026-67277, ein Fehler fehlender Authentifizierung im Dienst bandwidth-test, kurz btest. Eine nicht authentifizierte Verbindung konnte in einen Zustand gelangen, der angemeldeten Nutzern vorbehalten sein sollte. Zusammen mit einem Leck uninitialisierter Daten aus einem Kernel-Paketpuffer und einem Integer-Unterlauf bei der Größenprüfung kann dies Kernel-Speicher offenlegen oder das Gerät in einen Neustart stürzen.

Drei Schwachstellen geringerer Schwere runden das Set ab: ein Problem im SSH-Client, eine Schwäche bei der Signaturprüfung in der X.509-Zertifikatsbehandlung und ein Informationsleck in der WebFig-Oberfläche. Keine davon gehört zur beobachteten Übernahmekette, doch sie erweitern die Angriffsfläche, über die Administratoren nachdenken müssen.

Die Spuren der Angreifer

CERT Polska verknüpfte die bestätigte Kompromittierung mit konkreten Artefakten. Die RouterOS-Protokolle angegriffener Geräte enthalten Einträge, die einem Anmeldefehlschlag für den Benutzer -2 ähneln, gefolgt von einer Benutzeranlage, die ssh:-2@ und der Adresse des Angreifers zugeschrieben wird. Die Behörde nannte außerdem ein unerklärtes, hoch privilegiertes Konto namens ops als Zeichen einer erfolgreichen Ausnutzung.

Die Angriffe, die sie bestätigen konnte, einschließlich der Anlage dieses ops-Kontos, kamen von 82.192.72.4, einer Adresse aus einem Leaseweb-Bereich, aktiv mindestens seit dem 2. September, drei Tage vor der öffentlichen Warnung. Eine zweite Adresse, 103.102.31.18, wurde bei Ausnutzungsversuchen verwendet. Die auf kompromittierten Systemen beobachtete Nutzlast war eine BusyBox-Binärdatei für die MIPS-Architektur, die stark an eine offizielle BusyBox-Version aus dem Jahr 2010 erinnert und zusammen mit Python- und Shell-Skripten ausgeliefert wurde, laut der Forschungsnotiz der Cloud Security Alliance. Ein Jahrzehnte altes, öffentlich verfügbares Werkzeug statt maßgeschneiderter Malware wiederzuverwenden, spricht für Tempo statt Tarnung und passt zu internetweitem Scannen statt zu einer handverlesenen Zielliste.

Der Zeitablauf ist unbehaglich. Die Ausnutzung lief spätestens am 2. September. MikroTik lieferte die Korrekturen am 3. September. Die öffentliche Offenlegung folgte am 5. September. Mehrere Tage lang existierte eine funktionierende Übernahme ohne Authentifizierung gegen Geräte, für die es keine CVE-Nummer zum Suchen und keine Warnung zum Lesen gab.

Warum Edge- und Management-Geräte immer wieder ins Visier geraten

RouterOS ist am Netzwerkrand allgegenwärtig. Internetdienstanbieter, kleine und mittlere Unternehmen und Netzwerkbegeisterte setzen es ein, weil die Hardware günstig und die Konfigurationsmöglichkeiten tief sind. Genau dieselben Eigenschaften machen die Geräte attraktiv: Sie sitzen am Perimeter, werden von allem dahinter als vertrauenswürdig behandelt und oft einmal installiert und dann vergessen.

Dieses Muster hat sich schon früher gezeigt. Eine von der CSA-Notiz zitierte Censys-Erhebung aus dem Jahr 2023 zählte fast 450.000 Hosts, die Monate nach einem früheren kritischen Patch noch immer anfällige RouterOS-Konfigurationsoberflächen exponierten. Geräte, in die niemand sich anmeldet, sind auch Geräte, die niemand planmäßig patcht, was das Fenster verlängert, in dem ein bekannter Fehler für einen Angreifer nützlich bleibt.

Der Vergleich mit den GitLab- und Artifactory-Geschichten aus denselben Wochen ist aufschlussreich. In jedem Fall saß die anfällige Software innerhalb des Perimeters, hielt Anmeldedaten oder steuerte Datenverkehr und wurde langsamer gepatcht als die aus dem Internet erreichbaren Anwendungen, die mehr Aufmerksamkeit erhalten. Managementebenen werden konstruktionsbedingt vertraut. Wer eine erreicht, erbt einen großen Teil dieses Vertrauens.

Die Vorbehalte, die man behalten sollte

MikroTricks Authentifizierungsumgehung ist schwerwiegend, und ihre praktische Reichweite ist enger, als der CVSS-Wert allein nahelegt. Der gefälschte Schlüssel muss sich einen Modul mit einem echten autorisierten Schlüssel teilen, das heißt, der Angreifer muss diesen Modul kennen. Schlüssel, die über eine Geräteflotte hinweg wiederverwendet, versehentlich veröffentlicht oder mit schwachen Parametern erzeugt wurden, machen das leichter. Die CSA-Notiz berichtet, dass die Technik bei RSA-Schlüsseln mit niedrigem öffentlichem Exponenten zuverlässig reproduziert wurde, während Schlüssel mit dem gängigen Exponenten 65537 nicht durchweg anfällig waren. Organisationen sollten das als Grund lesen, die auf RouterOS-Geräten autorisierten SSH-Schlüssel zu inventarisieren und neu zu erzeugen, und als Grund, nicht jeden exponierten Router für trivial ausnutzbar zu halten.

Der zweite Vorbehalt betrifft die Kompromittierungsprüfung des Herstellers. RouterOS prüft die Konfiguration nun beim Start, deaktiviert erkannte verdächtige Einträge, schreibt eine kritische Protokollmeldung und markiert das Gerät als Flagged. CERT Polska sagt ausdrücklich, dass dieser Mechanismus nur ausgewählte Spuren erkennt. Das Fehlen der Markierung ist kein Beleg dafür, dass ein Gerät sauber ist. Administratoren sollten die Markierung als eines von mehreren Signalen behandeln und nicht als Gesundheitszeugnis.

Was Administratoren jetzt tun sollten

Die Empfehlungen von CERT Polska sind direkt, und die Reihenfolge zählt.

• Aktualisieren Sie RouterOS sofort auf 6.49.21, 7.23.4, 7.24.2 oder den Build 7.25beta3. Erst patchen; der Rest ist Triage.
• Ist ein sofortiges Upgrade unmöglich, deaktivieren Sie SSH, WWW/WWW-SSL und den bandwidth-test-Server oder beschränken Sie jeden davon auf vertrauenswürdige Managementnetze. Vermeiden Sie es, von einem ungepatchten Gerät aus TLS-Verbindungen aufzubauen oder seinen eingebauten SSH-Client gegen nicht vertrauenswürdige Hosts zu verwenden.
• Prüfen Sie die Ausgabe von /system/device-mode/print auf die Flagged-Markierung und durchsuchen Sie /system history und die Benutzerliste nach dem -2-Artefakt, einem unerwarteten ops-Konto oder anderen unbekannten Anmeldungen.
• Untersuchen Sie die Konfiguration auf unbekannte Benutzer, Skripte, Scheduler-Aufgaben, Proxyserver und Tunnel.
• Behandeln Sie ein Gerät mit Flagged-Markierung, unerklärten Konfigurationsänderungen oder unbekannten Skripten als kompromittiert. Isolieren Sie es, sichern Sie Protokolle und Konfiguration, bauen Sie es aus einer bekannt guten Konfiguration neu auf und rotieren Sie Passwörter, Schlüssel und weitere Geheimnisse. Stellen Sie nicht blind ein vollständiges Backup von einem verdächtigen Gerät wieder her.

Worauf zu achten ist

Die unmittelbare Frage ist die Verbreitung. Die Korrekturen sind verfügbar und die Ausnutzung ist dokumentiert, doch die gefährdete Gruppe ist groß und träge. Shadowservers Zählung legt nahe, dass Hunderttausende Geräte SSH offen haben, und die KEV-Frist der CISA gilt nur für Bundesbehörden. Beweise einer Kompromittierung dürften dem Patchen hinterherlaufen, denn ein vor Ort neu aufgebautes Gerät ohne Untersuchung kann einen Eindringling weitertragen.

Ein zweiter Strang, der sich lohnt, ist die Art, wie die Fehler gefunden wurden. CERT Polska schreibt das Aufspüren Sławomir Rozbicki und den Modellen GPT-5.5-cyber und GPT-5.6-sol zu, die in einem agentenbasierten Labor unter Forscheraufsicht eingesetzt wurden. Wenn modellgestützte Forschung weiterhin solche Ketten in Edge-Firmware findet, wächst der Druck auf die Hersteller, die Lücke zwischen einem privaten Fix und nutzbarer öffentlicher Anleitung zu schließen, statt zu schrumpfen.

Titelbild: „MikroTIK hAP Lite and RouterBOARD 750" von Stacatto, Wikimedia Commons, CC BY-SA 4.0.