Una de ellas fue el evento que cada año lidera incansablemente Diego A Salazar: Securinf; en este evento participé con dos conferencias: Análisis de Malware sobre windows y un WorkShop de BackTrack.

El objetivo de este post es publicar los video tutoriales que presenté ese día. Aunque son muy cortos y básicos pueden servir para quienes recién inician en este campo de la seguridad mediante el uso de la distribución BackTrack. También debe tenerse en cuenta que estos los realicé exclusivamente para un workshop, por lo tanto no tienen audio, pues están pensados en ir mostrando la herramienta e ir explicando su funcionamiento y configuración en vivo. Haré una recopilación de lo publicado hasta el momento sobre los laboratorios de BackTrack y luego los enlaces de descarga con una pequeña descripción de los videos presentados en la conferencia.

Video Tutorial BackTrack, Introducción y Conceptos Básicos

Video Tutorial BackTrack: Booteo, Interfaz Gráfica y Directorios

Video Tutorial: Instalación de BackTrack 4 (Pre-Final)

Video Tutorial: Configuración Básica de Red en BackTrack 4 (Pre-Final)

Video Tutorial: Instalación de VMWare WorkStation en BackTrack 4 (Pre-Final)

——————————————————————————————————————————————————————————–

Videos del WorkShop de Backtrack:

01- Booteo BackTrack (Creación y configuración de una máquina virtual en VirtualBox – Booteo inicial de BackTrack)

02 – Ejecución inicial de BackTrack (Inicio del servicio de red, Inicio del servidor X, Cambio de contraseña, Rápido recorrido por el menú K)

03 – Recorrido por los directorios de herramientas contenidas en BackTrack -Web, Wireless, Passwords, Cisco, etc. Ejecución de servicios disponibles en BackTrack – HTTP, VNC, TFPT, etc.

04 – Escaneo e identificación  de puertos y servicios con Nmap en BackTrack.

05 – Escaneo automatizado de nuestra red con la herramienta AutoScan en BackTrack.

06 – Information Gathering/Footprinting con Maltego en BackTrack.

07 – Introducción al análisis básico de ejecutables con OllyDbg en BackTrack.

08 – Identificación de cifrados utilizados en la web con BackTrack.

09 – Escaneo e identificación de directorios y archivos sensibles en servidores web con DirBuster en BackTrack.

10 – Identificación del servidor Web con netcat y httprint.

11 – Escaneo e identificación de directorios y archivos sensibles en servidores Web con Nikto (BackTrack) y Wikto (Windows).

12 – Spidering con Wget en BackTrack.

13 – Xhydra y John The Ripper en BackTrack.

El receptor de escucha es el punto de entrada a conexiones remotas a una base de datos Oracle. Escucha peticiones de conexión y realiza la gestión acorde de las mismas. Esta comprobación es posible si la persona a cargo de las pruebas puede acceder a este servicio — la comprobación debería ser realizada desde la Intranet (la mayoría de instalaciones de Oracle no exponen este servicio a la red externa).

El receptor escucha en el puerto 1521 por defecto (el puerto 2483 es el nuevo puerto oficialmente registrado para el receptor TNS y el 2484 para el receptor TNS Listener usando SSL). Es una buena práctica cambiar el receptor de este puerto a un número de puerto arbitrario. Si el receptor está “apagado” el acceso remoto a la base de datos no es posible. Si este es el caso, la aplicación fallaría, creando también un ataque de denegación de servicio.

Integrigy AppSentry Listener Check for the Oracle Database:

AppSentry Listener Security Check es una herramienta desarrollada para chequear las configuraciones de seguridad de los receptores de escucha y aplicaciones de la base de datos Oracle. (Más información…)

En el siguiente video tutorial se muestra el procedimiento de descubrimiento del servicio de escucha de Oracle y la ejecución de algunas pruebas al receptor haciendo uso de la herramienta Listener Security Check.

Link:

Descargar video tutorial de pruebas al listener de Oracle (Password: www.dragonjar.org)

Muchas aplicaciones tienen vulnerabilidades y estrategias de ataque conocidas, que pueden ser explotadas para conseguir control remoto o explotación de los datos de la aplicación.

Además, muchas aplicaciones están a menudo mal configuradas o sin actualizar, debido a la impresión de que solo se usan “internamente”, y por tanto no representan ninguna amenaza.

Con la proliferación de servidores web virtuales, la tradicional relación de una dirección IP con un servidor web 1 a 1 ha ido perdiendo su significado original. No es nada raro tener múltiples sites y aplicaciones web cuyos nombres resuelvan a la misma dirección IP (este escenario no se limita a entornos de hosting, también aplica a entornos corporativos).

Nmap:

Nmap es un programa de código abierto que sirve para efectuar rastreo de puertos TCP y UDP atribuido a Fyodor. Se usa para evaluar la seguridad de sistemas informáticos, así como para descubrir servicios o servidores en una red informática. (Más información…)

El siguiente video tutorial muestra el proceso de descubrimiento básico de aplicaciones con Nmap.

Link:

Descargar video tutorial de descubrimiento de aplicaciones con Nmap (Password: www.dragonjar.org)

1. Imágen ISO / LiveCD USB / Appliance de BackTrack
2. Software de virtualización (VMWare WorkStation, VMWare Player, Qemu, Virtual BOX, MOKA5, etc.)
3. PC de mediana capacidad.
4. Conexión a internet (algunos ejercicios, referencias)

Contenido temático:

1. Conceptos básicos de BackTrack
2. Servicios básicos (DHCP, IP, Apache, SSHD, Tftp, VNC)
3. Entorno básico Bash
4. NetCat
5. Wireshark
6. Nmap
7. Técnicas de recolección de información
8. Recursos Web
9. Reconocimiento DNS
10. Reconocimiento SNMP
11. Reconocimiento SMTP
12. Recolección de información Microsoft Netbios
13. Escaneo de puertos
14. ARP Spoofing
15. Explotación de Buffer overflow en Windows
16. Fuzzing
17. Trabajando con Exploits
18. Transferencia de archivos
19. Frameworks de explotación
20. Ataques del lado del cliente
21. Redirección
22. Ataques a contraseñas
23. Vectores de ataques a aplicaciones Web
24. Troyanos
25. NTFS Alternate Data Streams
26. Rootkits

Palabras clave: BackTrack, Test de Penetración, Distribución, LiveCD, scanner de puertos, Vulnerabilidades, exploits, sniffers, SQL Injection, Troyanos, RootKits, NTFS Alternate Data Streams, Fuerza Bruta, Redirección, Fuzzing, Spoofing, NetCat, Bash, Nmap.

Este nuevo recurso estará basado en el sistema de entrenamiento ofrecido por los propios desarrolladores y colaboradores del proyecto BackTrack (Remote-Exploit) Offensive-security.com.

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 1 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org)

Herramientas necesarias:

NetCat
Nmap
Wikto
Wget
.Net Framework 2.0

Palabras claves (Documentos de interés, Definiciones):

Nmap – NetCat – Wikto – Wget – .Net Framework – ICMP – Clases de redes – Ping – Puertos – Subred – Escaneo – Servidor Web – Apache – PHP – Vulnerabilidades – JavaScript – HTTP – Robots.txt – Logs

En este primer nivel, que sirve como toma de contacto con el modelo de resolución, lo primero que haremos será marcar unos objetivos principales, que bien podrán servir tanto para afrontar este reto, como en general para el inicio de cualquier actividad que tenga como finalidad determinar posibles puntos de intrusión en un sistema.

Los objetivos son los siguientes:

• Conocer la estructura del sistema y de la red
• Conocer la estructura del aplicativo
• Buscar ficheros por defecto con información sensible
• Analizar la lógica del aplicativo
• Determinar los posibles puntos de intrusión
• Información sobre Red y Servicios

Vamos a comenzar delimitando los sistemas presentes en la red de clase C 192.168.200.0/24 . Para hacerlo, usamos nmap con su modificador –sP ( ICMP Ping ), aunque bien se puede dar la circunstancia de existir sistemas que no contesten a tráfico ICMP.

> nmap -sP 192.168.200.1-254

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 18:51 Hora estandar romance
Host 192.168.200.1 appears to be up.
Host www.blindware.inc (192.168.200.2) appears to be up.
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)
Nmap finished: 254 IP addresses (2 hosts up) scanned in 17.016 seconds

Por ello, una comprobación también es interesante es verificar directamente algunos puertos típicos, haciendo uso de tráfico TCP, sin usar comprobación previa por ICMP. Por ejemplo lo podemos hacer con el modificador –P0 –p 80, indicando así que no se envíe un “ping” previo, y que se compruebe el puerto 80/tcp.

En nuestro caso concreto, y dado que directamente parece que no existe ningún otro host activo en esa subred, escanearemos la IP 192.168.200.2. Podremos escanear por defecto, eliminando el modificador “-p”, algunos puertos concretos o escanearlos todos “-p 1-65535”. Un detalle importante que siempre debemos recordar es que cuando marcamos un escaneo –sS o –sT, o sin tipo, únicamente escaneamos puertos TCP, los puertos UDP deben escanearse con el modificador –sU. En nuestro caso este ha sido el resultado.

> nmap -P0 -sS -p 22,23,25,80,110,443,3306 192.168.200.2

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 19:02 Hora estßndar romance
Interesting ports on www.blindware.inc (192.168.200.2):
PORT STATE SERVICE
22/tcp filtered ssh
23/tcp filtered telnet
25/tcp filtered smtp
80/tcp open http
110/tcp filtered pop3
443/tcp open https
3306/tcp filtered mysql
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)

Nmap finished: 1 IP address (1 host up) scanned in 0.360 seconds

De esta verificación obtenemos que existen 2 puertos abiertos en ese sistema: 80 y 443, en un principio coorrespondientes a tráfico http y https. Existe otro modificador que nos puede dar más información sobre estos puertos: –sV

> nmap -sV -p 80,443 192.168.200.2

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 19:14 Hora estandar romance
Interesting ports on www.blindware.inc (192.168.200.2):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.4 ((Fedora))
443/tcp open ssl OpenSSL
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)

Nmap finished: 1 IP address (1 host up) scanned in 6.719 seconds

Llegados a este punto, podemos decir que si bien podemos seguir haciendo un uso más intensivo de herramientas de red, para nuestros propósitos hemos conseguido establecer la existencia de un sistema activo en la subred determinada, el cual cuenta con 2 puertos TCP abiertos, sobre los que ofrece servicio http y https.

Información sobre el Servidor Web

¿Cuál es nuestro segundo objetivo? Como dijimos inicialmente, familiarizarnos con toda la estructura del aplicativo web. ¿Por qué? Primero, porque en el sistema activo para la subred 192.168.200.0/24, no parecen existir otro tipo de servicios. Además de ello, debemos tener muy presente, que en la actualidad y de forma mayoritaria, la inseguridad se ha ido desplazando desde los servicios y elementos de red, a las aplicaciones web sobre el servicio http/https. Por tanto, a pesar de que pudieran existir otros servicios, sobre el aplicativo web, siempre que exista, incidiremos con especial detalle.

Una conexión directa haciendo uso de netcat, y una petición al servicio web nos muestra la siguiente información:

> nc 192.168.200.2 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 05 Jul 2007 19:20:20 GMT
Server: Apache/2.2.4 (Fedora)
X-Powered-By: PHP/5.1.6
Connection: close
Content-Type: text/html; charset=UTF-8

A todos los efectos, esto nos sirve para comprobar que se tratan de versiones actualizadas de Apache y de PHP y que por tanto, las vulnerabilidades existentes, como suele ser común, no residen en los servicios de red, sino que deberemos buscarlas dentro del aplicativo web.

Lo siguiente que debemos hacer es obtener información sobre el árbol web. Desde aquí recomendamos que el spidering ( nombre que comúnmente recibe esta técnica ) se realice sin usar aplicativos integrados en el navegador, pues algunos tienen la mala costumbre de interpretar código javascript pudiendo hacer que obviemos detalles importantes debido a la automatización del proceso. Wget o httrack son unas herramientas muy válidas para la tarea.

> wget -r http://www.blindware.inc
–19:28:15– http://www.blindware.inc/
=> `www.blindware.inc/index.html’
Resolving www.blindware.inc… 192.168.200.2
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/html]

[ <=> ] 24 –.–K/s

19:28:15 (1.02 MB/s) – `www.blindware.inc/index.html’ saved [24]

Loading robots.txt; please ignore errors.
–19:28:15– http://www.blindware.inc/robots.txt
=> `www.blindware.inc/robots.txt’
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 33 [text/plain]

100%[====================================>] 33 –.–K/s

19:28:15 (1.12 MB/s) – `www.blindware.inc/robots.txt’ saved [33/33]

–19:28:15– http://www.blindware.inc/load.js
=> `www.blindware.inc/load.js’
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 76 [application/x-javascript]

100%[====================================>] 76 –.–K/s

19:28:15 (2.30 MB/s) – `www.blindware.inc/load.js’ saved [76/76]

FINISHED –19:28:15–
Downloaded: 133 bytes in 3 files

Ese es el resultado inicial para http://www.blindware.inc. Si lo repetimos sobre http://intranet.blindware.inc no obtendremos nada porque nos pide autenticación, y por el momento la desconocemos. Por último, si lo llevamos a cabo sobre el servicio HTTPS, https://www.blindware.inc o https://intranet.blindware.inc obtenemos un index.html en blanco.

De esto concluimos que, al menos, se están sirviendo 3 escenarios diferentes. Uno por HTTP para www.blindware.inc, otro por HTTP para intranet.blindware.inc y por último, lo que parece uno común por HTTPS que sirve un index.html en blanco.

Vamos a verificar qué contienen los ficheros descargados:

> type index.html
script src=”load.js”>

> type load.js
// document.location.href=’data/0.html’
Document.location.href=’web/0.html’;

> type robots.txt
User-agent: *
Disallow: /data/

Como podemos comprobar desde el fichero index.html existe una llamada a un fichero con contenido javascript (load.js) el cual tiene como misión redirigir el tráfico hacia la web principal. Nos debemos percatar, que existe una línea comentada dentro de este fichero, la cual nos da información sobre una ruta diferente a la habitual data/0.html. Así mismo dentro del fichero robots.txt volvemos a encontrar una referencia a esta ruta. Si continuamos descargando contenidos desde web/0.html comprobamos que únicamente se descarga contenido estático en html.

Así que hasta el momento, y como conclusión, sabemos que existe una carpeta web/, la cual no parece contener nada reseñable, más que el contenido estático del site, y la carpeta data/, sobre la cual hablaremos más adelante.

Vulnerabilidades y Ficheros Sensibles

A continuación, debemos determinar ficheros, configuraciones, o posibles fallos conocidos en el servicio web. Para esta tarea existen numerosas aplicaciones, desde AppScan, a Nikto, o su port a Win32, Wikto. Nosotros vamos a utilizar este último, concretamente sus funciones destinadas a la exploración de contenido backend, cuya finalidad es extraer mediante una exploración por diccionario carpetas y ficheros ocultos, así como la propia utilidad Nikto, que nos escaneará la web buscando vulnerabilidades conocidas. Advertencia: El uso de herramientas automatizadas puede provocar falsos positivos, que debemos comprobar antes de emitir cualquier tipo de valoración.

Los resultados de la ejecución de Wikto son los siguientes:

BackEnd

#Directories
www.blindware.inc/
www.blindware.inc/cgi-bin/
www.blindware.inc/data/
www.blindware.inc/error/
www.blindware.inc/data/stats/
www.blindware.inc/error/include/
#Indexable
www.blindware.inc/data/
#Files
www.blindware.inc/index.php
www.blindware.inc/robots.txt

Nikto

/index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
/index.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
/index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
/WS_FTP.LOG

De esta información podemos obtener los siguientes datos relevantes:

• La existencia de un directorio /data/stats
• La existencia de un fichero WS_FTP.LOG
• La existencia de un fichero robots.txt
• Información sobre PHP

Un paseo por la aplicación visible, podemos hacerlo con Paros por ejemplo, nos desvela que, a priori, los que vemos es un contenido pre-generado de forma estática y cuya única entrada de datos se encuentra en el formulario contacto. Podemos analizarlo, pero no vamos a encontrar ningún comportamiento anómalo, ya que si nos damos cuenta el campo “action” de ese formulario va en blanco. Esto nos debe hacer pensar, que en caso de existir partes vulnerables, no se encuentran accesibles al público directamente.

Como información adicional decir que muchos gestores de contenido, entre ellos los más robustos, generan el contenido de forma estática desde un aplicativo en backend, haciendo que la parte visible de la aplicación carezca, casi por completo, de contenido dinámico, y de entradas por parte del usuario. Existirán por el contrario, otros aplicativos, como foros, buscadores, o secciones de prensa, cuyo contenido utilice generación dinámica. En estos casos, deberemos probar la inclusión sobre sus parámetros de código SQL, código HTML, código PHP, etc. buscando un comportamiento extraño.

Busqueda de un Punto de Intrusión

Para buscar un punto de intrusión, debemos recopilar lo que sabemos hasta el momento, ordenar las ideas y tomar una decisión, que vaya por delante, no tiene porqué ser la correcta. Dicho de otra forma, todo lo realizado hasta el momento nos lleva a suposiciones plausibles, pero nada nos garantiza que estemos en lo cierto. Vamos a ver lo que sabemos:

1. Existen 3 contenidos diferentes servidos por el servidor web
1. http://www.blindware.inc ( En adelante www )
2. http://intranet.blindware.inc ( En adelante intranet )
3. https://www.blindware.inc y https://intranet.blindware.inc ( En adelante https )
2. El contenido de https que podemos revisar con Wikto no parece contener nada.
3. Intranet nos pide autenticación para acceder.
4. En www conocemos que:
1. Tanto por la información pública existente, como por Wikto, existen sendos directorios de nombre data/ y data/stats/
2. Wikto nos revela la existencia del fichero WS_FTP.LOG

Antes de continuar debemos revisar el fichero WS_FTP.LOG:

2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/index.php
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd0.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd1.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd2.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd3.log

Con lo cual, parece que tenemos 2 opciones:

1. Atacar la autenticación de intranet
2. Intentar acceder en WWW a data/stats/ ( y a lo que parecen ser logs )

Aquí hay que decidir, en este caso, sobre intranet no sabemos absolutamente nada, mientras que sobre data/stats/ al menos sabemos que el día 8 de Mayo de 2007, contenía algún tipo de fichero de logs.

Evidentemente cada uno puede buscar lo que prefiera, y dónde prefiera, pero en este caso, los LOGS pueden resultar una información de vital interés pues pueden desvelarnos partes ocultas del aplicativo, y otras áreas de las que no tenemos conocimiento, así como usuarios con los que se accede a ellas ( si el acceso se hace autenticado mediante apache ) y otros muchos detalles.

Por el contrario, atacar directamente una autenticación de Apache, salvo que esté incorrectamente configurada, es algo bastante poco probable de llevar a buen fin, porque a priori, únicamente podremos atacar por fuerza bruta.

Con esto podemos concluir el primer nivel, habiendo visto las siguientes vulnerabilidades relativas a la “publicación de información sensible”:

• En los comentarios del fichero “load.js” se filtra información
• El fichero robots.txt mal facilita información relativa a áreas del aplicativo no públicas
• Existen el WS_FTP.LOG conteniendo información sensible
• El servidor Apache, está incorrectamente configurado, permite, mediante la opción INDEXES, la navegación por aquellos directorios que no contienen un fichero índice.

Así mismo tenemos un objetivo para iniciar nuestro ataque: el directorio data/stats/ terminando así el primer nivel de Sauron. Este primer nivel es igual para ambos niveles de complejidad.

Práctica 17 – Identificación del Sistema Operativo
Herramienta: NMAP /nmapFE- Descargar NMAP Windows – Descargar NMAP Linux
Prerequisitos: Ninguno
Contramedidas: Alteración de banners, Firewalls, Sistemas de detección de intrusos (IDS).
Descripción: La aplicación Nmap puede ser utilizada para identificar el posible S.O de la máquina objetivo. Un atacante puede utilizar esta información para llevar a cabo ataques más elaborados. A diferencia de la herramienta Xprobe2 analizada en la sesión de identificación de banners, nmap permite otra cantidad de opciones de encubrimiento de IP de la máquina atacante, que no son posibles realizar desde Xprobe2.
Procedimiento: Desde la shell de Linux (BackTrack) ejecutar la siguiente sintaxis:

nmap <opciones> (Dirección IP)

Para la práctica utilizaremos las siguientes opciones para identificar el Sistema Operativo de la máquina objetivo (192.168.146.131):

nmap -sS -p 139 -O -D 24.213.28.234 192.168.146.131

La opción -sS, dá la instrucción a nmap que utilize TCP sincronizado (SYN) encubierto o sigiloso, enviando un paquete SYN, sin luego enviar el paquete ACK, evitando de esta manera el establecimiento de conexión y por ende el registro en los logs.
La opción -p 139 ordena a nmap dirigir su actividad (escaneo) al puerto 139.
La opción -O ordena a nmap usar TCP/IP fingerprinting para identificar el S.O de la máquina objetivo.
La opción -D 24.213.28.234 ordena a nmap usar esta IP como metodo encubierto, es decir, que los sistemas de detección de intrusos o los mismos logs que puedan generar los intentos de identificación del S.O lanzado por nmap quedarán registrados con esta IP como dirección de inicio del “ataque”. Esta es una de las opciones más interesantes de nmap, pues permite a un atacante encubrir su verdadera identidad. Para hacer el trabajo más complicado para el administrador del sistema, el atacante puede utilizar varias IP falsas separadas por una coma (24.24.24.24, 24.24.24.25, 24.24.24.26, etc.)

El resultado de esta consulta nos arroja que el sistema operativo que gestiona la máquina objetivo es Microsoft Windows XP|2003|2000, con una alta probabilidad de que sea Microsoft Windows XP SP2, seguido de Windows 2003 Server, que en este caso es el S.O correcto.

Veamos a continuación una demostración del potencial de la herramienta nmap. Para la demostración utilizaremos un sniffer en la máquina objetivo, para determinar en este caso desde donde viene la consulta y a que puerto en especifico.

Claramente observamos que el origen de la consulta se hace desde la IP que utilizamos para encubrir nuestra verdadera identidad, además vemos el puerto en especifico al cual dirigimos la consulta.

Pasemos ahora a la utilización de la utilidad interactiva entre nmap y el usuario (Front-end) para linux, nmapfe.
Desde la shell de BackTrack ejecutamos el siguiente comando para ejecutar la herramienta:

nmapfe

Escribimos la dirección IP de la máquina objetivo, para este caso 192.168.146.131.

Cambiamos la opción de puertos a escanear que aparece por defecto a Range Given Below, y allí ingresamos el puerto 139.

Verificamos que la detección de Sistema Operativo este seleccionada.

Luego vamos a la pestaña de opciones y allí seleccionamos la opción Decoy (la cual nos permite encubrir nuestra IP real), y entramos una IP falsa. Para este caso 24.213.28.234.

Por último clic en Scan y esperamos los resultados.

Los resultados obtenidos son idénticos a los que arrojó el nmap sin utilizar el Front-end, Microsoft Windows.

Hagamos de nuevo la prueba del sniffer.

Perfectamente encubierta la dirección IP origen. (Cabe recordar que pueden ser utilizadas múltiples IP para encubrir, estas deben estar separadas por “,”. ej. 25.25.25.25, 25.25.25.26, 25.25.25.27, etc.

Hagamos uso ahora de la herramienta Nmap desde un entorno Windows.

Al igual que el uso desde la distribución BackTrack, la herramienta nmap puede ser utilizada con los mismo comandos.

nmap <opciones> (Dirección IP)

Pero para este laboratorio utilizaremos el Front-end disponible para Windows.

Después de descargar la herramienta procedemos a su instalación. (haré una simple secuencia de capturas sin muchos comentarios, pues es muy sencilla la instalación de la misma).

Ubicación del instalador.

Acuerdo de licencia. (GNU-GPL)

Componentes a instalar. (Dejamos la selección por defecto)

Ruta de instalación.

Instalación adicional del winpcap.

Creación de accesos directos.

Terminada la instalación procedemos a su ejecución y puesta en marcha.

Interfaz principal de la herramienta nmap.

Es esta pantalla la que nos ofrece todas las posibilidades de nmap.
La nueva versión de nmap nos permite dirigir escaneos pre-establecidos, es decir, simplemente seleccionando la opción perfil, obtendremos los comandos necesarios para dirigir un “ataque”. Para el caso seleccionaremos Quick Operating System detection, pero mejoraremos la línea de comandos pre-establecida, agregando la opción señuelo -D con la IP 69.69.69.69. Veamos:

Rápidamente nos arroja los resultados obtenidos, tanto puertos y servicios abiertos, MAC Address y el objetivo: Sistema Operativo, para este caso Windows 2003 Server.

Así mismo como en las prácticas anteriores hacemos la prueba de efectividad de encubierto de nmap. Activemos el sniffer.

Vemos que la IP de origen efectivamente es la que asignamos como señuelo (69.69.69.69)

__________________________________________________________

Práctica 18 – Enumeración IP/Hostname
Herramienta: Nslookup
Prerequisitos: Ninguno
Contramedidas: Firewalls, Sistemas de Detección de Intrusos (IDS).
Descripción: La herramienta nslookup permite realizar consultas al sistema de nombres de dominio (DNS), ofreciendo de esta manera el nombre de host para una ip determinada o Host determinado.
Procedimiento: Desde una shell de Windows o BackTrack, ejecutar la siguiente sintaxis:

nslookup (Nombre de host o dirección IP)

En el ejemplo hemos determinado el nombre del host para la IP 64.233.169.99, uno de los servidores de google.

Veamos ahora el caso inverso, donde conociendo el nombre del host haremos la respectiva consulta:

Para este caso www.microsoft.com

Hemos resuelto las direcciones IP 207.46.193.254 y 207.46.19.190 de microsoft corp.

__________________________________________________________

Práctica 19 – Localización / Identificación de registros
Herramienta: Visual Route
Prerequisitos: Ninguno
Contramedidas: Ocultar datos sensibles y/o personales en el momento de hacer registros de máquinas, dominios y/o servicios derivados.
Descripción: La aplicación Visual Route permite no solo hacer un trazado de ruta a la máquina Web objetivo, sino también ofrece un servidor geolocalizador de la misma. Además de Ping test, IP Trace, Localización de IP’s, DNS Lookup y más.
Procedimiento: Descargar la versión que más se ajuste a tus necesidades, tenemos dos opciones, una versión Lite con algunas limitaciones importantes para la información que pretendemos obtener y otra versión completamente operativa por un periodo de 15 días.

Haremo uso de las dos versiones (pero en las capturas haré uso de la instalación de la versión lite, aunque ambas son iguales en este proceso, y en la utilización haré además uso de la versión completa).

Entramos a la URL del producto y seleccionamos la versión a descargar.

Después de descargar vamos a la carpeta contenedora del archivo.

Procedemos en ese momento a la instalación. (los pasos son sencillos, por lo tanto haré una secuencia de capturas)

Terminada la instalación procedemos a iniciar el aplicativo. Podemos seleccionar el idioma de nuestra preferencia.

Ahora haremos algunas pruebas tomando como objetivo el sistema www.dragonjar.org

Vemos todos los saltos que realiza antes de llegar al objetivo final, además de observar la IP de los router donde hace los saltos, podemos con tan solo pararnos sobre los cuadros obtener otra información importante para la enumeración. Veamos.

Quiero además citar el pequeño reporte que genera la herramienta:

Este rastreo fue iniciado en 23/10-2007 06:15:17 PM. El sistema www.dragonjar.org (Conocido como apache2-heavy.elcamino.dreamhost.com) fue encontrado, fue alcanzado en 11 saltos.
En general esta ruta tiene buen rendimiento, con los saltos respondiendo en promedio dentro de 48ms

Otro ejemplo, en este caso hacia el sistema www.microsoft.com

Y el reporte generado:

Este rastreo fue iniciado en 23/10-2007 06:17:57 PM. El sistema www.microsoft.com no pudo ser alcanzado – no responde a paquetes diagnósticos de VisualRoute. No hay información disponible para determinar el salto que sigue salto 13 – esto normalmente indica un cortafuegos a tal punto.

Ahora veamos el aspecto visual que nos permite la versión completa (trial de 15 días) .

Y hacemos la misma consulta al sistema www.dragonjar.org

Veamos en el mapa los saltos que hace, desde mi ciudad/pais, hasta el sistema objetivo.

Próxima sesión: Técnicas y contramedidas – Enumeración del objetivo III