Si tu intención es entrar a este repositorio solo para sacar las flags, estás muy equivocado! La finalidad de este repositorio es ofrecerte una guía útil en caso de que te encuentres realmente perdido, pero la idea principal es que intentes resolver todo por ti mismo.
Si solo buscas la solución y no te esfuerzas en resolver los retos, no aprenderás nada en un CTF. En un entorno real, no te van a dar las soluciones hechas, y la clave del aprendizaje está en enfrentarte a los problemas, pensar de manera crítica y probar distintas soluciones.
Es una vulnerabilidad que ocurre cuando una aplicación web no valida adecuadamente las rutas de archivo proporcionadas por el usuario. Esto puede permitir que un atacante navegue a través de directorios del sistema de archivos del servidor que no deberían ser accesibles desde la aplicación.
Acceso no autorizado a archivos sensibles. El atacante puede acceder a archivos que normalmente estarían fuera de su alcance, como archivos de configuración del sistema, archivos de contraseñas, registros de bases de datos, archivos de sesión, etc.
Ejemplo básico muy parecido al que veremos nosotros AQUÍ
Ejemplo básico y otras variantes sobre path traversal AQUÍ
Si has omitido mi advertencia voy explicar cada captura e intentar que aprendas! Presta atención❗👀
- El primer paso que debemos seguir, una vez estamos dentro de la página web, sera observar como estan estructuradas las URLs de la página y navegaremos un poco por la web en busca de patrones que sugieran que la web es vulnerable a la inclusion de rutas de archivos o directorios en las URLS.
- Explorando por la página vemos que si le damos al botón de
SIGN INnos cargará la página con un panel de inicio de sesión y veremos que la URL de la página no sigue una ruta tradicional (absoluta/relativa).
Que significa esta URL❓ La parte de la URL antes del ´?´ sigue siuendo la ruta base. Lo que hay después de ´?´ son parámetros de consulta, estos parámetros proporcionan datos adicionales que son relevantes para la solicitud.
Basicamente, lo que sugiere esto es que lo que le estamos diciendo al servidor es que la página (page) que queremos cargar es signin (que eso sera una macro o algo por el estilo de un fichero, por ejemplo: signin.html).
- Una vez conocemos como funciona la estructura de URL y sabiendo que el parametro
pagepuede ser manipulado sustituiremos la ruta designinpor la ruta a un fichero que nos interese. Lo primero que haremos sera poner varias veces../ya que eso significa que retrocederemos en los directorios del servidor , de esta manera llegaremos al directorio raiz y una vez ubicados en el directorio raiz le pediremos que cargue el fichero/etc/passwdya que es un fichero muy valioso en el cual podemos ver nombres de usuarios, etc.
Una vez hemos hecho la consulta el servidor, en caso de ser vulnerable, nos devolveria el contenido de /etc/passwd. En este caso al ser un entorno controlado conseguimos la flag del ejercicio.
Los puntos mas importantes para prevenir el ataque sería validar y sanitizar adecuadamente las entradas de usuario, limitar los permisos de acceso a archivos y directorios.
2 - Hidden input 🕵️♂️🔍
Esta vulnerabilidad consiste en poder modificar valores en campos ocultos () en formularios web para alterar su comportamiento. Esto podría incluir cambiar privilegios de usuario, enviar datos falsos o manipular el estado de la aplicación.
Elevación de privilegios, donde un atacante cambia el estado de un usuario de "user" a "admin", otorgándole control administrativo completo sobre la aplicación. Además, la manipulación de campos ocultos podría facilitar la modificación de datos sensibles como precios de productos, contenido de mensajes u otra información crítica almacenada en la aplicación.
Ejemplo básico muy parecido al que veremos nosotros, empezar a ver desde min 4:13 🕦 AQUÍ
-
El primer paso que haremos sera abrir el codigo fuente de la página web y examinarlo en busca de formularios
<form>ya que suelen ser lugares comunes donde se encuentran campos ocultos que podrían ser manipulables.
-
Navegando por la página hemos encontrado algunos formularios pero en los campos ocultos no aparece nada de valor. Hasta que nos topamos con el apartado
Recover password.
-
Si abrimos el codigo fuente podemos observar como hay un campo oculto con un valor de un correo electronico.
-
Sabiendo esto lo que haremos a continuacion sera sustituir dicho valor desde
inspectpara que de esta manera en vez de llegar la recuperación de contraseña al correo por defecto nos llegue al correo que nosotros especifiquemos.
-
Una vez lo hayamos modificado le haremos click al boton de
submity ya nos dara la flag del ejercicio.
Verificar que todos los datos recibidos, incluidos los provenientes de campos ocultos, sean válidos y autorizados antes de procesar cualquier acción.
Esta vulnerabilidad ocurre cuando una aplicación web permite a los usuarios ser redirigidos a URLs externas sin validar su seguridad. Esto permite a un atacante manipular la URL de redirección, llevando a las víctimas a sitios maliciosos que pueden estar diseñados para el phishing o la distribución de malware.
- Phishing: Los usuarios pueden ser engañados para que ingresen información confidencial en sitios fraudulentos.
- Distribución de Malware: Los atacantes pueden redirigir a los usuarios a sitios que descargan software malicioso.
- Pérdida de confianza: La reputación de la aplicación se puede ver gravemente afectada.
Explicación de Open Redirect AQUÍ
Ejemplo de uso AQUI
- Al inspeccionar la página, observamos que la aplicación utiliza la estructura
index.php?page=redirect&site=whateverdonde el valorsiteno se valida correctamente. Esto permite que un atacante manipule el parámetrositepara redirigir a los usuarios a cualquier URL, incluidas aquellas potencialmente maliciosas.
- Modificamos el valor de
sitepor el de otra página.
- Finalmente, al hacer clic en el logo que hemos modificado con la redirección, deberíamos obtener la flag.
Validar las URL's, permitiendo solo sitios de confianza o usar whitelists de dominios permitidos.
La aplicación no valida correctamente los valores de entrada enviados a través de un formulario POST. Pudiendo modificar los valores de dicho formulario. Esta vulnerabilidad es conocida como Client-Side Validation Bypass.
Fraude financiero, acceso no autorizado a servicios o productos y integridad de los datos comprometida.
Ejemplo de uso similiar AQUI
- En este caso, si entramos en la pestaña survey de la página, vemos la siguiente encuesta.
- Al inspeccionar la página o revisar el código fuente, notamos que la encuesta no valida correctamente los valores de entrada enviados a través de un formulario POST. El hecho de que se pueda enviar el parámetro
value=sin que la aplicación verifique si es un valor válido indica un fallo en la lógica de validación.
- Modificamos el campo value por el valor que queramos. En este caso, si escogemos la opción 10 de ol, el valor será
9999999999999.
- Hacemos clic en la opción que hemos modificado.
- Esto nos devuelve la flag del ejercicio.
Validación de entradas, sanitizando todo correctamente. Sobretodo, implementandolo en el backend ya que el frontend puede ser manipulado fácilmente por un atacante.
El atacante aprovecha la capacidad de modificar el contenido de las cookies desde el lado del cliente, usualmente mediante herramientas como la consola del navegador, para alterar su valor y engañar al servidor haciéndole creer que tiene ciertos privilegios o estado de autenticación.
Suplantación de identidad y por lo tanto acceso no autorizado a recursos.
Ejemplo básico sobre manipulación de Cookies muy parecido al que veremos nosotros, empezar a ver desde min 6:30 🕦 AQUI
- Inspeccionamos la página y vemos nuestra cookie de sesión escribiendo el comando
document.cookieen la consola del navegador. Observamos el ID de sesión y el valor de la cookie. Notamos que contieneI_am_admin=, pero no entendemos el valor asignado, así que buscamos la forma de desencriptarlo.
- Resulta que el valor es
false. Lo que indica que nuestra cookie tiene el valor deI_am_admin=false. Lo que haremos será cambiar el valor de la cookie atrue.
- Cogemos la cadena
truey la encriptamos en md5, copiamos ese valor.
- Modificamos el valor de nuestra cookie de sesión para que sea el
trueencriptado.
- Al refrescar la página, ya seremos administradores, lo que nos dará acceso a la flag correspondiente.
Tener firmado y cifrado de cookies, monitoreo para detectar cualquier actividad sospechosa, una validación y autenticación adecuada.
Permite a un atacante ejecutar scripts maliciosos en el navegador de otros usuarios. Ocurre cuando los datos enviados por un usuario a través de formularios o mensajes se guardan en la base de datos sin sanitizar adecuadamente, y luego se muestran a otros usuarios en alguna parte de la aplicación.
Ejecución de código malicioso, robo de cookies, redirección a sitios maliciosos.
Qué es XSS❓ Explicado PASO a PASO AQUI
Demostración y RIESGOS de esta VULNERABILIDAD AQUI
- En la sección de
Feedback, observamos que al publicar un mensaje, este se refleja directamente en la página web. Lo que intentaremos hacer es enviar un script para comprobar si el input está mal sanitizado y si, en lugar de tratarlo como texto plano, el servidor lo ejecuta. En este caso particular, al ser un CTF, si el mensaje contiene la palabrascript, automáticamente obtenemos la flag, por lo que no es necesario un payload más complejo.
- Una vez le damos a sign ya nos aparece la flag.
Validar y sanitizar todos los datos de entrada para eliminar o escapar cualquier contenido malicioso y codificar adecuadamente todos los datos antes de mostrarlos en la interfaz de usuario
El web scraping es la práctica de extraer información de sitios web de manera automatizada. Si la aplicamos al ejemplo que nos da esta maquina veremos que tendremos que hacer una búsqueda exhaustiva a través de directorios y archivos para buscar la flag en uno de ellos.
Exposición de información sensible y carga no intencionada del servidor.
WIP ⚒️
Utilizar técnicas como CAPTCHA, límites de tasa y protecciones basadas en IP.
Es una técnica en la que un atacante modifica los encabezados de las solicitudes HTTP para engañar a un servidor web. Esto puede permitir a los atacantes cambiar el comportamiento del servidor, como el manejo de sesiones, la autenticación y las redirecciones.
Ejecutar ataques de cross-site scripting (XSS), phishing, y la exposición de información sensible. Los atacantes pueden suplantar a usuarios legítimos, eludir controles de seguridad o redirigir tráfico a sitios maliciosos.
Estos videos educativos son útiles para comprender el concepto general de HTTP Header Manipulation, pero no siempre representan un ejemplo exacto de cómo resolver nuestro ejercicio específico. En el video, se muestra la manipulación del encabezado Host, ya que en el entorno del autor, el servidor no valida adecuadamente ese campo. En nuestro caso, la vulnerabilidad radica en la falta de validación de los encabezados User-Agent y Referer, que son los que necesitamos explotar para lograr la flag.
Explotando vulnerabilidades en la cabecera HTTP Host AQUÍ
- Si nos desplazamos hasta el final de la página web, encontraremos una redirección.
- Esta nos lleva a una página donde, de inmediato, comienza a sonar la canción de "Albatroz" y aparece un texto extraído de Wikipedia. Es, cuanto menos, una página peculiar. Por lo tanto, procederemos a inspeccionarla y revisar su código fuente.
- Si examinamos bien en el codigo fuente de la página encontraremos dos comentarios muy interesantes. Uno nos indica que debemos acceder desde la URL
https://www.nsa.gov/y el otro nos sugiere usar el navegador con el agente de usuarioft_bornToSec
- Genial, sabiendo esto, vamos a hacer una solicitud curl modificando los parámetros que nos pide. Con el flag -e especificaremos un encabezado Referer, engañando al sistema para que crea que la solicitud proviene de un lugar de confianza, en este caso,
https://www.nsa.gov/. Con el flag -A estamos indicando que el User-Agent que se enviará con la solicitud esft_bornToSec, simulando el navegador. Por último, indicamos sobre qué página queremos hacer esa petición, y el resultado del comando se almacenará en un fichero llamado file.txt.
- Una vez realizada la solicitud, el contenido HTML se habrá almacenado en el archivo. A continuación, utilizaremos
greppara buscar la flag dentro del archivo.
Validación y sanitización de encabezados. Utilizar conexiones seguras HTTPS que van cifradas.
WIP ⚒️
WIP ⚒️
Ocurre cuando un atacante intenta adivinar credenciales de acceso, como contraseñas, mediante un método automatizado que prueba combinaciones de usuarios y contraseñas. Este ataque es efectivo en sistemas que no implementan límites en los intentos de inicio de sesión, lo que permite al atacante intentar múltiples combinaciones en un corto período.
Acceso no autorizado a cuentas críticas, la información sensible puede ser robada y los múltiples intentos pueden sobrecargar el sistema.
Hydra🐍:
Como utilizar Hydra paso a paso AQUÍ
Como usar Hydra en Panel de LOGIN WEB AQUÍ
- Uno de los primeros elementos que llama nuestra atención en la página web es el llamativo botón de
Sign In.
- Al hacer clic en este botón, somos redirigidos al siguiente panel de inicio de sesión.
- En este panel, si introducimos credenciales incorrectas, el servidor carga el archivo
WrongAnswer.gifcomo respuesta.
- Procedemos a realizar un ataque de fuerza bruta en dicho panel utilizando la herramienta Hydra. Para ello, configuramos el usuario como
adminy la contraseña se irá probando desde el ficherorockyou.txt. También debemos especificar la URL del panel y el tipo de petición que deseamos realizar. Es importante incluir los parámetros que queremos modificar entre^^y establecer que solo nos muestre el usuario y la contraseña cuando la respuesta del servidor sea diferente aWrongAnswer.gif. Una vez que ejecutamos el comando, debemos esperar un momento mientras Hydra realiza el ataque.
-
Cuando Hydra termina, introducimos las credenciales obtenidas en el panel de inicio de sesión. En este caso, usamos:
Usuario:
adminContraseña:
shadow
- Después de iniciar sesión correctamente, accedemos y obtenemos la flag del ejercicio.
Limitar los intentos de inicio de sesión y bloquear la cuenta tras varios intentos fallidos, requerir un segundo factor de autenticación para acceder a la cuenta y fomentar el uso de contraseñas complejas.
En este caso, esta vulnerabilidad se podría clasificar como Exposición de Información Sensible. Esta vulnerabilidad ocurre cuando un sistema revela información que no debería estar accesible, como contraseñas, a través de archivos de configuración o rutas ocultas.
Permite a un atacante acceder a áreas restringidas del sistema, implicando con ello la exposición de credenciales críticas y daño a la reputación.
Qué es FUZZING❓ AQUI
- Una de las primeras tareas al buscar vulnerabilidades en una página web es identificar directorios ocultos. Para ello, utilizaremos la herramienta gobuster junto con un diccionario de directorios, lo que nos permitirá probar diferentes rutas a partir de la raíz del sitio.
- Al ingresar en las distintas rutas descubiertas, obtendremos diferentes tipos de información. Por ejemplo, al acceder a
admin/, observamos que hay un panel de inicio de sesión.
- En la ruta
whatever/, encontramos un archivo. Procedemos a descargarlo para analizar su contenido.
- Al visualizar el contenido del archivo descargado, se revela información importante: aparece el usuario
rootjunto a lo que parece ser una contraseña. Intentamos ingresar estas credenciales en el panel de inicio de sesión deadmin/, pero el intento resulta infructuoso. Es posible que la contraseña esté encriptada.
- Seleccionamos el texto encriptado y buscamos una página que permita desencriptar MD5. Introducimos la cadena en la herramienta de desencriptación, la cual nos indica que la contraseña es
qwerty123@.
-
Ahora, intentamos nuevamente iniciar sesión con las credenciales:
Usuario:
rootContraseña:
qwerty123@
- Al ingresar correctamente, logramos acceder y conseguimos la flag correspondiente.
Asegurarse de que archivos como robots.txt no revelen información sensible, utilizar nombres menos evidentes para directorios críticos (por ejemplo, cambiar /admin/ a algo como /s3cr3t-area-2024/) y asegurarse de que todos los accesos a áreas sensibles requieran credenciales sólidas y que se implementen roles de usuario.
Es una vulnerabilidad de seguridad que permite a un atacante inyectar scripts maliciosos en una página web que es ejecutada por el navegador de un usuario. Esto ocurre cuando una aplicación web incluye datos proporcionados por el usuario en su respuesta sin una adecuada validación o escape.
Robo de datos, como cookies de sesión o información sensible del usuario, phising, redirección maliciosa, daño a la reputación.
Qué es y como funciona XSS Reclected❓ AQUI
Ejemplo básico parecido al que veremos nosotros AQUÍ
- Si clickamos sobre la imagen nsa se nos abre la siguiente pagina.
- La URL contiene parámetros, en este caso,
pageysrc. Las aplicaciones web a menudo utilizan parámetros de la URL para generar contenido dinámico. Si el parámetrosrcse usa directamente en el HTML sin ser validado o sanitizado, puede ser un punto de inyección. Probamos asignar un payload de XSS directamente a la URL, pero sin éxito.
- Como no hemos tenido éxito poniendolo a lo bruto, utilizaremos el esquema de URI que permite incrustar datos directamente en una página web o en un archivo, en lugar de enlazarlos desde una ubicación externa. Esto se utiliza comúnmente para incluir imágenes, archivos de texto o cualquier otro tipo de datos directamente en el código HTML o CSS. La estructura básica de una DATA URI es la siguiente: data:[tipo_mime][;base64], [contenido]. Sabiendo esto vamos a codificar el script en base64 para intentar colarlo.
- Modificamos la URL siguiendo la estructura básica de una DATA URI para asi incluir el script codificado.
http://10.11.250.221/index.php?page=media&src=data:text/html;base64,PHNjcmlwdD5hbGVydCgnZGFtZSBsYSBmbGFnJyk8L3NjcmlwdD4=. Esta vez si, con éxito.
Sanitizar y validar todas las entradas del usuario antes de ser procesadas o mostradas y implementar políticas que limiten los recursos que pueden ser cargados en la aplicación web.
La capacidad de un atacante para cargar archivos maliciosos a un servidor a través de un formulario de carga de archivos. Esta vulnerabilidad ocurre cuando una aplicación web no valida adecuadamente los archivos que los usuarios intentan cargar, lo que permite que se suban archivos que pueden ser utilizados para ejecutar código malicioso, obtener acceso no autorizado o comprometer la seguridad del servidor.
Ejecución de código malicioso, acceso no autorizado, filtración de datos, daño a la reputación.
Ejemplo de uso buenísimo. No utilizaremos la herramienta Burpsuite pero nos sirve para entender como funciona. AQUI
- Si nos vamos a la pestaña de
Add imagevemos que podemos subir un archivo.
- Creamos un fichero malicioso, en este caso no hara nada pero la idea es crear un fichero con contenido malicioso en
.php
- Falseamos una petición para que el servidor crea que esta recibiendo un fichero
.jpegcuando realmente estamos subiendo el fichero malicioso.php. La salida de este comando se hara en el fichero tmp.txt. Despues lo que haremos sera hacer cat al fichero y grep para buscar la flag.
Implementar validaciones rigurosas para los archivos cargados. Esto incluye verificar la extensión del archivo, el tipo MIME y el contenido real del archivo para asegurarse de que es seguro.
Este tutorial ha llevado mucho trabajo, si crees que te ha sido útil agradeceria mucho starred 🌟 para que así se comparta y pueda ayudar a más estudiantes 👨🏻🎓❤️
 gemartin  |
◦ Email: gemartin@student.42barcelona.com
◦ Linkedin: https://www.linkedin.com/in/gemartin99/