Squashed
Squashed es una máquina Linux de dificultad fácil que combina la identificación y el aprovechamiento de configuraciones incorrectas en recursos compartidos NFS mediante la suplantación de identidad de usuarios. Además, la máquina incorpora la enumeración de una pantalla X11 en la escalada de privilegios al hacer que el atacante tome una captura de pantalla del escritorio actual.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Squashed. Este resultado lo almacenaremos en un archivo llamado allPorts.
A través de la herramienta de extractPorts, la utilizaremos para extraer los puertos del archivo que nos generó el primer escaneo a través de Nmap. Esta herramienta nos copiará en la clipboard los puertos encontrados.
Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX para posteriormente trabajar con ellos. En el resultado, comprobamos que se encuentran abierta una página web de Apache el servicio rpcbind habilitado.
Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.
Accederemos a http://localhost y verificaremos el resultado en un formato más cómodo para su análisis.
Web Enumeration
Realizaremos una comprobación de las tecnologías que son utilizadas en el sitio web.
Accedemos a http://10.10.11.191 y comprobamos la siguiente página web en la cual en una enumeración inicial no logramos obtener ningún dato relevante.
Realizaremos un escaneo de directorios y páginas web a través de la herramienta de dirsearch, pero tampoco logramos obtener ningún resultado interesante.eeeeeeeeeeeeeeeeeeeeeee
Initial Access
NFS Enumeration
Identificamos que el puerto 111/tcp estaba abierto, lo que indica la presencia del servicio RPCbind. Este servicio es clave en entornos UNIX/Linux, ya que permite a los clientes localizar otros servicios RPC, como NFS (Network File System), que suele ejecutarse en puertos dinámicos.
Uno de los principales servicios que dependen de RPCbind es NFS, utilizado para compartir archivos y directorios entre sistemas en red. La presencia del puerto 111 abierto podría indicar un NFS accesible, lo que nos permitiría:
Montar directorios remotos.
Leer o modificar archivos si los permisos lo permiten.
Escalar privilegios si el directorio compartido contiene información sensible.
Aquí ya confirmamos que el sistema tiene NFS habilitado porque aparece el servicio nfs (programa 100003) en los protocolos TCP y UDP, tanto en IPv4 como en IPv6.
Además, vemos el servicio mountd (100005), que se encarga de gestionar los puntos de montaje de NFS. Esto significa que podríamos listar los sistemas de archivos compartidos y, si los permisos lo permiten, montarlos en nuestra máquina.
Al realizar un escaneo con showmount, encontramos que el sistema tiene dos directorios exportados:
/home/ross, accesible desde cualquier host (*).
/var/www/html, igualmente accesible desde cualquier host (*).
Esto significa que:
Montar directorios remotos: Ambos directorios están disponibles para ser montados por cualquier cliente, lo que nos permitió explorar sus contenidos.
Leer o modificar archivos: Dado que los directorios son accesibles sin restricciones, tuvimos la posibilidad de leer y modificar archivos si los permisos lo permitían.
Escalada de privilegios: Si alguno de estos directorios contiene archivos sensibles o configuraciones incorrectas, podríamos haber escalado privilegios en el sistema.
Crearemos los siguientes directorios para montar los directorios NFS en ellos.
Utilizando la información obtenida, se montaron los directorios exportados a través de NFS. El primer directorio montado fue /home/ross, lo que permitió acceder a varios subdirectorios, tales como "Desktop", "Documents", "Downloads", entre otros.
Posteriormente, se intentó montar el directorio /var/www/html, pero al intentar listar los archivos dentro del directorio, se encontraron problemas de permisos. Los siguientes errores de acceso se mostraron al intentar acceder a los archivos dentro de este directorio:
Durante la exploración del directorio /home/ross, encontramos el archivo Passwords.kdbx dentro de la carpeta Documents. Este archivo es una base de datos de KeePass, que generalmente contiene credenciales encriptadas.
Se realizaron intentos para obtener el hash de la contraseña maestra y acceder al contenido del archivo, pero no se obtuvo ningún resultado positivo. Por lo tanto, decidimos descartar este archivo por el momento.
En el directorio /home/ross, encontramos el archivo .Xauthority. Este archivo, que está relacionado con las sesiones X11, podría ser útil para una posible escalada de privilegios. Aunque no se ha explorado a fondo, hay una posibilidad de que podamos aprovecharlo para acceder a la sesión de otro usuario o ejecutar comandos con privilegios más altos si conseguimos explotarlo de la manera adecuada.
Abusing owners assigned to NFS shares by creating new users on the system (Get Access to Web Root)
Al intentar acceder al archivo .Xauthority con nuestro usuario normal de Kali, recibimos un error de permiso denegado, lo que impide visualizar su contenido en este momento.
En este caso, procedimos a crear un nuevo usuario, gzzcoo, y nos cambiamos a su cuenta para explorar el sistema. Al intentar ver el contenido del archivo .Xauthority, conseguimos visualizar datos que indican que está relacionado con el sistema de autenticación MIT-MAGIC-COOKIE, lo que podría ser útil para futuras pruebas, posiblemente relacionadas con la escalada de privilegios. Sin embargo, no se extrajo información relevante de inmediato.
Al realizar una búsqueda en el directorio /mnt/html, verificamos que el propietario del directorio raíz es www-data, y el grupo asignado tiene el identificador 2017. Sin embargo, encontramos que el acceso a varios subdirectorios como index.html, images, css, y js está restringido debido a permisos denegados.
Tras modificar el identificador de usuario de gzzcoo para que coincida con el grupo 2017, logramos acceder al directorio /mnt/html. Dentro de este directorio, confirmamos que los archivos ahora están bajo el control del usuario gzzcoo con el grupo www-data. Esto incluye los subdirectorios css, images, y js, así como el archivo index.html, que tiene permisos de lectura solo para el usuario gzzcoo y el grupo www-data.
Creating a web shell to gain system access
Probamos escribir un archivo en el directorio /mnt/html con el siguiente comando. El archivo gzzcoo.txt se creó correctamente con permisos rw-rw-r-- para el usuario gzzcoo y el grupo gzzcoo, lo que significa que tenemos permisos suficientes para escribir en este directorio.
Verificamos que, dado que subimos el archivo gzzcoo.txt en /var/www/html y la máquina tenía una página web montada, al hacer un curl hacia la URL correspondiente, obtuvimos el resultado del archivo creado en la montura NFS.
El contenido del archivo gzzcoo.txt se mostró correctamente como gzzcoo was here, lo que confirma que la escritura en el directorio fue exitosa y accesible a través del servidor web.
Probamos realizar lo mismo con un archivo PHP para ver si la página web lo interpretaba correctamente. Creamos el archivo gzzcoo.php con el siguiente contenido:
Al hacer la petición HTTP al archivo gzzcoo.php mediante el siguiente comando, se confirma que la página web está interpretando el archivo PHP correctamente, lo que indica que hemos logrado ejecutar código PHP en el servidor web a través de la montura NFS.
Dado que hemos verificado que podemos crear archivos en el directorio /var/www/html y que la página web interpreta código PHP, el siguiente paso será cargar una webshell para ganar acceso al sistema. De esta forma, podremos ejecutar comandos en el servidor y, si la configuración lo permite, escalar privilegios o ejecutar cualquier otra acción maliciosa.
Una vez que subimos la webshell y verificamos que es capaz de ejecutar comandos, realizamos una prueba con el comando id para comprobar los privilegios del usuario bajo el cual se está ejecutando la web. La respuesta muestra que estamos operando bajo el usuario alex, con un UID y GID asignados a este usuario.
Nos pondremos en escucha con nc para recibir la Reverse Shell.
Utilizamos la webshell para ejecutar un comando bash que se conectará de vuelta a nuestra máquina en el puerto 443, creando así una reverse shell.
Después de ejecutar el comando, nuestra máquina escuchará en el puerto 443 y, al ejecutar el comando en la webshell, recibiremos una conexión inversa que nos proporcionará una shell interactiva en el sistema víctima. Logramos visualizar la flag de user.txt.
Al obtener la reverse shell, mejoramos la calidad de la shell con los siguientes pasos para obtener una TTY interactiva.
Privilege Escalation
Abusing Xauthority file (Pentesting X11)
Revisamos los permisos y grupos a los que forma parte el usuario alex, pero no logramos obtener nada interesante.
Volvimos a verificar la existencia del archivo .Xauthority en el directorio home del usuario ross, el cual sigue presente.
En este punto, verificamos la sesión activa del usuario ross con el comando w, y observamos que está conectado en tty7, que es el terminal asociado con la sesión gráfica. El proceso /usr/libexec/gnome-session-binary --systemd --session=gnome indica que está utilizando el entorno gráfico GNOME, y está ejecutándose en el display :0.
Este detalle es importante porque tty7 corresponde a la sesión gráfica activa, lo que nos da una pista de que podría ser posible aprovechar el display :0 para intentar acceder a aplicaciones gráficas o incluso escalar privilegios dentro del entorno gráfico de GNOME.
Al intentar revisar el entorno gráfico utilizando xdpyinfo y xwininfo en el display :0, encontramos que no tenemos los permisos adecuados para acceder a la información del servidor X. El error "No protocol specified" indica que no estamos autorizados para interactuar con el display :0, lo que limita nuestras opciones para obtener información sobre la sesión gráfica o intentar escalar privilegios a través de X11.
En el blog mencionado, se explica cómo el MIT-MAGIC-COOKIE-1 utiliza una clave de 128 bits generada y almacenada en el archivo ~/.Xauthority. Esta clave actúa como un "cookie" que el cliente envía al servidor, y si el servidor tiene una copia de este "cookie", permite la conexión. El problema es que cualquier usuario que tenga acceso a este archivo puede hacer uso de la clave y conectarse al servidor como si fuera el usuario legítimo. Este tipo de vulnerabilidad podría ser aprovechado para escalar privilegios si logramos acceder a este archivo ~/.Xauthority
Como mencionamos antes, no tenemos permisos suficientes para visualizar el archivo .Xauthority con el usuario alex, ya que al intentar acceder a él nos da un error de "Permiso denegado".
Recordando la montura NFS que realizamos previamente, accedimos al archivo .Xauthority mediante el usuario gzzcoo. Al estar montado el directorio, pudimos ver el contenido sin restricciones de permisos. Al ejecutar los comandos siguientes. Pudimos obtener el contenido codificado en base64 del archivo.
Para poder aprovechar la información obtenida en el archivo .Xauthority, lo que hicimos fue decodificar el contenido base64 y almacenarlo en el archivo /tmp/.Xauthority. De esta manera, replicamos el archivo original en nuestro sistema, lo que nos permite emular la autenticación en el servidor X11.
Al exportar la variable de entorno XAUTHORITY para que apunte al archivo /tmp/.Xauthority, hemos configurado el sistema para que utilice las credenciales del archivo que replicamos. Esto permite que las aplicaciones gráficas, como xauth o cualquier aplicación X11, ahora utilicen ese archivo para autenticar al usuario alex en el servidor X11.
Al ejecutar el comando xwininfo -root -tree -display :0, encontramos que una de las ventanas abiertas es "Passwords - KeePassXC", que corresponde a la aplicación KeePassXC, una herramienta de gestión de contraseñas.
Esto indica que el usuario ross tiene abierta una ventana de KeePassXC, y es posible que contenga información sensible como contraseñas. Aprovechando que la aplicación está visible en el servidor X11, tenemos una posible vía para acceder a los datos guardados en ella.
Si conseguimos tomar control sobre la ventana de KeePassXC o interactuar con la sesión, podríamos extraer las contraseñas almacenadas en su base de datos.
Taking a screenshot of another user's display
Al ejecutar el comando xwd -root -screen -silent -display :0 > screenshot.xwd, hemos tomado una captura de pantalla de la sesión del usuario ross en el servidor X11. La imagen se ha guardado en el archivo screenshot.xwd.
Este archivo contiene la imagen de la pantalla del usuario ross, la cual puede ser útil para obtener más información visual sobre su actividad. Ahora, para visualizar la imagen, podemos convertirla a un formato más estándar como PNG o JPEG utilizando una herramienta como xwdtopnm o convert.
Nos pondremos en escucha con nc para recibir el archivo screenshot.xwd.
Enviaremos el archivo mediante el /dev/tcp.
Al convertir el archivo screenshot.xwd a un formato más accesible como PNG utilizando el comando convert screenshot.xwd screenshot.png, ahora tenemos una imagen que podemos visualizar. Al abrirla con el comando open screenshot.png, podemos observar la captura de pantalla de la sesión del usuario ross en su escritorio.
Al visualizar la captura de pantalla realizada, verificamos que el usuario ross tenía una ventana de KeePassXC abierta en su sesión y en la cual aparecían las credenciales del usuario root.
Probamos de autenticarnos como usuario root con las credenciales obtenidas y logramos el acceso. Finalmente, comprobamos la flag de user.txt.
Última actualización
¿Te fue útil?