CVE-2021-22205: Es war ein GitLab Smash

Einführung

GitLab ist ein Open-Source-Code-Repository-System für die Softwareentwicklung, das in erster Linie von großen Unternehmen für die Verwaltung von DevOps- und anderen damit verbundenen Softwareprojekten verwendet wird. Das Hauptangebot von GitLab wird von der Firma GitLab selbst verwaltet und gehostet; sie bietet auch eine selbst gehostete Version ihres Produkts sowohl für Communities als auch für Unternehmen mit unterschiedlichen Support-Levels an.

Am 07. Mai 2021 meldete ein Forscher namens "vakzz" (William Bowling) über das Bug Bounty-Programm von HackerOne einen bösen Fehler, der die Unternehmens- und Community-Software von GitLab betraf. Die GitLab-Ingenieure haben das Problem umgehend behoben, und die Schwachstelle schien für einige Monate unter dem Radar zu verschwinden. Bis ein Benutzer auf Twitter berichtete, dass ein Botnet mit Tausenden von kompromittierten GitLab-Instanzen eine massive DDoS-Kampagne startete und mehr als ein Terabit an Daten pro Sekunde generierte(das sind 75.000 ZD/m (Zip Disks pro Minute)).

Was ist das Problem?

Dem ursprünglichen Bericht zufolge werden Bilder, die auf den GitLab-Server hochgeladen werden, durch ein Perl-Tool namens ExifTool geleitet, um unbrauchbare Metadaten zu entfernen. Leider unterstützt ExifTool auch ein DjVu-Dateiformat, das benutzerdefinierte S-Ausdrücke verarbeitet, eine LISP-ähnliche Auswertungssprache, die in bestimmten Abschnitten der DjVu-Datei gefunden wird. Ein verwandter Fehler, CVE-2021-22204, wurde bereits im April 2021 bekannt gegeben, wobei derselbe Forscher zeigte, dass das ExifTool DjVu Eingaben vor dem Aufruf der Perl-Funktion eval() nicht ordnungsgemäß bereinigt, was eine benutzergesteuerte, beliebige Perl-Codeausführung (Remote Code Execution) ermöglicht. William Bowling hat in seinem Blog einen ausgezeichneten Überblick über die Forschung, die zu diesen Ergebnissen geführt hat, geschrieben.

Zum Zeitpunkt der Erstellung dieses Berichts fand Censys 20.524 Hosts mit Internetzugang, auf denen 20.565 Dienste liefen, die als verwundbare Version der GitLab-Server-Software identifiziert wurden. Auf den meisten Hosts lief Version 11.11 mit über 1.400 Vorkommen, dicht gefolgt von Version 13.1 und 12.1 mit rund 1.300 Hosts.

Da der GitLab-Server über keine Funktion verfügte, mit der wir die spezifische Version der laufenden Software ermitteln konnten, haben wir eine effektive Methode zur Identifizierung und zum Fingerprinting entwickelt, bei der wir (buchstäbliche) Artefakte aus der Build-Pipeline von GitLab verwenden.

GitLab startet automatisch eine Reihe von Aufträgen, die die GitLab-Software kompilieren und testen, sobald ein Code-Commit markiert wird. Ein Teil dieses Build-Prozesses ist ein Job namens "compile-production-assets", das im Verzeichnis ".gitlab/ci/frontend.gitlab-ci.yml"dessen Ziel es ist, die öffentlichen Assets des Produkts (Bilder und CSS-Dateien) in einem Ausgabeordner zusammenzufassen und zu kompilieren. Da diese Dateien ohne Authentifizierung öffentlich zugänglich sind und in einem offenen GitLab-Website-Index referenziert werden (und somit über Censys durchsuchbar sind), eignen sie sich perfekt für ein Ad-hoc-Fingerprinting.

Viele dieser generierten Dateinamen ändern sich kaum (z. B. das Logo), aber einige schon. Zum Beispiel scheint "public/assets/application.css" für jede kleinere Version einen anderen generierten Dateinamen zu haben. Darüber hinaus enthalten die Namen dieser Dateien eine 64-Byte-Zeichenkette in ASCII-HEX-Kodierung, die an den ursprünglichen Dateinamen angehängt ist, so dass wir diese Dateinamen dem Build-Job und der Softwareversion zuordnen können, die sie erzeugt haben. Unser Ziel war es also, jeden mit einem Tag versehenen Build (mit einer verwundbaren Version) der GitLab-Software herunterzuladen, dann den Namen des erzeugten Dateinamens mit dem Präfix "public/assets/application-" und der Erweiterung "css" zu notieren und diesen Dateinamen mit dem Tag des Builds zu verknüpfen. Das ist nicht perfekt, aber es reicht.

Nachdem wir jedes verwundbare Image von docker.io heruntergeladen hatten (alle 247 Major-, Minor- und Release-Kandidaten), führten wir ein kleines Shell-Skript aus, das eine Tabelle mit Tag-Namen zu eindeutigen Dateinamen generierte, was zu 44 eindeutigen Dateinamen-Hashes führte:

#!/usr/bin/env bash
 
assetdir="/opt/gitlab/embedded/service/gitlab-rails/public/assets"
tags=$(cat ./vulnerable_tags.txt)
 
for tag in $tags; do
    filename=$(docker run --rm -it --entrypoint "" gitlab/gitlab-ce:$tag ls $assetdir|egrep '^application-.*\.css' | grep -v \.gz)
    echo $tag,$filename
done

Nach einer manuellen Datenbereinigung begannen wir mit der Suche, indem wir eine BigQuery-SQL-Anweisung generierten, um alle laufenden GitLab-Dienste zusammen mit dem gesuchten Dateinamen zu finden. Die Ergebnisse wurden in einer temporären Datenbanktabelle für die weitere Analyse gespeichert. (Eine Funktion, auf die Censys Unternehmenskunden Zugriff haben):

WITH
  results AS (
  SELECT
    DISTINCT host_identifier.ipv4 AS host,
    autonomous_system.asn AS asn,
    autonomous_system.name AS asn_name,
    location.country_code AS cc,
    location.coordinates.latitude AS lat,
    location.coordinates.longitude AS long,
    REGEXP_EXTRACT(SAFE_CONVERT_BYTES_TO_STRING(svc.http.response.body),
        ".*(/assets/application-[a-f0-9]{64}.css).*") AS version,
  FROM
    `censys-io.universal_internet_dataset.universal_internet_dataset`
  JOIN
    UNNEST(services) svc
  JOIN
    UNNEST(svc.http.response.html_tags) x
  WHERE
    DATE(snapshot_date) = "2021-11-03"
    AND SAFE_CONVERT_BYTES_TO_STRING(svc.http.response.body)LIKE '%/assets/application-%.css%'
    AND SAFE_CONVERT_BYTES_TO_STRING(x) LIKE '%/assets/gitlab_logo-%'
  ORDER BY
    version DESC )
SELECT
  *
FROM
  results;

Der nächste Schritt bestand darin, die von der obigen Abfrage generierten Daten zu nehmen und die gefundenen Dateinamen der jeweiligen Version zuzuordnen, wie sie in den Docker-Images zu sehen ist, was zu folgendem Ergebnis führte

Wir können auch eine etwas ausführliche Censys -Suchabfrage mit den obigen Hashes erstellen, um die Hosts, die diesen Bedingungen entsprechen, besser anzuzeigen, indem wir sowohl nach dem Dateinamen gitlab_logo als auch nach der Liste der übereinstimmenden Dateien suchen.

Während die Verwendung dieser ausgenutzten Hosts für DDoS an sich schon schrecklich ist, gab es auch Diskussionen über andere Massenangriffe, bei denen zufällige Admin-Benutzer gefunden wurden. Ein Angreifer könnte zum Beispiel Hintertüren und anfällige Funktionen in den Quellcode von Projekten einschleusen, die von diesen Diensten gehostet werden. In diesem Fall könnte selbst der am sichersten geschriebene Code zu einem administrativen Albtraum werden.

Der Angriff selbst ist einfach, und es gibt leicht zugängliche Exploits, was dieses Problem zu einem schwerwiegenden Problem macht, das sofort behoben werden sollte. Wir hoffen, dass die in diesem Beitrag vorgestellten Daten Ingenieuren und Administratoren dabei helfen werden, anfällige GitLab-Instanzen zu identifizieren und zu patchen.

Was kann ich dagegen tun?

• Aktualisieren Sie auf GitLab v13.10.3, v13.9.6 oder v13.8.8.
• Suchen Sie nach eigenen Vermögenswerten, die in diesem Censys Search
• Censys ASM-Kunden wurden per E-Mail benachrichtigt, wenn eigene Anlagen als gefährdet eingestuft wurden.
• Die YARA-Regeln von Neo23x0 für die oben genannten Hashes.

Referenzen

• MITRE
• Metasploit-Modul
• Ursprünglicher Bericht
• Vakzz's Rundown