CVE-2021-22205 : C'était un coup de GitLab

Introduction

GitLab est un système de dépôt de code open-source pour le développement de logiciels, principalement utilisé par les grandes organisations pour gérer DevOps et d'autres projets logiciels connexes. L'offre principale de GitLab est gérée et hébergée par la société GitLab elle-même ; elle propose également une version auto-hébergée de son produit pour les communautés et les entreprises, avec différents niveaux de support.

Le 7 mai 2021, un chercheur nommé "vakzz" (William Bowling) a signalé un méchant bogue qui ciblait le logiciel d'entreprise et de communauté GitLab via le programme de primes aux bogues de HackerOne. Les ingénieurs de GitLab ont rapidement corrigé le problème, et la vulnérabilité a semblé passer inaperçue pendant quelques mois. Jusqu'à ce qu'un utilisateur de Twitter signale qu'un botnet composé de milliers d'instances GitLab compromises a lancé une campagne DDoS massive, générant plus d'un térabit de données par seconde(soit 75 000 ZD/m (Zip Disks par minute)).

Quel est le problème ?

Selon le rapport original, les images téléchargées sur le serveur GitLab passent par un outil Perl appelé ExifTool pour supprimer les métadonnées inutiles. Malheureusement, ExifTool prend également en charge le format de fichier DjVu, qui traitera les S-Expressions définies par l'utilisateur, un langage d'évaluation de type LISP trouvé dans des sections spécifiques du fichier DjVu. Un bogue connexe, CVE-2021-22204, a été annoncé en avril 2021, dans lequel le même chercheur a montré que l'ExifTool DjVu ne nettoyait pas correctement les entrées avant d'appeler la fonction Perl eval(), ce qui permettait l'exécution de code Perl arbitraire contrôlé par l'utilisateur (exécution de code à distance). William Bowling a écrit un excellent résumé sur son blog avec plus de détails sur la recherche qui a conduit à ces résultats.

À l'heure où nous écrivons ces lignes, Censys a trouvé 20 524 hôtes orientés vers l'internet et exécutant 20 565 services identifiés comme étant une version vulnérable du logiciel serveur GitLab. La plupart des hôtes utilisent la version 11.11, avec plus de 1 400 occurrences, suivie de près par les versions 13.1 et 12.1, avec environ 1 300 hôtes.

Bien que le serveur GitLab ne dispose d'aucune fonction nous permettant de déterminer la version spécifique du logiciel en cours d'exécution, nous avons mis au point une méthode efficace d'identification et d'empreinte digitale à l'aide d'artefacts (littéraux) du pipeline de construction de GitLab.

GitLab lance automatiquement un ensemble de tâches qui compilent et testent le logiciel GitLab chaque fois qu'un commit de code est marqué. Une partie de ce processus de construction est un travail appelé "compile-production-assets"trouvé dans le répertoire ".gitlab/ci/frontend.gitlab-ci.yml"dont l'objectif est d'agréger et de compiler les ressources publiques du produit (images et fichiers CSS) dans un dossier de sortie. Ces fichiers étant accessibles au public sans authentification et référencés dans l'index d'un site web GitLab (donc consultables à l'adresse Censys), ils constituaient des candidats parfaits pour un relevé d'empreintes ad hoc.

Beaucoup de ces noms de fichiers générés ne changent pratiquement jamais (comme le logo), mais certains le font. Par exemple, "public/assets/application.css" semble avoir un nom de fichier généré différent pour chaque version mineure. En outre, les noms de ces fichiers comprennent une chaîne de 64 octets codée en ASCII-HEX ajoutée au nom de fichier original, ce qui nous permet d'associer ces noms de fichiers à la tâche de construction et à la version du logiciel qui les a générés. Notre objectif était donc de télécharger chaque version étiquetée (avec une version vulnérable) du logiciel GitLab, puis de noter le nom du fichier généré avec le préfixe "public/assets/application-" et l'extension "css", et d'associer ce nom de fichier à l'étiquette de la version. Ce n'est pas parfait, mais cela fera l'affaire.

Après avoir téléchargé toutes les images vulnérables de docker.io (les 247 images majeures, mineures et release candidates), nous avons exécuté un petit script shell qui a généré une table de noms de tags pour les noms de fichiers uniques, ce qui a donné 44 hachages de noms de fichiers uniques :

#!/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

Après un élagage manuel des données, nous avons commencé la recherche en générant une instruction SQL BigQuery pour trouver tous les services GitLab en cours d'exécution ainsi que le nom de fichier spécifique que nous recherchions. Les résultats ont été stockés dans une table de base de données temporaire en vue d'une analyse ultérieure. (Une fonctionnalité à laquelle les entreprises clientes de Censys ont accès) :

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;

L'étape suivante a consisté à prendre les données générées par la requête ci-dessus et à mettre en correspondance les noms de fichiers trouvés avec leur version respective telle qu'elle apparaît dans les images docker, ce qui a donné le résultat suivant :

Nous pouvons également construire une requête de recherche Censys quelque peu verbeuse en utilisant les hachages ci-dessus pour mieux visualiser les hôtes correspondant à ces conditions en recherchant à la fois le nom de fichier gitlab_logo et la liste des fichiers qui correspondent.

Si l'utilisation de ces hôtes exploités pour des attaques DDoS est déjà terrible, des discussions ont également eu lieu sur d'autres attaques d'exploitation de masse où des utilisateurs administrateurs aléatoires ont été trouvés. Par exemple, un attaquant pourrait introduire des portes dérobées et des fonctionnalités vulnérables dans le code source des projets hébergés par ces services. Si cela devait se produire, même le code le plus sûr pourrait devenir un cauchemar administratif.

L'attaque elle-même est simple, et il existe des exploits facilement disponibles, ce qui en fait un problème grave qui doit être traité immédiatement. Nous espérons que les données présentées dans cet article aideront les ingénieurs et les administrateurs à identifier et à corriger les instances GitLab vulnérables.

Que dois-je faire ?

• Mettre à jour vers GitLab v13.10.3, v13.9.6, ou v13.8.8.
• Recherchez les actifs possédés dans ce site Censys Search
• Censys Les clients de l 'ASM ont été informés par courrier électronique de la vulnérabilité des biens qu'ils possèdent.
• Règles YARA de Neo23x0 pour les hachages ci-dessus.

Références

• MITRE
• Module Metasploit
• Rapport original
• Le bilan de Vakzz