🟠Assertion101
Write-up de la máquina Assertion101 de Proving Grounds #writeup #walkthrough
Last updated
Write-up de la máquina Assertion101 de Proving Grounds #writeup #walkthrough
Last updated
Comenzamos enumerando que servicios tiene abiertos la máquina Assertion101.
La máquina tiene abiertos los puertos 22 y 80. El siguiente paso será la enumeración profunda de estos servicios.
Servicios abiertos
Puerto 22 -> SSH -> OpenSSH 7.6
Puerto 80 -> HTTP -> Apache httpd 2.4.29
La máquina objetivo está ejecutando un servicio HTTP en el puerto 80. Vamos a ver el contenido en el navegador Web.
Vemos la página Web de un negocio relacionado con la actividad física.
Vamos a navegar un poco por el sitio Web en busca de posibles puntos vulnerables. En la parte superior tenemos el menú de navegación del sitio Web. Al pulsar sobre alguno de ellos, vemos la siguiente petición que puede ser interesante.
Este parámetro "page" puede ser vulnerable a LFI. Vamos a realizar una de las comprobaciones más comunes para probar esta vulnerabilidad.
Recibimos el mensaje "Not so easy brother!", lo cual puede indicar que si es vulnerable a LFI pero necesitamos montar un payload más complejo para perpetrar la explotación de la vulnerabilidad.
Si te encuentras con un LFI complicado que parece estar filtrando cadenas de desplazamiento como ".." y responde con algo como "Intento de hackeo" o "¡Buen intento!", un payload de inyección de 'assert' podría funcionar.
Partiendo del nombre de la máquina y las extensiones de archivos php, podemos suponer que la máquina trata sobre asserts en PHP. Buscando un poco por Internet, encontramos los siguientes posibles payloads.
Estos payloads parecen funcionar y empezamos a obtener resultados.
Es hora de obtener una shell inversa. Podemos obtener una shell desde nuestra máquina copiando la shell desde /usr/share/webshells/php/php-reverse-shell.php y editándola con la IP y el puerto de nuestra máquina local.
Comenzamos configurando nuestra IP y puerto de escucha en la shell.
Ahora vamos a cargarla. Para ello, debemos levantar un servidor http con Python. Por otro lado, configuramos un oyente nc en el puerto 1234.
Y ya tendriamos acceso al sistema como usuario "www-data"
Otra forma de obtener acceso al sistema es ejecutando una shell de bash aprovechando la vulnerabilidad presente. ¿Cómo? De la siguiente manera:
Recordamos que para detectar la vulnerabilidad de LFI, hemos utilizado el siguiente payload ' and die(show_source('/etc/passwd')). Ahora vamos a modificarlo para integrar la shell de bash. El payload quedaría de la siguiente manera.
Veamos si funciona el payload que hemos creado.
Y ya volveremos a tener acceso al sistema.
El siguiente paso será la búsqueda de la flag local.txt
Comenzamos enumerando si el usuario "www-data" puede ejecutar algún comando con privilegios pero necesitamos la contraseña para el usuario "www-data", así que este no es un vector de escalada.
El siguiente punto a enumerar es el de los binarios con permisos de SUID.
Hay uno que llama especialmente la atención, aria2c.
Veamos si podemos encontrar infomación interesante en GTFOBins. Pero no aporta información que nos permita avanza aunque si parece el vector para la elevación de privilegios. GTFOBins nos indica que este binario sirve para sobreescribir archivos en el sistema y tiene permisos SUID, así que podemos tratar de hacer varias cosas.
Ya que este binario nos permite sobreescribir archivos en el sistema, ¿por qué no añadir un usuario al archivo /etc/passwd? Lo vamos a hacer de la siguiente manera:
Después de leer la página de manual de aria2c, parece que podemos sobrescribir un archivo usando las opciones "-d" y "-o". Para probar esto, generamos una contraseña para el usuario root usando el comando "openssl passwd -1 -salt root pass123" y luego descargamos el archivo "/etc/passwd" para poder agregar la contraseña recién creada.
Ahora actualizamos el archivo "passwd" con esta nueva contraseña para el usuario "root".
Ahora, aprovechando el binario con permisos SUID, "aria2c", vamos a volver a cargar en la máquina víctima este archivo actualizado.
Comprobamos si se ha cargado correctamente y probamos.
Y ya tendríamos acceso al sistema como usuario "root".
Sabemos que aria2c se puede utilizar para reemplazar la información de algunos archivos importantes. En esta ocasión, vamos a emplearlo para sobrescribir el archivo authorized_keys del usuario root.
Para obtener nuestra clave pública en la máquina remota, es necesario iniciar un servidor web en la carpeta .ssh de nuestra máquina local. Si aún no hemos creado un par de claves SSH, podemos hacerlo utilizando el comando ssh-keygen.
En el directorio donde está el archivo authorized_keys, levantamos un servidor http con Python.
Ahora en la máquina objetivo ejecutamos:
Llegó la hora de comprobar si este método ha funcionado.
Solo quedará buscar la flag proof.txt para finalizar la máquina.
