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

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

Per il processo di verifica si può fare riferimento alla Issue ufficiale, ma il processo di verifica seguente prevede alcune piccole modifiche ai passaggi in base a questo lab

0x51 Pre-creazione degli account per la verifica

Con l'utente root aprire la pagina http://127.0.0.1/admin/users e creare 3 account:

• victim: l'account della vittima
• attacker1: account dell'attaccante 1
• attacker2: account dell'attaccante 2

Durante la creazione dell'account non è possibile impostare una password iniziale; GitLab per impostazione predefinita invia la password iniziale all'Email configurata. Per comodità, si può inserire un Email qualsiasi, creare l'account e poi modificarlo subito: a quel punto è possibile impostare con root la password iniziale dell'account, senza passare dall'Email

0x52 Pre-creazione del repository della vittima

• Accedere a GitLab con l'account victim
• Creare un nuovo repository New Project:
  • Name: target
  • Visibility Level: Private
• Nel repository creare un file README.md e impostarne il contenuto a piacere, ad esempio mykey is abcxyz

Ovviamente target è il repository privato di victim, e il nostro obiettivo è sfruttare la vulnerabilità per ottenere il contenuto di questo repository

0x53 Creazione del repository poc dell'attaccante

• Accedere a GitLab con l'account attacker1
• Creare un nuovo repository New Project:
  • Name: poc
  • Visibility Level: Public
• Nel repository creare un file .gitlab-ci.yml con il seguente contenuto:

image: "ruby:2.6"

rspec:  
  script:  
    - git clone http://gitlab-ci-token:[email protected]/victim/target.git
    - cd target
    - ls -lah .  
    - cat README.md

【Scopo】Nei passaggi successivi, con alcune tecniche si farà sì che victim, senza saperlo, esegua questo script CI con i propri permessi.

Poiché il lab attuale non ha certificati configurati, si può usare solo il protocollo http; inoltre 172.168.30.2 è l'IP assegnato da docker-compose.yml al container GitLab: poiché questo script CI verrà eseguito tramite il Runner, e nel lab attuale il Runner e GitLab non sono nello stesso container, è necessario usare l'indirizzo IP assegnato da Docker

0x53 Creazione del repository mirror poc dell'attaccante

• Accedere a GitLab con l'account attacker2
• Creare un nuovo gruppo New Group:
  • Name: test
  • Visibility Level: Public
• All'interno del gruppo test creare un repository completamente vuoto New Project:
  • Name: poc
  • Visibility Level: Public

Configurare il repository mirror Settings => Repository => Pull from a remote repository:

• Mirror repository: spuntare
• Git repository URL: inserire http://GITLAB/attacker1/poc
• Password: (lasciare vuoto, il livello di visibilità del repository da cui si fa Pull è Public, non serve la password)
• Trigger pipelines for mirror updates: spuntare (attiva l'esecuzione dello script CI durante la sincronizzazione dello specchio)

Una volta configurato correttamente, ogni 30 minuti viene controllato se il repository sorgente è cambiato; in caso di modifiche viene forzata la sincronizzazione.

Il Git repository URL punta al repository poc creato in precedenza; il motivo per cui non si usa 127.0.0.1 è che il Pull vieta di scaricare repository locali, ma è possibile aggirare il blocco usando il DNS: GITLAB è l'hostname assegnato da docker-compose.yml al container GitLab ed è impostato per impostazione predefinita in /etc/hosts; sebbene l'host non possa risolvere GITLAB, all'interno del container equivale ad accedere a http://127.0.0.1/attacker1/poc

0x54 Trasferimento forzato della proprietà del repository mirror poc alla vittima

• Continuare a usare l'account attacker2
• Aprire la pagina http://127.0.0.1/groups/test/-/group_members per gestire gli utenti del gruppo test
• Aggiungere l'utente victim al gruppo:
  • Add new member to test: victim
  • Permissions: Owner
  • Expiration date: (lasciare vuoto, cioè senza scadenza)
• Fare clic sull'avatar dell'account in alto a destra => Setting => Account => Delete account per eliminare l'account corrente (attacker2)

【Scopo】Nel gruppo test ci sono solo due Owner: victim e attacker2; quando l'utente attacker2 viene eliminato, la proprietà del gruppo test e di tutti i repository in esso contenuti viene trasferita forzatamente a victim. Poiché nel gruppo test c'è un repository test/poc sincronizzato via mirror da attacker1/poc, ciò equivale a cedere forzatamente il repository test/poc all'utente victim.

0x55 Lancio dell'attacco

Prima, riepiloghiamo la situazione attuale:

• L'attaccante ha creato forzatamente e di nascosto un repository test/poc per la vittima victim
• Il contenuto del repository test/poc viene sincronizzato via mirror dal repository attacker1/poc (ogni 30 minuti viene controllato se ci sono modifiche da sincronizzare)
• Il contenuto del repository attacker1/poc è controllato dall'attaccante, inclusi gli script CI .gitlab-ci.yml
• Poiché il repository test/poc ha impostato Trigger pipelines for mirror updates, lo script CI viene eseguito a ogni sincronizzazione
• Poiché l'Owner del repository test/poc è victim, lo script CI viene eseguito con i permessi di victim

Ricapitolando il contenuto dello script CI .gitlab-ci.yml configurato in precedenza, questo poc, nel Runner, usa i permessi di victim per accedere alla struttura delle directory e al file README.md del suo repository Private target:

image: "ruby:2.6"

rspec:  
  script:  
    - git clone http://gitlab-ci-token:[email protected]/victim/target.git
    - cd target
    - ls -lah .  
    - cat README.md

Successivamente, l'attaccante deve solo modificare arbitrariamente qualche contenuto insignificante nel repository attacker1/poc; nel caso peggiore basta attendere 30 minuti e lo script CI configurato verrà eseguito con i permessi di victim.

Sebbene l'attaccante non abbia accesso diretto ai risultati dell'esecuzione dei Pipeline Jobs, gli basta modificare la destinazione di output dello script, ad esempio inviando il contenuto del repository a una Email o a un server FTP specifici, per rubare il codice del repository.