Nimrod’s Sons

Seguir el rastro a las organizaciones: parte 3
Por Darkslaker

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:

Puerto	Servicio
21/TCP	FTP
22/TCP	SSH
23/TCP	Telnet
25/TCP	SMTP
53/UDP	DNS Querys
53/TCP	DNS Zone Transfer
80/TCP	http
110/TCP	Pop
143/TCP	IMAP
443/TCP	https
500/TCP	IKE ( para VPN)
8080TCP	Proxy

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