Nunchucks
Nunchucks es una máquina sencilla que explora una inyección de plantilla del lado del servidor (SSTI) basada en NodeJS que conduce a un error de AppArmor que ignora el perfil de AppArmor del binario mientras ejecuta scripts que incluyen el contenido de la aplicación perfilada.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Nunchucks. 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 unas páginas web de Nginx y el servicio de SSH.
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.
Añadiremos la siguiente entrada en nuestro archivo /etc/hosts.
Web Enumeration
Realizaremos una comprobación de las tecnologías que utiliza el sitio web.
Accederemos a https://nunchuks.htb y nos encontramos con la siguiente página web, en la cual en una enumeración básica, no logramos obtener resultado relevante.
Realizamos una enumeración de directorios y páginas web que pudiera tener la página web, nos encontramos con el siguiente resultado.
Disponemos en https://nunchucks.htb/signup una página de registro de usuarios. Al intentar registrarnos como un nuevo usuarios, se nos indicaba que no podíamos realizar dicha acción.
Subdomain Enumeration
Realizamos una enumeración de subdominios, entre los cuales logramos encontrar un nuevo subdominio llamado store.nunchucks.htb.
Añadiremos esta nueva entrada en nuestro archivo /etc/hosts.
Realizaremos una comprobación de las tecnologías que utiliza el sitio web.
Accedemos a https://store.nunchucks.htb y nos encontramos con la siguiente página web.
Realizamos una enumeración de directorios y archivos a través de feroxbuster y no logramos obtener algún directorio o archivo interesante.
Initial Access
Node.js SSTI (Server Side Template Injection)
Realizando diversas pruebas en la página web, el único campo que nos parece interesante es en el cual nos permite indicar nuestro correo electrónico y posteriormente en el output por parte del servidor se imprime el input introducido.
Con lo cual, nos abre la posibilidad de que quizás exista un Template Engine y podamos intentar realizar un SSTI (Server Side Template Injection).
Revisaremos nuevamente las tecnologías de la página web, y comprobamos que utiliza Node.js como lenguaje de programación.
Intentamos realizar una inyección de SSTI básica, pero se nos indica que debemos introducir un correo válido.
Por lo tanto, para intentar eludir esta restricción, interceptaremos la solicitud con BurpSuite. En la solicitud, verificamos que el input y output se encuentran en un formato JSON
Intentamos realizar la siguiente inyección básica de SSTI para comprobar si era vulnerable. En la respuesta por parte del servidor, comprobamos que se ha interpretado la operación y nos ha aparecido el resultado de 7*7, con lo cual todo parece indicar que podemos realizar el SSTI correctamente.
En el siguiente blog, se nos mencionan diversas técnicas y payloads para identificar el tipo de Template Engine que nos enfrentamos.
A través del siguiente polyglot payload, intentaremos enumerar el tipo de Template Engine. En este caso, solamente pudimos comprobar que se nos mostraba errores JSON, con lo cual nos hace afirmar que detrás quizás esté Node.js como se nos indicaba en el Wappalyzer.
En caso de vulnerabilidad, se puede devolver un mensaje de error o el servidor puede generar una excepción. Esto se puede utilizar para identificar la vulnerabilidad y el motor de plantillas en uso.
Para identificar la vulnerabilidad, se puede seguir la siguiente lista de tareas pendientes:
Detectar dónde existe la inyección de plantillas Identificar el motor de plantillas y validar la vulnerabilidad.
Seguir los manuales del motor de plantillas específico.
Aprovechar la vulnerabilidad
Se puede utilizar la siguiente Cheat Sheet para identificar el motor de plantillas en uso:
Code Execution via SSTI (Node.js Nunjucks)
Realizando una búsqueda sobre Node.js SSTI, nos encontramos con el siguiente blog en el cual mencionan la posibilidad de ejecutar comandos arbitrarios remotos a través de SSTI Node.js Nunjucks.
Realizando una búsqueda por Internet, nos encontramos con el siguiente repositorio de GitHub el cual mediante SSTI en Node.js Nunjucks, logra obtener un RCE.
Inyectaremos el siguiente comando para que se nos muestre el contenido del/etc/passwd. Al enviar la solicitud a través de BurpSuite, en la respuesta del servidor se verifica el contenido del archivo del servidor. Con lo cual, queda confirmada la existencia de poder ejecutar comandos arbitrarios a través del SSTI Node.js.
Por lo tanto, podemos intentar realizar la Reverse Shell para conectarnos al equipo de diferentes maneras. En nuestro caso, para no tener problemas con las ', decidimos verificar si el binario de cURL se encontraba disponible en el sistema objetivo.
A través de la siguiente inyección, se verificó que el binario cURL se encontraba instalado en el equipo.
Por lo tanto, en nuestro equipo local crearemos un script sencillo en Bash para que se ejecute la Reverse Shell, este script lo compartiremos a través de un servidor web.
Desde otra terminal, nos pondremos en escucha con nc para recibir la conexión.
Ejecutaremos la siguiente inyección SSTI para que realice un cURL hacía nuestro script de la Reverse Shell y lo ejecute a través de una bash.
Verificamos que finalmente logramos obtener el acceso correspondiente al sistema y 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
Attempting to perform Abusing Capabilities (perl) [FAILED]
Revisaremos una comprobación de los grupos y de si disponemos de permisos de sudoers. En este caso, no disponemos de grupos especiales y tampoco podemos comprobar los privilegios sudoers debido que nos requiere proporcionar credenciales del usuario david el cual de momento no disponemos.
Por otro lado, revisamos si había algún binario inusual con privilegios de SUID, no logramos encontrar ninguno. Intentamos también verificar si disponíamos de alguna capabilitie, en el resultado obtenido, nos encontramos la capabilitie /usr/bin/perl = cap_setuid+ep, con la cual podríamos llegar a aprovecharnos para obtener acceso como root.
A través dela herramienta de searchbins, revisamos la manera de abusar de esta capabilitie que disponemos.
Revisamos la ubicación del binario perl, accedemos a su directorio y ejecutamos la sintaxis para poder abusar de esta capabilitie, en el primer comando intentamos obtener una Bash como root pero no obtuvimos resultado ninguno.
Intentamos ejecutar el binario para obtener una shell como root, pero no conseguimos una sesión completamente privilegiada. Al ejecutar id, vimos que el UID era root, pero el GID seguía siendo david, lo que impedía elevar nuestros privilegios.
AppArmor Profile Bypass
Realizamos una enumeración con linpeas.sh y nos encontramos que AppArmor se encontraba habilitado en el sistema.
Por otro lado, también volvemos a verificar la existencia de la capabilitie mencionada.
Al revisar la documentación sobre AppArmor, encontramos información sobre su funcionamiento y la ubicación donde se definen las políticas y restricciones de los binarios. Al analizar /etc/apparmor.d/, detectamos un perfil asociado a /usr/bin/perl, lo que podría limitar su uso en la explotación.
Al revisar el perfil de AppArmor en /etc/apparmor.d/usr.bin.perl, observamos que /usr/bin/perl tiene la capacidad setuid, lo que le permite cambiar el UID del proceso. Sin embargo, existen restricciones clave que limitan su alcance:
Se deniega el acceso de escritura y ejecución a
/root/*y/etc/shadow.No se permite la lectura de
/etc/nsswitch.conf.Se permite la ejecución controlada de algunos binarios como
/usr/bin/id,/usr/bin/ls,/usr/bin/caty/usr/bin/whoami.Se restringe el acceso de
/usr/bin/perla ciertos archivos críticos, pero se permite la lectura en/home/y/home/david/.
Estas reglas limitan el impacto de la capability setuid, aunque aún es posible evaluar si existen formas de evasión para escalar privilegios.
Investigando en Internet, encontramos un blog donde explicaban cómo realizar un bypass de AppArmor usando un script en Perl. Siguiendo este método, creamos un script en /tmp/gzzcoo.pl, le asignamos permisos de ejecución y lo ejecutamos.
Inicialmente, al ejecutar perl gzzcoo.pl, el sistema devolvió un error de Permission denied. Sin embargo, al ejecutarlo directamente (./gzzcoo.pl), logramos obtener una shell como root y acceder a la flag root.txt.
Este comportamiento indica que AppArmor restringe la ejecución de Perl directamente, pero al ejecutar el script como binario, logramos evadir la restricción y escalar privilegios a root.
Última actualización
¿Te fue útil?