TOP
Autores
TOTAL
LecturasSET 31
94824 visitas
- Contenidos - SET Staff
- Editorial - Editor
- DOS GSM - FCA00000
- Bazar de SET - Varios Autores
- Historias de SET (bazar) - alicuenca
- Ciber Legislacion (bazar) - alicuenca
- Hotmail (bazar) - alicuenca
- Emulacion s45 - FCA00000
- Buffer Overflow - SeSoX
- Buscando Informacion - TheEnemi
- Programacion Orientada a Aspectos - Paler
- Java en Moviles - FCA00000
- Las apariencias enga~an - Qaldune
- Proyectos, peticiones, avisos - SET Staff
- Dispositivos Empotrados - SET Staff
- Ncurses - blackngel
- Building SSH - SeSoX
- Lista Negra - FCA00000
- Evadiendo el Fingerprinting Pasivo - ca0s
- SIM Emulacion - FCA00000
- Llaves PGP - SET Staff
Evadiendo el Fingerprinting Pasivo
7595
Autor: ca0s
-[ 0x0E ]--------------------------------------------------------------------
-[ Fingerprinting Pasivo ]---------------------------------------------------
-[ by ca0s ]---------------------------------------------------------SET-31--
##########################################
Evadiendo el Fingerprinting Pasivo
by ca0s
ca0s@getrewted.com.ar
http://www.getrewted.com.ar
##########################################
--[ Contenidos
1 - Introduccion
2 - Que es el Fingerprinting de Red ?
2.1 - Fingerprinting Activo
2.2 - Fingerprinting Pasivo
2.3 - Fingerprinting por Tiempo
3 - Razones para evadir el Fingeprinting Pasivo
3.1 - Tecnica Anti-Forense
3.2 - Privacidad y Estadistica
3.3 - Ataques automatizados
4 - Tecnicas de Fingerprinting Pasivo
4.1 - Flags y opciones mas comunes
4.2 - Herramientas usadas
5 - Evadiendo el Fingerprinting Pasivo
5.1 - Linux LKMs
5.2 - /proc filesystem
5.3 - POM & MANGLE
5.4 - Packet Purgatory
5.5 - Divert Sockets
5.6 - Netfilter QUEUE
6 - Algunas conclusiones
7 - Referencias
--[ 1 - Introduccion
Este articulo tiene como objetivo, explicar el funcionamiento de las tecnicas
de fingerprinting pasivo para un Sistema Operativo, plantear las razones por
las que querriamos realizar una evasion, y analizar las diferentes tecnologias
que podriamos usar para lograr la evasion.
Con cada tecnologia analizada, veremos hasta donde se puede llegar con ella, y
mostraremos algunos simples ejemplos de evasion. En un segundo articulo sobre
esta misma tematica, iremos mas a fondo con el camino elegido, y veremos
algunas tecnicas mas avanzadas de evasion.
La idea principal de este articulo, es introducirnos en el tema, para luego
seguir trabajando con las tecnicas de evasion.
Espero que disfruten de la lectura, y ya que hay altas probabilidades de que
encuentren errores, cualquier comentario sera mas que bienvenido ;)
--[ 2 - Que es el Fingerprinting de Red ?
La tecnica del "fingerprinting" de red se basa en encontrar diferencias en los
paquetes que un sistema envia o recibe, y a partir de comparar estas
diferencias realizar una identificacion. Podemos hacer diferentes aplicaciones
de esta tecnica, pero en general es usada para identificar servicios,
programas, o un Sistema Operativo.
Un ejemplo muy basico, y que todos conoceran, es diferenciar un Windows de un
Linux usando el comando PING:
foo# ping 192.168.1.10
64 bytes from 192.168.1.10: icmp_seq=1 ttl=128 time=5.46 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=128 time=5.27 ms
foo# ping 192.168.1.163
64 bytes from 192.168.1.163: icmp_seq=1 ttl=64 time=2.36 ms
64 bytes from 192.168.1.163: icmp_seq=2 ttl=64 time=2.34 ms
En el primer ejemplo, identificamos al sistema Windows porque la TTL es de 128,
y en el segundo ejemplo identificamos al Linux porque la TTL es de 64. Claro
que este metodo no es muy confiable, ya que tambien hay otros SOs que utilizan
esos mismos valores de TTL. Por esta razon, es que a mayor cantidad de
diferencias, mas precisa sera nuestra identificacion.
Las tecnicas mas conocidas de fingerprinting de un SO, son mediante el metodo
Activo, Pasivo y por Tiempo. A continuacion veremos un ejemplo, y una breve
explicacion de cada una de ellas.
2.1. Fingerprinting Activo
La forma Activa del fingerprinting, es la mas conocida y usada por todos.
Trabaja enviando paquetes especialmente modificados a un sistema, y escuchando
por su respuesta. Como cada SO posee su propia implementacion del TCP/IP stack,
podemos comparar las diferentes respuestas, y en base a las diferencias,
identificar el SO que posee.
Hay varias herramientas que podemos utilizar, pero compartiran conmigo que la
mas popular es Nmap [Ref. 1]. Veamos un ejemplo del fingerprinting que realiza:
foo# nmap -sS -T4 -O docsrv.caldera.com
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2005-01-29 21:21 UTC
Interesting ports on docsrv.caldera.com (216.250.128.247):
(The 1657 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
80/tcp open http
113/tcp closed auth
507/tcp open crs
Device type: general purpose
Running: NCR BSD-misc, SCO UnixWare
OS details: NCR S26 server (i386) running NCR MP-RAS SVR4 UNIX System,
SCO UnixWare 7.1.0 x86
Uptime 225.442 days (since Fri Jun 18 11:31:44 2004)
Una de las razones por la que la forma activa sea tan usada, se debe a que a la
hora de comprobar la seguridad de un sistema, muchas vulnerabilidades dependen
directamente de un SO en particular, por lo que hacer un reconocimiento de este
se vuelve fundamental.
2.2. Fingerprinting Pasivo
Esta otra variante de fingerprinting tambien puede ser usada para reconocer
un SO, pero la forma y el proposito para hacerlo es totalmente diferente.
Como su nombre lo indica, al contrario del fingerprinting Activo donde enviamos
pedidos a un equipo, en este metodo solamente vamos a escuchar las conexiones
generadas por otros sistemas, y en base a las diferentes opciones y flags que
cada conexion posee vamos a intentar identificar un SO.
Lo obvio, y fundamental de este metodo, es que al solo estar escuchando las
conexiones, nunca vamos a ser detectados. Al contrario del metodo Activo, que
suele ser muy ruidoso.
Tambien hay varias herramientas para hacer fingerprinting Pasivo, pero la mejor
de su clase es sin duda p0f [Ref. 2]. Veamos un ejemplo de p0f en accion:
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'any', 231 sigs (13 generic), rule: 'all'.
192.168.1.163:32768 - Linux 2.4/2.6 <= 2.6.7 (up: 0 hrs)
-> 65.108.147.27:80 (distance 0, link: ethernet/modem)
Hay muchos usos que le podemos dar a esta tecnica, como veremos mas adelante,
pero es muy interesante como se la ha comenzado a utilizar en soluciones de
IDS/IPS para reducir los falsos positivos.
Varios productos comerciales de Deteccion/Prevencion de Intrusos, entre ellos
el ISS RealSecure por ejemplo, realizan escaneos de vulnerabilidades en los
sistemas que protegen para luego correlacionar esta informacion contra los
ataques recibidos. De esta forma es posible verificar si un ataque puede ser
exitoso, ya que se cuenta con el patron de ataque que se ha recibido, y las
vulnerabilidades anteriormente conocidas en los servidores. La idea es buena,
pero agrega una gran latencia en la red debido a que constantemente hay que
escanear los servidores en busca de vulnerabilidades.
Aqui es donde entra esta tecnica para innovar, la empresa Sourcefire que
utiliza toda la tecnologia de Snort para sus soluciones de IDS/IPS, creo un
dispositivo que realiza Fingerprinting Pasivo para obtener informacion de
los sistemas y sus vulnerabilidades, y luego correlacionarla con los ataques
recibidos. Gracias a esto, no agrega ningun tipo de latencia a la red, ya que
todo lo obtiene escuchando pasivamente en un puerto de trunk del switch de
la LAN.
2.3. Fingerprinting por Tiempo
Esta tecnica es relativamente nueva, y se la describe como "Medio-Pasiva". Su
funcionamiento, se basa en analizar el tiempo de retransmision por timeout de
los paquetes en un handshake de TCP.
Dentro de las pocas herramientas que realizan este tipo de analisis,
encontramos a Snacktime [Ref. 11], un simple Perl script, pero que cumple su
proposito:
foo# iptables -A OUTPUT -p tcp --dport 80 --tcp-flags RST RST -j DROP
foo# iptables -A INPUT -p tcp --sport 80 --tcp-flags SYN SYN -j DROP
foo# perl snacktime.pl -t www.sun.com -p 80 -v -m
It's snacktime for 209.249.116.195 on port 80...
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238093.881357]
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238097.245171]
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238103.995990]
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238117.515720]
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238144.494415]
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238198.492660]
209.249.116.195 gave me a snack! Yum! [SYN-ACK Time: 1117238258.490415]
First snack at: 1117238093.881357
Retry 1 delta: 3.363814 secs 1117238097.245171
Retry 2 delta: 6.750819 secs 1117238103.99599
Retry 3 delta: 13.51973 secs 1117238117.51572
Retry 4 delta: 26.978695 secs 1117238144.494415
Retry 5 delta: 53.998245 secs 1117238198.49266
Retry 6 delta: 59.997755 secs 1117238258.490415
Alright guess: 209.249.116.195 is SunOS_5.5.1 (7)
Runner up (Lame guess): Generic_Perfect_RFC_2988_Stack (2)
Esta tecnica es muy interesante, pero dada la complejidad de la evasion, la
vamos a cubrir en el proximo articulo sobre tecnicas avanzadas, igualmente ya
tienen lo necesario si desean investigar por su cuenta.
--[ 3 - Razones para evadir el Fingeprinting Pasivo
Hay muchas razones por las cuales querriamos evadir un fingerprinting pasivo,
a continuacion veremos algunas de ellas, las que se me han ocurrido a mi, pero
todo depende de la imaginacion de cada uno de ustedes.
3.1. Tecnica anti-forense
Esta es la razon por la cual comenze a investigar sobre este tema, me atraia
lo interesante de las arquitecturas de honeypots, y me preguntaba como alguien
podria evadir uno de estos sistemas. Descubri que formas de detectar y hackear
honeypots hay muchas, daria para un articulo aparte, pero si todo el trafico
de red era capturado, nada impedia que un analista forense pueda descubrir
cuales fueron las acciones de un atacante y realizar un perfil de este.
The Honeynet Project [Ref. 3] es una de las organizaciones que mas ha
incursionado en el estudio de las herramientas, tacticas y motivos que posee
el atacante de un sistema. Para ello han creado lo que se conoce como una
Honeynet, que es una de las soluciones mas complejas y reales de honeypots.
Una Honeynet no puede ser emulada, todo debe ser real, y puede involucrar hasta
una red entera de honeypots. El desafio es grande, ya que un atacante debe
poder interactuar con todos estos sistemas, sin dudar en ningun momento del
lugar donde se encuentra. Al mismo tiempo debe ser una red controlada, para que
no se pueda atacar sistemas fuera de ella, y por supuesto, se pueda capturar
toda la informacion que paso por su interior.
A partir de toda esta compleja arquitectura, The Honeynet Project ha escrito
muchos documentos, y hasta un libro. Uno de sus whitepapers, que tiene el
nombre "Know Your Enemy: Passive Fingerprinting" [Ref. 4], esta dedicado
exclusivamente al analisis forense de red usando la tecnica del fingerprinting
pasivo. Aunque solo se enfoca en la deteccion del SO del atacante.
Podemos encontrar varias razones por las que un analista forense desee conocer
el SO que un atacante utilizaba, todo depende de las circunstancias, y de cada
caso en particular. Pero si al hecho de haber reconocido el SO, le sumamos otra
informacion que se haya podido conseguir, como las herramientas utilizadas, las
acciones que se realizaron, el objetivo que se perseguia, etc. se podria llegar
a sacar un perfil bastante aproximado de un atacante, que hasta podria ser
usado en una futura instancia judicial.
Muchos autores de virus, han logrado ser identificados tras encontrar patrones
en los archivos de una de sus creaciones, que permitian identificar que el
mismo codigo de programacion, o las mismas librerias, habian sido utilizadas
en otros virus.
En un analisis forense de red podria pasar algo similar, pero en vez de buscar
patrones en el archivo de un virus, lo estariamos buscando en el trafico de
red.
3.2. Privacidad y Estadistica
Con respecto a la privacidad, creo que no hace falta demasiada explicacion, y
ya se imaginaran hacia adonde apunto. No hace falta ser hacker ni abogado para
darse cuenta de los abusos que muchos gobiernos y empresas realizan en contra
del derecho a la privacidad que cada uno de nosotros posee. Con solo leer los
diarios de vez en cuando cualquiera se puede dar cuenta de ello.
La estadistica esta directamente relacionada a la privacidad, pero a veces no
nos damos cuenta de ello, y simplemente dejamos que las cosas pasen.
El ejemplo mas simple, lo encontramos cada vez que navegamos por alguna pagina
web, y al mismo tiempo estamos revelando informacion personal, como el SO que
usamos, en cada lugar que visitamos.
Para hacer una simple demostracion, vamos a entrar con diferentes browsers a
Google, y con Ngrep [Ref. 5] a capturar el paquete directamente de la red:
foo# ngrep
interface: eth1 (192.168.1.0/255.255.255.0)
* Usando "Links" desde Linux:
T 192.168.1.16:32797 -> 64.233.161.104:80 [AP]
GET / HTTP/1.1
User-Agent: Links (2.1pre11; Linux 2.4.22 i686; 100x37)
* Usando "Internet Explorer" desde Windows:
T 192.168.1.23:1787 -> 64.233.161.104:80 [AP]
GET / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
.NET CLR 1.1.4322)
* Usando "Firefox" desde Windows:
T 192.168.1.23:1782 -> 10.1.0.92:80 [AP]
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8)
* Usando "Firefox" desde Linux:
T 192.168.1.16:32792 -> 64.233.161.147:80 [AP]
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
* Usando "Lynx" desde Linux:
T 192.168.1.16:32794 -> 64.233.161.104:80 [AP]
GET / HTTP/1.0
User-Agent: Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7d
Como podran observar, excepto Lynx, el resto de los browsers que usamos revelan
cual es nuestro SO. Tal vez puedan considerar que esta no es una informacion lo
suficientemente importante, para tomarse la molestia de usar Proxys o cambiar
de browser. Pero este tipo de informacion, es muy valiosa para empresas que la
usan para crear perfiles de sus usuarios, con innumerables propositos, y aqui
la gran pregunta: Quien quiere ser una estadistica ?
3.1. Ataques automatizados
Para explicar este punto, les contare una historia, asi que les pedire que usen
un poco bastante su imaginacion, y supongamos esta hipotetica situacion:
Un "black hat" malvado, descubre una vulnerabilidad en un SO con un pobre
dise~o de seguridad, puede ser cualquier SO que conozcamos, pero utilizaba el
SP 3.
Tras este gran descubrimiento, nuestro black hat decide ir en busca de codigos
de homebanking, o numeros de tarjetas de credito que algun usuario despistado
guarde en su PC, o que puedan ser sustraidos utilizando un keylogger.
Sabe que su recien codeado exploit no fallara, pero si comienza a escanear
grandes redes en busca de PCs con un SO en particular, es probable que alguien
lo detecte y termine en la carcel. O peor aun, otro black hat, aun mas malvado
que el, descubra su 0 day, venda la vulnerabilidad a iDEFENSE, y el no solo
pierda su tiempo de investigacion y los creditos, si no tambien el dinero!
El problema era simple, si escaneaba grandes redes en busca de sus victimas,
seria descubierto, y no lograria su objetivo. Entonces, como no podia
buscarlos, deberia atraerlos.
Para ello monta un sitio web en un servidor que ya controlaba, sube las ultimas
fotos y videos de Jenna Jameson, y comienza a hacer propaganda de la mejor web
de contenidos XXX de Internet, en cuanto IRC, lista de correo y foro
encontraba.
Nuestro black hat sabia que su 0 day, al comenzar a atacar sistemas, tendria
una vida util muy corta. Por ello, es que la precision jugaba un papel
fundamental.
Si habia abandonado la idea de escanear grandes redes, tampoco se arriesgaria
a correr su exploit contra cuanta victima visitara su web XXX, y de la cual
desconocia si poseia el SO vulnerable.
Como ingenio le sobrava a nuestro black hat, decidio hacer un script
automatizado para que cuando una victima entrara a la web, primero detectaria
su SO haciendo un fingerprinting pasivo de la conexion que este habia iniciado,
y si poseia el SO vulnerable, recien alli el exploit se ejecutaria, y entonces
un backdoor seria instalado en la victima.
La historia termina aqui, el black hat utilizando una tecnica, que generalmente
es usada para otros propositos, gano tiempo, y consiguio una mayor cantidad de
victimas.
La moraleja es que si no quieres ser la victima, de un black hat malvado
jugando con su 0 day, debes poder evadir la deteccion de tu SO en un
fingerprinting pasivo.
Bueno, les adverti que debian usar su imaginacion ;)
--[ 4 - Tecnicas de Fingerprinting Pasivo
Ahora veremos como se realiza el Fingerprinting Pasivo de un SO, analizando
las conexiones TCP/IP. Los que ya posean buenos conocimientos de TCP/IP, pueden
saltar al punto 4.2, aunque nunca esta de mas refrescar algunos conceptos.
4.1. Flags y opciones mas comunes
En TCP/IP vamos a encontrar muchos flags y opciones de los protocolos que nos
van a permitir diferenciar un SO de otro, a continuacion veremos una breve
descripcion de los mas usados.
- TTL (Time To Live):
El proposito del campo TTL es prevenir que un datagrama termine en un loop
infinito. Esto puede suceder, cuando por ejemplo, un router crashea o la
conexion entre dos routers se pierde, entonces a los protocolos de ruteo les
puede tomar un tiempo detectar cual es la ruta perdida y buscar una nueva.
Durante este tiempo, puede pasar que el datagrama termine dando vueltas en
un loop de ruteo. El campo TTL entonces, pondra un limite a las vueltas que
el datagrama puede dar dentro de este loop.
Cada router que recibe un datagrama, debe decrementar el TTL en 1, o en la
cantidad de segundos que tardo en procesarlo. Como la mayoria de los routers
tarda menos de un segundo en hacerlo, el campo TTL termina siendo un muy
efectivo contador de saltos, que se decrementa de uno en uno por cada router
por el que pasa.
Un programa que basa su funcionamiento en el TTL, es el muy conocido
traceroute, el cual comienza enviando un datagrama con el TTL en 1, y lo va
incrementando hasta llegar a su destino. Como por cada router por donde pasa el
datagrama, el TTL se decrementa, cuando este llega a 0, el router devuelve un
mensaje ICMP de time exceeded in-transit, y de esta forma el traceroute se
entera por donde paso el datagrama. Para saber cuando el datagrama llega al
host destino, el traceroute espera a que este le envie un mensaje ICMP de
echo-reply, si uso el protocolo ICMP, o de port-unreachable, si utilizo el
protocolo UDP, ya que para UDP usa puertos muy altos que no suelen ser
utilizados.
Para dejarlo mas claro, como el TTL trabaja en el protocolo IP, podemos hacer
un traceroute utilizando diferentes tipos de protocolos. Las implementaciones
mas comunes del traceroute, utilizan UDP e ICMP, en Unix y compatibles, e ICMP,
en el tracert de Windows. Por ejemplo, otro protocolo con el que podriamos
hacer un traceroute seria con TCP.
Llendome un poco del tema, un traceroute con TCP es muy util, porque suele
pasar que un router o firewall filtre el trafico UDP hacia una red, y si el
admin medianamente sabe lo que hace, tambien va a filtrar ICMP, otra gran
fuente de fingerprinting [Ref. 6]. Pero por suerte, siempre vamos a encontrar
un servicio TCP escuchando al final del camino, como por ejemplo un servidor
web, razon por la que podriamos hacer un traceroute TCP al puerto 80 de este
servidor, y pasariamos sin ser filtrados.
Esta de mas decir que si hacemos un traceroute con TCP, en vez de esperar un
mensaje ICMP de port-unreachable, o echo-reply cuando el paquete llega al host
destino, lo que recibiriamos seria un SYN/ACK en respuesta a nuestro SYN.
Veamos un ejemplo del traceroute. Con UDP o ICMP(flag -I), vamos a recibir la
misma respuesta que aparece a continuacion:
foo# traceroute -n -I www.telefonica.es
traceroute to www.telefonica.es (194.224.55.24), 30 hops max, 38 byte packets
1 192.168.1.1 2.529 ms 2.458 ms 2.508 ms
2 x.x.x.x 18.660 ms 19.878 ms 19.525 ms
3 200.x.x.x 20.366 ms 19.569 ms 20.094 ms
4 200.x.x.x 19.759 ms 20.018 ms 20.804 ms
5 200.x.x.x 23.999 ms 22.366 ms 22.182 ms
6 200.3.49.121 23.871 ms 22.119 ms 22.466 ms
7 * * *
8 * * *
9 195.22.199.73 209.609 ms * 175.036 ms
10 195.22.216.169 184.849 ms 185.579 ms 186.585 ms
11 213.140.52.153 207.172 ms * 184.275 ms
12 213.140.37.189 290.499 ms 271.434 ms 270.237 ms
13 213.140.36.133 291.821 ms 313.774 ms 311.341 ms
14 213.140.50.126 291.692 ms 289.924 ms 311.334 ms
15 194.69.226.60 291.652 ms 328.648 ms 289.771 ms
16 193.152.56.22 286.145 ms 288.765 ms 310.180 ms
17 * * *
18 * * *
19 * * *
20 * * *
Como pueden ver, nunca llegamos a nuestro destino, saltos 17 en adelante,
porque seguramente hay un dispositivo filtrando UDP e ICMP delante del servidor
web, posiblemente un firewall. En los saltos 7 y 8 solamente John Chambers debe
saber lo que pasa...
Ahora veamos el mismo ejemplo, pero haremos el traceroute utilizando TCP hacia
el puerto 80 de www.telefonica.es, utilizando el famoso Hping [Ref. 7]:
foo# hping www.telefonica.es -n -S -p 80 -t 1 -z
HPING www.telefonica.es (eth0 194.224.55.24): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=192.168.1.1
2: TTL 0 during transit from ip=x.x.x.x
3: TTL 0 during transit from ip=200.x.x.x
4: TTL 0 during transit from ip=200.x.x.x
5: TTL 0 during transit from ip=200.x.x.x
6: TTL 0 during transit from ip=200.3.49.121
9: TTL 0 during transit from ip=195.22.199.73
10: TTL 0 during transit from ip=195.22.216.169
11: TTL 0 during transit from ip=213.140.52.153
12: TTL 0 during transit from ip=213.140.37.189
13: TTL 0 during transit from ip=213.140.36.133
14: TTL 0 during transit from ip=213.140.50.126
15: TTL 0 during transit from ip=194.69.226.60
16: TTL 0 during transit from ip=193.152.56.22
17: TTL 0 during transit from ip=194.224.52.16
18: len=46 ip=194.224.55.24 ttl=233 DF id=15879 sport=80 flags=SA seq=34
win=9112 rtt=312.7 ms
len=46 ip=194.224.55.24 ttl=233 DF id=15882 sport=80 flags=SA seq=37
win=9112 rtt=313.6 ms
len=46 ip=194.224.55.24 ttl=233 DF id=15883 sport=80 flags=SA seq=38
win=9112 rtt=291.5 ms
Como pueden ver, el dispositivo que nos estaba filtrando, y que logramos
descubrir, tiene la IP 194.224.52.16 en el salto 17. Luego, en el salto 18
ya recibimos la respuesta (SYN/ACK) de la web de www.telefonica.es.
Volviendo al uso del TTL en el fingerprinting, vimos al comienzo de este
articulo, un simple ejemplo en el que usando el comando PING podiamos
diferenciar entre un Linux y un Windows, porque los TTLs eran de 64 y 128 en
cada caso. Ahora vemos, que en la respuesta del comando HPING, el servidor web
responde con un TTL de 233. Los valores de inicio del TTL, en la mayoria de los
SOs, son en general de 30, 32, 60, 64, 128 y 255. Por lo que podemos presumir
que el TTL del servidor web es de 255, ya que si a los 233 de respuesta, le
sumamos los 18 saltos de distancia a los que me encuentro, mas algunos saltos
dentro de la red interna de telefonica.es, vamos a llegar a ese numero.
Como habiamos comentado, es muy burdo intentar identificar un SO unicamente por
el valor de su TTL, pero de querer hacerlo, podriamos consultar, entre otras
fuentes, por un whitepaper llamado "Default TTL Values in TCP/IP" [Ref. 8], en
donde vamos a encontrar que el TTL de 255 corresponde a Solaris. Buscando un
poco mas de informacion, podemos asociar este valor de TTL a las versiones de
Solaris entre la 2.5 y la 2.7.
Esta tecnica es la misma que utiliza la conocida web Netcraft [Ref. 9] para
identificar el SO de un website, solo que ademas, tambien toma los banners del
HTTP Server, entre otras cosas. Si consultamos en Netcraft por el SO de la web
de www.telefonica.es, vamos a comprobar que efectivamente es un Solaris.
- Window Size:
En una conexion entre un cliente y un servidor, el Window Size, es la cantidad
de datos que el cliente puede enviarle al servidor, antes de recibir un
reconocimiento indicando que ha recibido todo o parte de estos datos.
Para mantenerlo simple, si por ejemplo tenemos a dos hosts hablando sobre una
conexion TCP con un Window Size de 64KB, el cliente puede mandar solamente
64KB de datos, luego debe parar, y esperar a recibir un reconocimiento por
parte del servidor. Si el servidor reconoce que recibio todos los datos,
entonces el cliente puede volver a enviar 64KB. Si al contrario, el servidor
solo reconoce 32KB, porque supongamos que los otros 32KB se perdieron en el
camino, entonces el cliente debe volver a mandar solamente los ultimos 32KB
perdidos, porque no puede pasarse de los 64KB acordados al principio.
En el caso del fingerprinting, nuestra atencion estara puesta sobre el valor,
que diferentes SOs, le fijan al Window al iniciar una conexion, y luego como
esta va cambiando.
- DF (Don't Fragment):
Cuando la capa IP recibe un datagrama, primero verifica porque interfaz local
lo va a rutear, y luego obtiene el MTU que esta posee. El MTU es el "Maximun
Transfer Unit" que un tipo de red en particular tiene, en redes Ethernet por
ejemplo, el MTU es de 1500 bytes. Una vez que IP tiene el valor del MTU, lo
va a comparar con el tama~o del datagrama, y si es necesario, fragmentara el
datagrama.
Hay varios campos en el IP Header que entran en juego con la fragmentacion,
uno de ellos es el llamado "Don't Fragment". Cuando este campo esta activado,
el protocolo IP no fragmentara el datagrama. Una vez que el datagrama ha sido
enviado con el DF bit activado, si en algun punto es necesario fragmentar el
datagrama, este sera descartado, y un mensaje ICMP de error "fragmentation
needed but don't fragment bit set" sera enviado al origen de la conexion.
La mayoria de los SOs poseen el campo DF activado, por lo que no nos servira de
mucho para identificar un SO en particular, pero si nos permitira reconocer mas
facilmente, a aquellos SOs que no posean este campo activado por default, como
es el caso de SCO o OpenBSD.
- MSS (Maximum Segment Size):
El MSS es la cantidad maxima de datos que TCP puede enviar hacia el otro lado.
En el momento en que una conexion se establece, cada lado tiene la opcion de
anunciar el MSS que espera recibir. Si uno de los lados no recibe el MSS del
otro, se asume un valor de 536 bytes. Este valor permite que un IP Header de
20 bytes y un TCP Header de 20 bytes, entren en un datagrama IP de 576 bytes.
Por ejemplo, si tenemos un host conectado a una red Ethernet, el MSS que
enviara sera de 1460 bytes, ya que al MTU de 1500 bytes le restamos los 40
bytes del IP y TCP Header; y si del otro lado, tenemos un host conectado con
PPP o SLIP que poseen un MTU de 296 bytes, el MSS que enviara sera de 256
bytes. En esta conexion, el host conectado a la red Ethernet, por mas que haya
anunciado un MSS de 1460 bytes, jamas podra enviar un datagrama mayor a 256
bytes.
El fingerprinting con respecto al MSS, pasa por el valor que algunos SO's poseen
por default. La mayoria de los SO's usan un MSS de 1460 bytes, pero por ejemplo,
hay algunas implementaciones de BSD que pueden usar un MSS multiplo de 512 bytes,
o tambien Novell, que generalmente usa un MSS de 1368 bytes.
4.2. Herramientas usadas
Como ya lo hemos venido comentando a lo largo de este articulo, la herramienta
mas popular para realizar un Fingerprinting Pasivo de un SO es el p0f, por esta
razon, nuestro analisis pasara por conocer como trabaja esta herramienta, y en
la siguiente seccion, como podemos evadir la deteccion que realiza.
A partir de la version 2.0, el p0f ha incorporado nuevas tecnicas mas avanzadas
de deteccion, y se ha vuelto mucho mas preciso. Aun asi, esta lejos de ser tan
preciso como Nmap, debido a que solo puede escuchar las conexiones que un host
realiza, y no verificar como este responde a paquetes invalidos o modificados.
El p0f puede realizar la deteccion de un SO utilizando tres modos diferentes:
- Conexiones entrantes, este es el modo por default, y se basa en escuchar los
paquetes SYN del inicio de una conexion.
- Conexiones salientes, escucha los paquetes SYN+ACK, que son las respuestas a
los paquetes SYN.
- Conexiones salientes rechazadas, escucha los paquetes RST+ que pueden ser la
respuesta, por ejemplo, a un SYN dirigido a un puerto que estaba cerrado.
El principal desarrollo del p0f se encuentra en el primer modo, con los
paquetes SYN, ya que estos son los mas ricos en flags y opciones, mientras que
los otros modos, estan enfocados a casos mas particulares y son menos exactos,
por ello es que no tienen tanta investigacion y mantenimiento de firmas.
Nosotros vamos a trabajar solamente con el primer modo.
Dentro del archivo de SYN fingerprints del p0f, las firmas tienen este formato:
wwww:ttt:D:ss:OOO...:QQ:OS:Details
donde cada campo, de principio a fin, significa lo siguiente:
wwww - window size
ttt - TTL inicial
D - don't fragment bit
ss - tama~o del paquete SYN
OOO - orden y valores de opciones
QQ - flags extra~os que pueden aparecer
OS - sistema operativo
details - detalles del sistema operativo
Para comprender mejor como el p0f realiza la deteccion usando las firmas, vamos
a analizar un ejemplo practico con la ayuda del famoso Tcpdump [Ref. 10].
En este ejemplo, nosotros realizamos una conexion hacia la web de
198.81.129.100, por lo que el p0f va analizar que SO posee nuestro host basado
en el paquete SYN que nosotros enviamos para iniciar la conexion. Si
quisieramos saber el SO de los hosts que se conectan a nuestro web server
local, este ejemplo seria igual de valido.
Tras haber accedido el sitio web, veamos que ha detectado el p0f:
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
192.168.1.133:32784 - Linux 2.4/2.6 <= 2.6.7 (up: 2 hrs)
-> 198.81.129.100:80 (distance 0, link: ethernet/modem)
Como vemos, escuchando el paquete SYN, el p0f ha detectado que nuestro SO es un
"Linux 2.4/2.6 <= 2.6.7", es una identificacion bastante amplia, pero
comprobemos si es cierta:
foo# uname -a
Linux foo 2.4.22 #6 Tue Sep 2 17:43:01 PDT 2003 i686 unknown unknown GNU/Linux
Efectivamente, nuestro SO se encuentra dentro del amplio rango que detecto el
p0f. Ahora veamos como llego a esta conclusion analizando la firma utilizada,
en conjunto con el paquete SYN capturado por tcpdump:
S4:64:1:60:M*,S,T,N,W0:.:Linux:2.4/2.6 <= 2.6.7
foo# tcpdump -n -vvv
21:21:49.068588 IP (tos 0x0, ttl 64, id 52779, offset 0, flags [DF],
length: 60) 192.168.1.133.32784 > 198.81.129.100.80: S 2948542712:2948542712(0)
win 5840 <mss 1460,sackOK,timestamp 917203[|tcp]>
Cada campo de la firma esta separado por un ":", asi que vamos a comenzar de
principio a fin.
S4 (window size):
Esto significa que el valor del window size es un multiplo de 4 del valor del
MSS. Como vemos, el MSS es de 1460, y si lo multiplicamos por 4 nos va a dar
5840 que es el valor con el que aparece el window size.
64 (TTL):
Ninguna explicacion, la TTL aparece en el paquete con un valor de 64.
1 (don't fragment bit):
El DF puede ser 0 o 1, como en este caso esta activado el valor es de 1. En la
salida de tcpdump vemos que aparece "[DF]", esto significa que esta activado,
si no lo estuviera no apareceria.
60 (tama~o del paquete SYN):
Tama~o total del paquete en bytes, en tcpdump lo vemos como "length: 60".
M*,S,T,N,W0 (orden y valores de opciones):
Este campo posee diferentes valores de las opciones del paquete, separados por
una coma o un espacio, en el orden en que aparecen en el paquete.
La "M*" corresponde al MSS y generalmente aparece con una wildcard, la "S"
significa que el flag del Selective ACK permitted esta activado y en el
tcpdump aparece como "sackOK", la "T" se refiere al timestamp que en el caso
que fuera 0 apareceria como T0, la "N" corresponde a la NOP option, y la "W0"
se refiere al Window Scaling que permite escalar el window size.
. (flags extra~os que pueden aparecer):
Cuando aparece un punto es porque no hay ninguno de estos flags, que en
general aparecen en implementaciones que poseen el TCP/IP stack con bugs.
Linux:2.4/2.6 <= 2.6.7 (sistema operativo):
Esta es la descripcion del sistema operativo que corresponde a la firma antes
analizada.
En conclusion, en nuestro ejemplo, el p0f escucho el primer paquete SYN
enviado, parseo cada uno de sus flags y opciones, y los comparo con su archivo
de firmas para identificar nuestro SO. Si desean conocer mas profundamente como
trabajo el p0f, la documentacion que posee es muy buena, y leer el codigo
fuente tambien ayuda.
--[ 5 - Evadiendo el Fingerprinting Pasivo
Como ya comente anteriormente, cuando comenze a investigar todo esto encontre
que hay mucha informacion sobre las tecnicas del fingerprinting, pero muy poca
o nula sobre las tecnicas para evadirlas. La mayoria eran solo comentarios de
que tal vez se podria hacer de una forma, o de que tal vez se podria hacer de
otra, pero absolutamente nada en concreto.
A causa de esto, el primer objetivo que me propuse, seria definir las
diferentes tecnologias que podrian ser usadas para la evasion, y elegir entre
ellas la mas apropiada para seguir trabajando.
Con todas las tecnologias que vamos a ver a continuacion, se podria realizar
una evasion del fingerprinting, pero no a todas las investigue a fondo,
directamente le dedique mas esfuerzo a las que parecian mas viables.
Para que tengan el concepto, nuestro problema, es como hacer para modificar los
paquetes que salen de nuestro SO, y que esto sea totalmente transparente para
nosotros.
5.1. Linux LKMs
Para el problema que tenemos que resolver, una de las primeras cosas en la que
vamos a pensar, es en escribir un modulo de Kernel (LKM) que haga la tarea. Es
probable que el resultado final seria positivo, pero hay muchas cosas a evaluar
antes de seguir por este camino.
Con un LKM, lo primero que me viene en mente es usar los hooks de Netfilter
para realizar nuestra tarea, y calculo que con eso alcanzaria, pero en el caso
de tener la necesidad de modificar el TCP/IP stack, ya tendriamos problemas,
porque estariamos modificando el Kernel mismo, y ya no seria un LKM, si no un
patch del Kernel, con todos los problemas que ello trae.
Otra cosa que debemos tener en cuenta, es que un LKM no es facil de
desarrollar, y que estariamos perdiendo la posibilidad de trabajar con los
paquetes en user space, lo que es fundamental para la dificil tarea que
tenemos.
5.2. /proc filesystem
El /proc es un sistema de archivos virtual con una directa representacion del
sistema en memoria. Por esta razon, puede ser utilizado como un centro de
control e informacion del Kernel. Por ejemplo, usar el comando "lsmod" seria lo
mismo que hacer "cat /proc/modules".
Lo que vamos a intentar ahora, es ver hasta donde podemos llegar utilizando el
/proc para modificar parametros del Kernel relacionados al TCP/IP stack.
El parametro mas conocido por todos, es el que nos permite modificar la TTL:
echo 'numero' > /proc/sys/net/ipv4/ip_default_ttl
Como ya comentamos antes, Linux posee una TTL de 64. Ahora vamos a cambiar este
valor, y vamos a ver como se comporta el p0f antes y despues del cambio:
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
192.168.1.13:32769 - Linux 2.4/2.6 <= 2.6.7 (up: 0 hrs)
-> 65.108.147.27:80 (distance 0, link: ethernet/modem)
foo# echo 128 > /proc/sys/net/ipv4/ip_default_ttl
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
192.168.1.13:32772 - UNKNOWN [S4:128:1:60:M1460,S,T,N,W0:.:?:?] (up: 0 hrs)
-> 65.108.147.27:80 (link: ethernet/modem)
Como veran, luego de hacer un cambio en la TTL, el p0f ya no puede identificar
al SO y lo muestra como "UNKNOWN", porque los flags del paquete dejaron de ser
exactamente iguales a los que tiene en su firma.
Obviamente, esto es facilmente identificable por un analista forense, por ello
nuestro objetivo siempre sera modificar todos los valores posibles que nos
permitan evadir el fingerprinting, y que por supuesto, nos aseguren un correcto
funcionamiento de nuestro trafico de red.
Otros parametros que podemos modificar para dificultar aun mas la deteccion por
un analista, son algunos flags de las IP options, que van a convertir a
nuestros paquetes mucho mas genericos. Lo que vamos a hacer, es desactivarlos,
y veremos como reacciona el p0f y que nos muestra el tcpdump, antes y despues
de los cambios:
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
192.168.1.13:32773 - Linux 2.4/2.6 <= 2.6.7 (up: 1 hrs)
-> 65.108.147.27:80 (distance 0, link: ethernet/modem)
foo# tcpdump -n -vvv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
20:28:42.497538 IP (tos 0x0, ttl 64, id 13698, offset 0, flags [DF],
length: 60) 192.168.1.13.32773 > 65.108.147.27.80: S 1186188016:1186188016(0)
win 5840 <mss 1460,sackOK,timestamp 524146[|tcp]>
foo# echo 128 > /proc/sys/net/ipv4/ip_default_ttl
foo# sysctl -w net.ipv4.tcp_window_scaling=0
net.ipv4.tcp_window_scaling = 0
foo# sysctl -w net.ipv4.tcp_sack=0
net.ipv4.tcp_sack = 0
foo# sysctl -w net.ipv4.tcp_timestamps=0
net.ipv4.tcp_timestamps = 0
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
192.168.1.13:32776 - UNKNOWN [S4:128:1:44:M1460:.:?:?]
-> 65.108.147.27:80 (link: ethernet/modem)
foo# tcpdump -n -vvv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
20:31:29.953475 IP (tos 0x0, ttl 128, id 4444, offset 0, flags [DF],
length: 44) 192.168.1.13.32776 > 65.108.147.27.80: S [tcp sum ok]
1351504256:1351504256(0) win 5840 <mss 1460>
Pueden ver que es una modificacion interesante, pasamos de la firma estandar
que el p0f tienen para nuestro SO:
S4:64:1:60:M*,S,T,N,W0:.:Linux:2.4/2.6 <= 2.6.7
a lo que detecto en la red, que es bastante diferente:
UNKNOWN [S4:128:1:44:M1460:.:?:?]
En este punto, la evasion ya la hicimos, y estariamos comenzando a confundir a
un analista forense analizando nuestro trafico de red.
Si quieren investigar un poco mas, pueden ver:
/usr/src/linux/Documentation/networking/ip-sysctls.txt
5.3. POM & MANGLE
Netfilter/Iptables posee un sistema llamado Patch-O-Matic "POM" que permite
aplicar patches a las ultimas versiones del Kernel o de Iptables.
Dentro de estos patches, muchos programadores han agregado nuevas features que
podrian servir para nuestro proposito, ya que nos darian la posibilidad de
modificar ciertas opciones o flags de un paquete, que de otra forma no
podriamos hacerlo.
Usando el POM, podriamos lograr algunos de nuestros objetivos, pero tiene
varios problemas que no la hacen una solucion escalable. Por ejemplo, hay que
recompilar el Kernel para instalarlo, muchos de estos patchs tienen bugs, y
recuerden que los estamos aplicando en el Kernel, y ha dejado de ser
oficialmente mantenido por Netfilter.
Tambien podriamos hacer algunas modificaciones con el target MANGLE en
Iptables, pero tampoco son demasiadas las cosas que podemos modificar, como
para intentar usar este metodo para nuestra solucion.
Igualmente, si quieren jugar con todo esto, no deja de ser interesante.
5.4. Packet Purgatory
Packet Purgatory [Ref. 17] es una libreria que permite capturar paquetes de la
red y pasarlos a "user space" para modificarlos. Trabaja usando una interfaz
virtual, cambiando el ruteo hacia esta interfaz, y seleccionando el trafico a
capturar con reglas de firewall. Esta libreria esta basada en libpcap y libdnet
para comunicarse con el Kernel.
Los creadores de Packet Purgatory, tambien han desarrollado un programa llamado
Morph [Ref. 17], que tiene como objetivo evadir el fingerprinting de un SO y
que sea portable a diferentes plataformas. Hasta ahora, Morph solo puede evadir
el fingerprinting Activo de un SO, y se planea en un futuro que tambien pueda
evadir el fingerprinting Pasivo.
Morph aun se encuentra en desarrollo, y no es estable, para utilizarlo en el
fingerprinting Activo, por lo que se puede pensar que van a tardar bastante en
lograr que pueda evadir el metodo Pasivo.
Morph y Packet Purgatory, pueden ser una gran alternativa, para en el futuro,
lograr la evasion del fingerprinting Activo y Pasivo de un SO. Pero
actualmente, aun se encuentran en desarrollo, no poseen mucha documentacion, es
de dificil implementacion, y no sabemos si los desarrolladores van a seguir
trabajando en ella. Sera cuestion de esperar y ver que pasa.
5.5. Divert Sockets
Los Divert Sockets trabajan de una forma similiar a la que vamos a ver con el
Netfilter QUEUE. Mediante una regla de firewall, vamos a elegir un tipo de
trafico, y lo vamos a pasar directamente a "user space", una vez alli, podemos
modificarlo y enviarlo nuevamente al Kernel.
Para trabajar con esta tecnologia, tenemos que aplicar unos patches al Kernel y
al Ipchains. Hay un documento llamado Divert Sockets mini-HOWTO [Ref. 16] que
explica mas detalladamente este proceso, y muestra algunos ejemplos.
Sin duda, este tipo de tecnologia es a la que tenemos que apuntar para lograr
nuestro proposito, pero dado que Netfilter QUEUE trabaja de una forma similar,
pero mucho mejor, no vamos a profundizar con los Divert Sockets.
5.6. Netfilter QUEUE
Netfilter provee un mecanismo llamado "queue", que permite enviar un paquete
recibido por el stack hacia "user space", para luego devolverlo al Kernel pero
con un veredicto indicando si se lo acepta o se lo descarta. Cuando el paquete
esta en user space, tambien podemos modificarlo antes de enviarlo al Kernel.
Para trabajar con el QUEUE de Netfilter, vamos a usar Libipq, una libreria en
desarrollo, que nos brindara una API para poder comunicarnos con el QUEUE.
Un popular programa que utiliza el QUEUE de Netfilter, es Snort Inline
[Ref. 12], una version modificada de Snort [Ref. 13], pero trabajando en modo
"Prevention".
La forma en que trabaja Snort es la misma, solo que captura los paquetes con
libipq en vez de hacerlo con libpcap [Ref. 10]. Esto le agrega la posibilidad
de poder decidir que el paquete sea dropeado, rechazado, modificado o con
permiso de pasar, osea, convierte el IDS en un IPS.
Nosotros vamos a usar el QUEUE, para modificar nuestros paquetes salientes, y
de esta forma, intentar evadir la deteccion del SO que usamos.
El primer paso, es cargar los modulos necesarios para que el QUEUE funcione:
foo# modprobe iptable_filter
foo# modprobe ip_queue
Una vez hecho esto, le decimos a Iptables que paquetes queremos enviar a user
space, marcandolos con el target QUEUE:
foo# iptables -A OUTPUT -p tcp -j QUEUE
En este ejemplo, estamos indicando que todas las conexiones TCP salientes sean
enviadas al QUEUE, pero tambien podriamos especificar otros protocolos, o un
puerto en particular.
Al tener la posibilidad de pasar los paquetes a "user space", podemos modificar
estos con cualquier lenguaje de programacion. Con libipq tendriamos que hacerlo
en C, pero tambien existen ports de libipq para Python y Perl.
Para los ejemplos de este articulo, decidi usar la API de Perl, llamada Perlipq
[Ref. 14], simplemente porque nos permitira usar algunos modulos de Perl para
trabajar con paquetes en modo raw, de una manera mucho mas sencilla que con C.
A continuacion voy a copiar el script de Perl que usaremos de ejemplo, es muy
sencillo asi que con solo leer el codigo pueden darse una idea de como trabaja:
------------ comienzo ------------
use IPTables::IPv4::IPQueue qw(:constants);
use NetPacket::IP qw(:ALL);
use NetPacket::TCP qw(:ALL);
use constant TIMEOUT => 1_000_000 * 2;
my $queue = new IPTables::IPv4::IPQueue(copy_mode => IPQ_COPY_PACKET, \
copy_range => 2048) or die IPTables::IPv4::IPQueue->errstr;
while (1)
{
my $msg = $queue->get_message(TIMEOUT);
if (!defined $msg)
{
next if IPTables::IPv4::IPQueue->errstr eq 'Timeout';
die IPTables::IPv4::IPQueue->errstr;
}
my $ip = NetPacket::IP->decode($msg->payload());
my $tcp = NetPacket::TCP->decode($ip->{data});
########
## Aqui podemos modificar IP "$ip" o TCP "$tcp", antes de volver a enviarlo
## al Kernel
########
$ip->{data} = $tcp->encode($ip);
my $raw = $ip->encode;
$queue->set_verdict($msg->packet_id(), NF_ACCEPT, length($raw), $raw);
}
------------ final ------------
Para modificar los paquetes, estamos usando el modulo NetPacket [Ref. 14], que
nos permitira trabajar con el raw packet sin importarle de donde venga.
Ahora veremos unos simples ejemplos para demostrar las posibilidades de lo que
podemos hacer. Vamos a comenzar modificando la TTL. Para ello podemos acceder
al hash "$ip" haciendo referencia a la ttl, y seteando el valor que queremos:
$ip->{ttl} = "128";
Para comprobar si el cambio, efectivamene fue realizado, vamos a dejar
corriendo nuestro script mientras accedemos a una pagina web, y veremos con
Tcpdump si la TTL ha cambiado:
foo# ./kung-foo.pl
foo# tcpdump
09:58:32.629630 IP (tos 0x0, ttl 128, id 46507, offset 0, flags [DF],
length: 60) 192.168.1.163.34452 > 64.233.161.147.80: S [tcp sum ok]
1830653540:1830653540(0) win 5840 <mss 1460,sackOK,timestamp 6733459 0,
nop,wscale 0>
Como pueden ver en el paquete SYN de esta conexion, hemos podido modificar la
TTL default de Linux de 64 a 128.
Ahora vamos a ver otro ejemplo, en el que vamos a cambiar el valor del window
size en el header TCP. El valor por default en el Kernel que estamos usando es
de 5840. Para cambiarlo vamos a acceder al hash "$tcp" haciendo referencia al
winsize:
$tcp->{winsize} = "65535";
foo# ./kung-foo.pl
foo# tcpdump
10:10:29.769704 IP (tos 0x0, ttl 64, id 46522, offset 0, flags DF, length: 60)
192.168.1.163.34457 > 64.233.161.147.80: S [tcp sum ok] 2572699372:2572699372(0)
win 65535 <mss 1460,sackOK,timestamp 6805173 0,nop,wscale 0>
Podran observar, que efectivamente el window size ha sido modificado al valor
de 65535. Pero veamos tambien como afecto este cambio al p0f:
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
192.168.1.163:34457 - UNKNOWN [65535:64:0:60:M1460,S,T,N,W0:.:?:?] (up: 18 hrs)
-> 64.233.161.147:80 (link: ethernet/modem)
Nuevamente, haciendo un simple cambio al window size, el p0f ya no puede
detectar nuestro SO. Aprovechando esto, hay otros cosas que podemos hacer para
jugar con la deteccion del p0f. Primero hagamos una deteccion sin modificar
nada para poder comparar luego:
foo# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf@dione.cc>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'eth0', 231 sigs (13 generic), rule: 'all'.
192.168.1.163:34453 - Linux 2.4/2.6 <= 2.6.7 (up: 18 hrs)
-> 64.233.161.104:80 (distance 0, link: ethernet/modem)
Ahora modificaremos el window size a diferentes valores, y observaremos como se
comporta el p0f ante esto:
$tcp->{winsize} = "2920";
192.168.1.163:34454 - Linux 2.4 (big boy) (up: 18 hrs)
-> 64.233.161.104:80 (distance 0, link: ethernet/modem)
$tcp->{winsize} = "4380";
192.168.1.163:34455 - Linux 2.4.18 and newer (up: 18 hrs)
-> 64.233.161.147:80 (distance 0, link: ethernet/modem)
$tcp->{winsize} = "29200";
192.168.1.163:34458 - Linux 2.2.20 and newer (up: 19 hrs)
-> 64.233.161.147:80 (distance 0, link: ethernet/modem)
Compartiran que es interesante, cambiando unicamente el valor del window size
podemos hacernos pasar por diferentes Kernels de Linux. El valor de los window
sizes elegidos no son arbitrarios y tienen una logica, como lo explicamos en
el punto 4.2. Analizemos estas firmas del p0f:
S4:64:1:60:M*,S,T,N,W0:.:Linux:2.4/2.6 <= 2.6.7
S2:64:1:60:M*,S,T,N,W0:.:Linux:2.4 (big boy)
S3:64:1:60:M*,S,T,N,W0:.:Linux:2.4.18 and newer
S20:64:1:60:M*,S,T,N,W0:.:Linux:2.2.20 and newer
La primera firma, es la de nuestro Kernel, y las otras son las que emulamos,
como veran lo unico que cambia es el primer campo, el valor del window size, y
como ya habiamos explicado, el numero despues de la "S" significa que el tama~o
del window size es un multiplo "X" del MSS. Por ejemplo, para la ultima firma
multiplicamos 1460 por 20, y el resultado, 29200, fue el valor que le dimos
al window size modificado.
A esta altura se daran cuenta que si encontramos firmas parecidas, no es muy
dificil cambiar algunos valores para hacerse pasar por otro SO. El problema
aparece cuando hay que cambiar muchos valores, en donde ya tenemos que tener
en cuenta otras cosas, como calcular nuevamente el checksum del paquete si
agregamos o quitamos flags y opciones.
Uno de los grandes problemas de trabajar con la tecnologia del QUEUE, es la
falta de documentacion, que es practicamente nula. Si bien las posibilidades
son enormes, tener que redescubrir todo a cada paso significa el doble de
esfuerzo, y tiempo invertido, para llegar a nuestro objetivo.
En el proximo articulo de tecnicas avanzadas de evasion, seguiremos trabajando
con el QUEUE, y veremos ejemplos mucho mas complejos que los mostrados aqui, en
el mientras tanto, tienen lo suficiente para investigar por su cuenta ;)
--[ 6 - Algunas conclusiones
Como hemos visto a lo largo de este articulo, realizar una evasion de la
deteccion de nuestro SO, no es algo simple. Existen herramientas que podriamos
usar para conseguirlo, pero aun falta mucho desarrollo e investigacion.
Creo que esta claro, que de la tecnologias analizadas la que parece mas viable
es la del Netfilter QUEUE, por lo que seguramente seguiremos trabajando con
ella en el segundo articulo sobre esta tematica.
De los simples ejemplos de evasion que vimos, tenemos que tener en cuenta que
una cosa es burlar al p0f, y otra muy diferente, hacer lo mismo con un analista
forense de red. Tengan cuidado!
Como comente en la Introduccion de este articulo, es probable que tal vez hayan
encontrado errores, les agradecere que me los informen, y tambien me gustaria
aclarar que hay muchisimas cosas que no fueron cubiertas, el fingerprinting es
un tema muy extenso, y es imposible tratarlo en un unico articulo.
Todo lo que hemos visto, por lo menos a mi me resulta interesante, si alguno de
ustedes tambien comparte estos intereses, no duden en contactarme para poder
trabajar en equipo. Dos mentes piensan mejor que una, tres mejor que dos...
Hasta la proxima! y saludos a Turandot.
ca0s .-
--[ 7 - Referencias
IMPORTANTE: si bien no lo he mencionado como referencia en ninguna parte de
este articulo, esta por de mas entendido, que la principal refencia que pueden
usar es el libro "TCP/IP Illustrated" de Richard Stevens.
[Ref. 1] Nmap
http://www.insecure.org/nmap/
[Ref. 2] p0f
http://lcamtuf.coredump.cx/p0f/
[Ref. 3] The Honeynet Project
http://project.honeynet.org/
[Ref. 4] Know Your Enemy: Passive Fingerprinting
http://project.honeynet.org/papers/finger/
[Ref. 5] Ngrep
http://ngrep.sourceforge.net/
[Ref. 6]
http://www.sys-security.com/archive/articles/
[Ref. 7] Hping
http://www.hping.org/
[Ref. 8] Research Paper on Default TTL values
http://secfr.org/docs/fingerprint/en/ttl_default.html
[Ref. 9] Netcraft
http://www.netcraft.com/
[Ref. 10] Tcpdump / Libpcap
http://www.tcpdump.org/
[Ref. 11] Snacktime
http://www.planb-security.net/wp/snacktime.html
[Ref. 12] Snort Inline
http://snort-inline.sourceforge.net/
[Ref. 13] Snort
http://www.snort.org/
[Ref. 14] Perlipq
http://search.cpan.org/~jmorris/perlipq-1.25/
[Ref. 15] NetPacket
http://search.cpan.org/~atrak/NetPacket-0.04/
[Ref. 16] Divert Sockets mini-HOWTO
http://www.faqs.org/docs/Linux-mini/Divert-Sockets-mini-HOWTO.html
[Ref. 17] Packet Purgatory - Morph
http://www.synacklabs.net/
*EOF*