Zero-Day & Exploits
MikroTrick: o que a cadeia de falhas SSH ensina sobre RouterOS
Falhas no SSH do RouterOS receberam alerta de exploração ativa em setembro. Veja os limites da confirmação, as correções e uma triagem orientada a evidências.
Um roteador comprometido ocupa uma posição especialmente sensível: ele decide como outros sistemas chegam à rede e à internet. O alerta MikroTrick, publicado pelo CERT Polska em 5 de setembro de 2026, merece atenção tanto de administradores quanto de quem pesquisa autenticação e protocolos.
A matéria reúne o alerta daquela semana e as correções complementares disponíveis nas fontes consultadas em 6 de outubro. Não se trata de um novo incidente ocorrido hoje.
O que o CERT confirmou
O CERT Polska informou ter observado exploração de uma combinação de falhas contra dispositivos RouterOS com SSH acessível pela internet, permitindo controle sem autenticação. O nome MikroTrick identifica essa cadeia. A equipe também alertou para alterações não autorizadas de configuração e para os limites do marcador de comprometimento “Flagged”: sua ausência não comprova que o equipamento está íntegro. Consulte o alerta de 5 de setembro do CERT Polska.
Falhas diferentes não devem virar uma única descrição
O conjunto divulgado inclui problemas distintos. A CVE-2026-67276 envolve comparação incompleta da chave pública RSA na autenticação SSH. A CVE-2026-86060 trata do processamento do nome de usuário e da política de privilégios. Há ainda uma falha de sequência de estados SSH, CVE-2026-67279, e problemas em outros serviços. Listar essas falhas como se todas exigissem a mesma entrada ou tivessem o mesmo efeito produz uma avaliação imprecisa. Veja os requisitos e a descrição técnica de cada CVE.
Para pesquisa ofensiva autorizada, o aspecto mais interessante é a relação entre identidade, estado da sessão e privilégio. Em termos gerais, uma implementação precisa preservar essas condições mesmo quando recebe mensagens fora da sequência esperada. Testar um protocolo exige verificar o que acontece ao interromper, repetir ou reorganizar etapas, sempre em laboratório e com controles negativos.
Correções: atenção à atualização complementar
A MikroTik anunciou correções iniciais em 6.49.21, 7.23.4, 7.24.2 e 7.25beta3. Recomendou restringir SSH a redes confiáveis, revisar a configuração após atualizar e seguir o procedimento específico se o dispositivo apresentar “Flagged”. Leia o comunicado da MikroTik.
A ficha técnica do CERT registra uma ressalva importante: a correção da CVE-2026-67278, relacionada à validação de assinaturas RSA, ficou completa em 7.23.6 e 7.24.3. As versões 7.23.4 e 7.24.2 tiveram correção incompleta para esse problema. Esses números são referências históricas do aviso, não uma indicação de que sejam as versões mais recentes hoje. Confira o canal suportado e os changelogs antes da atualização.
| Verificação | Decisão operacional |
|---|---|
| Versão e canal | Comparar o inventário com todos os avisos aplicáveis, incluindo atualizações complementares. |
| SSH administrativo | Validar a exposição real e as regras de origem autorizadas. |
| Configuração | Comparar usuários, tarefas e serviços com uma referência aprovada. |
| Suspeita de invasão | Preservar evidências e definir recuperação antes de reutilizar o equipamento. |
Uma triagem que separa exposição de comprometimento
O roteiro proposto pelo NetCatTest começa com três respostas separadas: qual software está instalado, de onde a administração pode ser acessada e quais alterações foram efetivamente encontradas. Um roteador vulnerável não é automaticamente um roteador invadido. Da mesma forma, a atualização não desfaz por si só todas as mudanças que um invasor pode ter realizado antes dela.
No terminal de um equipamento de laboratório autorizado, consultas de leitura ajudam a registrar a situação:
/system resource print
/system package print
/ip service print
/user print
/system scheduler printGuarde os resultados em um local controlado. Informações de infraestrutura, usuários e configuração podem ser sensíveis. Esses comandos não executam a cadeia MikroTrick nem demonstram a presença de uma das CVEs.
Depois, compare o inventário com o desenho de rede. Um serviço restrito no roteador pode continuar acessível por uma regra de borda esquecida ou por um caminho de gestão não documentado. Faça a verificação a partir dos pontos autorizados do teste e registre o endereço, a origem e o horário.
Como transformar a notícia em um laboratório útil
Monte uma topologia isolada com uma rede de administração e uma rede simulando origem não confiável. Valide a diferença entre as duas, documente as regras e repita a medição após a atualização. O exercício básico é confirmar que a exposição administrativa corresponde ao projeto.
Um exercício avançado pode comparar versões e estados do protocolo com ferramentas de teste, mas precisa manter evidência reproduzível, restauração de snapshots e avaliação do impacto. Um resultado inesperado só vira um finding confirmado depois de repetição e análise; uma mensagem de erro diferente não basta.
Perguntas frequentes
Sem “Flagged”, posso encerrar a análise?
Não. O marcador cobre sinais selecionados. O inventário de configuração e as evidências independentes continuam necessários.
Atualizar substitui a revisão dos usuários?
São atividades diferentes: atualizar trata a falha do software; revisar e recuperar o ambiente trata possíveis efeitos de um acesso anterior.
Onde estudar segmentação e proteção de borda?
As aulas do NetCatTest incluem laboratórios com firewalls, IPS e VLANs. Use esse contexto para verificar onde a administração dos roteadores deveria estar acessível. A capa é uma ilustração conceitual, não uma imagem de um dispositivo comprometido.
