Falha permite acessar contas sem senha em alguns servidores Alpine Linux
Em alguns servidores Alpine Linux que usam o pacote padrão `openssh-server`, invasores podem acessar contas sem senha, como aquelas configuradas para aceitar apenas chaves SSH. Para explorar a falha, eles precisam ter acesso à rede do servidor, conhecer o nome de uma conta e enviar uma senha com tamanho entre 257 e 1.024 bytes.
O projeto OpenSSH classificou a vulnerabilidade como crítica e lançou a versão 10.6p2 para corrigi-la. O Alpine publicou pacotes corrigidos para todas as versões desde a 3.16.
O ataque funciona quando o servidor OpenSSH, por meio do processo `sshd`, verifica senhas sem usar a interface PAM, permite autenticação por senha e tem pelo menos outra conta com senha. O pacote `openssh-server` do Alpine é compilado sem PAM, e a autenticação por senha vem ativada por padrão.
A falha está relacionada à forma como o `sshd` interage com a musl, biblioteca C usada pelo Alpine. Sistemas que não usam Linux, distribuições Linux baseadas na glibc e sistemas que verificam senhas por meio do PAM não são afetados, afirmou Damien Miller, do projeto OpenSSH.
Miller recomendou que usuários de sistemas vulneráveis “definam `PasswordAuthentication=no` ou desativem o SSH nesses sistemas IMEDIATAMENTE”. Até o momento, não há relatos de ataques que explorem a falha.
Quem está exposto
O alerta de segurança do Alpine aponta quatro condições. Um servidor está vulnerável quando todas elas são atendidas:
- Executa o pacote `openssh-server`, compilado sem PAM, ou o pacote `openssh-server-pam` com a opção `UsePAM no`.
- Está com `PasswordAuthentication` definido como `yes`, configuração padrão do OpenSSH.
- Tem uma conta cujo campo de senha contém `*`, o que indica que nenhuma senha foi definida.
- Tem pelo menos outra conta local com um hash de senha iniciado por `$5$` ou `$6$`.
O invasor também precisa saber o nome de uma conta sem senha. Uma única conta com senha pode deixar todas as contas sem senha expostas. Segundo o alerta, o ataque funciona em todas as tentativas e exige apenas uma conexão.
No Alpine, contas sem senha definida podem incluir:
- usuários que aceitam apenas chaves e foram criados com `adduser` sem senha ou com `usermod -p '*'`;
- usuários obtidos de um serviço de diretório por meio do musl-nscd, que não têm uma entrada em `/etc/shadow`;
- a conta `root`, que vem como `root:*` na imagem básica desde aproximadamente a versão 3.16 do Alpine;
- o usuário `alpine` nas imagens oficiais de cloud criadas com tiny-cloud.
A configuração padrão `PermitRootLogin prohibit-password` protege a conta `root`, que só pode ser acessada diretamente se `PermitRootLogin yes` estiver definido. Essa proteção não é suficiente se uma conta vulnerável puder obter privilégios de `root`, por exemplo, por meio do `doas`.
As imagens tiny-cloud das versões 3.18.11 a 3.24.3 dão ao usuário `alpine` acesso ao `doas` sem senha. Elas são seguras na primeira inicialização, mas ficam expostas assim que um hash iniciado por `$6$` é criado na máquina, por exemplo, quando um administrador define uma senha para o console. A partir daí, um invasor pode entrar como `alpine` e usar o `doas` para obter privilégios de `root`.
Contêineres que não executam o `sshd`, sistemas com `PasswordAuthentication no` e imagens de cloud configuradas pelo cloud-init, que define essa opção, não são afetados. Também não estão vulneráveis as contas bloqueadas com `!` em `/etc/shadow` nem as máquinas sem contas com hashes de senha iniciados por `$`.
A falha não se limita ao Alpine. Em sua análise técnica, Özgün Kültekin, da Wakefield, cita OpenWrt, Buildroot e Yocto como outros sistemas baseados em musl que devem ser verificados.
O OpenWrt usa o Dropbear por padrão para conexões SSH, segundo a documentação do projeto. Kültekin afirma que o Dropbear não é afetado. No OpenWrt, o problema só pode ocorrer se um administrador instalar o servidor OpenSSH.
Como corrigir
No Alpine, é necessário atualizar o pacote e reiniciar o serviço. A atualização, por si só, não reinicia o `sshd` em execução:
- Atualize os pacotes: `apk upgrade -U -a`
- Reinicie o servidor: `rc-service sshd restart`
As versões 3.21.10, 3.22.8, 3.23.8 e 3.24.4 já incluem o pacote corrigido. As versões entre 3.16 e 3.21 não têm mais suporte, mas também receberam pacotes corrigidos.
Instâncias de cloud criadas com imagens tiny-cloud anteriores a essas versões ainda precisam da atualização ou da alteração de configuração descrita abaixo.
Quem compila o OpenSSH por conta própria deve usar a versão 10.6p2, que inclui a correção, conforme as notas de lançamento.
Se não for possível atualizar imediatamente, desativar a autenticação por senha também impede o ataque. Antes de fazer a alteração, confirme que o acesso por chave SSH está funcionando e mantenha a sessão atual aberta até conseguir entrar em uma nova sessão. Em seguida, defina `PasswordAuthentication no`, valide a configuração com `sshd -t` e reinicie o `sshd`.
O alerta recomenda adicionar a configuração em um arquivo complementar dentro de `/etc/ssh/sshd_config.d`, diretório lido pela configuração padrão do Alpine a partir da versão 3.19. As instruções também alteram para `no` todas as linhas `PasswordAuthentication` em `/etc/ssh/sshd_config`, inclusive as que estiverem dentro de um bloco `Match`. Ao final, o comando `sshd -T | grep -i passwordauthentication` deve exibir `passwordauthentication no`.
O alerta também recomenda procurar, em `/var/log/messages`, registros do `sshd` com a mensagem `Accepted password for` seguida do nome de uma conta sem senha, como `alpine`, `root` ou um usuário que aceite apenas chaves. Em máquinas expostas, também é importante revisar o uso do `doas`, os usuários criados recentemente, os arquivos e as chaves autorizadas.
“Se não for possível descartar um acesso indevido, considere a máquina comprometida”, diz o alerta.
Por que senhas longas funcionam
Sem PAM, o próprio `sshd` verifica a senha. O serviço usa a função `crypt()` da biblioteca C para transformar a senha em um hash e compara o resultado com o valor armazenado na conta.
Uma conta sem senha tem apenas `*` nesse campo. Como esse valor é curto demais para armazenar um salt, ou seja, um valor usado no cálculo do hash, o `sshd` usa o salt de outra conta que tenha um hash válido.
Para os tipos de hash `$5$` e `$6$`, a função `crypt()` da musl rejeita senhas com mais de 256 bytes e retorna `*` para indicar o erro. Esse resultado coincide com o `*` armazenado na conta sem senha, e o `sshd` aceita o acesso. O limite superior, de 1.024 bytes, é definido pelo próprio `sshd`.
Esse comportamento decorre de uma alteração feita na musl em 9 de agosto de 2012. A mudança fez com que uma chamada malsucedida a `crypt()` retornasse “um hash impossível de corresponder, em vez de NULL”, porque muitos programas não verificavam se a função havia falhado. O limite de 256 bytes foi adotado em 29 de agosto de 2012 para proteger servidores contra ataques de negação de serviço.
O uso do salt de outra conta foi introduzido em uma alteração do OpenSSH de 15 de julho de 2016, relacionada à
CVE-2016-6210
. A vulnerabilidade permitia que invasores descobrissem quais nomes de usuário existiam. Kültekin afirma que o problema está presente desde então.
A alteração incluída na versão 10.6p2 faz o `sshd` rejeitar a correspondência quando o campo armazenado tem menos de quatro caracteres. O OpenSSH chama a medida de solução provisória e afirma que a causa principal está fora do `sshd`. Os pacotes estáveis do Alpine incluem um patch para o mesmo problema.
Por que a correção saiu no dia seguinte
A equipe de Miller soube da falha no início daquela semana e lançou a correção o mais rápido possível. No anúncio da versão, ele afirmou que a equipe passou a considerar períodos prolongados de embargo perigosos e benéficos principalmente para invasores. Segundo Miller, recentemente agentes de IA redescobriram as mesmas falhas, às vezes em questão de horas.
Até aquele momento, a vulnerabilidade não tinha um identificador CVE.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...