This content originally appeared on DEV Community and was authored by Dilver Huertas Guerrero
Introducción
Se dispuso una máquina virtual con Metasploitable (versión 3), la cual está diseñada para pruebas de intrusión y testing (pentest) con varias aplicaciones listas para ser atacadas. Adicionalmente, una máquina virtual con Kali Linux, con la cual se ejecutó la herramienta de escaneo de red y puertos Nmap y las herramientas de escaneo de vulnerabilidades Nessus y Greenbone CE (antes conocido como OpenVAS). A partir de este análisis se identificaron vulnerabilidades que fueron explotadas utilizando Metasploit. Se busca mostrar el proceso de detección, análisis y explotación de vulnerabilidades, así como las herramientas y técnicas de identificación de estas.
También se monitoreo la carga en la máquina victima (Metasploitable) al lanzar el escaneo de vulnerabilidades con Nessus y con GreenboneCE, y se midió el rendimiento de la red (ancho de banda y la latencia) utilizando IPERF, con el fin de determinar los escenarios de aplicación, dado que se está realizando un escaneo activo, que en entornos reales generaría alertas en los sistemas de protección.
Desarrollo
Se dispuso del escenario mostrado en la Figura 1. Ambas máquinas tienen en su configuración de red el modo Host-only adapter habilitado, de esta manera pueden comunicarse entre sí.
Figura 1. Escenario de laboratorio. Fuente: propia.
Se procede a identificar las IPs asignada a cada una de las máquinas, en la figura 2 para Kali Linux, con IP 192.168.56.4 y en la figura 3 para Metasplotable 3, con IP 192.168.56.3.
Figura 2. Ejecución de ifconfig. Fuente: propia.
Figura 3. Ejecución de ipconfig. Fuente: propia.
Escaneo de red y puertos
Se procede a identificar los servicios disponibles en Metasploitable utilizando Nmap, los cuales se muestran en la figura 4.
Figura 4. Análisis de servicios con nmap. Fuente: propia.
Se identifica que el servicio de ping esta deshabilitado, como se muestra en la figura 5. Por ellos, se procede a generar una consulta más detallada con Nmap.
Figura 5. Servicio ping deshabilitado. Fuente: propia.
La consulta detallada nmap -Pn -A -sV 192.168.56.3, indica que el sistema operativo es Windows, además de lo mostrado en la figura 6.
Figura 6. Escaneo detallado con Nmap. Fuente: propia.
El escaneo realizado con Nmap muestra los siguientes puertos abiertos y servicios detectados:
- Puerto 21/tcp (FTP)
- Servicio: Microsoft FTPD
- Estado: Abierto
- Detalles adicionales: Windows_NT
- Puerto 22/tcp (SSH)
- Servicio: OpenSSH 7.1
- Estado: Abierto
- Detalles adicionales: Muestra la llave pública RSA-2048 y ECDSA-521. OpenSSH utiliza el protocolo 2.0.
- Puerto 80/tcp (HTTP)
- Servicio: Microsoft IIS httpd 7.5
- Estado: Abierto
- Detalles adicionales: Identifica métodos potencialmente peligrosos como TRACE, lo que podría permitir ataques de tipo Cross-Site Tracing (XST). No tiene http-title.
- Puerto 4848/tcp (HTTPS - Administración)
- Servicio: Oracle GlassFish Application Server (versión 4.0)
- Estado: Abierto
- Detalles adicionales: Certificado SSL no válido desde 2023-05-13. El http-title dice “Login”. Problema reportado con el análisis XML de la ruta ‘/evox/about’.
- Puerto 8080/tcp (HTTP)
- Servicio: Sun GlassFish Open Source Edition 4.0
- Estado: Abierto
- Detalles adicionales: El servidor GlassFish está ejecutándose y podría estar exponiendo métodos HTTP peligrosos, como PUT, DELETE y TRACE, lo que podría permitir la modificación de recursos en el servidor.
- Puerto 8383/tcp (HTTP - Apache)
- Servicio: Apache httpd
- Estado: Abierto
- Puerto 9200/tcp (HTTP)
- Servicio: Es muy probable que sea Elasticsearch, ya que este servicio utiliza frecuentemente el puerto 9200 para su API REST.
- Estado: Abierto
- Detalles adicionales: El servidor responde con 400 Bad Request cuando se intenta acceder a rutas como ‘/nice ports, Trinity.txt.bak’. El servidor responde con un JSON que contiene detalles de un servicio con nombre: "Devil Hunter Gabriel".
- Puertos 49153/tcp y 49154/tcp
- Servicio: Microsoft Windows RPC
- Estado: abierto
- Puerto 9200/tcp (HTTP)
- Servicio: Desconocido
Nmap también tiene la capacidad de generar informes detallados en formato XML, como se muestra en la figura 7.
Figura 7. Reporte generado con Nmap. Fuente: propia.
Medición de desempeño en el escaneo de vulnerabilidades
Para realizar la medición del desempeño de las herramientas Nessus y GCE, se utiliza Performance Monitor[1] e iperf3[2]. Primero, se procede a realizar una prueba del funcionamiento de iperf3, como se muestra en la figura 8.
Figura 8. Prueba del funcionamiento de iperf3. Fuente: propia.
Adicionalmente, se crea en Metasploitable un recopilador de datos personalizado con nombre UsoRecursosEscaneo, como se observa en la figura 9.
Figura 9. Recopilador de datos personalizado utilizando Performance Monitor. Fuente: propia.
Se configura el escaneo avanzado con Nessus, como se observa en la figura 10.
Figura 10. Escaneo avanzado de vulnerabilidades con Nessus. Fuente: propia.
Posteriormente, se ejecuta el escenario de análisis de vulnerabilidades y medición de desempeño para Nessus, como se muestra a continuación.
Figura 11. Escenario de análisis con Nessus. Fuente: propia.
Se muestran los resultados del escaneo en la figura 12.
Figura 12. Resultado del escaneo realizado con Nessus. Fuente: propia.
Se configura el escaneo avanzado (full and fast) con Greenbone CE, como se muestra en la figura 13.
Figura 13. Configuración del escaneo avanzado con GCE. Fuente: propia.
Se ejecuta el monitoreo de recursos y el escaneo de vulnerabilidades con GCE, como se muestra en la figura 14.
Figura 14. Escaneo avanzado con GCE y monitoreo.
Comparación de desempeño entre GCE y Nessus
GCE parece tener una mayor utilización de los recursos del sistema (procesador, memoria, y disco), con más fallos de página, lecturas/escrituras de páginas, y transferencias de disco; lo cual sugiere que está manejando una carga de trabajo más intensa o menos eficiente. Por otro lado, Nessus presenta más interrupciones y cambios de contexto, lo que sugiere que está manejando más eventos de hardware o procesos simultáneos, pero con menor uso general de memoria y disco.
A continuación, en la tabla 1, se muestra un resumen de las vulnerabilidades encontradas y el tiempo de ejecución, en esta última se observa que GCE toma más del doble de tiempo de ejecución que Nessus.
Tabla 1. Resumen de desempeño entre GCE y Nessus.
| Variable | Nessus | GCE |
|---|---|---|
| Vulnerabilidades reportadas | 52 (15 críticas, 19 altas, 16 medias, 2 bajas) | 55 (25 altas, 27 medias, 3 bajas) |
| Tiempo | 25 minutos 21 segundos | 57 minutos 16 segundos |
Nota: La clasificación que realiza Nessus y GCE difiere en sus niveles, por lo cual no es comparable directamente.
En las figuras 15 y 16 se observa el desempeño de ambas herramientas de acuerdo con la información obtenida por medio de Performance Monitor.
Figura 15. Métricas de desempeño de uso de memoria y procesador. Fuente: propia.
Figura 16. Métricas de paginamiento y uso de disco. Fuente: propia.
A continuación, se presenta un resumen de la comparación en rendimiento:
- Memoria Disponible
- GCE: Promedio de 196.88 MB
- Nessus: Promedio de 191.94 MB
- Diferencia: GCE tiene una mayor media de memoria disponible, lo que podría indicar una mayor disponibilidad de recursos de memoria.
- Utilización del Procesador
- GCE: 40.98%
- Nessus: 38.66%
- Diferencia: GCE muestra un uso del procesador más alto en promedio, lo que podría sugerir que está manejando una carga de trabajo más alta.
- Cambios de Contexto por Segundo
- GCE: 2873.92 cambios/seg
- Nessus: 3132.20 cambios/seg
- Diferencia: Nessus tiene una tasa mayor de cambios de contexto, lo que puede indicar una mayor carga de trabajo multitarea en este entorno.
- Longitud de la Cola del Procesador
- GCE: 0.78 procesos en cola
- Nessus: 0.41 procesos en cola
- Diferencia: GCE tiene una cola de procesos más larga, lo que puede indicar que el procesador estuvo más ocupado o que hubo más procesos esperando para ser ejecutados.
- Page Faults/sec
- GCE: Relativamente más alto en algunos puntos, lo que puede indicar más intentos de acceder a páginas de memoria que no estaban en la memoria física.
- Nessus: Mostró menos picos de fallos de página, lo que podría indicar una mejor gestión de la memoria.
- Pages/sec
- GCE: Muestra más actividad de lectura/escritura de páginas.
- Nessus: Menor cantidad de actividad en comparación con GCE.
- Pool Paged Bytes
- GCE: Muestra mayor uso de bytes paginados, lo que indica más datos en memoria virtual.
- Nessus: Menor uso de bytes paginados, lo que puede indicar que menos datos se enviaron al archivo de página.
- Disk Transfers/sec
- GCE: Mayor cantidad de transferencias de disco por segundo, lo que indica más actividad en el subsistema de almacenamiento.
- Nessus: Menos transferencias de disco, lo que podría indicar una menor carga de trabajo en el almacenamiento.
- Interrupts/sec:
- GCE: Menor cantidad de interrupciones por segundo.
- Nessus: Mayor cantidad de interrupciones por segundo, lo que puede sugerir una mayor interacción con dispositivos de hardware o una mayor carga en la gestión de interrupciones.
También se analizó el impacto en la red utilizando iperf3, como se muestra en la figura 17.
Figura 17. Transferencia y tasa de bits utilizando iperf3. Fuente: propia.
A continuación, se presenta un análisis comparativo de los resultados obtenidos al evaluar el desempeño de GCE y Nessus, utilizando iperf3, dónde se evalúa tanto la transferencia de datos (MBytes) como la tasa de bits (Mbits/seg):
- Transferencia de Datos (MBytes)
- GCE: La transferencia de datos en el caso de iperf3GCE oscila entre 10 y 665 MBytes. Se observan fluctuaciones significativas a lo largo del tiempo, con una caída abrupta alrededor de los 10 MBytes en un punto, lo que sugiere posibles interrupciones o inestabilidades en la conexión.
- Nessus: En comparación, la transferencia de datos en iperf3Nessus es más estable, con un rango de 450 a 704 MBytes. Aunque hay variaciones, son más suaves y no se presentan caídas tan dramáticas como en el caso de GCE.
- Tasa de Bits (Mbits/seg)
- GCE: La tasa de bits varía considerablemente, con un máximo de 665 Mbits/seg, pero también con caídas abruptas hasta los 10 Mbits/seg. Estas caídas pueden indicar problemas temporales en la red, como congestión, interferencias o limitaciones del hardware que afectan la estabilidad del enlace.
- Nessus: Por otro lado, la tasa de bits en Nessus es mucho más constante, con valores en su mayoría por encima de los 450 Mbits/seg y un máximo de 742 Mbits/seg. Aunque también muestra algunas variaciones, la estabilidad general es mucho mayor, con una mejor capacidad para mantener tasas de bits más elevadas durante el tiempo de la prueba.
- Estabilidad y Rendimiento
- GCE muestra una inestabilidad marcada, con varias caídas importantes tanto en la transferencia de datos como en la tasa de bits. Esto podría deberse a condiciones fluctuantes de la red o problemas específicos de la infraestructura que se usó para la prueba.
- Nessus, por el contrario, exhibe un comportamiento mucho más estable. Aunque tiene algunas fluctuaciones, las caídas son mucho menos severas y los valores se mantienen dentro de un rango más consistente, lo que indica un mejor rendimiento general.
Nessus presenta una red más confiable y estable con mejor capacidad para mantener altos niveles de transferencia y tasa de bits a lo largo del tiempo; mientras que GCE muestra variaciones más drásticas, lo que puede sugerir problemas de estabilidad o congestión en la red, con importantes caídas que afectaron el rendimiento general.
Si bien el desempeño de las herramientas es importante, también se debe tener en cuenta los resultados en cuanto las vulnerabilidades detectadas, dónde se observa que GCE obtiene datos más detallados e incluso encuentra credenciales para servicios abiertos, a diferencia de Nessus. En la tabla 2 se presenta un resumen.
Tabla 2. Cantidad de vulnerabilidades encontradas por tipo de tecnología.
| Tecnología | Nessus | GCE |
|---|---|---|
| Apache | 24 | |
| Apache Axis2 | 2 | |
| Apache Tomcat | 15 | 16 |
| Elasticsearch | 11 | |
| FTP Server | 2 | |
| Java JMX | 1 | |
| Microsoft Windows LAN Manager SNMP | 2 | |
| OpenSSH | 6 | |
| Oracle Glassfish Server | 1 | |
| SNMP Agent | 1 | 1 |
| SSH Server | 1 | 2 |
| SSL Certificate | 4 | 4 |
| SSL Cipher Suite | 2 | 2 |
| HTTP | 3 | 1 |
| SSL Service | 5 | |
| TCP Timestamp | 1 |
Nota. Esta clasificación fue realizada manualmente a partir de los reportes entregados por cada una de las herramientas.
De acuerdo con el análisis de las herramientas, el servicio Apache Tomcat es probablemente el que tiene la posibilidad de ser explotado, dado que ambas sugieren vulnerabilidades, revisando los informes se observa que fue detectado en el puerto 8282/tcp, sin embargo, Nmap no detecto nada expuesto en ese puerto, sino en el 8383/tcp HTTP Apache.
En la siguiente sección se procede a explotar las vulnerabilidades detectadas para Apache, utilizando Metasploit y los resultados generados por el escaneo de vulnerabilidades.
Explotación de vulnerabilidades utilizando Metasploit
En el puerto 8282 está expuesto el servicio Apache Tomcat 8.0.33, como se observa en la figura 18.
Figura 18. Servicio apache tomcat. Fuente:propia
Se procede a realizar un escaneo de directorios utilizando metasploit, como se observa en la figura 19, encontrando 4 directorios disponibles.
Figura 19. Escaneo de directorios con metasploit. Fuente: propia.
Se procede a explorar el primer directorio Axis2, dado que como se muestra en la figura 20, GCE encontró credenciales para este servicio.
Figura 20. Credenciales encontradas por GCE para el servicio Axis2.
En la figura 21, se observa que utilizando las credenciales reportadas (admin/axis2) por GCE es posible acceder al módulo web de administración.
Figura 21. Acceso al módulo web de administración de Axis2. Fuente: propia.
Adicionalmente, GCE reporto encontrar credenciales para los servicios de FTP y SSH como se observa en las figuras 22 y 23, respectivamente.
Figura 22. Credenciales para el servicio FTP. Fuente: propia.
Figura 23. Credenciales para el servicio SSH. Fuente: propia.
Se procede a acceder al servidor utilizando el servicio SSH, como se observa en la figura 24, utilizando las credenciales vagrant:vagrant.
Figura 24. Acceso al servicio SSH. Fuente: propia.
Otro directorio interesante es Manager, en el cual al intentar acceder se solicita credenciales, sin embargo, al poner credenciales erróneas, se genera un error 401, que entrega información relevante, en el cual se indica que en el archivo conf/tomcat-users.xml se encuentran las credenciales para utilizar la aplicación web, como se observa en la figura 25.
Figura 25. Página de error 401 al intentar acceder al directorio manager. Fuente: propia.
Utilizando esta información y la consola SSH previamente establecida, se procede a leer el archivo con el comando: findstr "^" "C:\Program Files\Apache Software Foundation\tomcat\apache-tomcat-8.0.33\conf\tomcat-users.xml". En este archivo se identifican las credenciales username="sploit" password="sploit" roles="manager-gui", como se observa en la figura 26.
Figura 26. Acceso al archivo tomcat-users.xml. Fuente: propia.
Adicionalmente, se procede a realizar una enumeración de usuarios en el directorio manager, como se muestra en la figura 27.
Figura 27. Enumeración de usuarios en el servicio apache tomcat. Fuente: propia.
Dado que ya se han realizado varias tareas de explotación, ahora se procede a realizar tareas de post-explotación utilizando Meterpreter [3]. Se procede a establecer una consola utilizando el exploit multi/http/tomcat_mgr_upload, como se muestra en la figura 28, obteniendo una consola con el usuario METASPLOITABLE3.
Figura 28. Estableciendo una consola con Meterpreter. Fuente: propia.
De manera similar al anterior y utilizando el mismo exploit, se procede a cambiar el payload a Windows/meterpreter/reverse_tcp, lo cual permite establecer una consola, pero con el usuario NT AUTHORITY\SYSTEM, permitiendo así tener permisos más elevados en la máquina. Esto se muestra en la figura 29.
Figura 29. Consola con un usuario de mayor privilegio. Fuente: propia.
Es posible igualmente utilizar un exploit para Axis2, con el fin de establecer la consola con Meterpreter, como se observa en la figura 30.
Figura 30. Consola utilizando un exploit para Axis2. Fuente: propia.
Ingresando a la pantalla de administración de apache tomcat, se observa que existe un servicio /struts2-rest/showcase, como se muestra en la figura 31. Este también puede aprovecharse para establecer una consola con Meterpreter, como se observa en la figura 32.
Figura 31. Servicio struts2 expuesto por apache tomcat. Fuente: propia.
Figura 32. Consola utilizando el servicio struts2. Fuente: propia.
Se registran múltiples maneras de establecer una consola utilizando Meterpreter y diferentes servicios/vulnerabilidades que permitirían continuar con tareas de post-explotación.
Conclusiones
La elección entre Nessus y Greenbone CE debe basarse en las necesidades específicas de la organización, el nivel de detalle requerido en los informes, y la capacidad del sistema para soportar el impacto del escaneo de vulnerabilidades. A continuación, se desarrollan estos puntos en detalle:
Evaluación de la calidad y la estructura de los informes de vulnerabilidades
Nessus: Los informes generados por Nessus se caracterizan por su claridad y estructura organizada. Incluyen detalles importantes como la clasificación de las vulnerabilidades en críticas, altas, medias y bajas, junto con descripciones, soluciones recomendadas y referencias adicionales. La presentación es intuitiva, facilitando la interpretación de los datos para profesionales de seguridad con diferentes niveles de experiencia. Sin embargo, puede presentar menos detalles técnicos en comparación con GCE.
Greenbone CE: Los informes de GCE tienden a ser más detallados, proporcionando información técnica profunda, incluyendo credenciales descubiertas y configuraciones específicas de los servicios. Sin embargo, esta riqueza de detalles puede hacer que los informes sean más complejos de interpretar para aquellos que no están familiarizados con el análisis de vulnerabilidades a nivel técnico.
Análisis del impacto en el rendimiento del sistema
CPU y Memoria: Durante la ejecución de escaneos, GCE mostró un mayor consumo de CPU y memoria en comparación con Nessus, lo que sugiere que maneja una carga de trabajo más intensa. Nessus, aunque presenta más interrupciones y cambios de contexto, usa menos recursos en general, lo que indica una operación más optimizada en cuanto a la gestión de memoria y procesos.
Ancho de Banda (IPERF): Las pruebas de IPERF revelaron que Nessus maneja de manera más eficiente la red, mostrando una tasa de bits más estable y una mayor consistencia en la transferencia de datos. Por otro lado, GCE presentó inestabilidades significativas, con caídas abruptas en la tasa de bits, lo que podría reflejar una mayor susceptibilidad a la congestión de la red o limitaciones de hardware.
Fortalezas y debilidades
Fortalezas de Nessus: Su capacidad para generar informes claros y organizados, junto con su menor impacto en los recursos del sistema, lo hace ideal para organizaciones que necesitan un análisis de vulnerabilidades eficiente y fácil de interpretar sin sacrificar el rendimiento del sistema.
Fortalezas de GCE: La riqueza de detalles técnicos en sus informes y su capacidad para detectar un mayor número de vulnerabilidades, incluyendo la identificación de credenciales, lo hacen una herramienta poderosa para un análisis profundo y exhaustivo.
Debilidades de Nessus: Puede omitir detalles técnicos que GCE captura, lo que podría ser un inconveniente en entornos donde se requiere un análisis profundo.
Debilidades de GCE: Su mayor consumo de recursos y la complejidad de sus informes pueden representar un desafío en ambientes donde los recursos son limitados o donde se requiere una interpretación rápida de los resultados.
Recomendaciones sobre cuándo utilizar cada herramienta
Nessus: Es recomendable en organizaciones que buscan un equilibrio entre un análisis efectivo de vulnerabilidades y la necesidad de minimizar el impacto en el rendimiento del sistema. También es adecuado para equipos con menos experiencia técnica que necesitan interpretar los resultados rápidamente.
Greenbone CE: Es ideal en situaciones donde se requiere un análisis profundo y detallado, especialmente en entornos técnicos con la capacidad de manejar su mayor demanda de recursos. También es útil cuando se necesita descubrir información crítica como credenciales de servicios o detalles específicos de configuraciones.
Referencias
[1] C. Marcho, «Windows Performance Monitor Overview - Microsoft Community Hub», https://techcommunity.microsoft.com/t5/ask-the-performance-team/windows-performance-monitor-overview/ba-p/375481.
[2] «iPerf - The ultimate speed test tool for TCP, UDP and SCTP», https://iperf.fr/.
[3] Sentinel One, «Metasploit Meterpreter: The Advanced and Powerful Payload», https://www.sentinelone.com/blog/meterpreter-advanced-powerful-metasploit-payload/.
This content originally appeared on DEV Community and was authored by Dilver Huertas Guerrero
Dilver Huertas Guerrero | Sciencx (2024-09-20T20:37:05+00:00) Detectar, analizar y explotar vulnerabilidades utilizando herramientas de código abierto: Medición de desempeño y resultados. Retrieved from https://www.scien.cx/2024/09/20/detectar-analizar-y-explotar-vulnerabilidades-utilizando-herramientas-de-codigo-abierto-medicion-de-desempeno-y-resultados/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.