Intervalli vulnerabili (tutti e sei): [7.24, 7.24.2), [7.0.0, 7.23.4), [6.0.0, 6.49.21).

Meccanismo CVE-2026-67276

1. RouterOS confronta il blob della chiave pubblica SSH presentato con la chiave autorizzata dell'utente tramite (tipo chiave, modulo) — l'esponente non viene confrontato.
2. La verifica della firma usa la chiave fornita dal client, cioè l'esponente dal blob dell'attaccante.
3. Presentare {ssh-rsa, e=1, n=vittima} rende sig^1 mod n == sig, quindi la "firma" valida è semplicemente EMSA-PKCS1-v1_5(hash, authdata) — calcolabile da chiunque conosca il modulo pubblico della vittima. Nessuna chiave privata necessaria.
4. Risultato: un canale di comando SSH come utente target.

Precondizioni (il minimo indicato dalla divulgazione stessa): username target + modulo RSA pubblico autorizzato di quell'utente.

Informazioni minime necessarie per riprodurre

1. Target: qualsiasi RouterOS negli intervalli vulnerabili, SSH raggiungibile (laboratorio: immagine CHR in QEMU con KVM; hardware reale equivalente).
2. Username di un account con chiave RSA autorizzata.
3. Il modulo RSA n di quella chiave autorizzata (da un .pub trapelato/catturato, registri di provisioning, o --modulus-hex). Questo è l'unico input simile a un segreto; la chiave privata non è mai necessaria.
4. Comportamento server confermato dalla divulgazione (il difetto stesso, da CERT PL): match = (tipo, n), verifica esponente = fornito dal client.
5. Un client che possa presentare un blob di chiave arbitrario e byte di firma arbitrari (paramiko + hook ForgeKey — OpenSSH standard non può).
6. Algoritmo di firma accettato dal server (ssh-rsa su 6.x, rsa-sha2-256 anche su 7.x).

File

• forge_67276.py — primitiva: parsing chiave pubblica OpenSSH, encoder EMSA RFC 8017, costruttori blob/firma falsificati, verificatore di riferimento RFC 8017.
• selftest.py — prova locale, senza router: encoder byte-identico a OpenSSL (tramite inversione firma reale), firma falsificata verifica a e=1 e NON a 65537, simulazione completa wire-shape RFC 4252 §7. Tutti i 15 controlli PASS.
• poc_67276.py — client paramiko che esegue il bypass (pinning algoritmo per-connessione; --lab-i-own-this-target richiesto).
• console_setup.py — preparazione CHR una tantum su serial telnet qemu (recupera chiave vittima via 10.0.2.2, importa per admin, abilita ssh).
• sanity_real_key.py — controllo: l'auth con chiave pubblica normale deve riuscire prima.
• victim_rsa / victim.pub — coppia di chiavi "vittima" 2048-bit usa-e-getta generata; deliberatamente esclusa da Git.

Setup locale

Laboratorio (provisionato su [email protected])

• Kali x86_64, QEMU 11.0.1 + KVM, /root/mikrotrick-lab/, bridge host br0 (192.168.100.1/24) con tap tap0-tap3; dnsmasq su br0 con lease per-MAC.

• Stato guest previsto: NIC e1000, IP guest statico, password admin labpass123, e chiave vittima importata per admin. I cambi password forzati al primo login sono stati gestiti via SSH (bootstrap_password.py legge il dialogo) o monitor QEMU sendkey (mon_type.py) — la console seriale CHR è morta di default; la console VGA è leggibile solo tramite monitor screendump.
• Tunnel dal 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]

Riesecuzione (esempio, VM3):

Risultati osservati (2026-09-06 rivalidazione indipendente)

Per la coppia 7.x, la baseline con chiave reale riesce su entrambe le build, l'autenticazione SSH none è rifiutata, una falsificazione con modulo errato è rifiutata da 7.23.3, e la falsificazione con modulo corretto riesce solo su 7.23.3. Questo è un confronto valido vulnerabile-versus-patchato.

Il guest 6.49.21 non è stato provisionato come documentato durante la rivalidazione indipendente: admin è rimasto scaduto, /user ssh-keys print detail era vuoto, e una richiesta SSH none senza credenziali ha eseguito comandi. Chiavi RSA reali non correlate e chiavi e=1 con modulo errato sono quindi anch'esse apparse riuscite. Riprovisionare questo guest e verificare che none e una chiave non correlata siano rifiutati prima di usarlo come controllo patchato.

Sfumatura di versione: su 6.49.20 il match lato server rifiuta il blob e=1 (/log ssh,debug: can't find matching key for user: admin) — l'omissione dell'esponente divulgata non era osservabile nel matcher 6.x sebbene l'intervallo generico di CERT elenchi [6.0.0, 6.49.21). Confermato vulnerabile: 7.23.3. Confermato patchato: 7.23.4. Lo stato attuale del laboratorio 6.49.21 non prova nessuno dei due risultati. L'attività MikroTrick in natura ha preso di mira anche dispositivi 7.x.

Risultato sul wire-format (RFC 8332): la stringa di tipo interna del blob resta ssh-rsa anche per algoritmi di firma rsa-sha2-256/512; l'algoritmo di firma va solo nel campo algoritmo esterno. Ignorare questo fa disconnettere il server a metà userauth (errore di parsing blob) — osservato sia su 6.x che su 7.x. Il ForgeKey del PoC gestisce questo, e --exp-enc aligned|canonical alterna la larghezza mpint di e=1 (1 vs 3 byte). Su 7.23.3 ENTRAMBE le larghezze autenticano — il matcher analizza l'esponente e ne ignora davvero il valore. Su 6.49.20 NESSUNA autentica (can't find matching key) — vedi la sfumatura di versione sopra. Gli hexdump pacchetti lato server /system logging add topics=ssh,debug + /log print hanno portato alla luce tutto questo.

Valori SHA-256 dell'archivio immagini sorgente usati da questo laboratorio:

Note difensive (CERT PL)

• Patchare immediatamente: 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21.
• In attesa: limitare SSH/WWW/bandwidth-test a reti di gestione fidate; evitare SSH/TLS iniziati da RouterOS da dispositivi non patchati.
• IOC: righe di log login failure for user -2 via ssh, user <name> added by ssh:-2@<ip>; utente sconosciuto altamente privilegiato ops; marcatore /system/device-mode/print "Flagged" (indica compromissione, la sua assenza non prova nulla). IP attaccanti osservati: 82.192.72.4, 103.102.31.18.

Fonti

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