Falha de redefinição de senha no GitLab deixa mais de 5,3 mil servidores em risco

 (scmagazine.com)
1 pontos por GN⁺ 2024-01-29 | 1 comentários | Compartilhar no WhatsApp
  • A vulnerabilidade CVE-2023-7028 no GitLab continuava presente em 5.379 servidores no mundo todo cerca de duas semanas após a divulgação do patch, podendo levar ao comprometimento remoto de contas de desenvolvedores
  • O problema está no fluxo de redefinição de senha do sistema de login, permitindo que um invasor faça com que o link de redefinição seja enviado para seu próprio endereço de e-mail não verificado, sem interação da vítima
  • O GitLab divulgou a vulnerabilidade de CVSS 10 em 11 de janeiro de 2024 e forneceu atualizações de segurança para as versões 16.5.6, 16.6.4, 16.7.2 e versões com backport de 16.1.6 a 16.4.5
  • A Shadowserver Foundation detectou 5.379 instâncias vulneráveis em 23 de janeiro, com maior concentração nos Estados Unidos (964) e na Alemanha (730); em 24 de janeiro, o total caiu para 4.652
  • Operadores de instâncias self-managed do GitLab Community Edition e Enterprise Edition devem verificar nos logs solicitações de redefinição no formato de array com múltiplos e-mails e ativar 2FA para reduzir o risco de comprometimento de contas

O risco da CVE-2023-7028

  • CVE-2023-7028 é uma vulnerabilidade no sistema de login do GitLab que pode levar ao comprometimento remoto de contas em servidores GitLab não corrigidos
  • O GitLab divulgou e corrigiu a falha pela primeira vez em 11 de janeiro de 2024
  • A pontuação CVSS da vulnerabilidade é 10, o nível máximo de gravidade
  • Com uma requisição HTTP especialmente criada, um invasor pode enviar o e-mail de redefinição de senha para seu próprio endereço de e-mail não verificado, sem interação da vítima
  • Um pesquisador que testou a falha no GitLab Community Edition 16.6.1 avaliou na AttackerKB que a CVE-2023-7028 é “muito eficaz e fácil de explorar”

Versões afetadas e patches

  • O GitLab forneceu atualizações de segurança para as seguintes versões
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • Os patches também receberam backport para as seguintes versões
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Resultados da detecção da Shadowserver

  • A Shadowserver Foundation detectou 5.379 instâncias vulneráveis do GitLab em todo o mundo em 23 de janeiro, cerca de duas semanas após a divulgação do patch
  • Por país, os Estados Unidos e a Alemanha concentravam o maior número de instâncias vulneráveis
    • Estados Unidos: 964
    • Alemanha: 730
  • Em 24 de janeiro, o número de instâncias vulneráveis no painel da Shadowserver caiu para 4.652
  • A Shadowserver afirmou que a redução em si é positiva, mas que ainda é cedo para dizer se representa uma tendência real ou apenas uma variação temporária na varredura

Como verificar indicadores de comprometimento

  • Clientes de GitLab Community Edition self-managed e GitLab Enterprise Edition devem verificar nos logs sinais de exploração da CVE-2023-7028
  • Os logs e condições a verificar são os seguintes
    • gitlab-rails/production_json.log: entre as requisições HTTP para o caminho /users/password, casos em que params.value.email seja um array JSON contendo vários endereços de e-mail
    • gitlabs-rails/audit_json.log: casos em que meta.caller.id seja PasswordsController#create e target_Details seja um array JSON contendo vários endereços de e-mail

GitLab.com, GitLab Dedicated e impacto do 2FA

  • O GitLab afirmou não ter detectado casos de exploração dessa falha em instâncias GitLab.com ou GitLab Dedicated
  • A ativação do 2FA é recomendada aos clientes
  • O 2FA impede o comprometimento de contas por meio da CVE-2023-7028, mas em instâncias não corrigidas um invasor ainda pode redefinir a senha e bloquear o usuário para fora da conta

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-29
Opiniões no Hacker News

  • Acho realmente assustadora a funcionalidade de vincular endereços de e-mail a uma conta em webapps baseados em conta
    Não conheço o histórico desse bug, mas é uma área que pentesters vão testar logo de cara, e é um tipo antigo que remonta até vulnerabilidades do início dos anos 2000 em implementações padrão de MTA Unix, nas quais era possível enganar o sistema para enviar e-mails de redefinição de senha para vários endereços
    Parece que, no GitLab, um framework web cheio de recursos acabou ressuscitando essa superfície de ataque; para leitores comuns do HN que tenham ficado interessados, vale muito a pena verificar a funcionalidade de redefinição de senha, especialmente a lógica de vinculação de e-mails
    Mesmo eu tendo a impressão de que a equipe de segurança do GitLab é bastante boa, o fato de um bug desses ter aparecido mostra como é difícil evitar essa família de bugs

    • Pelo comportamento explicado em outro comentário, esse bug parece muito fácil de evitar
      Se tivessem usado uma linguagem com tipagem estática, seria difícil isso acontecer a menos que fosse feito de propósito, e numa revisão de código teria chamado tanta atenção que talvez alguém desconfiasse que um colega estava tentando inserir um backdoor
    • É difícil dizer que a equipe de segurança do GitLab é excelente
      A funcionalidade de vincular endereços de e-mail secundários foi adicionada recentemente e nem era algo que existia desde o início, então parece que pegaram um atalho sem testar adequadamente abusos de uma nova funcionalidade relacionada à segurança de contas
      Além disso, parece que também houve um CVE com CVSS 9.6 em que uma integração permitia executar comandos com permissões de outro usuário
      Visto de fora, a velocidade de lançamento de funcionalidades parece estar à frente da velocidade em que elas podem ser testadas com segurança, talvez por dificuldade de monetização
      Do ponto de vista de negócio, dá para entender em parte, mas, se o núcleo de uma solução Git auto-hospedada é, na prática, o gerenciamento de contas, esse tipo de problema de segurança pode derrubar o próprio negócio
    • Que perspectiva estranha
      Se não for ao e-mail, deveria estar vinculado a quê? Operei por mais de 20 anos sites com uma grande base de usuários e, no começo, usávamos nomes de usuário, o que foi um desastre
      Todo mundo sabia os nomes de usuário uns dos outros, então era fácil tentar força bruta de senha ou redefinição de senha
      O problema não é usar e-mail em si, mas tornar a lógica de login e recuperação de senha complexa demais, exagerar nas abstrações, fazer overengineering e empurrar código para áreas sensíveis de segurança sem a devida verificação
      Também é preciso olhar o histórico de segurança do GitLab. Várias vezes por ano surgiam exploits críticos que exigiam upgrade emergencial das distribuições do GitLab e, em termos de segurança, o GitLab foi o pior produto que já usei
    • Sempre que recebo um e-mail de redefinição de senha indevido, fico preocupado se alguém não adicionou secretamente um endereço de e-mail de recuperação fora do meu controle para roubar minha conta
      Ainda não aconteceu comigo, mas, como este caso mostra, infelizmente é algo totalmente possível
    • Como esse exploit funciona? Se houver algum link com um texto organizado sobre isso, tenho curiosidade

  • Se você quiser ver, na base de código Rails, a parte que levou a esse exploit, o commit de correção está aqui
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • Isso parece mais uma refatoração posterior do que a correção real
      A correção parece ser esta: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      Mudou de recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? para recoverable.send_reset_password_instructions if recoverable&.persisted?
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail — então isso era uma funcionalidade?
      Mas, mesmo na versão corrigida, ainda usam o nome RecoverableByAnyEmail. As pessoas não leem o código ao redor do que estão alterando?
    • Como alguém que não conhece bem Ruby, você pode apontar onde está o erro?

  • Nós também sofremos esse ataque e vimos ele ser usado junto com um segundo “recurso” que aumentou ainda mais a exposição
    Basicamente, para esse ataque é preciso saber o e-mail do usuário cuja senha será redefinida, mas existe um endereço de e-mail oculto vinculado ao ID de usuário do GitLab. Esse ID é um número que aumenta a partir de 1
    IDs 1 ou 2 têm grande chance de serem administradores, então são bons alvos, e o e-mail tem um formato como 1-user@mail.noreply..
    Foi realmente ruim e parecia automatizado. Aqui, o que nos salvou foi o 2FA

  • Redefinição de senha por e-mail é um pesadelo de segurança mesmo quando implementada corretamente
    Pior ainda é que, na maioria dos serviços, não dá para desativar, e a forma de contornar costuma ser apenas SSO Enterprise
    Alguns serviços permitem configurar um número de telefone para tokens por SMS, mas nunca vi um modelo que exija tanto e-mail quanto token por SMS

    • Tenho curiosidade sobre em que sentido você considera isso um pesadelo de segurança

  • Isso me lembra um bug em que era possível fazer força bruta em contas colocando um array de senhas no formulário de login
    Por acaso era a interface web malfeita de um equipamento de spam, e não sei se era intencional ou se era código feito por um iniciante em PHP
    Um usuário cuja senha continha caracteres especiais, algo raro na época, descobriu isso

    • Ruby on Rails, quando recebe um array como parâmetro de .where(...) do ORM, trata os valores do array como uma condição OR
      Então, se o código fosse algo como User.where(name: name, password: password), parece totalmente possível que isso acontecesse

  • Um bom lembrete de que serviços internos como o GitLab devem ficar atrás de uma VPN, acessíveis apenas a usuários confiáveis

    • Eu realmente não entendo por que colocar controle de versão interno e CI/CD na internet pública
      É exatamente para esse tipo de uso que VPN existe
    • Exato, nós sobrevivemos graças a isso, e também tínhamos alguns outros mecanismos
      Trabalho em uma grande operadora estatal de telecomunicações, e o pessoal de redes é realmente excelente. Eles impedem que o pessoal de servidores passe dos limites
      Acabamos expondo o GitLab em certa medida para projetos externos específicos e consultores, mas ainda assim ele não fica livremente acessível pela internet
      Os usuários também são gerenciados pelo AD, então nem existe conexão SMTP para redefinição de senha
      Mas precisamos reforçar mais a exigência de 2FA. Hoje deixamos que cada projeto defina suas próprias regras de 2FA

  • Sinceramente, eu não colocaria nenhum servidor interno na internet pública
    É melhor permitir acesso apenas via VPN e ter uma segunda linha de defesa

    • Especialmente algo como o GitLab pode ganhar muito com integrações externas que precisam chamar a API do GitLab
      Até seria possível colocar exatamente essas requisições em uma lista de permissões, mas isso pode ser bem trabalhoso
    • O GitLab é minha escolha favorita para operar um forge de código: git.drk.sc
      Concordo em usar táticas mais defensivas em ambientes de alta segurança, mas acho que software deve ser projetado para aguentar também a web pública
    • Sim, especialmente se a empresa usa um GitLab auto-hospedado, ele sempre deveria ficar atrás da VPN da empresa

  • Automatizar atualizações do GitLab é realmente fácil
    Para citar só uma forma, se você usa o GitLab com Docker+Compose, ele é muito estável, e uma ferramenta como o Watchtower pode atualizá-lo diariamente
    Tenho dois servidores GitLab rodando assim há mais de 7 anos e nunca tive nenhum problema
    Vejo tantos GitLab desatualizados por aí que fico me perguntando o que esses administradores estão fazendo

  • Gostaria que parassem de fingir que Ruby/Rails é uma boa escolha para software que precisa ser seguro
    Entendo que o GitLab já está nisso e precisa lidar com a situação, mas, daqui para frente, deveríamos parar de fingir que linguagens e frameworks que priorizam esperteza e fluxos de controle ocultos são melhores do que alternativas mais tediosas
    Se pareço irritado demais, é porque preciso lidar com uma base de código Ruby em produção
    Como alguém achou que 17 camadas de abstração tornariam o código super extensível, vejo muitos cenários em que problemas parecidos estão só esperando para serem explorados

    • Acho melhor evitar linguagens ou frameworks que permitem ao chamador especificar um parâmetro como string ou como array de strings
      O custo desse único erro provavelmente supera todo o valor obtido com o uso desse recurso

  • Mais um lembrete para sempre usar SSO e 2FA