21 enero 2009

Vuelve el SMURF (antiguo y mítico DoS)

Hace no demasiado, se popularizó un tipo de ataque devastador llamado Smurf que tuvo en jaque a ISPs enteros. En una época en la que las IRC-Wars estaban en pleno auge, este tipo de ataque era la forma mas efectiva de poner fuera de juego cualquier sistema.

El ataque se fundamentaba en las facilidades que da tanto ICMP como UDP para 'spoofear' tráfico. Lo único que había que hacer era bombardear direcciones de broadcast con la dirección IP que se pretendía dejar offline (provocando un efecto bola-de-nieve).

Si tu lista de direcciones broadcast era lo suficientemente amplia, el sistema atacado no lardaba ni 30 minutos en pedir árnica.

Paulatinamente el aumento de la seguridad en ISPs y organizaciones hizo ese ataque inviable ya que se aplicaron los filtros correctos hasta hacer practicamente imposible encontrar direcciones broadcast que se presten a ese tipo de usos.

Ahora en 2009 parece que el concepto resurge con otra forma de ataque que ha sido detectada por la gente del ISC-Sans.

Mucho se habló el año pasado sobre las debilidades del protocolo DNS motivado por el uso de UDP y la facilidad para falsear tráfico inherente a ello (nosotros propusimos una solución).

En este caso se ha detectado un uso bastante intensivo de una oscura forma de hacer peticiones DNS que genera un volumen relativamente alto de tráfico. Por lo visto, lanzando una petición a un DNS preguntando por '.' el servidor DNS devuelve la lista de root nameservers.
$ host -t ns .
. name server F.ROOT-SERVERS.NET.
. name server G.ROOT-SERVERS.NET.
. name server H.ROOT-SERVERS.NET.
. name server I.ROOT-SERVERS.NET.
. name server J.ROOT-SERVERS.NET.
. name server K.ROOT-SERVERS.NET.
. name server L.ROOT-SERVERS.NET.
. name server M.ROOT-SERVERS.NET.
. name server A.ROOT-SERVERS.NET.
. name server B.ROOT-SERVERS.NET.
. name server C.ROOT-SERVERS.NET.
. name server D.ROOT-SERVERS.NET.
. name server E.ROOT-SERVERS.NET.
El ataque consiste en falsear la dirección IP en las consultas DNS para que el servidor responda la petición al host que se pretende atacar. Como el volumen de la respuesta tiene una equivalencia superior a 1=1 (por cada petición que se lance, el servidor devuelve mucho más tráfico) se consigue el efecto de amplificación necesario para realizar el ataque.

Habrá que estar atento

8 comments :

Anónimo dijo...

Pero lo bueno del asunto es... como
se falsea el paquete para decirle que viene de otra ip?

Yago Jesus dijo...

No se si te refieres a la parte de que tu ISP te deje 'spofear' tráfico o a la parte meramente técnica. Sobre el ISP, imagino que googleando encontraras cuales son mas 'amistosos' para ello. Sobre la parte técnica, hay muchos recursos para trabajar con Raw Sockets. Scapy para Python http://www.secdev.org/projects/scapy/ libnet para C http://www.packetfactory.net/libnet/ o Net::RawIP para Perl http://search.cpan.org/dist/Net-RawIP/

vierito5 dijo...

hping también es una herramienta interesante

Anónimo dijo...

Hola,
es decir lo que hacemos es cambiar la ip del que hace el envío (víctima) recalcular el offset o crc del paquete y a enviarlo no¿?

Yago Jesus dijo...

Aquí http://securityvulns.ru/files/birthday.pl hay un ejemplo muy aprovechable para construir paquetes DNS usando Raw Sockets

Jose Selvi dijo...

El Smurf y el Fraggle, que recuerdos... xD La verdad es que siempre pensé que las personas que ponen nombre a los ataques son un poco "cachondos" ;)

Los ataques de Amplificación DNS efectivamente son peligrosos.

Otro método para explotarlo: un atacante puede configurarse su DNS para que determinado nombre de su dominio devuelva un registro muy largo y luego buscar servidores DNS que permitan búsquedas recursivas (muchísimos lo hacen, y en muchos casos es sencillamente necesario) y le hacen una query para que guarden ese registro en su caché.

A partir de ahí, con la legión de DNSs "complices", envían querys DNS Spoofeadas preguntando por este registro, lo cual se traduce que por cada paquete que envien van a llegar hasta 4000 bytes al equipo destino, amplificando una barbaridad la cantidad de bytes que se le podrían enviar directamenet, y probablemente produciendose una denegación de servicio.

No sé que factor de ampliación se conseguirá con el que comentais, pero desde luego me parece más peligroso, el Incident Handler ni siquiera tendría el nombre del dominio para empezar a buscar sin tener que depender totalmente del ISP (que en muchos casos no les viene demasiado bien que meta mano en su red un "externo")

Al final... yo creo que son los ISPs los que deberían dar solución a este tipo de ataques DoS, por ejemplo poniendo algún tipo de detector de DoS UDP y que si empieza a detectar una ráfaga de reply's del protocolo que sea, entrando en su red o proveniente de un zona de su red a otra, sin que existan los respectivos query's, debería filtrarlo automáticamente, y así evitaría muchos disgustos.

Yago Jesus dijo...

Tienes mucha razon Jose. Tengo pendiente escribir sobre sistemas anti-DoS basados en correlación, a ver si saco tiempo y me das tu opinión.

Jose Selvi dijo...

Estoy impaciente por verlo :)