TryHackMe Guided Pentest Web

Hola hacketones! Bienvenidos a un nuevo CTF de la ruta completa de Jr Penetration Tester para obtener la certificación PT1: TryHackMe Guided Pentest Web

Tarea 1 Introducción

Imagina que te han contratado como pentester. Tu cliente utiliza una pequeña aplicación web llamada RecruitX , un portal interno de reclutamiento donde los responsables de contratación publican ofertas de trabajo, los candidatos envían sus solicitudes y los administradores gestionan todo el flujo de trabajo. El cliente sospecha que la aplicación tiene problemas de seguridad, pero desconoce dónde. Tu trabajo consiste en averiguarlo.

Esta sala te guiará a través de una prueba de penetración de aplicaciones web realista, de principio a fin. No te dejarán solo frente a una máquina y te dirán que «encuentres las banderas». En cambio, cada tarea te guiará a través de una fase del proceso, explicándote qué hacer, por qué hacerlo y qué buscar. Al finalizar, habrás pasado de no saber nada sobre el objetivo a lograr la ejecución remota de código en el servidor subyacente.

Objetivos de aprendizaje

El compromiso sigue este camino:

1. Reconocimiento y enumeración : descubre qué expone la aplicación.
2. Referencia directa a objetos insegura (IDOR) – Acceder a datos pertenecientes a otros usuarios
3. Restablecimiento de contraseña débil : toma el control de una cuenta a través de un mecanismo de restablecimiento defectuoso.
4. Acceso al panel de administración : pasar de usuario normal a administrador.
5. Ejecución remota de código : aproveche la funcionalidad de administración para ejecutar comandos en el servidor.

Cada vulnerabilidad se basa en la información recopilada en el paso anterior. Así es como funcionan las pruebas de penetración en el mundo real: rara vez se encuentra una única falla crítica sin protección. En cambio, se encadenan debilidades menores hasta que, en conjunto, conforman algo significativo.

Tarea 2 Reconocimiento y enumeración

Antes de empezar a usar la aplicación, entendamos con qué estamos trabajando. En cualquier prueba de penetración, la primera fase siempre es el reconocimiento: recopilar la mayor cantidad de información posible sobre el objetivo sin hacer suposiciones. Jamás entrarías en un edificio que te han contratado para evaluar sin antes mirar el exterior, revisar las puertas y leer los letreros. El mismo principio se aplica aquí.

Escaneo de puertos

Comencemos por descubrir qué servicios se están ejecutando en el objetivo. Abra una terminal y ejecute Nmap:

Podemos observar cuatro puertos abiertos. El puerto  22es SSH, útil más adelante si obtenemos las credenciales. El puerto 80es nuestra aplicación web objetivo que se ejecuta en Apache. El puerto 3306es MySQL, lo que indica que la aplicación utiliza una base de datos MySQL en el backend y el puerto 8080muestra la página predeterminada de Apache. Esta es información valiosa; significa que la aplicación probablemente construye consultas SQL, y cualquier debilidad en el manejo de entradas podría provocar problemas relacionados con SQL.

Explorando la aplicación

Abre tu navegador y ve a http://MACHINE_IP. Deberías ver la página de inicio de RecruitX. Antes de hacer clic en nada, tómate un momento para observar el contenido de la página. Verás una barra de navegación con enlaces a Inicio , Empleos , Iniciar sesión y Registrarse . También hay un pie de página que menciona «RecruitX v2.4».

Los encabezados confirman que el servidor está en funcionamiento con apache en la versión 2.4.58. La PHPSESSIDcookie confirma que se está utilizando la gestión de sesiones de PHP. Ahora conocemos la pila tecnológica: Apache + PHP + MySQL : una configuración LAMP clásica.

Enumeración de directorio

Ahora, descubramos qué directorios y archivos existen más allá de lo que muestra la barra de navegación. Usaremos Gobuster y una lista de palabras común:

Este resultado nos dice mucho. Analicemos los descubrimientos más importantes:

• /admin- Existe un panel de administración, pero redirige a la página de inicio de sesión. Necesitaremos credenciales para acceder a él.
• /api- UnAPIEl punto final está presente. Las API a menudo exponen datos de maneras que el frontend no lo hace.
• /reset.php- Una página de restablecimiento de contraseña. Los mecanismos de restablecimiento suelen implementarse de forma insegura.
• /uploads- Un directorio de subidas de archivos. Si podemos subir archivos, esto podría ser una vía para la ejecución de código.
• /profile.phpy /dashboard.php- Estos requieren autenticación, por lo que necesitamos iniciar sesión para acceder a ellos.

Registrar una cuenta

Varias páginas requieren autenticación. Iniciemos sesión con una cuenta para explorar las funciones de la aplicación. Navegue hasta [dirección web] http://10.67.129.46/login.phpe inicie sesión con los siguientes datos:

• Correo electrónico: testuser@fake.thm
• Contraseña: Password123

Nota : Puede registrar y utilizar cualquier otra cuenta registrándose en http://10.67.129.46/register.php.

Tras iniciar sesión, la aplicación te redirige a /dashboard.php. Ahora verás un panel que muestra información como Open Positions, Total Applicationso una opción para Browse Jobs, etc. Anota la URL mientras navegas, especialmente al ver tu perfil.

Explorando la API

Anteriormente, Gobuster encontró un /apipunto final. Investiguemos qué expone:

El API enumera útilmente sus propios puntos finales. Esto ya es un problema de divulgación de información en una aplicación de producción; un usuario no autenticado no debería poder descubrir información interna. Tengamos esto en cuenta al pasar a la siguiente tarea.

Responda las siguientes preguntas

¿Qué versión del servidor Apache está en funcionamiento?

2.4.58

¿Qué servicio de base de datos se está ejecutando en el sistema de destino?

MySQL

¿Cuál es la ruta a la página de restablecimiento de contraseña?

/reset.php

Tarea 3 IDOR

Ahora que tenemos una sesión autenticada y conocemos la estructura de la aplicación, comencemos a buscar vulnerabilidades. Uno de los fallos más comunes y frecuentemente pasados ​​por alto en las aplicaciones web es la

Referencia Directa Insegura a Objetos (IDOR) .

Consideremos esta analogía: usted se hospeda en un hotel y la llave de su habitación es simplemente el número 104. No hay cerradura electrónica, ni verificación, solo el número. ¿Qué le impide ir a la habitación 105 y abrir la puerta? Nada. Eso es esencialmente en lo que consiste en que la aplicación utiliza un identificador predecible para hacer referencia a objetos (perfiles de usuario, documentos, pedidos) y no verifica si el usuario solicitante está autorizado para acceder a ese objeto específico.

Encontrar el IDOR

Mientras estés conectado como tu usuario de prueba, navega a tu perfil haciendo clic en el botón que muestra tu nombre de usuario en la parte superior derecha del panel de control ( Test en este caso). Observa atentamente la URL en la barra de direcciones de tu navegador:

http://10.67.129.46/profile.php?id=6

La aplicación hace referencia a tu perfil mediante un id numérico. Tu cuenta fue la sexta creada, por lo que tu ID es 6. La pregunta inmediata que cualquier probador de penetración debería hacerse es: ¿Qué sucede si cambio ese número?

Probando la vulnerabilidad

Cambiemos el parámetro 1 y veamos qué sucede. Puedes hacerlo directamente en el navegador o con curl. En el navegador, al acceder a la URL http://10.67.129.46/profile.php?id=1 obtendría esto:

Extrayendo cookies

En este ejercicio, necesitará su cookie de sesión, que puede obtener haciendo clic con el botón derecho en cualquier parte de la página y seleccionando Inspeccionar, como se muestra a continuación:

Ve a lStorage, luego expande Cookies y selecciona http://10.67.129.46. Verás todas las cookies listadas, busca la PHPSESSID cookie y copia su valor.

 También podemos usar esto curl para ver exactamente qué se devuelve. Asegúrate de incluir tu cookie de sesión en el siguiente comando después PHPSESSID=del valor:

Acabamos de acceder al perfil de la usuaria con ID 1, Sarah Mitchell , que es administradora. La aplicación no verificó si estábamos autorizados a ver este perfil. Simplemente tomó el id, consultó la base de datos y devolvió el resultado.

Vamos a comprobar también si el punto final de la API que descubrimos anteriormente tiene el mismo problema, y ​​si ni siquiera requiere una cookie de sesión:

El API Es incluso más revelador que la página web. Devuelve un JSON estructurado con el nombre, correo electrónico, rol y fecha de creación de la cuenta del usuario. Al incrementar el id  del 1 al 5, podemos enumerar a todos los usuarios del sistema.

Por qué esto importa

Las vulnerabilidades IDOR se encuentran sistemáticamente entre los fallos más comunes de las aplicaciones web. Se producen porque los desarrolladores asumen que los usuarios solo accederán a sus propios recursos, una suposición que se rompe en cuanto alguien modifica un parámetro de la URL. La solución es sencilla: el servidor debe verificar que el usuario autenticado tenga permiso para acceder al objeto solicitado. Sin embargo, en la práctica, esta verificación suele faltar.

Responda las siguientes preguntas

¿Cuál es el nombre del usuario administrador?

Sarah Mitchell

¿Qué papel desempeña James Crawford?

hiring_manager

Tarea 4 Restablecimiento de contraseña débil

Ahora conocemos la dirección de correo electrónico de la administradora: s.mitchell@recruitx.thm. Nuestro siguiente objetivo es tomar el control de su cuenta. En lugar de intentar adivinar su contraseña (lo que podría llevar mucho tiempo y provocar el bloqueo de la cuenta), examinemos el mecanismo de restablecimiento de contraseña. Los flujos de restablecimiento de contraseña son una de las funciones que más fallan en las aplicaciones web, ya que son complejos de implementar de forma segura y los desarrolladores suelen tomar atajos.

Comprender el flujo de reinicio

Dirígete a [dirección http://10.67.129.46/reset.phpweb]. Verás un formulario sencillo que solicita una dirección de correo electrónico. Primero, probemos el proceso con nuestra propia cuenta para entender cómo funciona. Ingresa testuser@fake.thmy envía el formulario.

Este es nuestro primer hallazgo importante. En una aplicación bien diseñada, el token de restablecimiento se enviaría al correo electrónico del usuario y nunca se mostraría en pantalla. Sin embargo, esta aplicación muestra el token directamente en la respuesta. Si bien esto por sí solo nos permitiría restablecer nuestra propia contraseña, la verdadera pregunta es: ¿Cómo se comparte el token con el usuario?

Análisis del token

Generemos algunos tokens más y busquemos patrones. Envía el formulario de reinicio varias veces para tu propia cuenta y registra los tokens:

• Intento 1:784512
• Intento 2:291037
• Intento 3:503648

Los tokens son números de seis dígitos. Parecen aleatorios, pero el rango es limitado; solo hay un millón de valores posibles (de 000000 a 999999). Este es un espacio de tokens débil. Sin embargo, intentar forzar un millón de valores podría ser lento. Analicemos con más detenimiento e intentemos restablecer el token del administrador usando su dirección de correo electrónico s.mitchell@recruitx.thm. Obtendremos lo siguiente:

Restablecer la contraseña del administrador

Ya tenemos todo lo necesario. Usemos el token para restablecer la contraseña de Sarah Mitchell. Visita la URL de restablecimiento y te pedirá una nueva contraseña:

Vamos a verificarlo iniciando sesión con la nueva contraseña.

Ahora hemos iniciado sesión como administrador. Dediquemos un momento a comprender la cadena hasta ahora: hemos utilizado unIDORPara descubrir el correo electrónico del administrador, aprovechamos una vulnerabilidad en el mecanismo de restablecimiento de contraseña que exponía los tokens directamente en la respuesta. Ninguna de las vulnerabilidades por sí sola nos habría dado acceso de administrador, pero en conjunto, el resultado fue devastador.

¿Qué salió mal?

El mecanismo de restablecimiento de contraseña tenía tres fallos distintos:

1. Token mostrado en respuesta: El token solo debe enviarse al correo electrónico del propietario de la cuenta y nunca debe mostrarse  en pantalla.
2. Generación débil de tokens : un token numérico de seis dígitos tiene un espacio de claves pequeño y es susceptible a ataques de fuerza bruta.
3. Sin limitación de velocidad : la aplicación no limitaba el número de solicitudes de reinicio ni de intentos de adivinar el token.

Responda las siguientes preguntas

¿Cuántos dígitos tiene el token de reinicio?

6

Tras restablecer la contraseña de s.mitchell@recruitx.thm e iniciar sesión, ¿qué rol se muestra para esa cuenta en el panel de control?

Administrator

Tarea 5 Acceso al panel de administración

Ahora hemos iniciado sesión como Sarah Mitchell, la administradora de la aplicación. Anteriormente durante nuestra enumeración Descubrimos una  ruta que redirigía a los usuarios no autenticados a la página de inicio de sesión. Ahora que tenemos las credenciales de administrador, veamos qué hay detrás de esa puerta.

Explorando el panel de administración

Acceda a http://MACHINE_IP/adminla página utilizando el navegador donde ha iniciado sesión como Sarah Mitchell. El panel de administración muestra varias páginas de gestión. La mayoría son funciones administrativas estándar, pero una destaca de inmediato:  /admin/upload.php. Una función de carga de archivos en manos de un administrador es una característica poderosa y, desde la perspectiva de un probador de penetración, es una vía potencial para la ejecución remota de código.

Investigando la función de carga

Examinemos la página de carga. Haz clic derecho en el Uploadbotón y haz clic en Inspect, donde podrás inspeccionar el código del lado del cliente:

Podemos observar varios detalles importantes. El formulario indica que acepta archivos PDF, DOCX e imágenes. El atributo accept en la entrada de archivo restringe los tipos de archivo, pero esta es una restricción solo del lado del cliente . El navegador la aplica, pero una solicitud HTTP directa puede enviar cualquier tipo de archivo que desee. La página también revela el destino de carga: /uploads/documents/. 

Probando las restricciones de carga

Vamos a comprobar si el servidor aplica restricciones de tipo de archivo. Primero, intentaremos subir un archivo de texto inofensivo para ver cómo responde la aplicación. En AttackBox, introduce el siguiente comando para crear un archivo de texto:

Terminal

root@tryhackme:~#echo»This is a test file»>test.txt

Una vez creado el archivo, súbelo al panel de administración. Abre la página de carga, haz clic derecho en el campo de archivo y selecciona Inspeccionar. En el código HTML, elimina el atributo `accept` borrándolo (con la tecla de retroceso) para que el navegador ya no restrinja los tipos de archivo. Ahora selecciona y sube tu archivo directamente, evitando la restricción del lado del cliente.

El servidor rechazó el  .txtarchivo.

Existe cierta validación del lado del servidor. Pero, ¿qué tan exhaustiva es? Probemos si el servidor verifica solo la extensión del archivo o también su contenido. Crearemos un archivo PHP usando el siguiente comando:

Terminal

root@tryhackme:~#echo'<?php echo «PHP is executing»; ?>’>test.php

Una vez creado, intenta subirlo de nuevo. Sigue siendo rechazado. La aplicación parece estar comprobando la extensión final.

Intentemos otra forma común de eludir la norma utilizando la .phtmlextensión, que Apache suele procesar como PHP:

Terminal

root@tryhackme:~#echo'<?php echo «PHP is executing»; ?>’>test.phtml

La .phtmlextensión fue aceptada. El filtro de tipo de archivo de la aplicación bloquea .phppero no tiene en cuenta las alternativas.PHPextensiones. Este es un descuido común; los desarrolladores crean una lista de bloqueo de extensiones «peligrosas», pero omiten las menos comunes que el servidor aún procesa comoPHP.

Vamos a verificar que nuestro archivo subido se ejecuta visitando la página http://MACHINE_IP/uploads/documents/test.phtml.

El servidor ejecutó elPHPcódigo y devolvió el resultado. Hemos confirmado que podemos cargar y ejecutarPHParchivos en el servidor. En la siguiente tarea, utilizaremos esto para obtener ejecución remota de código.

Responda las siguientes preguntas

¿Cuál es el nombre del archivo PHP responsable de gestionar la carga de archivos en la aplicación web RecruitX? 

upload.php

¿Qué atributo HTML del campo de entrada de archivo se utiliza para restringir las extensiones de archivo seleccionables en el lado del cliente?

accept

¿Qué extensión alternativa de PHP eludió el filtro de carga?

.phtml

Tarea 6 Ejecución remota de código

Hemos confirmado que podemos subirPHParchivos al servidor y que el servidor los ejecutará. Este es el punto en la prueba de penetración donde todos los pasos anteriores se unen. Comenzamos sin nada, sin credenciales, sin conocimiento de la aplicación. A través de la enumeración,IDORDebido a la explotación, el abuso del restablecimiento de contraseñas y el acceso al panel de administración, hemos llegado a un punto en el que podemos ejecutar código arbitrario en el servidor.

Creación de un shell web

Un web shell es un pequeño script que acepta comandos a través deHTTPparámetros y los ejecuta en el servidor. Creemos uno simple y guardémoslo como shell.phtml:

Este script comprueba si existe un cmdparámetro en la URL. Si está presente, pasa el valor a shell_exec(), que ejecuta el comando en el sistema operativo y devuelve el resultado. Sube el archivo al panel de administración  http://10.64.167.252/admin/upload.php.

Ejecutando comandos

Vamos a comprobar que el código se ejecuta ejecutando un comando sencillo:

Tenemos ejecución remota de código. Los comandos se ejecutan como www-data, que es el usuario predeterminado del servidor web Apache en Ubuntu. Recopilemos más información sobre el sistema:

Ahora podemos ver el nombre de host, la versión del kernel y ejecutar cualquier comando en el sistema.

Lectura de archivos confidenciales

Dado que podemos leer archivos en el servidor, un buen primer paso es revisar los archivos del sistema que listan los usuarios. EnLinux, /etc/passwdcontiene información básica de la cuenta:

Mediante nuestra interfaz web, accedimos  /etc/passwde identificamos a los usuarios del sistema. En un escenario real, este nivel de acceso permitiría enumerar aún más los archivos de configuración para extraer las credenciales de la base de datos y obtener acceso completo a los datos del backend de la aplicación.

Obtención de una shell inversa

Una shell web funciona, pero tiene limitaciones: cada comando es una solicitud HTTP independiente, no hay sesión interactiva y los comandos complejos con caracteres especiales pueden ser difíciles de pasar a través de parámetros URL. Actualicemos a una shell inversa adecuada.

Primero, configura un oyente en tu AttackBox:

En una segunda terminal, active la shell inversa a través de la shell web. Codificaremos la carga útil en formato URL para evitar problemas con caracteres especiales:

De vuelta en tu terminal de escucha:

Ahora tenemos acceso interactivo a la consola del servidor objetivo. A partir de aquí, un especialista en pruebas de penetración normalmente procedería a la enumeración local y la escalada de privilegios, pero eso queda fuera del alcance de esta sala.

Leyendo la bandera

Para confirmar que ha completado la tarea, lea el archivo de indicadores en el sistema:

Responda las siguientes preguntas

¿Con qué usuario se está ejecutando la consola web?

www-data

¿Cuál es el nombre de host del servidor de destino?

recruitx-prod

¿Cuál es la bandera?

THM{ch41n3d_vulns_4r3_d3v4st4t1ng}

Tarea 7 La cadena de ataque

Retrocedamos un paso y analicemos el recorrido completo que seguimos. En un informe de prueba de penetración, se documenta toda la cadena de vulnerabilidades, mostrando al cliente cómo cada debilidad contribuyó a la vulneración general. Esta es nuestra cadena:

1. Enumeración : Descubrimos la pila tecnológica de la aplicación (apache,PHP, MySQL), su estructura de directorios, unAPIun punto final, una página de restablecimiento de contraseña, un directorio de cargas y un panel de administración.
2. IDOR(Tarea 3) : El  /profile.php?id=parámetro y el /api/user?id=punto final nos permitieron enumerar a todos los usuarios, incluyendo el nombre y la dirección de correo electrónico del administrador.
3. Restablecimiento de contraseña débil (Tarea 4) : El mecanismo de restablecimiento mostraba los tokens directamente en la respuesta HTTP, lo que nos permitía generar un token para el administrador y cambiar su contraseña.
4. Acceso al panel de administración (Tarea 5) : Utilizando la cuenta de administrador comprometida, accedimos al panel de administración y encontramos una función de carga de archivos con una lista de bloqueo de extensiones incompleta.
5. Ejecución remota de código (Tarea 6) : Subimos un shell web PHP usando la .phtmlextensión, lo que eludió el filtro. Esto nos permitió ejecutar comandos en el servidor y obtener acceso a un shell inverso completo.

Ninguna vulnerabilidad individual en esta cadena provocó por sí sola el compromiso total del servidor.IDORSe filtró información de los usuarios, pero no se obtuvo acceso directo. El restablecimiento de contraseña era vulnerable, pero solo era útil porque ya conocíamos el correo electrónico del administrador. El filtro de carga tenía una vulnerabilidad que se podía sortear, pero necesitábamos las credenciales de administrador para acceder a ella. Fue la combinación de estas debilidades lo que provocó el compromiso total del servidor.

Resumen de medidas correctivas

Si usted estuviera redactando el informe para este proyecto, estas son las recomendaciones de remediación que proporcionaría para cada hallazgo:

Vulnerabilidad	Gravedad	Remediación
IDOR en los perfiles de usuario y API	Alto	Implementar comprobaciones de autorización del lado del servidor en cada solicitud. Verificar que el usuario autenticado tenga permiso para acceder al recurso solicitado.
Token de restablecimiento de contraseña expuesto en la respuesta	Crítico	Envíe los tokens de reinicio exclusivamente por correo electrónico. Muestre solo un mensaje de confirmación genérico en la página. Utilice tokens criptográficamente aleatorios de al menos 32 caracteres.
Lista de bloqueo de extensiones de archivo incompleta	Crítico	Utilice una lista de permitidos en lugar de una lista de bloqueados. Permita solo extensiones específicas y esperadas. Valide el contenido del archivo (MÍMICA) además de la extensión. Almacenar los archivos subidos fuera de la raíz web.
API divulgación del punto final	Medio	Retire el API Indique el punto final del índice o restrinja su acceso a administradores autenticados. No exponga las estructuras de rutas internas a usuarios no autenticados.

Responda las siguientes preguntas

¿Cuántas vulnerabilidades distintas se entrelazaron en este enfrentamiento?

4

¿Qué método debería utilizarse en lugar de una lista negra para validar las cargas de archivos?

 allowlist

Tarea 8 Conclusión

En esta sala, realizamos una prueba de penetración completa de una aplicación web, desde el principio. Nmap  para la ejecución remota de código en el servidor subyacente. En el proceso, practicaste la mentalidad que distingue a un buen probador de penetración de uno excelente: paciencia, observación y la capacidad de conectar hallazgos en diferentes partes de una aplicación.

Repasemos las principales lecciones de este encuentro:

• La enumeración lo es todo. Las vulnerabilidades que explotamos fueron detectables porque nos tomamos el tiempo de mapear la estructura, los encabezados, los puntos finales y el comportamiento de la aplicación antes de intentar la explotación.
• Los pequeños fallos se convierten en grandes inconvenientes. Ningún problema en particular era exótico ni especialmente complejo. IDOR Las vulnerabilidades como el restablecimiento de contraseñas débiles y la omisión de cargas de archivos son bien conocidas. Su impacto radicaba en cómo se conectaban entre sí.
• Las restricciones del lado del cliente no son seguridad. El formulario de carga de archivos usaba un accept atributo para restringir los tipos de archivo en el navegador. La verificación del lado del servidor usaba una lista de bloqueo que no incluía alternativas. PLa seguridad real requiere validación del lado del servidor con un enfoque de lista de permitidos.
• Los mecanismos de restablecimiento de contraseñas merecen especial atención. Su implementación segura es compleja, y un solo fallo de diseño, como exponer el token en la respuesta, puede provocar el robo de la cuenta.
• Piensa como un atacante, informa como un consultor. Encontrar las vulnerabilidades es solo la mitad del trabajo. Documentarlas claramente, con clasificaciones de gravedad y recomendaciones prácticas para su corrección, es lo que realmente aporta valor al cliente.

Has completado la prueba de penetración guiada. Es hora de aplicar lo aprendido a los próximos desafíos.

Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!