Hackers exploram a falha SSHole do OpenSSH para invadir servidores Alpine Linux

Atacantes já estão a explorar o SSHole (CVE-2026-123158, gravidade 8,1 em 10), uma falha no OpenSSH que permite entrar em alguns servidores Linux com qualquer palavra-passe com mais de 256 caracteres. Afeta sistemas baseados na biblioteca C musl, sobretudo o Alpine Linux. A empresa de inteligência de ameaças GreyNoise registou a primeira intrusão bem-sucedida a 7 de novembro às 00:46 UTC, cerca de 40 horas depois de sair a correção. Depois de entrarem, os intrusos procuraram palavras-passe e chaves, adicionaram as suas próprias chaves SSH e, num caso, instalaram um agente de controlo remoto, relata o BleepingComputer.

Como funciona a falha

No Linux, um * no campo da palavra-passe em /etc/shadow significa que não é possível entrar nessa conta com palavra-passe. O Alpine usa-o para o root e para utilizadores que entram só com chave. O investigador Özgün Kültekin, da Wakefield, que reportou o erro, encontrou a origem numa alteração do musl de 2012: quando a função de hash de palavras-passe falha, devolve * em vez de um erro. E falha com qualquer palavra-passe acima de 256 bytes. Assim, uma palavra-passe muito longa dá *, coincide com a conta bloqueada e o sshd deixa o atacante entrar. Com o PAM ativo, o sshd não compara os hashes desta forma, por isso esses sistemas estão a salvo.

O ataque precisa de quatro condições ao mesmo tempo: sshd compilado com musl, PAM desligado, início de sessão por palavra-passe permitido e pelo menos uma conta com * no campo da palavra-passe. No Alpine, as três primeiras são as predefinições do pacote openssh-server, e o root tem * desde a versão 3.16. As imagens oficiais do Alpine para AWS e Azure têm ainda um utilizador alpine que pode executar comandos como root sem palavra-passe, pelo que entrar com ele dá controlo total.

O que fizeram os atacantes

O OpenSSH lançou a versão 10.6p2 com a correção a 5 de novembro. A análise do investigador saiu no mesmo dia e, menos de uma hora depois, havia código de exploração no GitHub. A GreyNoise viu 16 cadeias de ataque bem-sucedidas a partir de seis endereços IP nos sistemas que monitoriza e sublinha que é apenas parte da atividade. Os intrusos verificaram se estavam dentro de um contentor, consultaram serviços de metadados da nuvem, tentaram ler as chaves SSH do root e o /etc/shadow e acrescentaram as suas chaves ao authorized_keys do root e do utilizador alpine para manter o acesso.

Um grupo obteve privilégios de root, mudou as definições de DNS, arrancou um segundo servidor SSH escondido e instalou o TAC Agent, um programa em Python com comentários e mensagens em chinês que executa comandos e transfere ficheiros. Nunca conseguiu registar-se no seu servidor de controlo, tac.vpnla[.]org, e não recebeu tarefas. As empresas de segurança Previdian e Defused também registaram tentativas, e a watchTowr associou a falha a botnets e mineração de criptomoedas.

Como verificar o seu servidor

• Veja o que está instalado: cat /etc/os-release. Se for Alpine ou outro sistema com musl, continue a ler. Servidores com Ubuntu e Debian não estão expostos a este erro.
• Atualize: apk upgrade openssh no Alpine. Há pacotes corrigidos para os ramos 3.19 a 3.24 e edge, segundo o registo de segurança do Alpine.
• Se usa chaves, desligue o início de sessão por palavra-passe: PasswordAuthentication no na configuração do sshd e reinicie o sshd. Isto fecha a falha mesmo antes de atualizar.
• Procure vestígios: inícios de sessão por palavra-passe bem-sucedidos (grep "Accepted password" /var/log/messages) em contas com * no /etc/shadow, chaves desconhecidas no authorized_keys, os ficheiros /opt/py3/tac_agent.py e /etc/init.d/tac-agent, alterações em /etc/hosts e /etc/resolv.conf e um servidor SSH extra numa porta invulgar (ss -tlnp mostra as portas abertas).
• Se encontrar algo disto, considere o servidor comprometido: reinstale-o e mude todas as palavras-passe e chaves que lá estavam.

Isto diz respeito a quem tem a sua própria VPN num VPS barato: as imagens leves do Alpine são populares para isso. A maioria dos routers domésticos com OpenWrt usa o Dropbear para SSH e não é afetada, a não ser que o dono o tenha trocado pelo OpenSSH. O nosso guia para proteger um VPS já recomenda o acesso SSH apenas por chave, e essa definição bloqueia o ataque.