0x30 Notas preliminares

0x40 Montagem do Lab

0x41 Construção

• Pré-instalar docker e docker-compose no host
• Clonar este repositório: git clone https://github.com/lyy289065406/CVE-2020-13277
• Gerar o par de chaves de crack: ./keygen.sh ou ./keygen.ps1
• Construir e executar o Gitlab (garanta que a porta 80 não esteja em uso): ./run.sh ou ./run.ps1
• Após cerca de 5 minutos, é possível acessar o Gitlab pelo navegador: http://127.0.0.1 (no primeiro login, é necessário redefinir a senha da conta de administrador root)

0x42 Crack

Ao gerar o par de chaves de crack anteriormente, a chave pública já foi gravada no backend do contêiner Gitlab; agora é necessário enviar a chave privada pelo frontend para o Gitlab para concluir o crack:

• O par de chaves é gerado no diretório ./gitlab/keys/; copie o conteúdo de .gitlab-license (a chave privada)
• Com o usuário root, abra a página http://127.0.0.1/admin/license/new
• Selecione Enter license key, cole a chave privada e clique no botão Upload license para concluir o crack

Neste ponto, o recurso Mirror Repository - Pull foi ativado

0x43 Configuração de saída (Outbound)

• Com o usuário root, abra a página http://127.0.0.1/admin/application_settings
• Encontre Outbound requests na parte inferior, marque Allow requests to the local network from hooks and services e salve

Neste ponto, o Mirror Repository - Pull já suporta puxar Repository local

0x44 Configurar Runner

• Com o usuário root, abra a página http://127.0.0.1/admin/runners
• Encontre o registration token e copie
• Registre o Runner: ./register.sh $TOKEN ou ./register.ps1 $TOKEN

Neste ponto, todos os Repository podem usar este Runner para executar scripts de CI (Pipeline Jobs)

0x50 Verificação do Lab

O processo de verificação pode consultar a Issue oficial, mas o processo abaixo ajusta alguns passos de acordo com este lab

0x51 Pré-criar contas para verificação

Com o usuário root, abra a página http://127.0.0.1/admin/users e crie 3 contas:

• victim: conta da vítima
• attacker1: conta do atacante 1
• attacker2: conta do atacante 2

Ao criar a conta, não é possível definir uma senha inicial; o Gitlab envia a senha inicial para o Email configurado. Para facilitar, você pode preencher qualquer Email, criar a conta e em seguida editar a conta imediatamente; nesse momento é possível usar root para definir a senha inicial dessa conta, sem precisar do Email

0x52 Pré-criar o repositório da vítima

• Faça login no Gitlab com a conta victim
• Crie um novo repositório New Project:
  • Name: target
  • Visibility Level: Private
• Dentro do repositório, crie um arquivo README.md e defina o conteúdo como mykey is abcxyz

Obviamente, target é o repositório privado de victim, e nosso objetivo é usar a vulnerabilidade para obter o conteúdo desse repositório

0x53 Criar o repositório poc do atacante

• Faça login no Gitlab com a conta attacker1
• Crie um novo repositório New Project:
  • Name: poc
  • Visibility Level: Public
• Dentro do repositório, crie um arquivo .gitlab-ci.yml com o seguinte conteúdo:

【Propósito】Nas próximas etapas, algumas técnicas farão com que victim, sem saber, execute este script de CI usando suas permissões.

Como o lab atual não possui certificado configurado, só é possível usar o protocolo http; além disso, 172.168.30.2 é o IP atribuído ao contêiner Gitlab pelo docker-compose.yml. Como este script de CI será executado pelo Runner, e o Runner e o Gitlab neste lab não estão no mesmo contêiner, é necessário usar o endereço IP atribuído pelo Docker

0x53 Criar o repositório espelho poc do atacante

• Faça login no Gitlab com a conta attacker2
• Crie um novo grupo New Group:
  • Name: test
  • Visibility Level: Public
• Dentro do grupo test, crie um repositório completamente vazio New Project:
  • Name: poc
  • Visibility Level: Public

Configure o repositório espelho em Settings => Repository => Pull from a remote repository:

• Mirror repository: marque
• Git repository URL: preencha com http://GITLAB/attacker1/poc
• Password: (deixe em branco; o repositório de origem do Pull é Public, não precisa de senha)
• Trigger pipelines for mirror updates: marque (dispara a execução do script de CI durante a sincronização do espelho)

Após a configuração, a cada 30 minutos o repositório de origem é verificado para ver se houve alterações; se houver, a sincronização é forçada.

A Git repository URL aponta para o repositório poc criado anteriormente. Não se usa 127.0.0.1 porque o Pull proíbe puxar repositórios locais, mas é possível contornar usando DNS: GITLAB é o hostname atribuído ao contêiner Gitlab pelo docker-compose.yml e, por padrão, é configurado no /etc/hosts. Embora o host não consiga resolver GITLAB, dentro do contêiner é equivalente a acessar http://127.0.0.1/attacker1/poc

0x54 Transferir à força a propriedade do repositório espelho poc para a vítima

• Continue usando a conta attacker2
• Abra a página http://127.0.0.1/groups/test/-/group_members para gerenciar os usuários do grupo test
• Adicione o usuário victim ao grupo:
  • Add new member to test: victim
  • Permissions: Owner
  • Expiration date: (deixe em branco, ou seja, sem prazo)
• Clique no avatar da conta no canto superior direito => Setting => Account => Delete account para excluir a conta atual (attacker2)

【Propósito】No grupo test, há apenas dois Owner: victim e attacker2. Quando o usuário attacker2 for excluído, a propriedade do grupo test e de todos os repositórios sob ele será transferida à força para victim. Como atualmente há um repositório test/poc sob o grupo test, espelhado a partir de attacker1/poc, isso equivale a transferir à força o repositório test/poc para o usuário victim.

0x55 Executar o ataque

Vamos primeiro organizar a situação atual até aqui:

• O atacante criou, à força e secretamente, um repositório test/poc para a vítima victim
• O conteúdo do repositório test/poc é sincronizado por espelhamento a partir do repositório attacker1/poc (a cada 30 minutos é verificado se houve alterações que precisam ser sincronizadas)
• O conteúdo do repositório attacker1/poc é controlado pelo atacante, incluindo o script de CI .gitlab-ci.yml
• Como o repositório test/poc tem Trigger pipelines for mirror updates habilitado, o script de CI é executado a cada sincronização
• Como o Owner do repositório test/poc é victim, o script de CI é executado com as permissões de victim

Revisando o conteúdo do script de CI .gitlab-ci.yml configurado anteriormente, este poc usa as permissões de victim no Runner para acessar a estrutura de diretórios e o README.md do repositório privado target de victim:

Em seguida, o atacante só precisa modificar arbitrariamente algum conteúdo irrelevante no repositório attacker1/poc; no pior caso, basta esperar 30 minutos para executar o script de CI definido com as permissões de victim.

Embora o atacante não tenha permissão direta para acessar os resultados da execução dos Pipeline Jobs, basta ajustar o destino de saída do script, por exemplo enviando o conteúdo do repositório para um Email ou servidor FTP especificado, para roubar o código do repositório.