En Soccer obtuvimos una shell por Tiny File Manager por medio de la ejecucion de un archivo PHP, dentro encontramos un nuevo subdominio que es vulnerable a SQLi lo que nos permitio el acceso por SSH. Finalmente la escalada de privilegios a traves de un plugin que es ejecutado como root por dstat.
Nombre | Soccer |
---|---|
OS | Linux |
Puntos | 20 |
Dificultad | Facil |
IP | 10.10.11.194 |
Maker | |
|
Recon
nmap
nmap
muestra multiples puertos abiertos: http (80) y ssh (22).
|
|
Web Site
El sitio web redirige al dominio soccer.htb
.
|
|
El dominio presenta imagenes y noticias.
Directory Brute Forcing
feroxbuster
muestra la direccion /tiny.
|
|
Tiny File Manger
En la direccion nos encontramos con el gestor de archivos Tiny File Manager.
La documentacion muestra las credenciales por default.
|
|
Podemos subir y eliminar archivos unicamente en la direccion /tiny/uploads.
Asi mismo observamos el archivo bajo la misma direccion en el servidor.
|
|
User - www-data
Command Execution
Creamos un archivo PHP para la ejecucion del comando whoami utilizando dos funciones conocidas.
Tras visitar la direccion por el navegador observamos el resultado de la ejecucion.
Asi mismo observamos distintas solicitudes desde la maquina.
|
|
Shell
Ejecutamos shells localmente y creamos un archivo PHP para ejecutar una shell inversa.
|
|
Tras subir y “ejecutar” el archivo PHP obtuvimos una shell inversa como www-data.
|
|
User - Player
Observamos que el puerto 3000 esta localmente abierto.
|
|
Descubrimos un subdominio> soc-player.soccer.htb
.
|
|
Tras realizar una solicitud con curl observamos contenido parecido al sitio web del dominio.
|
|
Chisel - Reverse proxy
Utilizamos chisel
para obtener el puerto 3000 localmente. Ejecutamos chisel server en kali.
|
|
chisel client en la maquina.
|
|
Configuramos FoxyProxy en el navegador.
Y editamos el archivo proxychains.
|
|
Al visitar el puerto 3000 observamos un sitio similar al dominio.
Web User
Registramos un usuario nuevo.
Tras autenticarnos nos muestra un formulario, segun parece para verificar el numero de ticket.
Tras varios intentos no obtuvimos ningun tipo de respuesta. Sin embargo tras verificar la consola observamos que intenta realizar una conexion al subdominio que encontramos anteriormente, websocket.
Agregamos el subdominio apuntando a nuestra direccion local.
|
|
Con ello logramos obtener una respuesta al ingresar un valor en el formulario, en este caso el ticket no existe.
Observando las solicitudes que realiza el sitio, vemos que envia el id con el valor del formulario.
User - Player
SQLi WebSocket
Intentamos con distintos ‘payloads’ en el parametro id, pero no conseguimos informacion. Tras investigar sobre WebSockets nos topamos con el post Automating Blind SQL injection over WebSocket donde se expone una explotacion de SQLi utilizando sqlmap y un script que obtiene las solicitudes de sqlmap, realiza la conexion con el servidor, obtiene la respuesta y la envia a sqlmap, como si fuera un “intermediario”. En este caso modificamos el script:
|
|
Ejecutamos el script utilizando proxychains.
|
|
Por otro lado ejecutamos sqlmap en la direccion local de nuestro script. Vemos que sqlmap logro obtener informacion.
|
|
Logramos obtener credenciales de la base de datos soccer_db para el usuario player.
|
|
SQLMap tambien tiene soporte para websocket, por lo que la forma mas sencilla seria la siguiente
|
|
Shell
Ingresamos por SSH y realizamos la lectura de flag user.txt
.
|
|
Privesc
Tras enumerar los ficheros SUID encontramos doas
.
|
|
La configuracion muestra que es posible ejecutar dstat como root por este usuario.
|
|
Al ejeutar el fichero nos muestra informacion del sistema.
|
|
Plugin to root
Analizamos el archivo, se muestra que existen directorios donde se almacenan plugins.
|
|
Observamos que en uno de los directorios tenemos permisos de escritura.
|
|
Tomando como ejemplo uno de los plugins (/usr/share/dstat/) creamos uno propio el cual ejecuta el comando id
.
|
|
Lo almacenamos en el directorio /usr/local/share/dstat
.
|
|
Observamos que al listar los plugins se muestra el nuestro.
|
|
Tras ejecutar el plugin vemos el resultado de la ejecucion de id
.
|
|
Shell
Creamos una clave SSH para el usuario player.
|
|
Editamos nuestro plugin para agregar la clave publica al archivo authorized_keys
de root.
|
|
Tras la ejecucion del plugin, ingresamos a traves de SSH como root, logrando acceder a la flag root.txt
.
|
|