Bug de redefinição de senha do GitLab deixa mais de 5,3 mil servidores à mercê

Artigo original ↗ Discussão no Hacker News ↗

Uma vulnerabilidade crítica do GitLab (CVE-2023-7028) permitia que atacantes acionassem e-mails de redefinição de senha tanto para o endereço da vítima quanto para o seu próprio, abusando de como a aplicação baseada em Rails lidava com múltiplos parâmetros de e-mail, potencialmente expondo milhares de servidores auto-hospedados. Os comentários usam o caso para destacar armadilhas antigas na recuperação de senha baseada em e-mail, frameworks web sem segurança de tipos e desenvolvimento apressado de funcionalidades, ao mesmo tempo em que enfatizam mitigadores como validação rígida no backend, acesso apenas via VPN, SSO e 2FA obrigatório.

Mecânica do exploit e causa raiz

  • Bug central: o endpoint de redefinição de senha aceitava múltiplos parâmetros email (um array).
  • O GitLab procurava um usuário por um e-mail, mas então enviava códigos de redefinição para todos os endereços fornecidos, incluindo os controlados pelo atacante.
  • Exemplo de payload: user[email][][email protected]&user[email][][email protected].
  • Correção: enviar instruções de redefinição usando o e-mail armazenado no registro do usuário, não o valor fornecido pelo usuário, e buscar os endereços a partir do próprio objeto “recoverable”.
  • O recurso “RecoverableByAnyEmail” (originalmente pensado para qualquer/qualquer e-mail verificado) é visto como conceitualmente perigoso, e seu nome recebeu críticas.

Redefinição de senha e design do identificador da conta

  • Muitos consideram fluxos de redefinição baseados em e-mail “assustadores” e uma fonte antiga de bugs, especialmente em recursos de “associar e-mail secundário”.
  • Design recomendado: tratar ID da conta e e-mail como distintos; usar o ID da conta internamente e derivar o e-mail apenas do banco de dados, nunca de parâmetros da requisição.
  • Alguns sugerem nomes de usuário ou exigir tanto nome de usuário quanto e-mail para recuperação; outros observam os trade-offs de usabilidade e a aversão dos usuários a mais atrito.
  • Aliases de e-mail (+tag) podem ajudar a ocultar identificadores reais, mas podem criar problemas de UX e colisões quando serviços canonicalizam endereços de forma diferente dos provedores de e-mail.

E-mail como um canal de segurança fraco

  • O e-mail é criticado como inseguro: fácil de encaminhar ou vazar tokens, validação de remetente parcial e inconsistente, sem criptografia ponta a ponta por padrão, canonicalização ambígua e forte dependência da segurança de uma única caixa de entrada.
  • Se uma conta de e-mail ou seu domínio for sequestrado ou re-registrado, muitos serviços vinculados tornam-se trivialmente comprometíveis.
  • Alguns querem a opção de exigir múltiplos fatores para redefinição (por exemplo, e-mail + SMS), mas relatam que isso raramente é suportado.

Segurança e qualidade de engenharia do GitLab

  • As opiniões divergem:
    • Um lado argumenta que bugs críticos são inevitáveis mesmo com equipes de segurança fortes, e que a abertura do GitLab torna os problemas mais visíveis.
    • Outros veem CVEs de alto impacto recorrentes, entrega apressada de recursos, upgrades dolorosos e bugs antigos de CI/UX como sinais de uma cultura de engenharia fraca ou subfinanciamento.

Debates de linguagem/framework e design

  • Vários culpam o tratamento flexível de parâmetros do Rails/Ruby (arrays vs. escalares) e abstrações “espertas”.
  • Outros rebatem que bugs lógicos semelhantes ocorrem em stacks tipados estaticamente (Java/C#) e que nenhum ecossistema mainstream tem um histórico limpo de segurança.
  • Tipagem mais forte e APIs mais seguras (por exemplo, getlist do Django, construtores de consultas tipados) são citadas como formas de transformar alguns erros lógicos em falhas em tempo de compilação.

Mitigações operacionais e práticas de implantação

  • Muitos argumentam que o GitLab não deveria estar exposto diretamente à internet pública; em vez disso, deve ficar atrás de VPN/SSO, usar 2FA e integrar-se à identidade corporativa (por exemplo, AD).
  • Alguns relatam que 2FA e exposição externa limitada mitigaram este incidente para eles.
  • Outros observam que atualizações automatizadas e frequentes do GitLab (por exemplo, via contêineres e ferramentas como Watchtower) podem reduzir a janela de ataque, e questionam por que tantas instâncias continuam desatualizadas.