Asegurando DVWA en AWS | SQLI

En la automatización con Nessus y OpenVas utilizamos el DVWA (Damn Vulnerable Web App), ahora vamos a poner unos controles para evitar que las herramientas ya mencionadas identifiquen vulnerabilidades de riesgo medio.

*Primero: Creamos un Balanceador de carga para asociarlo a nuestra instancia EC2 que tiene expuesto el puerto 80.

El balanceador de carga de aplicaciones distribuye el tráfico HTTP y HTTPS entrante entre varios destinos, como instancias de Amazon EC2, microservicios y contenedores, en función de los atributos de la solicitud. Cuando el balanceador de carga recibe una solicitud de conexión, evalúa las reglas del agente de escucha por orden de prioridad para determinar qué regla se debe aplicar y, si corresponde, selecciona un destino del grupo de destino para la acción de la regla.

La Arquitectura Ideal

Para proteger una aplicación (como un entorno de pruebas DVWA) no apuntamos el tráfico directo a la EC2. En su lugar, implementamos un flujo de capas:
Usuario ➔ Cloudflare (DNS/Proxy) ➔ AWS ALB (Load Balancer) ➔ AWS WAF ➔ Instancia EC2 (Subred Privada)

Para que el balanceador distribuya el tráfico, creamos 2 instancias con el servicio web publico.

Establecemos las reglas de entrada y salida a través de los "Security Groups"

También utilizamos Cloudflare para redireccionar el tráfico hacia nuestro Application Load Balancer (ALB) de AWS.

Para finalizar, realizamos un Network Scan con Nessus Professional para identificar vulnerabilidades; intentamos un Web Application Test y no permite, el target al momento de lanzar el scan lo pone vacío. Esas son algunas restricciones del trial de Nessus, pero bueno, recurrimos a OpenVas XD.

Ahora los resultados son distintos; con la arquitectura actual solo identifico 13 alertas que posiblemente permitirían obtener información del servidor.

OpenVas siempre nos ayuda y no pone restricciones. Comparto reporte de vulnerabilidades con OpenVas.

Intentamos realizar SQL Injecton para validar si el balanceador protege contra ataques SQL

a) 1' or 1=1 #

b) 1. test' union select null, version() #

Con esto validamos que el balenador de AWS no protege ni está configurado para bloquear ataques SQL Injection. La configuración inicial de Cloudflare tampoco, solo dirige el tráfico a través de su proxy.

Entonces creamos unas reglas en Cloudflare; si eso no es suficiente, configuraremos el WAF de AWS.

Primero vamos con Cloudflare.

Nos centramos en el amado "union select" podemos poner 4000 caracteres y buscar payloads como los de pentestmonkey para armar o utilizar el "expression builder". En total se puede crear 5 reglas con la versión free.

Utilizamos: 1' OR 1=1 union SELECT user()#

Cloudflare detectará la SQL injection y bloqueará la peticion.

En la imagen se visualiza que nueva regla con nombre "Regla SQL Injection" tiene la acción de "block"

Ahora vamos a configurar un WAF en AWS e intentaremos hacer un SQLInjection.

Revisamos el log de la inyección y visualizamos que el WAF está funcionando.