Riepilogo

Un attaccante remoto non autenticato può ottenere il controllo amministrativo completo di un dispositivo MikroTik RouterOS vulnerabile interagendo esclusivamente con il suo servizio SSH. Non sono richieste credenziali, interazione utente né accesso locale.

Una volta ottenuta la policy completa, un attaccante dispone degli stessi privilegi di un amministratore RouterOS del gruppo full: lettura e modifica dell'intera configurazione, creazione di account privilegiati e backdoor, abilitazione/disabilitazione di servizi, reindirizzamento o intercettazione del traffico e utilizzo del dispositivo come punto d'appoggio per il pivoting verso reti interne.

Versioni interessate

• Vulnerabili: RouterOS 6.x e 7.0.0 fino a 7.23.3 (l'intero ramo 6.x e 7.x fino alla correzione).
• Corrette: RouterOS 7.23.4 e successive.

Il problema è stato validato sulle release ufficiali CHR 6.49.20 e CHR 7.21.5 in esecuzione in un laboratorio locale basato su QEMU (MikroTik Cloud Hosted Router) e confermato inoltre su un piccolo numero di installazioni esposte a Internet raggiunte durante una ricerca di validazione limitata (dettagli non divulgati; nessuna pubblicazione di host di terze parti).

Descrizione tecnica

La vulnerabilità è un'escalation di privilegi pre-autenticazione nel servizio SSH di RouterOS che consente a un client SSH non autenticato di raggiungere una sessione console RouterOS con una maschera di policy amministrativa completa.

Il meccanismo specifico, i percorsi di codice interessati e qualsiasi valore di trigger sono intenzionalmente omessi per impedirne la riproduzione. Viene descritto solo l'effetto ad alto livello: un client non autenticato può ottenere la policy amministrativa completa senza credenziali valide.

Nota sulla divulgazione responsabile: questo documento intenzionalmente non pubblica codice di exploit, i valori di trigger specifici né una ricetta di riproduzione passo-passo. Sono forniti screenshot di proof-of-concept (vedi sotto); non viene rilasciato alcun payload funzionante o codice sorgente.

Impatto

Un attacco riuscito conferisce all'attaccante remoto non autenticato pieni privilegi amministrativi del gruppo full sul router. Conseguenze osservate e realistiche:

• Lettura/scrittura completa della configurazione — dump di peer BGP/OSPF, regole firewall, credenziali VPN, segreti RADIUS/PPP, certificati.
• Manipolazione degli account — creazione di nuovi utenti del gruppo full e backdoor, blocco degli amministratori legittimi.
• Abuso dei servizi — abilitazione/disabilitazione di servizi, apertura di buchi nel firewall, proxy del traffico.
• Intercettazione / reindirizzamento del traffico — dirottamento DNS, MITM sul traffico instradato, reindirizzamento del traffico di gestione o degli utenti.
• Movimento laterale — utilizzo del router come punto di pivot verso le reti che instrada e recupero di credenziali utilizzabili altrove sulla rete.
• Botnet / materiale DDoS — i router con controllo completo vengono frequentemente reclutati in botnet DDoS e di scansione.

Poiché i dispositivi RouterOS si trovano al bordo della rete (gateway, concentratori VPN, CPE di ISP, router aziendali), il raggio d'azione è tipicamente molto più ampio di quello di un singolo host compromesso.

Proof of concept

Per mantenere questo advisory sicuro per la distribuzione pubblica, qui non vengono pubblicati codice di exploit, valori di trigger né script di riproduzione.

• Validazione in laboratorio: confermata su MikroTik CHR 6.49.20 e 7.21.5 in un laboratorio locale QEMU/Docker. La prova ha dimostrato un'azione di scrittura (creazione e successiva rimozione di un utente con policy full) impossibile per una sessione in sola lettura/non autenticata — la policy amministrativa completa è stata ottenuta pre-auth.

• Screenshot del proof-of-concept:

  

  

Correzione

Aggiornare RouterOS

Il problema è corretto in RouterOS 7.23.4 e successive.

1. Eseguire prima il backup della configurazione:

   root@kitploit:~

   /system backup save name=backup-before-upgrade
   /export file=export-before-upgrade
   

2. Aggiornare tramite i canali normali:

   • Winbox / WebFig: System → Packages → Check for updates (oppure caricare il file routeros-<version>.npk per l'architettura del router).
   • CLI: consultare il manuale su https://help.mikrotik.com/docs/spaces/ROS/pages/47579159/Upgrade.

3. Dopo l'aggiornamento, verificare la versione in esecuzione:

   root@kitploit:~

   /system resource print
   

4. Solo successivamente considerare di riabilitare SSH sulle interfacce esterne (vedi sotto).

Preferire l'applicazione delle patch alle soluzioni alternative. Gli aggiornamenti di versione sono l'unica correzione completa. Le soluzioni alternative seguenti riducono l'esposizione ma non eliminano la falla sottostante.

Prevenzione e hardening

Per i dispositivi che non possono essere aggiornati immediatamente — e come difesa in profondità per quelli già corretti:

1. Limitare l'esposizione di SSH a livello di firewall. Non esporre SSH a Internet o a reti non attendibili. Consentire solo indirizzi sorgente attendibili:

   root@kitploit:~

   /ip firewall filter
   add chain=input protocol=tcp dst-port=22 src-address=192.168.1.0/24 \
       action=accept place-before=1
   add chain=input protocol=tcp dst-port=22 action=drop place-before=2
   

2. Disabilitare completamente SSH dove non è necessario. Winbox, WebFig e l'API sono spesso sufficienti per la gestione; valutare se l'accesso CLI remoto debba essere esposto del tutto:

   root@kitploit:~

   /ip service disable ssh
   

3. Richiedere un'autenticazione forte. Se SSH deve rimanere abilitato:

   • Utilizzare l'autenticazione SSH basata su chiave e disabilitare l'autenticazione tramite password dove possibile: /user ssh-keys import user=<admin> public-key-file=<file>.
   • Non utilizzare mai password vuote o predefinite (in particolare l'account predefinito admin).
   • Applicare password complesse e ruotarle regolarmente.

4. Mettere la gestione dietro una VPN / rete di gestione segmentata. Instradare l'accesso di gestione attraverso una rete attendibile o una VPN anziché l'esposizione diretta; questo vale per SSH, Winbox (8291), WebFig/HTTP (80/443), l'API RouterOS (8728/8729) e qualsiasi porta SSH personalizzata (3333, 2222, 8022 e altri re-pin comuni sono frequentemente utilizzati).

5. Monitorare gli indicatori di compromissione (vedi Rilevamento sotto) e abilitare la registrazione degli eventi di autenticazione e configurazione.

6. Mantenere il firmware aggiornato e iscriversi agli advisory di sicurezza MikroTik: https://mikrotik.com/support/security.

Rilevamento

Segnali che questa vulnerabilità potrebbe essere stata tentata o sfruttata su un dispositivo:

• Modifiche impreviste alla configurazione: nuovi utenti (specialmente con gruppo full), nuove regole firewall che aprono l'accesso, servizi modificati, account backdoor imprevisti.
• Nuovi o modificati /system identity, impostazioni DNS o regole di routing/firewall che non sono stati creati da voi.
• Attività SSH insolita nei log del router, come ripetuti fallimenti di autenticazione o sessioni aperte senza un corrispondente evento di login riuscito.

Controlli utili su un dispositivo in esecuzione:

Disclaimer

Questo documento è pubblicato per scopi difensivi ed educativi — per consentire agli amministratori di dispositivi MikroTik di valutare l'esposizione, verificare lo stato delle patch e rafforzare le proprie installazioni. I dettagli di sfruttamento sono intenzionalmente omessi e non viene rilasciato alcun exploit funzionante. Testare solo sistemi di propria proprietà o per i quali si è autorizzati a effettuare valutazioni.