ScriptKiddie
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
ScriptKiddie es una máquina Linux de dificultad fácil que presenta una vulnerabilidad de Metasploit (), junto con ataques clásicos como la inyección de comandos del sistema operativo y una configuración sudo insegura sin contraseña. El punto de apoyo inicial en la máquina se obtiene cargando un archivo .apk malicioso desde una interfaz web que llama a una versión vulnerable de msfvenom para generar cargas útiles descargables. Una vez que se obtiene el shell, el movimiento lateral a un segundo usuario se realiza inyectando comandos en un archivo de registro que proporciona una entrada no higienizada a un script Bash que se activa al modificar el archivo. A este usuario se le permite ejecutar msfconsole como root a través de sudo sin proporcionar una contraseña, lo que resulta en la escalada de privilegios.
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina ScriptKiddie. Este resultado lo almacenaremos en un archivo llamado allPorts.
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 Werkzeug y el servicioSSH.
Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.
Realizaremos a través de la herramienta de whatweb un reconocimiento inicial de las tecnologías que utiliza la aplicación web.
Accedemos a http://10.10.10.226:5000 y nos encontramos con la siguiente página web. Al parecer, esta aplicación web ofrece diversas tools de pentesting, entre las cuales podemos observar los siguientes tres apartados.
Nmap --> Permite realizar un escaneo de los 100 puertos TCP más comunes de la dirección IP que se le proporcione.
Payloads --> Permite utilizar msfvenom para crear un meterpreter bin para generar una RevShell.
Sploits --> Permite realizar una consulta a través de la herramienta searchsploit en busca de vulnerabilidades ya conocidas (CVE).
Realizaremos una enumeración de las diferentes funcionalidades que disponemos, para poder encontrar algún vector de entrada, etc.
En el primer caso, indicamos la dirección IP 127.0.0.1 para que la herramienta se intente realizar un escaneo al mismo servidor para poder localizar algún puerto interno que se encontrase abierto.
En el resultado obtenido, se nos muestra los mismos puertos los cuales habíamos localizado en el reconocimiento inicial conNmap.
Por otro lado, también probamos de intentar realizar un Command Injection de diversas maneras, a través de ; && ||, etc. Pero tampoco obtuvimos resultados.
A continuación, probamos la siguiente tool que ofrecía la aplicación web. En este primer intento para comprobar cómo funcionaba, se le especificó valores normales y comprobamos el resultado obtenido en la respuesta del servidor. También ofrece una opción de template file, que revisaremos más adelante si podemos hacer un File Upload o intentar realizar otras acciones.
Intentamos realizar nuevamente un Command Injection, pero no logramos obtener resultados.
Para finalizar, realizamos una comprobación de la tool llamada sploits la cual se basa en la herramienta searchsploit para lograr encontrar vulnerabilidades ya reportadas. Realizamos una búsqueda simple y comprobamos que se nos mostraba el resultado de las vulnerabilidades encontradas en la respuesta por parte del servidor.
En este caso, al intentar realizar el Command Injection, se nos indicaba un mensaje indicando stop hacking me - will hack you back. Dando a entender, que paremos de intentar hackear la aplicación web o nos realizaría lo mismo.
Dado que en este punto, se nos mostró este mensaje de error inusual que en los anteriores funcionalidades no nos apareció, decidimos profundizar más en intentar realizar un Bypass al Command Injection, pero no logramos obtener resultados.
Dado que no disponemos de mucha información sobre la página web y revisando diferentes maneras de intentar realizar un Command Injection los cuales no obtuvimos resultado, decidimos realizar lo siguiente.
En la herramienta llamada payloads de la aplicación web, sabemos que utiliza la herramienta de msfvenom de Metasploit. Desconocemos la versión exacta de la herramienta, pero intentamos buscar a ver si había alguna vulnerabilidad en el cual nos encontramos con el siguiente CVE-2020-7384.
No perderíamos nada intentando realizar la explotación de la siguiente vulnerabilidad, debido que tampoco tenemos gran cosa para avanzar y ganar acceso al sistema, así que nos pondremos manos a la obra.
La trama msfvenom en Metasploit de Rapid7 maneja archivos APK de una manera que permite a un usuario malicioso crear y publicar un archivo que ejecutaría comandos arbitrarios en la máquina de la víctima
Nos copiaremos a nuestro directorio actual de trabajo el exploit que nos muestra disponible la herramienta de searchsploit.
Modificaremos el script de Python para realizar el Command Injection. En este caso, para verificar que la aplicación web es vulnerable, lo que inyectaremos es un comando para que realice una petición cURL a un recurso que no existe para comprobar en nuestro servidor web que se ha realizado dicha petición. En caso de que nos llegase un GET, confirmaríamos que existe el Command Injection.
Una vez tengamos el exploit modificado, lo ejecutaremos y comprobaremos que se nos genera un archivo APK malicioso. Para realizar la explotación, la víctima deberá ejecutar msfvenom con nuestro archivo APK malicioso.
Levantaremos un servidor web con Python para realizar la prueba de la confirmación de la vulnerabilidad.
En el apartado de payloads dejaremos la siguiente configuración y en template file subiremos el evil.apk que contiene nuestre payload malicioso. Le daremos a la opción de generate.
Al darle a dicha opción, en la respuesta por parte del servidor se nos muestra el siguiente mensaje de error.
Pero por parte nuestra, en nuestro servidor web se ha recibido una petición por GET desde la dirección IP víctima. Con lo cual, hemos confirmado que la versión que utiliza la aplicación web es Msfvenom 6.0.11 la cual es vulnerable a Command Injection, además hemos podido confirmar la explotación de la vulnerabilidad.
Con lo cual, el siguiente paso será lograr obtener acceso al sistema. Para ello, crearemos un script en Bash que realice la Reverse Shell. Este script lo deberemos compartir a través de un servidor web.
Editaremos nuevamente el exploit y le indicaremos que realice una petición con cURL sobre nuestro script de Bash y se ejecute en una bash el script que estamos compartiendo.
En una nueva terminal, nos pondremos en escucha con nc para recibir la Reverse Shell.
Utilizaremos nuevamente el exploit para generar un nuevo archivo APK malicioso.
Realizaremos los mismos pasos y subiremos este nuevo archivo APK malicioso que hemos generado en el paso anterior.
Al utilizar la herramienta vulnerable, finalmente comprobamos que hemos ganado acceso al sistema a través del usuario kid y podemos visualizar la flag user.txt.
Al obtener la reverse shell, mejoramos la calidad de la shell con los siguientes pasos para obtener una TTY interactiva.
Realizando enumeración en el directorio /home, nos encontramos con el directorio personal de un nuevo usuario llamado pwn. Este directorio contenía otro directorio llamado recon el cual no disponíamos de acceso y de un script llamado scanlosers.sh el cual no podíamos ejecutar pero si visualizar su contenido.
El script extrae direcciones IP de un archivo de logs, elimina duplicados y escanea los 10 puertos más comunes con Nmap, guardando los resultados en recon/{IP}.nmap. Luego, si el log tiene contenido, lo vacía.
La línea while read ip; do sh -c "nmap ... ${ip}" & done usa sh -c, lo que permite ejecución de comandos si $log contiene una entrada manipulada, como:
Si el script lo procesa, ejecutará whoami.
Por otro lado, también comprobamos que podemos revisar la configuración de la aplicación web que hemos logrado vulnerar anteriormente. La configuración se encuentra en el siguiente script de Python: /home/kid/html/app.py.
A través del usuario kid, tenemos la capacidad de revisar el código. Si recordamos, anteriormente intentamos realizar un Command Injection en la herramienta searchsploit dentro de la aplicación web. En respuesta, se nos mostró un mensaje indicando que dejáramos de intentar hackear la aplicación, e incluso nos amenazaba con hacer lo mismo contra nosotros.
Al analizar el código de la aplicación, encontramos el siguiente contenido:
Este código abre el archivo /home/kid/logs/hackers y registra la fecha y hora actuales, junto con la srcip proporcionada en la aplicación web. Luego, muestra el mensaje: stop hacking me - well hack you back.
La variable regex_alphanum se define en el código de la siguiente manera:
Esta regex solo permite letras (A-Z, a-z), números (0-9), espacios y puntos (.).
Gracias a esta validación, no es posible inyectar caracteres especiales en text, lo que evita un Command Injection directo en searchsploit.
Si el input text no cumple con la regex, la aplicación escribe la dirección srcip en el archivo /home/kid/logs/hackers.
Problema: srcip no pasa por ninguna validación, lo que permite manipular su contenido.
Para verificar el formato con el cual se almacenan las entradas en el archivo /home/kid/logs/hackers, realizamos la siguiente comprobación desde nuestro equipo local utilizando Python 3.
El resultado obtenido fue el siguiente formato:
[2025-03-02 17:40:10.917029] 10.10.14.2
De este modo, confirmamos que los logs siguen el formato:
[YYYY-MM-DD HH:MM:SS.microsegundos] IP
Este formato se utiliza para registrar las direcciones IP en el archivo de logs, permitiéndonos manipular srcip sin ningún tipo de validación o filtrado.
Realizamos una prueba de escritura simulada en el archivo de logs /home/kid/logs/hackers, utilizando el formato indicado en la aplicación web.
Ejecutamos el siguiente comando: echo '[2025-03-02 17:40:10.917029] 10.10.14.2' > hackers, y luego comprobamos el contenido del archivo con cat hackers, obteniendo el resultado [2025-03-02 17:40:10.917029] 10.10.14.2.
Posteriormente, insertamos un comando de pausa y, después de 1 segundo, volvimos a verificar el archivo con echo 'pause'; sleep 1; cat hackers; echo 'done', observando que el contenido desaparecía.
Esto sugiere que el script se ejecutó automáticamente al recibir el log simulado, lo que implica que podría haber una tarea programada (como una tarea cron) o algún proceso en segundo plano que limpia los logs inmediatamente después de procesarlos. Además, es posible que el script sea ejecutado por el usuario pwn, quien es el propietario del script, lo que indicaría que dicho usuario tiene configurado algún mecanismo que activa la ejecución del script al escribir en el archivo de logs.
Volvimos a comprobar el funcionamiento del script, el cual revisa el contenido del archivo /home/kid/logs/hackers para obtener el tercer valor de cada línea (en este caso, la dirección IP) utilizando el comando cut. A continuación, el script utiliza sort para ordenar y obtener un listado único de IPs. Luego, para cada IP obtenida, ejecuta un escaneo de puertos con nmap en segundo plano para las 10 principales puertos. El resultado de cada escaneo se guarda en un archivo en el directorio recon/, pero la salida estándar y de error se redirige a /dev/null para ocultar la salida.
El script también incluye una verificación para comprobar si el archivo de logs contiene alguna línea; si es así, borra el contenido del archivo.
Realizamos una prueba para verificar qué valor es el que el script maneja al procesar el archivo de logs. Ejecutamos el siguiente comando en el sistema:
echo '[2025-03-02 17:40:10.917029] 10.10.14.2' | cut -d' ' -f3-
El resultado fue:
10.10.14.2
Esto confirma que el script toma la tercera columna de cada línea en el archivo de logs, que corresponde a la dirección IP (en este caso, 10.10.14.2).
El valor extraído es luego utilizado por el script en la variable ip para realizar el escaneo de puertos con Nmap.
Sin embargo, al no validar correctamente el valor de la IP, es posible que se realice un Command Injection. Para demostrar esto, realizamos una prueba en la que inyectamos un comando adicional. En este caso, aprovechamos el formato del valor extraído, ya que el script solo toma la tercera columna, sin validar su contenido completamente.
Ejecutamos el siguiente comando:
echo 'x x x 10.10.14.2; curl 10.10.14.2/gzzcoo #' | cut -d' ' -f3-
El resultado obtenido fue:
x 10.10.14.2; curl 10.10.14.2/gzzcoo #
Aquí, la parte 10.10.14.2; curl 10.10.14.2/gzzcoo # se inyecta correctamente en el comando, lo que indica que podemos ejecutar comandos adicionales (en este caso, un curl) junto con el escaneo de puertos de nmap. El # asegura que el resto de la línea se comente y no interfiera con el comando. Esto demuestra una vulnerabilidad de Command Injection, lo que podría permitirnos ejecutar comandos arbitrarios en el sistema.
La sintaxis que recibiría el script scanlosers.sh cuando le pasemos esos valores sería algo parecido a esto.
Para realizar la prueba final para verificar el Command Injection nos levantaremos un servidor web para ver si recibimos una petición por GET a un recurso inexistente.
Escribiremos el siguiente contenido en el archivo hackers donde llegan los logs, en este ejemplo pondremos en marcha lo explicado anteriormente.
Por parte de nuestro servidor web, confirmamos que se ha realizado la petición con cURL hacía nuestro servidor web, confirmamos finalmente el Command Injection.
Por lo tanto, el siguiente paso será lograr obtener acceso a través de una Reverse Shell con el usuario que ejecuta el script, que probablemente sea pwn.
Inyectaremos el siguiente código en el archivo de logs hackers.
Confirmaos que hemos recibido correctamente el acceso a la máquina con el usuario pwn.
Al obtener la reverse shell, mejoramos la calidad de la shell con los siguientes pasos para obtener una TTY interactiva.
Revisando los permisos de sudoers que dispone el usuario, nos encontramos que puede ejecutar el binario de msfconsole como usuario root sin proporcionar credenciales de este mismo.
Realizaremos los pasos de la explotación del binario para poder ganar acceso como usuario root. Comprobamos que finalmente logramos obtener una shell como usuarioroot y podemos visualizar la flag root.txt.
A través de la herramienta de , 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.
Accederemos a y verificaremos el resultado en un formato más cómodo para su análisis.
A través de la herramienta de comprobaremos la manera de explotar este binario con permisos de sudo sobre él. Esta herramienta tiene como funcionalidad realizar la consulta a GTFOBins pero localmente.
