Asegurando DVWA en AWS

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 servidio web publico.

Establecemos las reglas de entrada y salida a traves del "Security Groups"

También utilizamos Cloudflare para redireccionar el tráfico hacia nuestra 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.

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.

Microsoft vs. Hackers: Análisis de los parches urgentes de febrero 2026 (CVE-2026-21510)

Microsoft ha lanzado su actualización mensual de seguridad y este febrero de 2026 no ha sido tranquilo. Se han corregido 78 vulnerabilidades en total, pero lo alarmante es que 6 de ellas son Zero-Days que ya están siendo explotadas activamente por cibercriminales antes de que existiera el parche. 

De los parches liberados, hay dos que destacan por su peligrosidad y facilidad de explotación:

CVE-2026-21510: Windows Shell Security Feature Bypass

• El problema: Esta vulnerabilidad permite a los atacantes eludir la advertencia de "Mark of the Web" (MOTW).

• El ataque: Un usuario recibe un archivo .url o un acceso directo malicioso. Al hacer clic, Windows debería advertir que el archivo viene de internet y es peligroso (SmartScreen). Sin embargo, este exploit se salta esa defensa y ejecuta el código sin que el usuario sospeche nada.

• Impacto: Es la puerta de entrada perfecta para descargar malware o ransomware inicial.
  

CVE-2026-21533: Windows Remote Desktop Services (RDP) Elevation of Privilege

• El problema: Una falla en cómo el servicio de Escritorio Remoto maneja la gestión de memoria.

• El ataque: Un atacante que ya tenga acceso limitado a una red (quizás lograda con el CVE anterior) puede usar esto para convertirse en SYSTEM (administrador total) en el servidor.

• Impacto: Control total del servidor y movimiento lateral por toda la red corporativa.

La recomendación estándar es "parchar en 24 horas", pero priorizando:

1. Servidores expuestos a internet (especialmente si usan RDP).

2. Equipos de usuarios finales (laptops de RRHH, Finanzas) que son propensos a recibir archivos maliciosos por correo.

Iniciamos el 2026

Esto es un post para recordar cómo funciona esta plataforma; porque ando un poco oxidado.

El objetivo es aprender inglés.

¿Como se realiza la Identificación de Servicios y Versiones?

La identificación de servicios y versiones es una fase crucial en el escaneo de vulnerabilidades, a menudo denominada "fingerprinting" (toma de huellas digitales). Sin esta información precisa, un escáner no podría determinar qué vulnerabilidades conocidas son aplicables a un sistema, ya que la mayoría de los fallos de seguridad están vinculados a software o versiones específicas.

Aquí te explico cómo los escáneres de vulnerabilidades realizan esta identificación:

1. Escaneo de Puertos (Port Scanning):

   • Primer paso: Antes de identificar servicios, el escáner debe saber qué puertos están abiertos y "escuchando" conexiones en el sistema objetivo. Esto se logra enviando diferentes tipos de paquetes a los puertos comunes (como TCP SYN, FIN, ACK, UDP, etc.) y analizando las respuestas.

   • Ejemplo: Si un escáner envía un paquete SYN a un puerto y recibe un SYN-ACK, sabe que el puerto está abierto. Si no recibe respuesta o recibe un RST, el puerto podría estar cerrado o filtrado por un firewall.

   • Herramientas comunes: Nmap es la herramienta más conocida para el escaneo de puertos y es utilizada por muchos escáneres de vulnerabilidades.

2. Análisis de Banners (Banner Grabbing):

   • Una vez que se identifica un puerto abierto, muchos servicios envían un "banner" o mensaje de bienvenida cuando se establece una conexión. Este banner a menudo contiene información sobre el servicio, el nombre de la aplicación, y lo más importante, su versión.

   • Ejemplo:

     • Conectarse al puerto 80 de un servidor web podría devolver un banner como: HTTP/1.1 200 OK Server: Apache/2.4.52 (Ubuntu) Date: Fri, 28 Jun 2025 07:00:00 GMT

     • Conectarse al puerto 22 (SSH) podría devolver: SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1

   • Los escáneres capturan estos banners y los comparan con su base de datos para identificar el servicio y su versión. Sin embargo, no todos los servicios proporcionan banners informativos, y algunos administradores de sistemas modifican los banners para ocultar información.

3. Fingerprinting Activo (Active Fingerprinting):

   • Cuando los banners no son suficientes, los escáneres emplean técnicas de "fingerprinting activo" enviando sondas (probes) específicas y analizando las respuestas. Estas sondas están diseñadas para provocar una respuesta única de diferentes servicios o sistemas operativos.

   • Sondas TCP/IP: Los escáneres pueden enviar paquetes con ciertas combinaciones de flags, opciones TCP, tamaños de ventana, etc., y analizar cómo el sistema objetivo responde. Diferentes sistemas operativos y stacks de red responden de maneras distintivas a estas sondas.

   • Sondas de aplicación: Para servicios específicos, los escáneres envían solicitudes diseñadas para elicitas una respuesta que revele más detalles.

     • HTTP: Envían solicitudes HTTP específicas (HEAD, GET /nonexistent_page, OPTIONS) y analizan los encabezados de respuesta, el código de estado, la forma en que manejan errores, etc.

     • FTP: Pueden intentar comandos FTP específicos o intentar iniciar una sesión para ver cómo el servidor responde a diferentes entradas.

     • SMB/NetBIOS: Envían solicitudes para enumerar recursos compartidos o consultar información sobre el sistema.

     • SNMP: Intentan consultas SNMP para obtener información del sistema.

   • Bases de datos de firmas (signatures): Las respuestas a estas sondas se comparan con una extensa base de datos de "firmas" (o huellas digitales). Cada firma está asociada a una versión específica de un servicio o sistema operativo. Por ejemplo, Nmap tiene una base de datos nmap-service-probes que contiene miles de patrones de respuesta para la detección de servicios y versiones.

4. Fingerprinting Pasivo (Passive Fingerprinting):

   • Algunos escáneres avanzados, o herramientas de monitoreo de red, pueden realizar "fingerprinting pasivo" analizando el tráfico de red ya existente sin enviar ninguna sonda activa.

   • Análisis de encabezados de paquetes: Pueden observar los patrones en los encabezados TCP/IP (como el tamaño de la ventana, el valor TTL, el orden de las opciones TCP) del tráfico que pasa por la red. Diferentes sistemas operativos tienen implementaciones ligeramente distintas de la pila TCP/IP, lo que puede revelar su identidad.

   • Análisis de tráfico de aplicación: Observan cómo se comunican las aplicaciones (por ejemplo, los encabezados HTTP en el tráfico web) para inferir el software y la versión.

   • Esta técnica es menos intrusiva y no genera tráfico adicional, pero puede no ser tan precisa como el fingerprinting activo y requiere que ya haya tráfico significativo para analizar.

5. Uso de Credenciales (Authenticated Scanning):

   • En un escaneo autenticado, el escáner utiliza credenciales válidas (usuario y contraseña) para iniciar sesión en el sistema objetivo (por ejemplo, a través de SSH, WinRM, o bases de datos).

   • Una vez autenticado, el escáner puede ejecutar comandos directamente en el sistema operativo para obtener información precisa sobre el software instalado, las versiones, los parches aplicados, la configuración del sistema, etc.

   • Ejemplos:

     • En un sistema Linux: lsb_release -a, cat /etc/os-release, dpkg -l, rpm -qa.

     • En un sistema Windows: systeminfo, wmic product get name,version.

     • Consultas a la base de datos para obtener la versión del motor de la base de datos (SELECT @@version; para MySQL, SELECT VERSION(); para PostgreSQL, etc.).

   • Este método es generalmente el más preciso porque obtiene la información directamente del sistema, evitando las conjeturas del fingerprinting basado en la red.

Importancia de la Precisión:

La precisión en la identificación de servicios y versiones es crítica por varias razones:

• Evitar falsos positivos: Si un escáner identifica incorrectamente un servicio o versión, podría reportar vulnerabilidades que no existen en el sistema real.

• Priorización efectiva: Una identificación correcta permite al escáner asignar la severidad adecuada a las vulnerabilidades y priorizar los esfuerzos de remediación.

• Relevancia de las vulnerabilidades: Las bases de datos de vulnerabilidades (como CVE, NVD) están directamente vinculadas a versiones específicas de software. Sin la versión precisa, es imposible saber si una vulnerabilidad conocida es aplicable.

En resumen, la identificación de servicios y versiones es un proceso multifacético que combina el escaneo de puertos, el análisis de banners, el fingerprinting activo y pasivo, y, idealmente, el escaneo autenticado para construir un perfil detallado del software en ejecución en el sistema objetivo.