Ing. Calogero Bono
A vulnerabilidade SSHole do OpenSSH, catalogada como CVE-2026-123158, está sendo explorada em ataques reais. Segundo a BleepingComputer, as primeiras tentativas começaram em 5 de novembro, o dia em que apareceu um exploit de demonstração, e no dia seguinte houve o primeiro sucesso. O bug permite entrar em contas Linux sem conhecer a senha, em certas configurações. Se você administra servidores com Alpine Linux ou containers leves, a questão afeta você diretamente.
Alguns termos, antes de entrar nos fatos. OpenSSH é o software que permite conectar-se remotamente aos servidores. musl é uma biblioteca C alternativa à mais comum, usada por exemplo no Alpine Linux. PAM é o sistema modular que gerencia a autenticação no Linux. Hash da senha é o valor com que o sistema guarda a senha em forma não legível. C2 é o servidor de comando e controle com o qual os atacantes guiam o malware.
O que é o SSHole e como funciona?
Segundo a BleepingComputer, a falha foi tornada pública pelo pesquisador Ozgun Kultekin. Afeta o OpenSSH em sistemas Linux baseados em musl, entre eles o Alpine, muito usado em ambientes de nuvem e virtuais.
O mecanismo é este. Algumas contas têm no campo da senha um asterisco, para impedir o acesso por senha. Se for enviada uma senha muito longa, a função de hash do musl devolve um asterisco como erro. O OpenSSH o confunde com uma correspondência com o valor guardado e deixa entrar.
Já escrevemos sobre isso no nosso artigo sobre o bug *sshole nas contas do Alpine Linux.
Quais sistemas estão realmente expostos?
O The Hacker News indica uma pontuação CVSS de 8,1 e especifica as condições. São necessários Linux com OpenSSH em musl e PAM desativado, o que inclui a configuração padrão do servidor OpenSSH do Alpine.
Kultekin explica que são necessárias configurações de autenticação específicas e que as contas com hash válido não são afetadas. O acesso root é possível onde a conta comprometida tem privilégios administrativos sem senha.
O que os atacantes estão fazendo?
Segundo a GreyNoise, a primeira exploração bem-sucedida ocorreu em 7 de novembro às 00h46 UTC, cerca de 40 horas após a correção. A empresa registrou 16 cadeias de exploração bem-sucedidas contra redes que protege, a partir de seis endereços IP. Diz, porém, que elas não representam a atividade total.
Os atacantes fizeram reconhecimento do sistema e dos containers, consultaram os serviços de metadados da nuvem, tentaram ler hashes e chaves SSH de root e modificar o arquivo authorized_keys para permanecer dentro. A Previdian fala de 20 tentativas a partir de 13 IPs em nove países. A watchTower viu usos ligados a botnets e criptomineração.
O que é o TAC Agent?
É um agente Python de comando e controle instalado em um ataque a um sistema em que o atacante obteve privilégios de root. Segundo a BleepingComputer, ele executa comandos, faz reconhecimento amplo, envia e baixa arquivos e pode se atualizar. Não tem persistência integrada, por isso os atacantes configuram um serviço de inicialização.
Nesse caso, não conseguiu alcançar o servidor C2 e nunca recebeu tarefas. A Ars Technica, citando a GreyNoise, atribui a atividade a um grupo chamado GT10 e observa que o backdoor tem comentários em chinês e parece gerado com IA. O mesmo grupo instala Python3 onde ele falta.
Limites a conhecer
Não sabemos quantos sistemas foram comprometidos. A própria GreyNoise diz que suas 27,5 milhões de varreduras na porta 22 e 20,1 milhões de sessões SSH não são ataques SSHole confirmados. Os comentários em chinês não bastam para a atribuição, e as fontes não concordam sobre quem é o autor. A Ars Technica fala de um grupo chamado GT10, a BleepingComputer não o menciona.
O que muda para quem trabalha com o digital
Se você administra servidores Linux, atualize o OpenSSH para a versão 10.6p2, lançada em 5 de novembro. Como alternativa, desative a autenticação por senha via SSH, como recomenda a BleepingComputer. Depois verifique os acessos com senha bem-sucedidos em contas com asterisco em /etc/shadow, as chaves SSH não autorizadas e os arquivos ou serviços de inicialização do TAC Agent. Quem usa Alpine em containers deve reconstruir as imagens. Se você tem servidores gerenciados por terceiros, pergunte se foram atualizados, por exemplo com uma hospedagem com atualizações de segurança gerenciadas.
Nossa opinião
O caso mostra o quanto é frágil a confiança em um valor de erro. Um asterisco devolvido por uma biblioteca vira uma chave válida para outro componente. Não é uma falha exótica, é um erro de fronteira entre dois componentes. O dado mais útil é a rapidez. O código de ataque apareceu cerca de quatro horas após a correção. A margem entre o patch e a exploração agora se mede em horas, e quem atualiza no fim do mês já está atrasado.
Perguntas frequentes
O SSHole afeta todos os servidores Linux?
Não. Afeta o OpenSSH em sistemas com musl e PAM desativado, como a configuração padrão do Alpine. Também são necessárias configurações de autenticação específicas.
Qual é a versão correta do OpenSSH?
A 10.6p2, lançada em 5 de novembro segundo a BleepingComputer. Atualizar é a medida principal.
Se não puder atualizar agora, o que faço?
Desative a autenticação SSH por senha, como sugere a BleepingComputer. Depois verifique os acessos suspeitos.
O que os atacantes procuram?
Segundo a GreyNoise, hashes de senhas, chaves SSH de root e metadados de nuvem. Também tentam modificar o authorized_keys para permanecer dentro.
Como reconheço o TAC Agent?
Procure seus arquivos e os serviços de inicialização criados para ele. A BleepingComputer também recomenda verificar chaves SSH não autorizadas.
O que observar nas próximas semanas sobre SSH e musl
O quadro ainda está em movimento, com novos dados esperados de quem monitora os ataques. Vale acompanhar poucas coisas concretas.
- Acompanhe as atualizações da GreyNoise e da Previdian sobre o número de sistemas comprometidos.
- Verifique quando sua distribuição publicar as imagens Alpine com o OpenSSH corrigido.
- Revise quais contas têm asterisco em /etc/shadow e se ainda são necessárias.
