- Os invasores simplesmente não cederão e encontrarão novas maneiras engenhosas de se infiltrar em nosso espaço pessoal.
- Os especialistas em segurança expuseram outra vulnerabilidade do GitLab que é ativamente explorada em liberdade.
- Isso foi possível porque esta versão do GitLab CE realmente permite o registro do usuário por padrão.
- Terceiros podem abusar da funcionalidade de upload e executar comandos arbitrários do sistema operacional remotamente.
Parece que não importa até que ponto as empresas estão dispostas a ir para proteger seus produtos, os invasores estão sempre um passo à frente e encontram maneiras engenhosas de contornar toda a proteção.
Neste mundo on-line em constante mudança, manter seus dados confidenciais protegidos está cada vez mais difícil e estamos aqui para informá-lo sobre outra vulnerabilidade que está sendo explorada ativamente em o selvagem.
Outra vulnerabilidade do GitLab explorada ativamente em estado selvagem
De acordo com a HN Security, duas contas de usuário suspeitas com direitos de administrador foram encontradas no servidor GitLab CE exposto à Internet.
Aparentemente, esses dois usuários foram registrados entre junho e julho de 2021, com nomes de usuário de aparência aleatória. Isso foi possível porque esta versão do GitLab CE permite o registro do usuário por padrão.
Além disso, o endereço de e-mail fornecido durante o registro não é verificado por padrão. Isso significa que o usuário recém-criado é conectado automaticamente sem quaisquer etapas adicionais.
Para tornar as coisas mais complicadas, absolutamente nenhuma notificação é enviada aos administradores.
Um dos anexos carregados chamou a atenção dos especialistas, então eles configuraram seu próprio servidor GitLab e realmente tentaram replicar o que observaram na natureza.
Um exploit lançado recentemente para CVE-2021-22205 abusa da funcionalidade de upload para executar remotamente comandos arbitrários do sistema operacional.
A vulnerabilidade mencionada acima reside no ExifTool, uma ferramenta de código aberto usada para remover metadados de imagens, que falha na análise de certos metadados incorporados na imagem enviada.
O GitLab é composto de vários elementos, como Redis e Nginx. Aquele que lida com uploads é chamado gitlab-workhorse, que por sua vez chama ExifTool antes de passar o anexo final para Rails.
Indo mais fundo nos logs, algumas evidências descobertas de dois uploads com falha nos logs do Workhorse.
Esta carga útil usada pelo exploit público pode executar um shell reverso, enquanto o usado contra nosso cliente simplesmente escalou os direitos dos dois usuários registrados anteriormente para admin.
echo 'user = User.find_by (username: "czxvcxbxcvbnvcxvbxv"); user.admin = "true"; user.save!' | gitlab-rails console / usr / bin / echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmU | base64 -d | / usr / bin / gitlab-rails consoleEntão, basicamente, o que parecia ser uma vulnerabilidade de escalonamento de privilégios, acabou se revelando uma vulnerabilidade RCE.
Como os especialistas em segurança explicaram, todo o processo de exploração se resume a apenas duas solicitações.
Em uma instalação GitLab padrão (até a versão 13.10.2), não há necessidade de abusar da API para encontrar um projeto válido, não há necessidade de abrir um problema e o mais importante não há necessidade de autenticar.
Todas as vulnerabilidades descritas no artigo (ExifTool, abuso de API, registro de usuário, etc.) não estão presentes na versão mais recente do GitLab CE no momento da escrita.
No entanto, é altamente recomendável ter cuidado ao lidar com qualquer coisa que envolva você estar on-line, para que você não tenha experiências infelizes.
Qual é a sua opinião sobre esta situação? Compartilhe sua opinião conosco na seção de comentários abaixo.
