CVE-2020-13277

Lab CVE-2020-13277: Vulnerabilidade lógica do Gitlab - Acesso não autorizado de qualquer usuário a repositórios privados

---

0x10 Ambiente do Lab

0x20 Estrutura de diretórios

CVE-2020-13277
├── README.md ............... [此 README 说明]
├── imgs .................... [辅助 README 说明的图片]
├── gitlab .................. [Gitlab 容器的挂载目录]
│   ├── Dockerfile .......... [Gitlab 的 Docker 构建文件]
│   ├── config .............. [Gitlab 配置挂载目录]
│   ├── data ................ [Gitlab 数据挂载目录]
│   ├── logs ................ [Gitlab 日志挂载目录]
│   ├── keys ................ [Gitlab 破解 License 存储目录]
│   └── runner .............. [Runner 容器的挂载目录]
├── license ................. [破解 License 的容器构建目录]
│   ├── Dockerfile .......... [License 的 Docker 构建文件]
│   └── license.rb .......... [生成破解 License 的 Ruby 脚本]
├── docker-compose.yml ...... [Docker 的构建配置]
├── keygen.ps1 .............. [Windows: 一键生成破解 License]
├── keygen.sh ............... [Linux:   一键生成破解 License]
├── run.ps1 ................. [Windows: 一键运行 Gitlab 靶场]
├── run.sh .................. [Linux:   一键运行 Gitlab 靶场]
├── register.ps1 ............ [Windows: 一键注册 Runner]
├── register.sh ............. [Linux:   一键注册 Runner]
├── stop.ps1 ................ [Windows: 一键停止 Gitlab 靶场]
└── stop.sh ................. [Linux:   一键停止 Gitlab 靶场]

0x30 Notas preliminares

Sobre o critério de escolha da versão do Docker Image do lab

O núcleo desta vulnerabilidade utiliza principalmente o Mirror Repository - o recurso de sincronização/backup de repositórios espelhados.

A direção de sincronização do Mirror é dividida em dois tipos:

• Pull: puxa o conteúdo de um Repository especificado para o Repository atual
• Push: envia o conteúdo do Repository atual para um Repository especificado

Esta vulnerabilidade explora o Mirror Repository na direção Pull

Saiba que o Gitlab é dividido em duas versões: CE (Community Edition gratuita) e EE (Enterprise Edition paga), e o Gitlab também afirma oficialmente que esta vulnerabilidade afeta as seguintes versões de CE e EE:

• >=10.6, <12.9.10
• >=12.10, <12.10.11
• >=13.0, <13.0.6

Mas isso não significa que o Gitlab Docker Image dessas versões possa ser usado para montar o lab, porque:

• A versão CE do Mirror Repository tem apenas a direção Push
• A versão EE é subdividida em quatro edições: Core, Starter, Premium e Ultimate. Pela tabela de comparação de funcionalidades fornecida oficialmente: apenas a edição Core não possui a direção Pull, e todas as Docker Images do Gitlab-EE fornecem apenas a edição Core

Em outras palavras, para montar o lab com Docker, só é possível usar a versão Gitlab-EE e crackeá-la (os ricos também podem optar por comprar uma License) para ativar o recurso Mirror Repository - Pull.

Mas mesmo com o Gitlab-EE crackeado, seja 10.x, 12.x ou 13.x, quando a URL do Mirror Repository - Pull contém um caminho local, ocorre o erro Import url is blocked: Requests to localhost are not allowed.

Embora seja possível configurar uma URL local ativando Allow requests to the local network from hooks and services em Admin area => Settings => Network => Outbound requests, ao sincronizar o espelho ocorre o erro 2:Fetching remote upstream failed: fatal: unable to access http://127.0.0.1/xxxx/: The requested URL returned error: 301. Em outras palavras, apenas o Pull Remote Repository é utilizável.

Porém, felizmente, embora 12.x e 13.x tenham métodos de validação de URL local muito rigorosos, na versão 10.x há uma forma de contornar: ao configurar a Pull URL, basta usar o nome do serviço DNS configurado localmente para contornar a restrição.

Diante disso, só é possível construir este lab usando a Docker Image da versão gitlab-ee:10.6.0-ee.0.

Na verdade, pela descrição anterior, também se percebe que as condições de exploração desta vulnerabilidade são bastante restritas; basicamente, é muito difícil alguém sem recursos ser afetado por ela.

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: