Usuários do GitLab sem 2FA vulneráveis ​​a invasões de contas • Strong The One

Os administradores do GitLab devem aplicar o lote mais recente de patches de segurança imediatamente, dada a nova vulnerabilidade crítica de desvio de conta que acabamos de divulgar.

Rastreado como CVE-2023-7028, o bug de gravidade máxima explora uma mudança introduzida na versão 16.1.0 em maio de 2023 que permitia aos usuários emitir redefinições de senha por meio de um endereço de e-mail secundário.

Os invasores que visam instâncias vulneráveis ​​do GitLab autogerenciadas podem usar uma solicitação HTTP especialmente criada para enviar um e-mail de redefinição de senha para um endereço de e-mail não verificado e controlado pelo invasor.

Um invasor pode concluir a aquisição sem qualquer intervenção do usuário, e aqueles que não ativaram a autenticação de dois fatores (2FA) são os principais alvos do crime oportunista.

Os usuários com 2FA habilitado não são vulneráveis ​​ao controle de conta, a menos que o invasor também tenha controle do autenticador 2FA, mas uma redefinição de senha ainda pode ser conseguida.

O GitLab não oferece suporte a 2FA baseado em SMS – a implementação mais comumente sequestrada – apenas oferece suporte a 2FA baseado em aplicativo ou emitido por meio de um dispositivo WebAuthn, que é muito mais seguro.

Existem, no entanto, algumas versões das edições Community e Enterprise do GitLab que foram afetadas e exigirão correção o mais rápido possível:

• 16.1 a 16.1.5

• 16.2 a 16.2.8

• 16.3 a 16.3.6

• 16.4 a 16.4.4

• 16,5 a 16,5,5

• 16.6 a 16.6.3

• 16,7 a 16.7.1

Todos os mecanismos de autenticação são afetados aqui, disse o GitLab, mesmo alguns daqueles que usam logon único (SSO).

“Usuários sem aplicação de SSO são vulneráveis”, disse o GitLab em seu comunicado. “Se sua configuração permitir que um nome de usuário e uma senha sejam usados ​​além das opções de SSO, você será afetado. Desativando todas as opções de autenticação de senha via https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#password -authentication-enabled mitigará a vulnerabilidade para clientes autogerenciados que possuem um provedor de identidade externo configurado, pois isso desabilitará a capacidade de realizar redefinição de senha.”

Felizmente, no momento da divulgação, não havia nenhuma evidência que sugerisse que o bug tivesse sido explorado com sucesso, mas como sempre, quando uma vulnerabilidade é tornada pública, com uma exploração tão simples como esta, são prováveis ​​tentativas de exploração mais amplas e torna-se uma corrida. contra os invasores para corrigir a falha.

Como os administradores precisarão de tempo para aplicar patches, sem pular as paradas de atualização para evitar a manifestação de problemas de instabilidade, uma mitigação mais rápida seria impor o 2FA em todas as contas, pois isso, na grande maioria dos casos, evitará tentativas de controle de contas.

Idealmente, uma vez ativado, ele permanecerá ativado para sempre, especialmente para contas importantes, como aquelas com privilégios de administrador.

Só precisamos olhar para a semana passada para aprender o valor de habilitar 2FA – até mesmo os maiores nomes da segurança se atrapalham com o básico de vez em quando.

A aquisição de uma conta GitLab pode significar um negócio sério para os invasores, dada a quantidade de propriedade intelectual e código-fonte pertencente a organizações mantidas na plataforma DevOps.

O GitLab disse que os clientes podem verificar seus registros em busca de sinais de exploração, destacando dois que revelarão qualquer atividade nefasta:

• Verifique gitlab-rails/production_json.log para solicitações HTTP para o /users/password caminho com params.value.email consistindo em uma matriz JSON com vários endereços de e-mail.

• Verifique gitlab-rails/audit_json.log para entradas com meta.caller_id de PasswordsController#create e target_details consistindo em uma matriz JSON com vários endereços de e-mail.

Desde que a vulnerabilidade foi trazida à atenção do GitLab por meio de seu programa de recompensas de bugs, a empresa adicionou novos testes para validar a lógica de redefinição de senha para evitar que vulnerabilidades semelhantes ocorram no futuro.

Também iniciou um processo de análise de causa raiz que espera gerar ações adicionais de acompanhamento a serem implementadas, bem como atualizar sua documentação para melhorar a conscientização do problema para os engenheiros.

Uma segunda vulnerabilidade crítica também foi abordada na mesma rodada de patches. CVE-2023-5356 recebeu uma pontuação CVSS de 9,6 e permite que invasores executem comandos de barra no Slack ou Mattermost.

Embora não seja tão grave quanto o controle de uma conta, uma exploração bem-sucedida pode proporcionar aos invasores a oportunidade de se adicionarem aos canais, expondo potencialmente o trabalho secreto de uma organização a partes não autorizadas.

Organizações com aplicativos personalizados e integrações que usam comandos de barra também podem vazar dados confidenciais, dependendo de sua função, por exemplo.

Outras soluções menos severas também incluem:

• CVE-2023-4812: Um problema foi descoberto no GitLab afetando todas as versões a partir de 15.3 antes de 16.5.5, todas as versões a partir de 16.6 antes de 16.6.4, todas as versões a partir de 16.7 antes de 16.7.2. A aprovação necessária de CODEOWNERS pode ser ignorada adicionando alterações a uma solicitação de mesclagem previamente aprovada.

• CVE-2023-6955: Existe uma vulnerabilidade de controle de acesso impróprio no GitLab Remote Development afetando todas as versões anteriores a 16.5.6, 16.6 anteriores a 16.6.4 e 16.7 anteriores a 16.7.2. Esta condição permite que um invasor crie um espaço de trabalho em um grupo associado a um agente de outro grupo.

• CVE-2023-2030: um problema foi descoberto no GitLab CE/EE afetando todas as versões de 12.2 anteriores a 16.5.6, 16.6 anteriores a 16.6.4 e 16.7 anteriores a 16.7.2 em que um invasor poderia potencialmente modificar os metadados de commits assinados. ®