O CEO da Binance, Changpeng Zhao (CZ), alertou para um bug de autenticação de longa data no OpenSSH que pode permitir que invasores entrem em alguns servidores sem saber a senha — e que permaneceu oculto nos sistemas por quase uma década. O que aconteceu - Em 5 de novembro, o OpenSSH e o Alpine Linux publicaram correções para uma falha que permite contornar a autenticação e que, segundo pesquisadores, remonta a alterações feitas entre 2012 e 2016. CZ amplificou o alerta no X no dia seguinte, pedindo aos administradores que instalassem as correções imediatamente. Ele não disse que a Binance havia sido afetada; os avisos não relataram evidências de comprometimento. Como o bug funciona (versão resumida) - A falha afeta o OpenSSH em sistemas que usam musl libc (notavelmente, muitas compilações do Alpine Linux) quando: - PAM não é usado para verificar senhas, - A autenticação por senha continua ativada e - Existem determinadas configurações de conta. - Um invasor pode contornar a autenticação enviando uma única senha excessivamente longa (entre 257 e 1.024 bytes). Se o campo de senha armazenada da conta de destino contiver um asterisco (*) — que significa “sem senha” na função de hash da musl — e outra conta local tiver um hash SHA-256 ou SHA-512 compatível, o servidor poderá aceitar erroneamente a senha excessivamente longa e conceder acesso. - Isso pode permitir o acesso a contas que os administradores acreditavam estar configuradas para aceitar apenas logins com chaves SSH. Quem é afetado - Potencialmente vulneráveis: sistemas Alpine Linux que executam OpenSSH sem PAM e com autenticação por senha ativada; algumas imagens Alpine de nuvem/“tiny-cloud” quando condições específicas são criadas posteriormente. - Não são afetados: sistemas que usam PAM para verificar senhas, servidores com a autenticação por senha desativada e contêineres sem um servidor SSH ativo. - O problema também pode afetar outras distribuições Linux que usam musl libc (algumas configurações de OpenWrt, Buildroot e Yocto). O SSH Dropbear padrão do OpenWrt não é afetado por esse bug. Descoberta e contexto técnico - O pesquisador de segurança Özgün Kültekin (Wakefield) descobriu a falha e a batizou de “*sshole”. Ele a relacionou ao comportamento de hash de senhas da musl: a musl retorna um asterisco quando uma senha ultrapassa seu limite de processamento de 256 bytes. Uma alteração no OpenSSH de julho de 2016 (feita para resolver vazamentos que permitiam descobrir nomes de usuário) pode fazer com que o sshd use o salt de outra conta ao validar uma conta sem um hash válido. Em conjunto, esses comportamentos fazem com que um asterisco retornado corresponda a um asterisco armazenado, resultando em uma autenticação bem-sucedida. - A equipe do OpenSSH reconheceu a vulnerabilidade, mas afirmou que a causa-raiz está fora do sshd; a versão lançada em 5 de novembro (OpenSSH 10.6p2) implementa uma solução alternativa para bloquear o erro de autenticação. Por que isso importa para operadores de criptoativos - Muitas imagens de nuvem leves e opções de infraestrutura no setor de criptoativos usam Alpine Linux ou compilações baseadas em musl. O aviso do Alpine destaca as imagens tiny-cloud das versões 3.18.11 a 3.24.3: a conta alpine padrão pode executar o doas sem senha e, se as condições para exploração surgirem posteriormente, um login bem-sucedido pode ser elevado a root. Mesmo que os logins como root estejam bloqueados por padrão, uma conta administrativa comprometida ainda pode ser usada para obter privilégios elevados — um risco grave para operadores de nós, carteiras, validadores e serviços de custódia. O que fazer agora - Atualize: instale o OpenSSH 10.6p2 ou os pacotes corrigidos do Alpine Linux (o Alpine afirma ter correções disponíveis desde a versão 3.16). Observe que apenas instalar as atualizações dos pacotes não basta — é necessário reiniciar o processo sshd após a atualização. - Se não puder atualizar imediatamente: desative temporariamente a autenticação por senha definindo PasswordAuthentication no em sshd_config e reinicie o sshd depois de confirmar que o acesso por chave SSH funciona. - Verifique os logs: examine os logs de autenticação SSH em busca de logins inesperados por senha em contas que não deveriam aceitar senhas. - Se não puder descartar um acesso não autorizado, considere a máquina comprometida e siga seus procedimentos de resposta a incidentes. Correções e versões - O OpenSSH lançou a versão 10.6p2 em 5 de novembro. - O Alpine identificou versões corrigidas dos pacotes (incluindo, por exemplo, 3.21.10, 3.22.8, 3.23.8 e 3.24.4) e afirmou que há correções disponíveis para as versões atuais e para ramificações mais antigas até a 3.16. Contexto - A publicação de CZ é a mais recente de uma série de alertas de segurança que ele destacou publicamente (recentemente, chamou a atenção para um site falso da Trust Wallet usado para aplicar golpes de phishing contra usuários). Diante do potencial de movimentação lateral a partir de uma única conta comprometida, os operadores de infraestrutura de criptoativos devem priorizar essas correções. Em resumo: se você usa Alpine ou qualquer sistema baseado em musl com OpenSSH e autenticação por senha ativada, instale a correção e reinicie o sshd agora — ou, no mínimo, desative a autenticação por senha até poder aplicar a correção e verificar seus sistemas. Leia mais notícias geradas por IA em: https://app.chaingpt.org/news