CVE-2021-22205: Fue un destrozo de GitLab

Introducción

GitLab es un sistema de repositorio de código abierto para el desarrollo de software, utilizado principalmente por grandes organizaciones para gestionar DevOps y otros proyectos de software relacionados. La oferta principal de GitLab está gestionada y alojada por la propia empresa GitLab; también ofrecen una versión autoalojada de su producto tanto para comunidades como para empresas con distintos niveles de soporte.

El 7 de mayo de 2021, un investigador llamado "vakzz" (William Bowling) informó de un desagradable fallo que afectaba al software empresarial y comunitario GitLab a través del programa de recompensas por fallos HackerOne. Los ingenieros de GitLab solucionaron rápidamente el problema, y la vulnerabilidad pareció pasar desapercibida durante unos meses. Eso fue hasta que un usuario en Twitter informó de que una botnet de miles de instancias de GitLab comprometidas inició una campaña DDoS masiva, generando más de un terabit de datos por segundo(eso son 75.000 ZD/m (Discos Zip por minuto)).

¿Cuál es el problema?

Según el informe original, las imágenes subidas al servidor de GitLab pasan por una herramienta Perl llamada ExifTool para eliminar los metadatos inútiles. Por desgracia, ExifTool también es compatible con el formato de archivo DjVu, que procesará las S-Expressions definidas por el usuario, un lenguaje de evaluación similar a LISP que se encuentra en secciones específicas del archivo DjVu. Un bug relacionado, CVE-2021-22204, fue anunciado en Abril de 2021, donde el mismo investigador mostró que ExifTool DjVu no saneaba adecuadamente las entradas antes de llamar a la función Perl eval(), permitiendo la ejecución arbitraria de código Perl controlada por el usuario (Ejecución Remota de Código). William Bowling escribió un excelente resumen en su blog con más detalles sobre la investigación que condujo a estos hallazgos.

En el momento de escribir estas líneas, Censys encontró 20.524 hosts con acceso a Internet que ejecutaban 20.565 servicios identificados como una versión vulnerable del software de servidor GitLab. La mayoría de los hosts ejecutaban la versión 11.11, con más de 1.400 casos, seguidos de cerca por las versiones 13.1 y 12.1, con unos 1.300 hosts.

Aunque el servidor de GitLab no disponía de ninguna función que nos permitiera determinar la versión específica del software en ejecución, ideamos un método eficaz de identificación y huella digital utilizando artefactos (literales) del proceso de compilación de GitLab.

GitLab iniciará automáticamente un conjunto de tareas que compilan y prueban el software de GitLab cada vez que se etiqueta una confirmación de código. Una parte de este proceso de compilación es un trabajo llamado "compile-production-assets" que se encuentra en el directorio ".gitlab/ci/frontend.gitlab-ci.yml"cuyo objetivo es agregar y compilar los activos públicos del producto (imágenes y archivos CSS) en una carpeta de salida. Dado que estos archivos son accesibles al público sin autenticación y se hace referencia a ellos en un índice expuesto del sitio web de GitLab (por lo tanto, se pueden buscar en Censys), eran candidatos perfectos para un poco de huella digital ad hoc.

Muchos de estos nombres de archivo generados apenas cambian (como el logotipo), pero otros sí. Por ejemplo, "public/assets/application.css" parecía tener un nombre de archivo generado diferente para cada versión menor. Además, los nombres de estos archivos incluirán una cadena codificada ASCII-HEX de 64 bytes añadida al nombre de archivo original, lo que nos permite asignar estos nombres de archivo a la tarea de compilación y a la versión de software que los generó. Nuestro objetivo era descargar todas las compilaciones etiquetadas (con una versión vulnerable) del software GitLab, anotar el nombre del archivo generado con el prefijo "public/assets/application-" y la extensión "css", y asociar ese nombre de archivo con la etiqueta de la compilación. No es perfecto, pero sirve.

Después de descargar todas las imágenes vulnerables de docker.io (las 247 principales, secundarias y candidatas a versión), ejecutamos un pequeño script de shell que generó una tabla de nombres de etiqueta con nombres de archivo únicos que dio como resultado 44 hashes de nombre de archivo únicos:

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

Después de un poco de poda manual de datos, comenzamos la búsqueda generando una sentencia SQL BigQuery para encontrar todos los servicios GitLab en ejecución junto con el nombre de archivo específico que estábamos buscando. Los resultados se almacenaron en una tabla temporal de la base de datos para su posterior análisis. (Una función a la que tienen acceso los clientes empresariales de Censys ):

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;

El siguiente paso fue tomar los datos generados por la consulta anterior y asignar los nombres de archivo encontrados a su respectiva versión, tal y como se ve en las imágenes docker, lo que dio como resultado lo siguiente:

También podemos construir una consulta de búsqueda algo verbosa en Censys utilizando los hashes anteriores para ver mejor los hosts que coinciden con estas condiciones buscando tanto el nombre de archivo gitlab_logo como la lista de archivos que coinciden.

Aunque el uso de estos hosts explotados para DDoS es terrible en sí mismo, también se ha hablado de otros ataques de explotación masiva en los que se encontraron usuarios administradores aleatorios. Por ejemplo, un atacante podría introducir puertas traseras y funcionalidades vulnerables en el código fuente de los proyectos alojados en estos servicios. Si esto ocurriera, incluso el código escrito de forma más segura podría convertirse en una pesadilla administrativa.

El ataque en sí es sencillo, y existen exploits fácilmente disponibles que hacen de este un problema grave que debe ser tratado de inmediato. Esperamos que los datos presentados en este post ayuden a los ingenieros y administradores a identificar y parchear las instancias vulnerables de GitLab.

¿Qué hago al respecto?

• Actualiza a GitLab v13.10.3, v13.9.6 o v13.8.8.
• Busque los bienes en propiedad encontrados en esta Censys Búsqueda
• Censys Los clientes de ASM han sido notificados por correo electrónico si algún activo de su propiedad ha sido identificado como vulnerable.
• Reglas YARA de Neo23x0 para los hashes anteriores.

Referencias

• MITRE
• Módulo Metasploit
• Informe original
• Resumen de Vakzz