Análisis y corrección de la vulnerabilidad de Git CVE-2024-32002

By OPSWAT

17 de diciembre de 2024 Última actualización: 24 de diciembre de 2024

Comparte esta publicación

Minh Pham y Thai Do, estudiantes de la Universidad Tecnológica de Ho Chi Minh, que participaron en el Programa OPSWAT — Los estudiantes participaron en el programa OPSWAT .

Recientemente se ha dado a conocer una vulnerabilidad crítica en Git que permite ataques de ejecución remota de código (RCE), la cual afecta a varias versiones de Git y a Microsoft Visual Studio 2017. La vulnerabilidad permite a los atacantes manipular repositorios de Git mediante submódulos, aprovechando un error en Git que permite escribir archivos fuera del árbol de trabajo del submódulo y en el directorio .git/. Este error permite la ejecución de un gancho malicioso mientras la operación de clonación del repositorio aún se está ejecutando [1].

La vulnerabilidad CVE-2024-32002 afecta a Microsoft Visual Studio 2017, versión 15.9, y a las versiones de Git anteriores a la 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 y 2.39.4. Puede ser explotada en entornos en los que el soporte de enlaces simbólicos esté habilitado en sistemas operativos que no distinguen entre mayúsculas y minúsculas.

Información sobre la gravedad y el vector del CVSS (Sistema Común de Puntuación de Vulnerabilidades) 3.x, con una puntuación base de 9,0 clasificada como «crítica», facilitada por GitHub, Inc.

Comprender Git

Git es un sistema de control de versiones distribuido, gratuito y de código abierto, diseñado para ayudar a los desarrolladores de software a gestionar los códigos de forma rápida y eficaz. Mejora la colaboración entre los miembros del equipo de desarrollo al organizar y realizar un seguimiento de los cambios en los archivos y directorios de una manera estandarizada y estructurada.

Git es muy utilizado en el desarrollo de software. Plataformas como GitHub, GitLab y Bitbucket se basan en Git para mejorar la colaboración entre desarrolladores gracias a sus potentes funciones:

Registro de los cambios trazables en los archivos de código, lo que se conoce como «commits».
Revertir los cambios realizados en el código a versiones anteriores cuando sea necesario.
Combinar de forma eficaz los cambios de diferentes ramas o colaboradores.
Llevar un registro del historial de quién ha realizado los cambios y las fechas en que se han producido.

Una representación visual de la estructura de la carpeta .git, en la que se muestran directorios como config, HEAD, hooks, objects y refs.

Git Hooks

Cuando se crea o se clona un repositorio de Git, mediante los comandos `git init ` o `git clone `, se genera un directorio `.git`en la raíz del árbol de trabajo. La estructura del directorio ` .git ` tiene inicialmente este aspecto:

Los hooks de Git son scripts ejecutables que se encuentran en el directorio .git/hooks o en el directorio .git/modules/tipo_de_módulo/nombre_del_módulo/hooks. Los hooks se activan automáticamente cuando se producen eventos específicos en un repositorio de Git.

Cuando un archivo del directorio «hooks» no lleva la extensión «.sample», los comandos que contiene se ejecutarán antes o después de una acción concreta de Git incluida en el nombre del archivo, como «pre-commit», «post-commit» y «post-checkout».

Submódulos de Git

Un submódulo de Git es un registro dentro de un repositorio de Git que hace referencia a una confirmación específica en un repositorio externo. Cuando se añade un submódulo a un repositorio, se crea un nuevo archivo en el directorio .gitmodules con los metadatos de la correspondencia entre la URL del submódulo y su directorio local. Cuando un repositorio contiene varios submódulos, el archivo .gitmodules incluirá una entrada para cada uno de ellos. [3]

Diagrama que muestra la interacción entre repositorios y submódulos, y que ilustra la relación entre el repositorio A, el submódulo B y la carpeta C

Ejemplo de contenido de un archivo .gitmodules, que muestra la configuración de un submódulo llamado «Example» — La siguiente imagen muestra el aspecto que tiene un archivo .gitmodules:

Enlaces simbólicos (symlinks)

Un enlace simbólico, también conocido como «symlink» o «enlace blando», es un archivo que apunta a otro archivo o directorio (denominado «destino») especificando su ruta. Si se elimina un enlace simbólico, su destino no se ve afectado. [4]

En Git, un enlace simbólico se crea como un archivo con metadatos para que sirva de referencia o de acceso directo a otro archivo. Los enlaces simbólicos se pueden utilizar para crear múltiples referencias a un archivo sin replicar su contenido.

Diagrama que ilustra los enlaces simbólicos y los enlaces físicos a un archivo (Archivo A), y muestra cómo estos enlaces acceden al mismo contenido del archivo — Git trata los enlaces simbólicos como archivos especiales que almacenan la ruta al archivo o directorio al que hacen referencia.

Visualización de enlaces simbólicos dentro de un repositorio Git, que muestra las estructuras de directorios y archivos, así como las rutas de sus enlaces simbólicos — Cuando se clona o se extrae un repositorio o una rama que contiene un enlace simbólico, el enlace simbólico almacenado en Git se convierte en un enlace simbólico en el sistema de archivos local.

Análisis de vulnerabilidades de seguridad en GIT

Análisis de parches

Para comprender mejor las vulnerabilidades de seguridad, los especialistas en seguridad suelen realizar análisis de parches. Se trata de una técnica que ayuda a identificar funciones vulnerables y posibles vectores de ataque. OPSWAT examinaron los cambios introducidos en la versión parcheada para solucionar la vulnerabilidad CVE-2024-32002 y descubrieron que se habían actualizado dos archivos para solucionar esta CVE.

Uno de los archivos actualizados es el archivo `submodule--helper.c`, que contiene el código encargado de la clonación de submódulos de Git. La nueva confirmación de la versión parcheada incluía los dos siguientes:

Se añade la función ` dir_contains_only_dotgit ` para garantizar que el directorio de submódulos no contenga ningún archivo o directorio .git.

Cambios en el código del archivo «submodule-helper.c» dentro de la interfaz de Git, que muestran 83 adiciones y ninguna eliminación

Se han introducido cambios en la función clone_submodule() para incluir una condición que compruebe si el directorio del submódulo existe y está vacío. Si el directorio no está vacío, el proceso de clonación se interrumpirá.

Fragmento de código detallado de una confirmación de Git, en el que se destaca una función que comprueba el contenido de un directorio durante las operaciones con submódulos

La segunda actualización de la nueva confirmación se realizó en el archivo t/t7406-submodule-update.sh, donde se añadió un script de prueba para verificar que se ha solucionado la vulnerabilidad de seguridad.

Modificaciones ampliadas del código en el archivo de prueba T7406-submodule-update.sh, en el que se detallan las configuraciones de prueba para las rutas de los submódulos y los enlaces simbólicos

Del análisis a la explotación

Análisis del flujo de trabajo de los enlaces simbólicos y los submódulos en Git

Además de la información obtenida del análisis del parche y la descripción de la vulnerabilidad CVE-2024-32002, OPSWAT se dedicaron a investigar el flujo de trabajo de los enlaces simbólicos y los submódulos en Git. Desglosaron la secuencia de eventos que tiene lugar cuando un usuario clona un repositorio:

Git comienza descargando archivos y directorios del repositorio principal.
Utiliza las definiciones especificadas en los archivos de enlaces simbólicos para recrear los enlaces simbólicos correspondientes en el sistema de archivos local.
Si el enlace simbólico apunta a un archivo existente, el enlace funcionará; de lo contrario, el enlace seguirá sin funcionar hasta que se restaure el destino.
Si el repositorio se clona con la opción --recursive, Git clona los submódulos (repositorios externos) y los coloca en las rutas de directorio indicadas en el archivo .gitmodules.
Si una ruta simbólica forma parte de la ruta del submódulo (por ejemplo, util/module/test, donde util es una ruta simbólica que apunta a otro directorio, como symlink_folder), Git almacenará el contenido del submódulo en el directorio real al que hace referencia la ruta simbólica (por ejemplo, symlink_folder/module/test), al tiempo que permite el acceso a través de la ruta simbólica original.

Un diagrama de flujo visual que muestra los pasos para clonar un repositorio, descargar archivos y directorios, recrear enlaces simbólicos, clonar submódulos y cambiar a la ruta correcta

Análisis de la vulnerabilidad de seguridad de Git CVE-2024-32002

Creación de repositorios maliciosos

OPSWAT analizaron más a fondo la creación de repositorios maliciosos basándose en las actualizaciones realizadas enel archivot/t7406-submodule-update.sh y desglosaron este proceso en los siguientes pasos:

Creación de un repositorio que contenga un gancho post-checkout

Un fragmento de código de terminal que muestra los comandos para configurar un gancho «post-checkout» en Git, incluyendo la creación de directorios y la incorporación de scripts

Creación de otro repositorio que incluye un submódulo, ubicado en la ruta A/modules/x. El nuevo submódulo hace referencia al repositorio creado anteriormente.

Un fragmento de código de terminal que muestra el proceso para añadir un submódulo a un repositorio mediante comandos de Git

Creación de un enlace simbólico llamado «a» que apunta a la carpeta .git del índice de Git.

Un ejemplo de script de terminal que muestra los comandos para crear y confirmar un archivo .git como herramienta en un repositorio

Un diagrama de flujo que detalla un escenario de ataque en el que se añade un repositorio de hooks malicioso como submódulo a un repositorio principal, lo que da lugar a la ejecución de un script — Un diagrama que muestra cómo un atacante puede aprovechar la vulnerabilidad CVE clonando un repositorio

Comprender la vulnerabilidad de seguridad

Cuando un usuario clona un repositorio malicioso, creado en el paso anterior, utilizando la opción --recursive, se ejecutará el script malicioso del gancho «post-checkout», lo que permitirá al atacante comprometer el dispositivo del usuario.

Esta ejecución remota de código se produce porque el repositorio principal detecta un enlace simbólico denominado «a» que apunta al directorio .git al clonarlo. Con el modo recursivo activado, los submódulos también se incorporan al repositorio clonado. Este repositorio contiene una carpeta «hooks», que a su vez contiene el script del hook «post-checkout», y su directorio local se encuentra en A/modules/x.

Dado que «a» apunta al directorio.git y el sistema de archivos no distingue entre mayúsculas y minúsculas, «A» se interpreta como equivalente a «a». Esto induce a Git a escribir el script del gancho post-checkouten el directorio .git/modules/query/fast/hooks/. Si se encuentra un script de hook post-checkout en la carpeta .git/modules/{module_type}/{module_name}/hooks, se activará cuando se clone el repositorio principal con la opción --recursive. Como resultado, los atacantes pueden comprometer con éxito el dispositivo del usuario ejecutando código remoto.

Un diagrama que ilustra la interacción de la víctima con un repositorio malicioso, incluyendo la clonación, la descarga de submódulos y la ejecución involuntaria de scripts — Un diagrama que muestra el desarrollo del ataque

Simulación del aprovechamiento de una vulnerabilidad de Git

A partir de los hallazgos anteriores, OPSWAT crearon un repositorio principal y un gancho para simular la creación de un repositorio malicioso:

En un primer momento, se recomienda configurar Git para que siempre permita elarchivo «protocol.file», habilitar «core.symlinks» y establecer el nombre de la rama predeterminada como «main» (para evitar mensajes de advertencia).

Un fragmento de código de terminal que muestra los comandos para configurar globalmente los ajustes de Git relativos al manejo de enlaces simbólicos y la configuración de la rama predeterminada

Se ha añadido un script malicioso de gancho «post-checkout» al directorio «hooks». Para garantizar que el script «post-checkout» se pueda ejecutar en el dispositivo del usuario, el script bash que crea este gancho incluye el comando «chmod +x fast/hooks/post-checkout».

Un script de terminal que muestra un comando Python malicioso codificado incrustado en un gancho de Git posterior al checkout

Se crea un enlace simbólico en el repositorio principal que apunta al directorio .git.

Un script de terminal que muestra el proceso de guardar los cambios para incluir utilidades y un archivo .git en el repositorio

Captura de pantalla del listado de un directorio de repositorio en la que se muestran carpetas como «src», «libs» y «.gitmodules» en una interfaz de Git — El repositorio principal vulnerable

Captura de pantalla de la interfaz de un repositorio Git en la que se muestra un directorio con un gancho «post-checkout» — La carpeta */hooks* con un gancho post-checkout

Captura de pantalla que muestra los comandos de terminal para clonar un repositorio Git y una sesión de PowerShell con una conexión de red establecida — Cuando el usuario clona este repositorio malicioso, el atacante puede comprometer el dispositivo de la víctima.

Remediación

Para neutralizar la amenaza, los usuarios pueden desinstalar Git o aplicar el último parche de seguridad. Como alternativa, una solución como MetaDefender Endpoint notificar inmediatamente al usuario y mostrar todas las vulnerabilidades CVE conocidas en el entorno a través de su interfaz intuitiva. MetaDefender Endpoint detectar y mitigar las últimas vulnerabilidades CVE aprovechando sus capacidades, que incluyen más de 3 millones de puntos de datos y más de 30 000 vulnerabilidades CVE asociadas con información sobre su gravedad. Al implementar cualquiera de estas contramedidas, el CVE quedará totalmente contenido, eliminando el riesgo de un ciberataque devastador.

¿Estás listo para situar MetaDefender Endpoint primera línea de tu estrategia de ciberseguridad?

Habla con un experto