Introducción
Todos los días se puede ver gente en cualquier parte de Internet con la misma pregunta de siempre... ¿Como me inicio en el mundo del hack? ¿Como comienzo?, ¿Que debo leer? , antes que nada cabe aclarar de una vez que no soy hacker ni mucho menos, simplemente algo curioso. Y más de alguno ha leído que hay que bajarse un programa llamado 'scaneador de puertos' con el que te dice los "servicios", que está corriendo el host que nos interesa, así que lo primero que hacen es ir en busca de un programita de estos que nos de esa información tan valiosa...
Bueno, algo así le pasó a el amigo de un amigo, pero en la actualidad hay herramientas tan 'sofisticadas' ante esas 'amenazas', ya cualquier administrador decente cuenta en su red con un IDS, y si lo ponemos a punto, pues es una magnifica herramienta para detectar este tipo de ataques a nuestros servidores. Así que, el punto era que no debemos de usar los scaneadores de puertos?, no, solo explicaré un poco más a fondo algunos métodos de escaneo más discretos y que podamos pasar un poco más desapercibidos.
Dividiré el txt en dos secciones, en la primera mostraré algunos tipos de escaneos para ver si un puerto está abierto o no. La segunda parte tratará un par de opciones para saber si un host existe o no en internet pero esta vez solo con tcp y no ICMP como estamos acostumbrados.
Nota: supongo que para este punto tienes una leve idea de lo que es el tcp/ip, cierto?
Extracto de Flags en tcp/ip
Nota: este pequeño extracto salio del texto escrito por Guybrush para RazaMexicana.
<++>
- FLAGS : Hay seis banderas de 1 bit:
1. URG : Se establece en 1 si esta en uso el apuntador urgente. El apuntador urgente sirve para indicar un desplazamiento en bytes a partir del numero actual de secuencia en el que se encuentran datos urgentes. Este recurso sustituye los mensajes de interrupción.
2. ACK : Se establece en 1 para indicar que el numero de acuse de recibo es valido. Si el ACK es 0, el segmento no contiene un acuse de recibo, por lo que se ignora el campo de numero de acuse de recibo.
3. PSH : Indica datos empujados (con PUSH). Por este medio se solicita atentamente al receptor entregar los datos a la aplicación a su llegada y no ponerlos en el buffer hasta la recepción de un buffer completo.
4. RST : Se usa para restablecer una conexión que se ha confundido debido a una caída de host u otra razón; también sirve para rechazar un segmento no valido o un intento de abrir una conexión.
5. SYN : Se usa para restablecer conexiones. La solicitud de conexiones tiene SYN = 1 y ACK = 0 para indicar que el campo de acuse de recibo incorporado no esta en uso. La respuesta de conexión si lleva un reconocimiento, por lo que tiene SYN = 1 y ACK = 1.
6. FIN : Se usa para liberar una conexión; especifica que el transmisor
no tiene mas datos que transmitir. Sin embargo, tras cerrar una conexión,
un proceso puede continuar recibiendo datos indefinidamente.
<-->
Extracto de sendtcp.c, donde se pueden ver los valores de las flags
<++>
#define URG 0x20 // 100000
#define ACK 0x10 // 010000
#define PSH 0x08 // 001000
#define RST 0x04 // 000100
#define SYN 0x02 // 000010
#define FIN 0x01 // 000001
<-->
PRIMERA PARTE.
Sección TCP típica
Cuando queremos comenzar una conexión común y corriente de acuerdo al protocolo se usa de la siguiente manera:
• Nuestro host manda un paquete tcp, con los flags SYN en 1 (o prendido
como quieran llamarle), y el ACK en 0 y esperamos una respuesta.
• Si el puerto al que queremos alcanzar está en LISTEN (escucha)
el host puede aceptar o rechazar la conexión, aquí hay dos caminos:
a) Acepta: El host nos responde con un paquete con los flags SYN y ACK prendidos,
nosotros al final mandamos su ACK.
b) Niega: El host nos responde con un paquete con los flags RST y ACK prendidos.
Así que como podemos ver, se hace una conexión completa con este medio por lo que los IDS nos agarran al hacer demasiadas conexiones que duran tan poco tiempo, e intentar muchas otras.
Ahora ya sabes un poco como trabaja un scaneador de puertos tradicional si logra conectar con el puerto, nos lo informa. Pero esto hoy en día es logueado al 100% y no queremos embarrar nuestra IP en montones de archivos de logs, cierto?
Ahora pasaremos a ver otras técnicas de escaneo donde no precisamos comenzar una sección tcp tradicional para conocer el estado del puerto, en estos casos siguiente no se abre una conexión completa, por decirlo de alguna manera.
NOTA: Para los logs estaremos en una shell linux, usando hping, ya que este nos proporciona las estadísticas de envío, cosa que algunas herramientas bajo windows no dan, o al menos las que he probado.
Log
Probaremos toda la teoría que veamos en pequeños registros, a continuación el primero de ellos mostrando una sección tcp típica. No veo la necesidad de esconder las IP, ya que la mía es dinámica y es la primera vez que me saca de los rangos "comunes", así que no hay mucho problema.
CASO A: El puerto está abierto
[root@bsdmex crypkey]# hping -S -p 80 200.64.170.73
HPING 200.64.170.73 (ppp0 200.64.170.73): S set, 40 headers + 0 data bytes
len=44 ip=200.64.170.73 flags=SA DF seq=150 ttl=119 id=7017 win=8760 rtt=153.4
ms
len=44 ip=200.64.170.73 flags=SA DF seq=166 ttl=119 id=7025 win=8760 rtt=177.0
ms
len=44 ip=200.64.170.73 flags=SA DF seq=217 ttl=119 id=7026 win=8760 rtt=196.7
ms
len=44 ip=200.64.170.73 flags=SA DF seq=219 ttl=119 id=7030 win=8760 rtt=238.4
ms
Como podemos ver mi PC responde con las flags Syn y Ack prendidas (flags=SA) lo que nos indica el estado de disponibilidad de nuestro puerto.
CASO B: El puerto está cerrado
[root@bsdmex crypkey]# hping -S -p 80 200.64.170.73
HPING 200.64.170.73 (ppp0 200.64.170.73): S set, 40 headers + 0 data bytes
len=40 ip=200.64.170.73 flags=RA seq=125 ttl=119 id=7007 win=0 rtt=254.8 ms
len=40 ip=200.64.170.73 flags=RA seq=127 ttl=119 id=7009 win=0 rtt=254.8 ms
len=40 ip=200.64.170.73 flags=RA seq=130 ttl=119 id=7013 win=0 rtt=254.8 ms
len=40 ip=200.64.170.73 flags=RA seq=135 ttl=119 id=7015 win=0 rtt=254.8 ms
Esta vez mi PC responde con los flags Rst y Ack prendidos (flags=RA).
Ahora que ya tenemos bien fundamentada la teoría podemos pasar con más técnicas.
Nota: Gracias a crypkey por rolar shell para loguear este apartado.
DumbScan
Historia
Apareció por primera vez según tengo entendido en un post de BUGTRAQ el 18 de Diciembre de 1998. Se le llamó de este modo gracias a que es necesario contar con un host 'silencioso', al que embarraremos en los logs del host que queremos scanear (si es que alcanza a logear...). Su 'descubridor' por así decirlo fue 'antirez'.
Teoría
Primero que nada necesitamos contar con un host que prácticamente no tenga NADA de tráfico en internet, hay varios, he visto redes enteras llenas de instalaciones de IIS con las opciones por default, y sin pagina de index esos nos sirven muy bien para los términos que necesitamos. Pensaba escribir los rangos de Ip donde se pueden encontrar pero mejor no me meto en problemas, o a ti te gustaría que un grupo de gente sin vida social prácticamente tome tus servidores de juguete?, verdad que no?
Bueno, ahora si comencemos con la teoría:
Nombraremos a los host en este orden:
A> Será nuestra maquina
B> Será el host que queremos escanear
c> Será el host sin trafico, de aquí viene el nombre de 'dumb'
Nosotros comenzamos midiendo el trafico que genera el host C, con hping se puede (Originalmente era con la opción '-r', en la versión < 1, hoy en día están por sacar la versión 3...). Al parecer solo se cambio en hping1 ya que en el MAN de hping2 podemos ver de nuevo:
-r --rel
Display id increments instead of id. See the HPING2-HOWTO for more information.
Increments aren't computed as id[N]-id[N-1] but using packet loss compensation.
See relid.c for more information.
Ya que estamos seguros de que el host C no tiene tráfico (mirando en el campo 'id' generalmente se tendrá un 1). Ahora procedemos a enviar un paquete al host B con la dirección de origen spoofeada para que parezca que el host C la mandó).
Miramos de nuevo el estado del host C y...
Si los campos de 'id' siguen en el número constante del principio, el puerto en B está cerrado.
Si los campos de 'id' están alterados ligeramente, que el número constante de 'id' del principio, se haya alterado en algunas unidades, bueno, el chiste es que el puerto en B se encuentra abierto, ya que al recibir el SYN B para iniciar la conexión le manda un paquete a C con SYN|ACk prendidos, y como este no sabe que es lo que pasó cierra la conexión con un RST, de ahí que veamos que C está generando tráfico.
Nota de revisión, ahora que me fijo bien, esto se podría clasificar como scan Half Open :D, lo veremos más adelante.
NOTA: Recomiendo usar como host 'dumb' (C) una maquina con windows, porque? porque los números id, son más predecibles (estables) que una maquina con linux por ejemplo. Los números de secuenciación suman +1 cada vez.
Herramientas
- Windows
Puedes usar el VScan, usando el parámetro '-idle'
- Linux
Para linux recomiendo usar el Idlescan
Ejemplo
vscan -idle 1.2.3.1 1.2.3.4 -p 21 23 -zombie 11.11.11.11 1337
Aquí se escaneará:
• Desde la IP 1.2.3.1 hasta 1.2.3.4 (1.2.3.1, 1.2.3.2, 1.2.3.3, 1.2.3.4)
• Desde el puerto 21 (ftp) hasta el 23 (telnet) (21, 22, 23)
• Cabe destacar que el puerto en 11.11.11.11 (1337 te suena?), debe estar
abierto para hacer las comprobaciones necesarias.
Half Open
Este tipo de scan es también denominado SYN scan, y es muy parecido a la función CONNECT, solo que a último momento decidimos no hacer la conexión, que chingados es eso?, ahora lo explico...
Nuestro host manda un paquete tcp a el objetivo con la bandera SYN encendida...
a) Si el puerto está cerrado, el objetivo nos responde con un RST.
b) Si el puerto está abierto, el objetivo nos responde con un SYN|ACK e inmediatamente debemos responder con un RST, cerrando la conexión.
La ventaja principal de este tipo de escaneo es que se reduce potencialmente los riesgos de que puedas ser detectado, pero en fín, no es 100% seguro, ya que hay algunas herramientas que ya lo loguean como son:
• Synlogger
• Courtney
Pro's
Es un scaneo más rápido, evita algunas barreras y IDS
Contra's
Es necesario tanto en Linux como en windows tener máximos privilegios
para usar los raw sockets.
Log
Usaremos el tan afamado Nmap
[root@localhost root]# nmap -sS -p135 -P0 -vv 200.64.170.182
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host dup-200-64-170-182.prodigy.net.mx (200.64.170.182) appears to be up ...
good.
Initiating SYN Stealth Scan against dup-200-64-170-182.prodigy.net.mx
(200.64.170.182)
The SYN Stealth Scan took 36 seconds to scan 1 ports.
Interesting ports on dup-200-64-170-182.prodigy.net.mx (200.64.170.182):
Port State Service
135/tcp filtered loc-srv
Nmap run completed -- 1 IP address (1 host up) scanned in 37 seconds
NOTA: Cabe aclarar que 200.64.170.182 es una PC con w2k sp4, conexión a internet con dial up. (Si, es mía ;), este tipo de scan nos da el resultado más preciso del puerto, ya que, es cierto que tengo el puerto 135 filtrado por firewall.
NOTA2: Si tu PC es de uso personal te recomiendo que desactives los servicios de DCOM, ya que por ahí ya hay algunos xploits que te dan una shell inversa según vi.
Xmass tree
Este tipo de scan es de los más nuevos, quizá de los más extraños ya que se utiliza una combinación de flags que en condiciones normales no se usaría de acuerdo al protocolo RFC 793.
Se comienza mandando un paquete tcp con las banderas de FIN, URG y PSH y se logra saber el estado del puerto si:
a) Si el puerto está cerrado, el objetivo nos responde con un RST.
[root@localhost root]# ./hping 64.70.145.95 -FUP -c 4 -p 81
HPING 64.70.145.95 (eth0 64.70.145.95): 40 data bytes
60 bytes from 64.70.145.95: flags=RA seq=0 ttl=238 win=0 time=108.1 ms
60 bytes from 64.70.145.95: flags=RA seq=1 ttl=238 win=0 time=107.9 ms
--- 64.70.145.95 hping statistic ---
4 packets tramitted, 2 packets received, 50% packet loss
b) Si el puerto está abierto, el objetivo no regresa nada.
[root@localhost root]# ./hping 64.70.145.95 -FUP -c 4 -p 80
HPING 64.70.145.95 (eth0 64.70.145.95): 40 data bytes
--- 64.70.145.95 hping statistic ---
4 packets tramitted, 0 packets received, 100% packet loss
En nmap bastaría con correrlo así:
nmap -sX -p(rangode-puerto) IP
Esta técnica no funciona en los sistemas de Microsoft, CISCO, IRIX, HP/UX, y BSDI.
Null Scan
Este tipo de scan requiere que mandemos un paquete tcp sin ninguna flag en uso, por eso se le llama 'Null scan' ya que prácticamente mandamos un paquete vacío, cabe aclarar que en los sistemas Windows no funciona este tipo de procedimiento. Logramos saber el estado del puerto cuando:
a) Si el puerto está abierto, el objetivo no responde a el paquete.
[root@localhost root]# ./hping2 64.70.145.95 -c 4 -p 81
HPING 64.70.145.95 (eth0 64.70.145.95): 40 data bytes
60 bytes from 64.70.145.95: flags=RA seq=0 ttl=238 win=0 time=109.5 ms
--- 64.70.145.95 hping statistic ---
4 packets tramitted, 1 packets received, 75% packet loss
b) Si el puerto está cerrado, el objetivo nos responde con un RST.
[root@localhost root]# ./hping2 64.70.145.95 -c 4 -p 80
HPING 64.70.145.95 (eth0 64.70.145.95): 40 data bytes
--- 64.70.145.95 hping statistic ---
4 packets tramitted, 0 packets received, 100% packet loss
Esta técnica no funciona en los sistemas de Microsoft, CISCO, IRIX, HP/UX, ,BSDI y MVS.
NOTA: para usar esta técnica hay que modificar el hping.c...
if (tcp_th_flags == 0) /*tcp flags ain't set */
tcp_th_flags |= TH_FIN;
Si no le dimos ninguna flag en el parámetro, nos pone el FIN como default, así que solo comentemos la línea y ruleará su hping.
* En nmap basta con correrlo así:
nmap -sN -p(rangode-puerto) IP
FIN Scan
Este tipo de scan manda un paquete "vació" completamente a el host, como prueba. Esta técnica no funciona en los sistemas de Microsoft, CISCO, IRIX, HP/UX, y BSDI y MVS.
* En nmap basta con correrlo así:
nmap -sF -p(rangode-puerto) IP
SEGUNDA PARTE.
Aquí comienzan las opciones al ICMP común y corriente al que estamos acostumbrados, ya que muchos administradores están comenzando a filtrar estos paquetes reduciendo el trafico innecesario a sus redes, y evitando ciertos tipos de ataques con este protocolo.
Así que es hora de buscar opciones a nuestro clásico ping. Aunque siempre es más practico agotar su uso, y ya luego buscar otras opciones :p
ACK Scan
El ACK Scan, nos puede servir de dos cosas:
1) Comprobar la existencia de un firewall.
En el ACK Scan, mandamos un paquete con la bandera de ACK prendida, cuando el filtro (la ente que está capturando el tráfico), revisa que no hemos comenzado una sección típica de tcp (primero va el SYN recuérdalo...), entonces:
a) Si el servidor nos responde con un RST, el puerto se puede clasificar como
'no filtrado'.
b) Si el servidor no nos responde, podemos considerar el puerto como filtrado.
Es bueno utilizar esta técnica para saber si nuestro objetivo deja de ser el host corriente con el que estás acostumbrado a tratar, ya que este cuenta con un firewall en la mayoría de los casos, digo la mayoría ya que no solo los firewall hacen eso).
2) Comprobar la existencia del host en Internet.
Igual que en el anterior mandamos el paquete con la flag prendida, entonces:
a) Si se nos responde con un RST el servidor existe.
b) Si no se nos responde, o nos llega el mensaje de "host unreachable"
entonces el servidor no existe.
* En nmap basta con correrlo así:
nmap -PT IP
Inverse Scan
Esta técnica es parecida a la anterior, solo que en esta se utiliza la flag RST, y esperamos respuesta, en caso de:
a) No recibir nada, el host probablemente exista.
b) Recibimos el mensaje de "ICMP host unreachable", esto quiere decir
que el host no existe.
Lo especialmente bueno de esta técnica es que ninguno (de los IDS que yo he visto) loguean los paquetes RST con la configuración por default.
Despedida
Pues como podemos ver hay varias maneras de tratar de ocultar nuestros "actos" y supongo que no son las únicas técnicas que hay, solo es cuestión de conocer el protocolo y adaptarlo a nuestras necesidades.
Y podemos ver que al final con un simple escaneo, pues se nos pueden pasar por inadvertidos puertos "sensibles" de nuestra victima, así que, aquí tienen un poco más de información que pueden utilizar para que su exploración sea precisa y un poco más segura.
Gracias a todos aquellos que me rolaron una shell para guardar los logs, ya que los sockets que se necesitan para hacer este tipo de cosas (Raw Sockets) necesitan máximos privilegios, así que no mucha gente está dispuesta a darme root en su box así nomás: Toloache, Crypkey, ST38410A y Spiderlinux.
Alguna queja, sugerencia, etc, etc, etc, escribe a: hd@hakim.ws
Nos vemos.
Referencias, Links & Stuff
El acrónimo "IDS" viene del ingles Intrusion Detection Systems, traduzcámoslo como sistema de detección de intrusiones, sirve para informar y loguear cualquier actividad que se le proporcione en el respectivo archivo de configuración del programa.
Entiéndase por 'id', como el campo de ID de la IP en el output de hping.
- Intrusion Detection FAQ
Version 1.80 - Updated June 12, 2003
http://www.sans.org/resources/idfaq/
- Texto original acerca del "dumb scan"
http://www.kyuzz.org/antirez/papers/dumbscan.html
- "The hping Idle Host Scan"
Erik J. Kamerling
http://www.giac.org/practical/gsec/Erik_Kamerling_GSEC.pdf
- "Port Scanning without the SYN flag"
Uriel Maimon
Phrack #49 articulo 15
http://www.phrack.org/phrack/49/P49-15
- Idlescan-v0.1
Linux
http://www.securityfocus.com/tools/679
- Hping
Salvatore Sanfilippo <antirez@invece.org>
Linux
http://packetstormsecurity.nl/UNIX/scanners/hping.c
- Hping2
Salvatore Sanfilippo <antirez@invece.org>
Linux
http://www.hping.org
- Hping3
Salvatore Sanfilippo <antirez@invece.org>
Estado actual de desarrollo de Hping3, que prometen que sea una herramienta
un poco más superior a hping2, con una salida más 'leíble',
y al parecer se le van a poder agregar scripts, esas son algunas de sus características
finales.
http://www.kyuzz.org/antirez/hping3.html
- Nmap
Fyodor <fyodor@insecure.org>
Linux, Windows, FreeBSD, OpenBSD, Solaris, IRIX, Mac OS X, HP-UX, NetBSD, Sun
OS, Amiga.
http://www.insecure.org/nmap/
- Man del Nmap
http://www.insecure.org/nmap/data/nmap_manpage-es.html
- Una pequeña guía acerca del uso de Nmap
http://www.plazalinux.com/nmap-intro-guide.php
- VScan
viv3kr <viv3kr@yahoo.com>
Windows 2000 y Windows Xp
http://www.securityfocus.org/tools/3124
- Sendtcp.c
messer <mssr@gmx.net>
http://packetstorm.linuxsecurity.com/Win/sendtcp.c
- SynLog
Thamer AL-Herbish <shadows@whitefang.com>
http://www.cis.udel.edu/~zhi/www.docshow.net/warcher/synlog-0.4.tar.gz
- Courtney
University of California
Requiere Perl v.5, libpcap, y tcpdump.
ftp://coast.cs.purdue.edu/pub/tools/unix/logutils/courtney/