CVE-2020-13277

CVE-2020-13277 Übungsfeld: Gitlab Logik-Schwachstelle – Unbefugter Zugriff auf private Repositories durch beliebige Benutzer

0x10 Übungsumgebung

0x20 Verzeichnisstruktur

CVE-2020-13277
├── README.md ............... [Diese README-Datei]
├── imgs .................... [Bilder zur Unterstützung der README]
├── gitlab .................. [Einhängeverzeichnis des Gitlab-Containers]
│   ├── Dockerfile .......... [Docker-Build-Datei für Gitlab]
│   ├── config .............. [Einhängeverzeichnis für Gitlab-Konfiguration]
│   ├── data ................ [Einhängeverzeichnis für Gitlab-Daten]
│   ├── logs ................ [Einhängeverzeichnis für Gitlab-Logs]
│   ├── keys ................ [Speicherverzeichnis für den geknackten Gitlab-Lizenzschlüssel]
│   └── runner .............. [Einhängeverzeichnis des Runner-Containers]
├── license ................. [Build-Verzeichnis des Containers für die Lizenz]
│   ├── Dockerfile .......... [Docker-Build-Datei für die Lizenz]
│   └── license.rb .......... [Ruby-Skript zum Generieren der geknackten Lizenz]
├── docker-compose.yml ...... [Docker-Build-Konfiguration]
├── keygen.ps1 .............. [Windows: Lizenz mit einem Klick generieren]
├── keygen.sh ............... [Linux:   Lizenz mit einem Klick generieren]
├── run.ps1 ................. [Windows: Gitlab-Übungsfeld mit einem Klick starten]
├── run.sh .................. [Linux:   Gitlab-Übungsfeld mit einem Klick starten]
├── register.ps1 ............ [Windows: Runner mit einem Klick registrieren]
├── register.sh ............. [Linux:   Runner mit einem Klick registrieren]
├── stop.ps1 ................ [Windows: Gitlab-Übungsfeld mit einem Klick stoppen]
└── stop.sh ................. [Linux:   Gitlab-Übungsfeld mit einem Klick stoppen]

0x30 Vorabinformationen

0x40 Aufbau des Übungsfelds

0x41 Bauen

• Auf dem Host müssen Docker und docker-compose vorinstalliert sein
• Dieses Repository herunterladen: git clone https://github.com/lyy289065406/CVE-2020-13277
• Geknacktes Schlüsselpaar generieren: ./keygen.sh oder ./keygen.ps1
• Gitlab bauen und starten (sicherstellen, dass Port 80 nicht belegt ist): ./run.sh oder ./run.ps1
• Nach etwa 5 Minuten kann man sich von einem Browser aus bei Gitlab anmelden: http://127.0.0.1 (beim ersten Anmelden muss das Passwort des Admin-Kontos root zurückgesetzt werden)

0x42 Knacken

Beim vorherigen Generieren des geknackten Schlüsselpaars wurde der öffentliche Schlüssel bereits im Hintergrund in den Gitlab-Container geschrieben. Der private Schlüssel muss noch über das Frontend in Gitlab hochgeladen werden, um das Knacken abzuschließen:

• Das Schlüsselpaar wird im Verzeichnis ./gitlab/keys/ generiert; den Inhalt der darin enthaltenen .gitlab-license (privater Schlüssel) kopieren
• Mit dem Benutzer root die Seite http://127.0.0.1/admin/license/new öffnen
• Enter license key auswählen, den privaten Schlüssel einfügen und auf die Schaltfläche Upload license klicken, um das Knacken abzuschließen

Damit ist die Mirror-Repository-Pull-Funktion aktiviert

0x43 Ausgehende Einstellungen

• Mit dem Benutzer root die Seite http://127.0.0.1/admin/application_settings öffnen
• Ganz unten Outbound requests finden, die Option Allow requests to the local network from hooks and services aktivieren und speichern

Damit unterstützt Mirror Repository - Pull nun das Abrufen lokaler Repositorys

0x44 Runner einrichten

• Mit dem Benutzer root die Seite http://127.0.0.1/admin/runners öffnen
• Das Registrierungs-Token finden und kopieren
• Runner registrieren: ./register.sh $TOKEN oder ./register.ps1 $TOKEN

Damit können alle Repositorys diesen Runner zur Ausführung von CI-Skripten (Pipeline Jobs) verwenden

0x50 Validierung des Übungsfelds

Der Validierungsprozess kann sich an der offiziellen Issue orientieren, aber der folgende Validierungsprozess wird in diesem Übungsfeld einige Schritte leicht anpassen

0x51 Vorbereitung von Validierungskonten

Mit dem Benutzer root die Seite http://127.0.0.1/admin/users öffnen und 3 Konten erstellen:

• victim: Opferkonto
• attacker1: Angreiferkonto 1
• attacker2: Angreiferkonto 2

Beim Erstellen eines Kontos kann kein initiales Passwort festgelegt werden. Gitlab sendet standardmäßig ein initiales Passwort an die angegebene E-Mail. Der Einfachheit halber kann man eine beliebige E-Mail-Adresse eingeben, das Konto erstellen und dann sofort bearbeiten. In diesem Fall kann man mit root das initiale Passwort für das Konto festlegen, ohne auf die E-Mail angewiesen zu sein.

0x52 Vorbereitung des Opfer-Repositorys

• Mit dem Konto victim bei Gitlab anmelden
• Neues Repository New Project erstellen:
  • Name: target
  • Sichtbarkeitsstufe: Private
• Im Repository eine neue Datei README.md erstellen und einen beliebigen Inhalt wie mykey is abcxyz eingeben

Offensichtlich ist target das private Repository von victim, und unser Ziel ist es, durch die Schwachstelle den Inhalt dieses Repositorys zu erlangen

0x53 Erstellung des Angreifer-PoC-Repositorys

• Mit dem Konto attacker1 bei Gitlab anmelden
• Neues Repository New Project erstellen:
  • Name: poc
  • Sichtbarkeitsstufe: Public
• Im Repository eine neue Datei .gitlab-ci.yml mit folgendem Inhalt erstellen:

image: "ruby:2.6"

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

【Zweck】In den folgenden Schritten wird durch einige Tricks erreicht, dass victim ohne Wissen unter Verwendung seiner Berechtigungen dieses CI-Skript ausführt.

Da dieses Übungsfeld keine Zertifikate einrichtet, kann nur das http-Protokoll verwendet werden; außerdem ist 172.168.30.2 die IP, die docker-compose.yml dem Gitlab-Container zuweist. Da dieses CI-Skript letztendlich über den Runner ausgeführt wird und der Runner und Gitlab in diesem Übungsfeld nicht derselbe Container sind, muss die vom Docker zugewiesene IP-Adresse verwendet werden

0x53 Erstellung des Angreifer-PoC-Spiegel-Repositorys

• Mit dem Konto attacker2 bei Gitlab anmelden
• Neue Gruppe New Group erstellen:
  • Name: test
  • Sichtbarkeitsstufe: Public
• In der Gruppe test ein neues, völlig leeres Repository New Project erstellen:
  • Name: poc
  • Sichtbarkeitsstufe: Public

Spiegel-Repository konfigurieren Settings => Repository => Pull from a remote repository:

• Mirror repository: aktivieren
• Git repository URL: http://GITLAB/attacker1/poc eingeben
• Password: (leer lassen, da das zu pullende Repository öffentlich ist, kein Passwort erforderlich)
• Trigger pipelines for mirror updates: aktivieren (Auslösen der CI-Skriptausführung bei Spiegel-Synchronisation)

Nach erfolgreicher Konfiguration wird alle 30 Minuten überprüft, ob sich das Quell-Repository geändert hat. Wenn ja, wird eine erzwungene Synchronisation durchgeführt.

Die Git repository URL zeigt auf das zuvor erstellte PoC-Repository. Der Grund, warum nicht 127.0.0.1 verwendet wird, liegt darin, dass das Abrufen lokaler Repositorys verboten ist, aber die DNS-Umgehung genutzt werden kann: GITLAB ist der Hostname, der dem Gitlab-Container in docker-compose.yml zugewiesen wird. Standardmäßig wird er in /etc/hosts eingetragen. Obwohl der Host GITLAB nicht auflösen kann, entspricht dies innerhalb des Containers dem Zugriff auf http://127.0.0.1/attacker1/poc

0x54 Erzwungene Übertragung des Besitzes des PoC-Spiegel-Repositorys an das Opfer

• Weiter mit dem Konto attacker2 arbeiten
• Die Seite http://127.0.0.1/groups/test/-/group_members öffnen, um die Benutzer der Gruppe test zu verwalten
• Den Benutzer victim zur Gruppe hinzufügen:
  • Add new member to test: victim
  • Permissions: Owner
  • Expiration date: (leer lassen, d.h. unbegrenzt)
• Rechts oben auf das Benutzersymbol klicken => Setting => Account => Delete account, um das aktuelle Konto (attacker2) zu löschen

【Zweck】In der Gruppe test gibt es nur zwei Owner: victim und attacker2. Wenn der Benutzer attacker2 gelöscht wird, wird der Besitz der Gruppe test und aller darunter liegenden Repositorys zwangsweise an victim übertragen. Da es in der Gruppe test derzeit ein von attacker1/poc gespiegeltes Repository test/poc gibt, wird das Repositorium test/poc effektiv zwangsweise an den Benutzer victim vererbt.

0x55 Angriff starten

Zunächst der aktuelle Stand:

• Der Angreifer hat heimlich und zwangsweise für das Opfer victim ein Repository test/poc erstellt
• Der Inhalt von test/poc wird vom Repository attacker1/poc gespiegelt (alle 30 Minuten wird geprüft, ob sich etwas geändert hat und synchronisiert werden muss)
• Der Inhalt von attacker1/poc wird vom Angreifer kontrolliert, einschließlich des CI-Skripts .gitlab-ci.yml
• Da das Repository test/poc die Option Trigger pipelines for mirror updates aktiviert hat, wird bei jeder Synchronisation das CI-Skript ausgeführt
• Da der Owner von test/poc victim ist, wird das CI-Skript mit den Berechtigungen von victim ausgeführt

Zurück zum Inhalt des zuvor festgelegten CI-Skripts .gitlab-ci.yml: Dieses PoC greift im Runner mit den Berechtigungen von victim auf die Verzeichnisstruktur und die Datei README.md seines privaten Repositorys target zu:

image: "ruby:2.6"

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

Anschließend muss der Angreifer nur beliebige unwichtige Änderungen am Repository attacker1/poc vornehmen. Im schlimmsten Fall muss er nur 30 Minuten warten, um dann das festgelegte CI-Skript mit den Berechtigungen von victim ausführen zu lassen.

Obwohl der Angreifer keine direkte Berechtigung hat, die Ergebnisse der Pipeline Jobs einzusehen, kann er durch Anpassen des Ausgabeziels des Skripts, z.B. durch Senden des Repository-Inhalts an eine bestimmte E-Mail oder einen FTP-Server, den Code des Repositorys stehlen.