Servidores sem patch para a vulnerabilidade GitLab CVE-2023-7028
- A vulnerabilidade crítica CVE-2023-7028 do GitLab seguia sem patch em mais de 5.300 servidores até terça-feira, o que pode permitir o sequestro remoto de contas de desenvolvedores de software.
- O bug recebeu a pontuação máxima de 10 no CVSS, e o GitLab o divulgou e corrigiu pela primeira vez em 11 de janeiro.
- Devido a uma vulnerabilidade no sistema de login do GitLab, um invasor pode enviar um link de redefinição de senha para um endereço de e-mail não autenticado sem qualquer interação da vítima.
Informações de patch e resultados de testes da vulnerabilidade
- Atualizações de segurança foram lançadas para as versões 16.5.6, 16.6.4 e 16.7.2 do GitLab, com backports também para as versões 16.1.6, 16.2.9, 16.3.7 e 16.4.5.
- Um pesquisador testou o bug na versão 16.6.1 do GitLab Community Edition e compartilhou no AttackerKB que ele é "muito eficaz e fácil de explorar".
Detecção de instâncias vulneráveis e tendência de redução
- Quase duas semanas após a disponibilização do patch, a Shadowserver Foundation detectou 5.379 instâncias vulneráveis do GitLab em todo o mundo.
- Os Estados Unidos e a Alemanha tinham o maior número de instâncias vulneráveis, com 964 e 730, respectivamente.
- A ferramenta de dashboard da Shadowserver mostrou que, em 24 de janeiro, o número de instâncias vulneráveis caiu para 4.652.
- Em confirmação à SC Media, um porta-voz da Shadowserver afirmou que a redução das instâncias vulneráveis é um avanço positivo, mas que é necessário mais tempo para determinar se essa queda é uma tendência ou apenas uma flutuação pontual.
Indicadores de comprometimento do GitLab CVE-2023-7028
- Clientes do GitLab com instâncias autogerenciadas do GitLab Community Edition e do GitLab Enterprise Edition devem revisar os logs para verificar se houve exploração do CVE-2023-7028.
- É preciso verificar solicitações HTTP para o caminho
/users/password em gitlab-rails/production_json.log e confirmar se params.value.email está composto por um array JSON com vários endereços de e-mail.
- Também é preciso verificar entradas em
gitlabs-rails/audit_json.log nas quais meta.caller.id seja PasswordsController#create e target_Details esteja composto por um array JSON com vários endereços de e-mail.
- Nenhuma exploração desse bug foi detectada no GitLab.com nem em instâncias dedicadas do GitLab.
- O GitLab também recomenda ativar a autenticação de dois fatores (2FA), que evita o sequestro de conta por meio do CVE-2023-7028, embora usuários de instâncias sem patch ainda corram o risco de ficar bloqueados fora da conta caso um invasor explore a vulnerabilidade para redefinir a senha.
Opinião do GN⁺
- Este artigo traz informações importantes sobre uma vulnerabilidade crítica de segurança no GitLab. O CVE-2023-7028 pode representar uma ameaça direta à segurança das contas de desenvolvedores de software, exigindo medidas adequadas.
- Apesar da disponibilização do patch, um grande número de servidores no mundo todo continua vulnerável, destacando a importância da conscientização em segurança e da aplicação de atualizações em tempo hábil.
- O texto reforça a importância da autenticação de dois fatores (2FA) e incentiva os usuários a adotar medidas adicionais de segurança, ajudando a ampliar a conscientização sobre proteção de contas.
1 comentários
Comentários do Hacker News
"Quero falar sobre o perigo do recurso de 'vincular endereço de e-mail à conta' em aplicativos web baseados em contas. Esse é um dos primeiros pontos que pentesters tentam manipular imediatamente, e vulnerabilidades desse tipo vêm sendo encontradas desde o começo dos anos 2000. Esse problema também se repetiu no GitLab. O GitLab tem uma excelente equipe de segurança, mas parece ser difícil evitar esse tipo de bug. Se você é um leitor comum do Hacker News interessado nessa história, recomendo verificar sua própria funcionalidade de redefinição de senha, especialmente a lógica de vinculação de e-mail."
"Compartilho o link do commit em que essa vulnerabilidade foi encontrada na base de código Rails: link do commit do GitLab"
"Fui afetado por esse bug. O ataque exige saber o e-mail do usuário, mas existe um endereço de e-mail oculto vinculado ao ID de usuário do GitLab (um número crescente a partir de 1). Os IDs 1 ou 2 provavelmente pertencem a administradores, então são bons alvos. O formato do e-mail é '1-user@mail.noreply.<gitlabhost>'. Parecia um ataque automatizado, e o 2FA nos salvou."
"A redefinição de senha por e-mail é um pesadelo de segurança mesmo quando implementada corretamente. Na maioria dos serviços, não é possível desativar esse recurso, e a alternativa muitas vezes é apenas SSO corporativo. Em alguns serviços, dá para configurar um número de telefone para token por SMS, mas nunca vi uma opção que exija tanto e-mail quanto token por SMS."
"Uma vez encontrei um bug em que era possível fazer brute force em contas inserindo um array de senhas no formulário de login. Era uma interface web bem tosca para um appliance de spam, e não tenho certeza se aquilo era intencional ou se um iniciante em PHP escreveu o código. Foi um usuário que usava uma senha com caracteres especiais na época que descobriu isso."
"Isso serve de lembrete de que serviços internos como o GitLab deveriam operar atrás de uma VPN acessível apenas a usuários confiáveis."
"Automatizar atualizações do GitLab é muito fácil. Basta usar GitLab com Docker+Compose e atualizar diariamente com algo como o Watchtower. Administro servidores GitLab há mais de 7 anos desse jeito e nunca tive problemas. Quando olho ao redor, vejo muitos GitLabs desatualizados — o que os administradores estão fazendo?"
"Tenho como princípio não expor à internet pública nenhum tipo de servidor interno. Deixo o acesso disponível apenas via VPN para criar uma segunda linha de defesa."
"Mais um lembrete de que é preciso sempre usar SSO e não esquecer de usar 2FA."
"Vamos parar de achar que Ruby/Rails é uma escolha adequada para software que precisa ser seguro. Entendo que o GitLab tenha de lidar com isso, mas precisamos admitir daqui para frente que o simples é melhor do que linguagens e frameworks que priorizam fluxo de controle inteligente e oculto. Trabalho em uma base de código Ruby em produção e consigo ver claramente como problemas parecidos podem surgir por causa de alguém que acha que várias camadas de abstração tornam o código extremamente extensível."