RCE with Mercurial (hg) hooks

Mercurial (hg) es un control de versiones, primo de Git. Como Git, dispara hooks: scripts que se ejecutan automáticamente al ocurrir un evento del repositorio (pre-commit, update, post-pull...). Un hook se define en el fichero de configuración .hgrc del repositorio o del usuario:

[hooks]
post-pull = /tmp/shell.sh

El vector aparece cuando podemos ejecutar hg como otro usuario (típicamente vía sudo) sobre un repositorio cuya configuración controlamos. Si tenemos un sudo -l del estilo (dev) /usr/bin/hg pull /home/dev/app-production/, al lanzar el pull Mercurial leerá el .hgrc aplicable y ejecutará el hook post-pull con la identidad del usuario destino, dándonos ejecución como él.

# .hgrc con el hook apuntando a nuestro script
sudo -u dev /usr/bin/hg pull /home/dev/app-production/

Un detalle práctico: el usuario destino debe poder leer el .hgrc y el repositorio. Si el original está en un home inaccesible para él (por permisos), se reconstruye el entorno en una ruta común como /tmp (mkdir .hg; cp .hgrc .hg/hgrc) para evitar errores de acceso. Mercurial además exige que el usuario figure como trusted para honrar el .hgrc ajeno.

Cómo detectarlo. La firma es un sudo hg pull/update en /var/log/auth.log seguido, en el host, del proceso hg (corriendo como el usuario destino) lanzando sh/bash como hijo, que es la ejecución del hook (auditd/Sysmon for Linux sobre execve con ppid=hg), algo que un pull legítimo no hace. En disco, un .hg/hgrc/.hgrc con una sección [hooks] apuntando a un script en una ruta escribible (/tmp) es el indicador (FIM). El mismo patrón aplica a git con hooks (core.fsmonitor, post-checkout).

Defensa. No conceder sudo sobre hg (ni git) apuntando a repositorios escribibles por el atacante; los hooks ejecutan código arbitrario por diseño. Si hace falta, restringir con rutas fijas y propiedad controlada, y desconfiar de los ficheros de configuración del repositorio.