Scribd
Cargar
15 vistas9 páginas

Proyecto Modulo Web

Cargado por

Julio1138
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
15 vistas9 páginas

Proyecto Modulo Web

Cargado por

Julio1138
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 9

Departamento de Ciencias Exactas e Ingenieria

Diplomado en Ciberseguridad de Desarrollo y Operaciones

OWASP Broken Web Apps


Proyecto Final del Módulo V del Diplomado en Ciberseguridad de Desarrollo y
Operaciones.

Julio Cesar Chavez Hidalgo

Cochabamba - Bolivia
Julio de 2024
Para el presente proyecto se hará uso de Máquinas virtuales de los Sistemas Operativos Kali Linux
así como también una OVA para VMWare que contiene el servidor vulnerable de Owasp Web
Broken Apps

A01:2021 PÉRDIDA DE CONTROL DE ACCESO

Vulnerabilidad: IDOR
Herramienta:
WEBGOAT.NET

El término IDOR hace referencia a "Referencia Directa a Objetos Inseguros". Se trata de una
vulnerabilidad de seguridad común en aplicaciones web que ocurre cuando un usuario puede acceder
o modificar recursos (objetos) dentro de una aplicación a los que no debería tener acceso directo.

La situación específica que abordaremos es una en la que se puede obtener la pregunta de seguridad
sin la debida autenticación está relacionada con IDOR ya que el sistema de la aplicación expone esta
información confidencial sin comprobar adecuadamente la autorización del usuario que realiza la
solicitud.

Ocurre debido a una mala implementación del control de acceso. Cuando se construye una aplicación
web, es esencial tener un control estricto sobre qué usuarios pueden acceder a qué recursos.
Como vemos en ambas imágenes, la aplicación web nos pide responder una pregunta secreta para
poder restablecer la contraseña. Posteriormente, deliberadamente puse una palabra al azar, para poder
hacer la captura con la herramienta BurpSuite

En primera instancia cambiamos el proxy para que redirija hacia el puerto de BurpSuite

Ya en BurpSuite podemos nos vamos a la ventana Request, donde podemos observar las peticiones
que se están realizando en ese momento
Ya en el código y las etiquetas podemos ver que se encuentra la pregunta de seguridad, pero de
forma codificada

Para ello usaremos en decoder de Burpsuite y tras decodificar por 2 ocasiones, se pudo dar con la
pregunta de seguridad.
Como se puede ver a continuación la palabra es correcta.

Para subsanar esta vulnerabilidad, la aplicación web debe usar un identificador seguro para
referenciar la pregunta de seguridad. Un identificador seguro es un valor que no se puede adivinar
fácilmente, como un hash o un UUID.

También se puede utilizar una lista blanca para restringir los valores que se pueden usar para
referenciar la pregunta de seguridad. Esto ayudaría a evitar que los atacantes ingresen valores
maliciosos.

A3:2017-SENSITIVE DATA EXPOSURE

Vulnerabilidad: Heartbleed
Herramienta: bWAPP

La vulnerabilidad Heartbleed se produce cuando el protocolo SSL/TLS, que se utiliza para cifrar el
tráfico entre un navegador web y un servidor web, tiene un error de diseño que permite a los atacantes
leer datos de la memoria del servidor.

Heartbleed está relacionado con una sobrecarga de memoria de un servidor vulnerable. Cuando un
atacante envía una solicitud de heartbeat al servidor, podía manipular la solicitud para indicar que su
paquete de datos era más grande de lo que realmente era. El servidor, debido a un error en la
implementación de la extensión de heartbeat, devuelve más datos de los que el atacante había
enviado, lo que permitía acceder a segmentos de memoria que podrían contener información sensible,
como claves privadas, datos de sesión, contraseñas u otra información confidencial.
Para el ejercicio en la plataforma primero debemos logearnos para ello usamos la cuenta bee y la
contraseña bug,una vez hecho esto procedemos a elegir la vulnerabilidad, ahi nos indica cómo
podríamos proceder para encontrar la forma de explotar esta vulnerabilidad
Nos indica que descarguemos un script que está escrito en python, para lo cual iremos a nuestra
terminal donde nos pondremos en el directorio Downloads, para ejecutar el script, previamente
debemos tomar en cuenta que el script está diseñado para python 2, para lo cual se hizo algunos
cambios al script para que pueda ejecutarse en la versión de kali a usar, al final nos dice que el
servidor se encuentra vulnerable.

Posteriormente haremos uso del script con el puerto 8443 y la ip del servidor OWASP. El comando
nmap -sV --script ssl-heartbleed es utilizado para detectar servidores vulnerables a Heartbleed.
Cuando se ejecuta contra una dirección IP y un puerto específico, Nmap intentará detectar si el
servidor responde de manera vulnerable a la vulnerabilidad Heartblee cosa que al final se puede
comprobar.

Al ejecutar el módulo auxiliary (auxiliary/server/openssl_heartbleed_client_memory) en Metasploit, se


intenta explotar la vulnerabilidad Heartbleed para extraer información sensible de la memoria del
servidor vulnerable. El conjunto de comandos set srport, set srhost, set verbose true y run están
configurando el entorno para el ataque y ejecutando el exploit.
El resultado es que pudimos acceder a información de la memoria del servidor.

Para subsanar esta vulnerabilidad, la aplicación web debe actualizar el software SSL/TLS a una
versión que corrija el error de Heartbleed.

Heartbleed ya no es considerada una vulnerabilidad actual. Fue identificada inicialmente en 2014 y


desde entonces se han aplicado parches y soluciones para corregir esta falla en la biblioteca
OpenSSL. Las versiones afectadas de OpenSSL fueron actualizadas y se alentó a todos los
administradores de sistemas a aplicar las actualizaciones correspondientes para protegerse contra esta
vulnerabilidad.
A04:2013-INSECURE OBJECT REFERENCES

Vulnerabilidad: Local File Inclusión


Herramienta: Mutillidae II

LFI (Local File Inclusion) se refiere a una vulnerabilidad en aplicaciones web que permite a un
atacante incluir y leer archivos locales del sistema donde se ejecuta la aplicación. Esto ocurre cuando
la aplicación web no valida adecuadamente las entradas del usuario y permite que se incluyan
archivos locales, permitiendo al atacante leer archivos sensibles presentes en el servidor.

una vez que elegimos la vulnerabilidad, podemos observar que nos muestra una ventana donde
podemos elegir un archivo, además de un botón para ver el mismo.

una vez hecho esto podemos usar burpsuite o developer tools para ver el codigo
ahí podemos ver que nos muestra diferentes URL’s de los textos en cuestión, entonces si cambiamos
en este caso el contenido por una ruta como por ejemplo el directorio
/etc/passwd/ y presionamos view file

podemos ver que nos muestra información que en principio no debería de verse de esta manera.

Para subsanar la vulnerabilidad se podría validar y filtrar estrictamente todas las entradas
proporcionadas por el usuario antes de utilizarlas para acceder a archivos. Esto implica asegurarse de
que las rutas de archivos o cualquier entrada relacionada estén limitadas a ubicaciones permitidas y
no permitan referencias a directorios sensibles, como /etc/passwd

También podría gustarte