Resumo

Um atacante remoto não autenticado pode obter controle administrativo total de um dispositivo MikroTik RouterOS vulnerável interagindo apenas com seu serviço SSH. Nenhuma credencial, nenhuma interação do usuário e nenhum acesso local são necessários.

Uma vez obtida a policy completa, um atacante possui os mesmos privilégios de um administrador RouterOS do grupo full: ler e modificar toda a configuração, criar contas privilegiadas e backdoors, habilitar/desabilitar serviços, redirecionar ou interceptar tráfego, e usar o dispositivo como ponto de apoio para pivotar em redes internas.

Versões afetadas

• Vulneráveis: RouterOS 6.x e 7.0.0 até 7.23.3 (todo o ramo 6.x e 7.x até a correção).
• Corrigidas: RouterOS 7.23.4 e mais recentes.

O problema foi validado contra as versões oficiais CHR 6.49.20 e CHR 7.21.5 executadas em um laboratório local baseado em QEMU (MikroTik Cloud Hosted Router), e adicionalmente confirmado contra um pequeno número de instalações expostas à internet alcançadas durante pesquisa de validação limitada (detalhes omitidos; sem publicação de hosts de terceiros).

Descrição técnica

A vulnerabilidade é uma escalação de privilégios pré-autenticação no serviço SSH do RouterOS que permite a um cliente SSH não autenticado alcançar uma sessão de console do RouterOS com uma máscara de policy administrativa completa.

O mecanismo específico, os caminhos de código afetados e quaisquer valores de gatilho são intencionalmente omitidos para impedir a reprodução. Apenas o efeito de alto nível é descrito: um cliente não autenticado pode obter policy administrativa completa sem credenciais válidas.

Nota de divulgação responsável: este documento intencionalmente não publica código de exploit, os valores de gatilho específicos, ou uma receita de reprodução passo a passo. Capturas de tela de prova de conceito são fornecidas (veja abaixo); nenhum payload funcional ou código-fonte é divulgado.

Impacto

Um ataque bem-sucedido concede ao atacante remoto não autenticado privilégios administrativos completos do grupo full no roteador. Consequências observadas e realistas:

• Leitura/escrita completa da configuração — extrair peers BGP/OSPF, regras de firewall, credenciais VPN, segredos RADIUS/PPP, certificados.
• Manipulação de contas — criar novos usuários do grupo full e backdoors, bloquear administradores legítimos.
• Abuso de serviços — habilitar/desabilitar serviços, abrir brechas no firewall, fazer proxy de tráfego.
• Interceptação / redirecionamento de tráfego — sequestro de DNS, MITM em tráfego roteado, redirecionamento de tráfego de gerenciamento ou de usuários.
• Movimento lateral — usar o roteador como ponto de pivô para as redes que ele roteia, e recuperar credenciais utilizáveis em outros pontos da rede.
• Material para botnet / DDoS — roteadores com controle total são frequentemente recrutados para botnets de DDoS e varredura.

Como dispositivos RouterOS ficam na borda da rede (gateways, concentradores VPN, CPE de ISP, roteadores corporativos), o raio de impacto é tipicamente muito maior do que um único host comprometido.

Prova de conceito

Para manter este aviso seguro para distribuição pública, nenhum código de exploit, nenhum valor de gatilho e nenhum script de reprodução são publicados aqui.

• Validação em laboratório: confirmado em MikroTik CHR 6.49.20 e 7.21.5 em um laboratório local QEMU/Docker. A prova demonstrou uma ação de escrita (criação e subsequente remoção de um usuário com policy full) que é impossível para uma sessão somente leitura/não autenticada — a policy de admin completa foi obtida pré-autenticação.

• Capturas de tela da prova de conceito:

  

  

Correção

Atualizar o RouterOS

O problema está corrigido no RouterOS 7.23.4 e posteriores.

1. Faça backup da sua configuração primeiro:

   root@kitploit:~

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

2. Atualize pelos canais normais:

   • Winbox / WebFig: System → Packages → Check for updates (ou envie o routeros-<version>.npk para a arquitetura do roteador).
   • CLI: consulte o manual em https://help.mikrotik.com/docs/spaces/ROS/pages/47579159/Upgrade.

3. Após a atualização, verifique a versão em execução:

   root@kitploit:~

   /system resource print
   

4. Só então considere reabilitar o SSH em interfaces externas (veja abaixo).

Prefira aplicar patches a usar workarounds. Atualizações de versão são a única correção completa. Os workarounds abaixo reduzem a exposição, mas não removem a falha subjacente.

Prevenção e hardening

Para dispositivos que não podem ser atualizados imediatamente — e como defesa em profundidade para os corrigidos:

1. Restrinja a exposição do SSH no firewall. Não exponha o SSH à Internet ou a redes não confiáveis. Permita apenas endereços de origem confiáveis:

   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. Desabilite o SSH completamente onde ele não for necessário. Winbox, WebFig e a API geralmente são suficientes para gerenciamento; considere se o acesso remoto via CLI precisa realmente ser exposto:

   root@kitploit:~

   /ip service disable ssh
   

3. Exija autenticação forte. Se o SSH precisar permanecer habilitado:

   • Use autenticação por chave SSH e desabilite a autenticação por senha quando possível: /user ssh-keys import user=<admin> public-key-file=<file>.
   • Nunca use senhas em branco ou padrão (notadamente a conta padrão admin).
   • Imponha senhas fortes e faça rotação regularmente.

4. Coloque o gerenciamento atrás de uma VPN / rede de gerenciamento segmentada. Roteie o acesso de gerenciamento através de uma rede confiável ou VPN em vez de exposição direta; isso se aplica a SSH, Winbox (8291), WebFig/HTTP (80/443), a API do RouterOS (8728/8729) e quaisquer portas SSH personalizadas (3333, 2222, 8022 e outros re-pins comuns são frequentemente usados).

5. Monitore indicadores de comprometimento (veja Detecção abaixo) e habilite o registro de eventos de autenticação e configuração.

6. Mantenha o firmware atualizado e assine os avisos de segurança da MikroTik: https://mikrotik.com/support/security.

Detecção

Sinais de que esta vulnerabilidade pode ter sido tentada ou explorada em um dispositivo:

• Alterações inesperadas na configuração: novos usuários (especialmente com grupo full), novas regras de firewall abrindo acesso, serviços alterados, contas backdoor inesperadas.
• /system identity, configurações de DNS ou regras de roteamento/firewall novos ou modificados que você não fez.
• Atividade SSH incomum nos logs do roteador, como falhas de autenticação repetidas ou sessões abertas sem um evento de login bem-sucedido correspondente.

Verificações úteis em um dispositivo em execução:

Isenção de responsabilidade

Este documento é publicado para fins defensivos e educacionais — para permitir que administradores de dispositivos MikroTik avaliem a exposição, verifiquem o status de aplicação de patches e reforcem suas implantações. Detalhes de exploração são intencionalmente omitidos, e nenhum exploit funcional é divulgado. Teste apenas sistemas que você possui ou está autorizado a avaliar.