Faixas vulneráveis (todas as seis): [7.24, 7.24.2), [7.0.0, 7.23.4), [6.0.0, 6.49.21).

Mecanismo da CVE-2026-67276

1. O RouterOS compara o blob de chave pública SSH apresentado com a chave autorizada do usuário por (tipo de chave, módulo) — o expoente não é comparado.
2. A verificação de assinatura usa a chave fornecida pelo cliente, ou seja, o expoente do blob do atacante.
3. Apresentar {ssh-rsa, e=1, n=vítima} faz com que sig^1 mod n == sig, portanto a "assinatura" válida é simplesmente EMSA-PKCS1-v1_5(hash, authdata) — calculável por qualquer pessoa que conheça o módulo público da vítima. Nenhuma chave privada é necessária.
4. Resultado: um canal de comando SSH como o usuário alvo.

Pré-condições (o mínimo da própria divulgação): nome de usuário alvo + o módulo RSA público autorizado desse usuário.

Informações mínimas necessárias para reproduzir

1. Alvo: qualquer RouterOS nas faixas vulneráveis, com SSH acessível (laboratório: imagem CHR no QEMU com KVM; hardware real equivalente).
2. Nome de usuário de uma conta com chave RSA autorizada.
3. O módulo RSA n dessa chave autorizada (de um .pub vazado/capturado, registros de provisionamento ou --modulus-hex). Esta é a única entrada semelhante a segredo; a chave privada nunca é necessária.
4. Comportamento do servidor confirmado pela divulgação (o próprio defeito, do CERT PL): correspondência = (tipo, n), verificação do expoente = fornecido pelo cliente.
5. Um cliente que possa apresentar um blob de chave arbitrário e bytes de assinatura arbitrários (paramiko + hook ForgeKey — o OpenSSH padrão não consegue).
6. Algoritmo de assinatura que o servidor aceita (ssh-rsa na 6.x, rsa-sha2-256 também na 7.x).

Arquivos

• forge_67276.py — primitiva: análise de chave pública OpenSSH, codificador EMSA RFC 8017, construtores de blob/assinatura falsificados, verificador de referência RFC 8017.
• selftest.py — prova local, sem roteador: codificador byte-idêntico ao OpenSSL (via inversão de assinatura real), assinatura falsificada verifica com e=1 e NÃO com 65537, simulação completa do formato de wire RFC 4252 §7. Todas as 15 verificações PASSAM.
• poc_67276.py — cliente paramiko que executa o bypass (fixação de algoritmo por conexão; --lab-i-own-this-target obrigatório).
• console_setup.py — preparação única do CHR via telnet serial do qemu (busca a chave da vítima via 10.0.2.2, importa para admin, habilita ssh).
• sanity_real_key.py — controle: a autenticação normal por chave pública deve ter sucesso primeiro.
• victim_rsa / victim.pub — par de chaves "vítima" descartável de 2048 bits gerado; deliberadamente excluído do Git.

Configuração local

Laboratório (provisionado em [email protected])

• Kali x86_64, QEMU 11.0.1 + KVM, /root/mikrotrick-lab/, bridge do host br0 (192.168.100.1/24) com taps tap0-tap3; dnsmasq no br0 com leases por MAC.

• Estado pretendido do convidado: NIC e1000, IP estático do convidado, senha do admin labpass123 e chave da vítima importada para admin. Alterações forçadas de senha no primeiro login foram conduzidas via SSH (bootstrap_password.py lê o diálogo) ou sendkey do monitor QEMU (mon_type.py) — o console serial do CHR está morto por padrão; o console VGA só é legível via screendump do monitor.
• Tunel a partir do 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]

Reexecução (exemplo, VM3):

Resultados observados (revalidação independente em 06/09/2026)

Para o par 7.x, a linha de base com chave real tem sucesso em ambas as versões, a autenticação SSH none é rejeitada, uma falsificação com módulo errado é rejeitada pela 7.23.3 e a falsificação com módulo correto só tem sucesso na 7.23.3. Esta é uma comparação válida entre vulnerável e corrigido.

O convidado 6.49.21 não foi provisionado conforme documentado durante a revalidação independente: admin permaneceu expirado, /user ssh-keys print detail estava vazio e uma solicitação SSH none sem credenciais executou comandos. Chaves RSA reais não relacionadas e chaves e=1 com módulo errado também pareceram ter sucesso. Reprovisione este convidado e verifique se none e uma chave não relacionada são rejeitados antes de usá-lo como controle corrigido.

Nuance de versão: na 6.49.20, a correspondência do lado do servidor rejeita o blob e=1 (/log ssh,debug: can't find matching key for user: admin) — a omissão de expoente divulgada não era observável no correspondente da 6.x, embora a faixa genérica do CERT liste [6.0.0, 6.49.21). Vulnerável confirmado: 7.23.3. Corrigido confirmado: 7.23.4. O estado atual do laboratório 6.49.21 não prova nenhum dos dois resultados. A atividade MikroTrick na natureza também visou dispositivos 7.x.

Descoberta de formato de wire (RFC 8332): a string de tipo interna do blob permanece ssh-rsa mesmo para algoritmos de assinatura rsa-sha2-256/512; o algoritmo de assinatura vai apenas no campo de algoritmo externo. Ignorar isso faz o servidor desconectar no meio do userauth (erro de análise do blob) — observado tanto na 6.x quanto na 7.x. O ForgeKey do PoC lida com isso, e --exp-enc aligned|canonical alterna a largura do mpint e=1 (1 vs 3 bytes). Na 7.23.3 AMBAS as larguras autenticam — o correspondente analisa o expoente e realmente ignora seu valor. Na 6.49.20 NENHUMA autentica (can't find matching key) — ver a nuance de versão acima. Hexdumps de pacotes do lado do servidor via /system logging add topics=ssh,debug + /log print revelaram tudo isso.

Valores SHA-256 do arquivo de imagem de origem usados por este laboratório:

Notas defensivas (CERT PL)

• Corrija imediatamente: 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21.
• Interino: restrinja SSH/WWW/bandwidth-test a redes de gerenciamento confiáveis; evite SSH/TLS iniciado pelo RouterOS a partir de dispositivos não corrigidos.
• IOCs: linhas de log login failure for user -2 via ssh, user <name> added by ssh:-2@<ip>; usuário altamente privilegiado desconhecido ops; marcador /system/device-mode/print "Flagged" (indica comprometimento; sua ausência não prova nada). IPs de atacantes observados: 82.192.72.4, 103.102.31.18.

Fontes

• Aviso do CERT PL: https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
• Página CVE do CERT PL: https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
• Boletim da MikroTik (03/09/2026): https://mikrotik.com/supportsec/september-2026-vulnerability/
• Mecanismo "Flagged": https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode#flagged-status