¿Qué es DVWA y por qué los hackers éticos la aman?

¿QUÉ ES DVWA? 

DVWA es un acrónimo de DAMM VULNERABLE WEB APP – una aplicación web vulnerable programada en PHP/MYSQL. En serio es demasiado vulnerable. En esta aplicación, los profesionales de la seguridad, los hackers éticos prueban sus habilidades y ejecutan estas herramientas en un entorno legal. También ayudan al desarrollador web a comprender mejor los procesos de seguridad de las aplicaciones web y los profesores/alumnos para enseñar/aprender la seguridad de las aplicaciones web en un entorno seguro.

El objetivo de la DVWA es practicar algunas de las vulnerabilidades web más comunes, con varios niveles de dificultad.

¿Cómo usar DVWA? 

Solo tienes que ir a este enlace http://www.dvwa.co.uk/ y descargarla.
Una vez que la hayas descargado, Instálala en la máquina virtual (VMWARE o VIRTUAL BOX )
Necesitarás XAMPP (para Windows).
Luego, DVWA te otorga su IP local. Puedes verificar esto escribiendo en la máquina virtual (ifconfig).
Luego, debes escribir esta IP en el navegador
Ahora estás en el entorno DVWA.

¿Cuáles son los beneficios de la DVWA?

1) Hackear cualquier cosa sin permiso es un crimen. Entonces, como estudiante o principiante aquí tienes ese permiso, puedes usarlo. Para que los usuarios avanzados mejoren su habilidad, la DVWA es la mejor plataforma.
2) En DVWA, no tienes que pedir el permiso de otros. Simplemente puedes instalarla en un entorno virtual y comenzar a usarla.
3) Es muy sencillo de instalar.
4) Este es el mejor lugar para hacer hacking.
5) De hecho, esto se está ejecutando en tu entorno local y es totalmente legal.

¿NIVELES DE DIFICULTADES EN DVWA? 

Como su nombre indica, la DVWA tiene muchas vulnerabilidades web. Cada vulnerabilidad tiene cuatro niveles de seguridad diferentes, bajo, medio, alto e imposible. Los niveles de seguridad suponen un desafío para el “atacante” y también muestra cómo cada vulnerabilidad puede medirse mediante una programación segura.

 

Niveles de seguridad.
Imposible: En este nivel, enfrentarás desafíos como CTF y es más difícil que el otro nivel. Este nivel da dificultades que enfrentamos en el mundo real.

 

Alto: Este nivel de vulnerabilidad brinda al usuario un ejemplo de cómo proteger la vulnerabilidad a través de métodos de programación seguros. Permite al usuario comprender cómo se puede medir la vulnerabilidad. Este nivel de seguridad debe ser imposible de hackear, sin embargo, como todos sabemos, este no es siempre el caso. Así que, si logras evitarlo, estarás haciendo lo correcto.

 

Medio: el propósito de este nivel de seguridad es dar al ‘atacante’ un desafío en la explotación y también servir como un ejemplo de malas prácticas de programación/seguridad.

 

Bajo: este nivel de seguridad está destinado a simular un sitio web sin ningún tipo de seguridad implementado en su programación. Le da al “atacante” la oportunidad de refinar sus habilidades de explotación.

En DVWA podemos probar varios tipos diferentes de Vulnerabilidades.

1) FUERZA BRUTA.

En la vulnerabilidad de fuerza bruta podemos probar si el portal de inicio de sesión es vulnerable a la fuerza bruta o no. Aquí podemos probar casi todas las combinaciones de palabras, números, símbolos especiales. También podemos utilizar un archivo de diccionario.

Los objetivos principales son descifrar el nombre de inicio de sesión y contraseña. La fuerza bruta se puede aplicar en los diferentes parámetros. Aquí tenemos la pantalla de inicio de sesión de fuerza bruta.

2) INYECCIÓN DE COMANDO.

En la vulnerabilidad de inyección de comando, el objetivo es la ejecución de comandos arbitrarios en el sistema operativo host a través de una aplicación vulnerable.

Los ataques de inyección de comandos son posibles cuando una aplicación pasa Datos inseguros proporcionados por el usuario a un shell del sistema.

En este ataque, el atacante envía comandos del sistema operativo que generalmente se ejecutan con los privilegios de la aplicación vulnerable, por lo que aquí tiene un campo vacío para que pueda ejecutar dichos comandos.

3) CSRF.

La falsificación de solicitudes entre sitios (CSRF) es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que están autenticados actualmente.

Los ataques CSRF se dirigen específicamente a las solicitudes de cambio de estado, no al robo de datos ya que el atacante no tiene forma de ver la respuesta a la solicitud falsificada. Con un poco de ayuda de ingeniería social (como enviar un enlace por correo electrónico o chat), un atacante puede engañar a los usuarios de una aplicación web para que ejecuten las acciones que elija el atacante.

Si la víctima es un usuario normal, un ataque CSRF exitoso puede obligar al usuario a realizar solicitudes de cambio de estado, como transferir fondos, cambiar su dirección de correo electrónico, etc. Si la víctima es una cuenta administrativa, CSRF puede comprometer toda la aplicación web. Así que aquí podemos crear una página falsa y enviarla a la víctima para que realice los pasos necesarios.

4) CARGA DE ARCHIVOS.

La carga de archivos es una función muy simple, simplemente se carga el archivo en el servidor. Para reducir el riesgo solo podemos aceptar ciertas extensiones de archivo, pero los atacantes pueden encapsular código malicioso en tipos de archivos inertes.

La prueba de archivos maliciosos verifica que la aplicación/sistema pueda proteger correctamente contra los atacantes que cargan archivos maliciosos.

La aplicación puede permitir la carga de archivos maliciosos que incluyen exploits o shellcode sin enviarlos al escaneo de archivos maliciosos. Aquí tenemos que cargar shell en el servidor.

5) CAPTCHA INSEGURO.

CAPTCHA (“Completely Automated Public Turing test to tell Computers and Humans Apart”) Los captchas se usan generalmente para evitar que los robots realicen una acción en lugar de los humanos.

Debería agregar una capa adicional de seguridad, pero mal configurada podría llevar a un acceso no autorizado. Lo que debemos hacer es omitir la función de seguridad de captcha mediante el uso de los datos de sabotaje u otros métodos.

6) INYECCIÓN DE SQL.

SQL Injection (SQLi) se refiere a un ataque de inyección en el que un atacante puede ejecutar sentencias de SQL maliciosas que controlan el servidor de base de datos de una aplicación web.

Dado que una vulnerabilidad de Inyección de SQL podría afectar a cualquier sitio web o aplicación web que haga uso de una base de datos basada en SQL, la vulnerabilidad es una de las vulnerabilidades de aplicaciones web más antiguas, frecuentes y peligrosas.

Un atacante puede usarla para omitir los mecanismos de autenticación y autorización de una aplicación web y recuperar el contenido de una base de datos completa. La inyección SQL también se puede utilizar para agregar, modificar y eliminar registros en una base de datos, afectando la integridad de los datos.

7) SQL INJECTION BLIND.

En el Blind SQL no podemos ver la respuesta en ese momento. Por lo tanto, cualquier tipo de consulta que realicemos no mostrará ninguna respuesta en ese momento.

Implica muchas conjeturas por parte del atacante y les lleva tiempo comprender la estructura de los datos a los que intentan acceder, pero con habilidad y perseverancia, todos los datos están al alcance de la mano. Para empeorar las cosas, las conjeturas se pueden automatizar fácilmente, reduciendo el tiempo que lleva robar tus datos.

Dos técnicas que se usan comúnmente para hacer esto: Content-based Blind SQL Injection y Time-based Blind SQL Injection. Aquí tenemos que comprobar si es vulnerable a SQL blind o no a un ejemplo utilizando el retardo de tiempo.

8) ID DE SESIÓN DÉBIL.

El ataque de predicción de sesión se centra en predecir los valores de ID de sesión que permiten a un atacante omitir el esquema de autenticación de una aplicación.

Al analizar y comprender el proceso de generación de ID de sesión, un atacante puede predecir un valor de ID de sesión válido y obtener acceso a la aplicación.

En el primer paso, el atacante debe recopilar algún ID de sesión válido, valores que se utilizan para identificar usuarios autenticados. Luego, debe comprender la estructura de la ID de sesión, la información que se utiliza para crearla y el algoritmo de cifrado o hash utilizado por la aplicación para protegerla.

Algunas implementaciones incorrectas utilizan identificadores de sesión compuestos por nombre de usuario u otra información predecible, como la marca temporal o la dirección IP del cliente. En el peor de los casos, esta información se usa en texto plano o se codifica utilizando algún algoritmo débil como la codificación base64.

Además, el atacante puede implementar una técnica de fuerza bruta para generar y probar diferentes valores de ID de sesión hasta que obtenga acceso a la aplicación con éxito. Entonces, aquí tenemos que averiguar si se está produciendo el ID de sesión débil o no.

9) XSS(DOM).

Cross-site scriptingLas secuencias de comandos entre sitios son una vulnerabilidad que permite a un atacante enviar código malicioso (generalmente en forma de Javascript) a otro usuario.

Debido a que un navegador no puede saber si la secuencia de comandos es confiable o no, ejecutará la secuencia de comandos en el contexto del usuario, lo que permitirá al atacante acceder a cualquier cookie o tokens de sesión retenidos por el navegador.

Si bien se produce una vulnerabilidad tradicional de secuencias de comandos entre sitios en el código del lado del servidor, las secuencias de comandos entre sitios basadas en modelos de objetos de documentos son un tipo de vulnerabilidad que afecta al código de secuencia de comandos en el navegador del cliente.

10) XSS (REFLECT).

Los ataques XSS reflejados, también conocidos como ataques no persistentes, ocurre cuando un script malicioso se refleja desde una aplicación web al navegador de la víctima.

Esta vulnerabilidad suele deberse a que las solicitudes entrantes no están lo suficientemente saneadas, lo que permite la manipulación de las funciones de una aplicación web y la activación de scripts maliciosos. Aquí podemos usar una función de javascript para explotar esto.

11) XSS (STORED).

La vulnerabilidad XSS  persistente (o almacenada) es un más peligrosa versión de un fallo cross-site scripting que se produce cuando los datos proporcionados por el atacante son guardados por el servidor, y luego se muestran permanentemente en páginas “normales” devueltas a otros usuarios en el curso de la navegación regular, sin el escape HTML adecuado.

Aquí también tenemos que usar Javascript, pero aquí si incrustaste exitosamente el javascript, esto se traducirá en el XSS almacenado, lo significa que cualquier persona podrá ver el contenido malicioso.

De igual forma existen otras máquinas vulnerables disponibles como bWAPP, Mutillidae, Metasploitable que también puedes probarlas.

Así que, en una sola aplicación web, puedes aprender muchos ataques prácticamente.