CVE-2020-13277

Lab CVE-2020-13277: vulnerabilità logica di GitLab - accesso non autorizzato di qualsiasi utente a repository privati

---

0x10 Ambiente del lab

0x20 Struttura delle directory

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 Note preliminari

Motivazione della scelta della versione dell'immagine Docker del lab

Il cuore di questa vulnerabilità è principalmente lo sfruttamento della funzione di backup e sincronizzazione a specchio dei repository, Mirror Repository.

La direzione di sincronizzazione del Mirror si divide in due tipi:

• Pull: porta il contenuto del Repository specificato nel Repository corrente
• Push: spinge il contenuto del Repository corrente nel Repository specificato

Questa vulnerabilità sfrutta il Mirror Repository in direzione Pull

Da notare che GitLab è disponibile in due versioni: CE (Community Edition gratuita) e EE (Enterprise Edition a pagamento), e GitLab ha dichiarato ufficialmente che questa vulnerabilità colpisce sia CE che EE nelle seguenti versioni:

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

Ma ciò non significa che tutte queste versioni delle Gitlab Docker Image possano essere usate per allestire il lab, perché:

• Nella versione CE il Mirror Repository supporta solo la direzione Push
• La versione EE si suddivide ulteriormente in quattro edizioni: Core, Starter, Premium e Ultimate; dalla tabella comparativa delle funzionalità fornita ufficialmente risulta che solo l'edizione Core non dispone della direzione Pull, e le Gitlab-EE Docker Image forniscono esclusivamente l'edizione Core

In altre parole, per allestire il lab con Docker si può scegliere solo la versione GitLab-EE e crackarla (chi ha molti soldi può anche scegliere di acquistare una License) per attivare la funzionalità Mirror Repository - Pull.

Ma anche dopo aver crackato GitLab-EE, sia con 10.x, 12.x che 13.x, quando l'URL di Mirror Repository - Pull contiene un percorso locale, viene restituito l'errore Import url is blocked: Requests to localhost are not allowed.

Sebbene dopo aver impostato Allow requests to the local network from hooks and services in Admin area => Settings => Network => Outbound requests sia possibile configurare URL locali, durante la sincronizzazione dello specchio si ottiene l'errore 2:Fetching remote upstream failed: fatal: unable to access http://127.0.0.1/xxxx/: The requested URL returned error: 301. In altre parole, è utilizzabile solo il Pull del Remote Repository.

Fortunatamente, sebbene 12.x e 13.x abbiano metodi di rilevamento degli URL locali molto severi, la versione 10.x offre una soluzione: quando si configura l'URL di Pull, basta usare il nome del servizio DNS configurato localmente per aggirare il blocco.

In conclusione, l'unica opzione possibile è costruire il lab con l'immagine Docker gitlab-ee:10.6.0-ee.0.

In realtà, dalle descrizioni precedenti si capisce anche che le condizioni per sfruttare questa vulnerabilità sono piuttosto severe; in pratica, i "poveri" difficilmente possono essere colpiti da questa vulnerabilità

0x40 Allestimento del lab

0x41 Costruzione

• Sull'host devono essere preinstallati docker e docker-compose
• Scaricare questo repository: git clone https://github.com/lyy289065406/CVE-2020-13277
• Generare la coppia di chiavi per il crack: ./keygen.sh o ./keygen.ps1
• Costruire ed eseguire GitLab (assicurarsi che la porta 80 sia libera): ./run.sh o ./run.ps1
• Dopo circa 5 minuti si può accedere a GitLab dal browser: http://127.0.0.1 (al primo accesso è necessario reimpostare la password dell'account amministratore root)

0x42 Crack

Quando in precedenza è stata generata la coppia di chiavi per il crack, la chiave pubblica è già stata scritta nel backend del container GitLab; ora è necessario caricare la chiave privata tramite il frontend su GitLab per completare il crack:

• La coppia di chiavi viene generata nella directory ./gitlab/keys/; copiare il contenuto di .gitlab-license (la chiave privata)
• Con l'utente root aprire la pagina http://127.0.0.1/admin/license/new
• Selezionare Enter license key, incollare la chiave privata e fare clic sul pulsante Upload license per completare il crack

A questo punto la funzionalità Mirror Repository - Pull è attivata

0x43 Impostazioni outbound

• Con l'utente root aprire la pagina http://127.0.0.1/admin/application_settings
• Trovare in fondo Outbound requests, spuntare Allow requests to the local network from hooks and services e salvare

A questo punto Mirror Repository - Pull supporta il pull di Repository locali

0x44 Configurazione del Runner

• Con l'utente root aprire la pagina http://127.0.0.1/admin/runners
• Trovare il registration token e copiarlo
• Registrare il Runner: ./register.sh $TOKEN o ./register.ps1 $TOKEN

A questo punto tutti i Repository possono usare questo Runner per eseguire script CI (Pipeline Jobs)

0x50 Verifica del lab