Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
mikrotrick-poc — CVE-2026-67276 RouterOS SSH-Public-Key-Authentifizierung-Bypass-Labor-PoC | Kitploit
Tools/GitHubGitHub/dinosn/mikrotrick-poc
SchwachstellenanalyseExploitationNetzwerksicherheitPenetrationstestsAuthentifizierung
GitHubdinosn/mikrotrick-poc

mikrotrick-poc

CVE-2026-67276 RouterOS SSH-Public-Key-Authentifizierung-Bypass-Labor-PoC

Repository anzeigen
52vor 12h 32mNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

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.

CVETypKernfehler
2026-67276CWE-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-86060CWE-88Argument-Injection über Benutzernamen, der mit einem verbotenen Zeichen beginnt (-2 in Angriffslogs gesehen) ⇒ Policy-Mask-Änderung ⇒ Privilegieneskalation
2026-67279CWE-841SSH tritt nach client-angefordertem Rekey ohne abgeschlossenes Userauth in das Verbindungsprotokoll ein ⇒ nicht authentifizierte Ausführung im Datei-Namespace
2026-67277CWE-306bandwidth-test Pre-Auth-Zustand + Offenlegung nicht initialisierter Puffer + Size-Underflow ⇒ Kernel-Speicherleck / Neustart
2026-67278CWE-347X.509 akzeptiert fehlerhafte RSA/PKCS#1v1.5-Signaturen; e=3-Vertrauensanker ⇒ Fälschung vertrauenswürdiger Zwischenzertifikate
2026-67281CWE-824WebFig /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

  1. 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.
  2. Die Signaturprüfung verwendet den client-gelieferten Schlüssel, d. h. den Exponenten aus dem Blob des Angreifers.
  3. 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.
  4. Ergebnis: ein SSH-Befehlskanal als Zielbenutzer.

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

Mindestinformationen zur Reproduktion

  1. Ziel: jedes RouterOS in den verwundbaren Bereichen, SSH erreichbar (Labor: CHR-Image in QEMU mit KVM; echte Hardware gleichwertig).
  2. Benutzername eines Kontos mit autorisiertem RSA-Schlüssel.
  3. 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.
  4. Durch die Offenlegung bestätigtes Serververhalten (der Defekt selbst, von CERT PL): Match = (Typ, n), Verify-Exponent = client-geliefert.
  5. Ein Client, der einen beliebigen Schlüssel-Blob und beliebige Signaturbytes präsentieren kann (paramiko + ForgeKey-Hook — Standard-OpenSSH kann das nicht).
  6. 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

root@kitploit:~
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.
VMImageGast-IPMACMac-seitiger Tunnel
chr-6.49.20verwundbares 6.x192.168.100.1152:54:00:aa:00:11127.0.0.1:2222
chr-6.49.21gepatchtes 6.x192.168.100.1252:54:00:aa:00:12127.0.0.1:2223
chr-7.23.3verwundbares 7.x192.168.100.1352:54:00:aa:00:13127.0.0.1:2224
chr-7.23.4gepatchtes 7.x192.168.100.1452:54:00:aa:00:14127.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):

root@kitploit:~
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 &
root@kitploit:~
./.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)

Zielechter privater Schlüssel (Baseline)gefälschter e=1-Schlüssel (PoC)
7.23.3Auth OKAuth OK + /system resource print-Ausführung — CVE bestätigt
7.23.4 (gepatcht)Auth OKabgelehnt
6.49.20Auth OKabgelehnt (siehe Nuance)
6.49.21 (gepatcht)ungültige Baselinenicht 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:

root@kitploit:~
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

Defensive Hinweise (CERT PL)

  • Sofort patchen: 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21.
  • Interim: SSH/WWW/bandwidth-test auf vertrauenswürdige Verwaltungsnetzwerke beschränken; RouterOS-initiiertes SSH/TLS von ungepatchten Geräten vermeiden.
  • IOCs: Logzeilen 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.

Quellen

  • CERT-PL-Advisory: https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
  • CERT-PL-CVE-Seite: https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
  • MikroTik-Bulletin (2026-09-03): https://mikrotik.com/supportsec/september-2026-vulnerability/
  • „Flagged"-Mechanismus: https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode#flagged-status
Tool herunterladen