Redes‎ > ‎Teoria e Introducción‎ > ‎

Vulnerabilidades en TCP


Es un nuevo DoS en la Pila de TCP ya confirmado por Cisco, que al parecer va a afectar a la mayoría de las implementaciones, Windows, Unix, IOS, ... etc.
Obviamente deben saber bien TCP/IP, por lo que leer los RFCs, les sera de gran ayuda.
El ataque usando la ventana es uno de los ataques en efecto, pero no es exactamente el mismo ataque que se encontro en el codigo de la implementacion de linux.

Para poder hacer pruebas se necesitaria iptables para evitar que tu computadora responda a los paquetes:
http://linux.die.net/man/8/iptables

Tambien algo como pcap para capturar los paquetes:
http://linux.die.net/man/3/pcap

Y para mandarlos raw:
http://linux.die.net/man/7/raw

Usando el truco de guardar el estado en el mismo mensaje de TCP, ya no necesitas guardar el estado en memoria, y recuerda que el objetivo es agotar los recursos del otro bando.. una ves que ya se tenga el primer ataque, el resto solo es cuestion de ver en que momento la implementacion usa la mayor cantidad de recursos, y despues mandar paquetes que creen ese estado.

El motivo por el cual se requiere una cantidad tan peque;a de paquetes por segundo en el atacante, es porque despues de cierto tiempo, todas las conexiones que iniciaste estaran consumiendo recursos en el servidor, y tu no estaras gastando nada

Tambien te recomiendo cheques lo que habla sobre como evitar que una conexion sea reseteada, las situaciones y los estados en los que el kernel estara esperando poder alocar memoria y el momento en el que se crean timers

Aunque estos ataques se estan haciendo contra linux, windows tambien es vulnerable a este mismo ataque.

Cada que una conexion nueva se hace, haces que el servidor reserve memoria para ti.
El problema en este caso es que puedes abrir muchas conexiones, haciendo que el servidor reserve recursos (en este caso timers) para transmitir cierta informacion, pero nunca la envia.
Este ataque necesita de muchas conexiones en ESTABLISHED, cosa que es facil detectable por muchos firewalls.

Son 5 ataques distintos.. a este creo le falta el detalle de decir que el servidor en realidad no gasta tanta memoria, el problema es que debe recordar que despues de X tiempo, debe mandarle al cliente la informacion otra ves, pero como despues de esa cantidad de tiempo, el cliente no habra recibido la informacion, el servidor la vuelve a enviar, etc..

No necesitas realmente miles de sockets abiertos, lo que necesitas es tras el mismo canal, seguir pidiendo que sigues esperando el paquete... es como.. pedir 0 litros de leche al lechero, y como nunca te llega nada, le sigues llamando, pidiendole que te los mande, al final, al lechero se le acaba el cuaderno donde apunta a quien le debe mandar leche.. y como ese cuaderno se usa para otras cosas en la empresa, pues llega un momento en el que ya nadie puede hacer nada.

En la prueba de concepto, esto no mostraba gran actividad en el CPU ni en memoria, las cosas simplemente empezaron a fallar (las ventanas no se drag/dropeaban, y al tratar de reiniciar X, nada paso) <-- linux

Los descubridores de esta falla (Robert Lee y Jack Louis de Outpost24) han publicado una breve presentación en PDF que explica un poco de las bases necesarias para llegar a descubrir a donde ellos llegaron, claro con muchos estudios y una gran comprehension del tema. he aquí el documento:
http://insecure.org/stf/tcpdos/outpost24-sect-sockstress.pdf

Los de outpost24 descubrieron el primer bug haciendo un PortScan, con BSD, ponle unos servicios y haz varios portscan a tu victima usando las conexiones stateless..
No vas a replicar el ataque, pero deberias de poder afectar al kernel lo suficiente (con 2 paquetes por puerto + 1 por puerto cerrado, solo eso ) si mandas paquetes a suficiente velocidad.. como para perder paquetes en una conexion previamente establecida.
No sera un problema permanente porque hasta donde recuerdo esto solo agota la capacidad de responder a peticiones (y solo durante el tiempo que dura tu portscan).


La explicación técnica está acá:

TCP Resource Exhaustion and Botched Disclosure
http://insecure.org/stf/tcp-dos-attack-explained.html

Aunque el tema ya es un poco pasado de tiempo está siendo tomnado con mayor interés al publicar una herramienta para Linux que aprobecha estas fallas y se llama "Complemento", una serie de softwares orientados a la auditoría de redes TCP:
http://complemento.sourceforge.net/
http://www.secuobs.com/news/18122008-letdown_complemento_dos_tcp_outpost.shtml



Referencias:

Más información en:  http://insecure.org/stf/tcp-dos-attack-explained.html
http://erratasec.blogspot.com/2008/10/tcp-dos-probably-real.html (Octubre 1)
http://joaotrindade.no-ip.org/?q=The+day+after+SockStress (Octubre 20)
La ultima noticia sobre esto marca a Cisco el día 17 donde publica un reporte de alerta de Seguridad Nivel 3 "Sockstress Exploit Tool Exposes Vulnerabilities in TCP Stack Implementations of Multiple Vendors"
También se puede ver que ya tiene su propio CVE: CVE-2008-4609
Funcionamiento de algunos de los ataques a TCP que Outpost24 encontro, pueden leer aqui:  http://www.darkreading.com/blog.asp?blog_sectionid=403&doc_id=164939&WT.svl=tease2_2
La entrevista que contiene algunos detalles importantes esta aqui:  http://debeveiligingsupdate.nl/audio/bevupd_0003.mp3
Para leer masomenos sobre como es la "vulnerabilidad" en la implementacion en linux del stack de TCP, pueden ver:  http://lion.cs.uiuc.edu/courses/cs498hou_spring05/lectures/lecture15.pdf
Métodos de DoS anteriores en Seguridad en TCP-IP

Ataques al RTO se han estudiado en el pasado (desde el 2003/2004).

Aqui hay un documento y una presentacion (ppt) que habla de ataques usando RTT y RTO (Low-Rate DoS Attacks)
http://www.cs.northwestern.edu/~akuzma/rice/doc/shrew.pdf
http://www.eng.tau.ac.il/~yash/infosec-seminar/Low_Rate_TCP_Yaniv.ppt (http://www.cs.northwestern.edu/~akuzma/rice/doc/shrew.ppt original)

Explicado mas "lentamente":
http://www.cs.unc.edu/~jeffay/courses/nidsS05/slides/5-Protocol-Attacks.pdf

Variacion mas potente del ataque (Shrew Attack at Saturation y Shrew Attack at Full Buffer) :
http://www.cs.bu.edu/fac/best/res/papers/icc06.pdf

Este el RFC2899 que denota el algoritmo que calcula el RTO
http://tools.ietf.org/html/rfc2988

Y un codigo de ejemplo que genera el trafico del DoS:
http://www.cs.northwestern.edu/~akuzma/rice/shrew/dos-public-ToN/linux/

Otro que compara FAST TCP con Reno en ataques de RTO..
http://ftp://ftp.computer.org/press/outgoing/proceedings/deeber/Silvia/ISDA-volume3/017_1385.pdf

Para lograr disminuir el RTT se usa optacking:
http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf

En el CCC (25c3) se hablo de estas vulnerabilidades:
Descripcion: http://events.ccc.de/congress/2008/Fahrplan/events/2909.en.html
Slides: http://www.recurity-labs.com/content/pub/25C3TCPVulnerabilities.pdf
Video: http://dewy.fem.tu-ilmenau.de/CCC/25C3/video_h264_720x576/25c3-2909-en-tcp_denial_of_service_vulnerabilities.mp4

Muy interesante por si quieren leerlo, y bueno,  les dejo el codigo de la implementacion de lo que dice Fyodor acerca de las stateless TCP sessions (de un blog chino: http://blog.csdn.net/rainman00001/archive/2008/11/08/3253962.aspx).
http://www.i.elhacker.net/sockstress.c
http://www.i.elhacker.net/sockstress.h

Sinembargo, el sistema operativo mas usado (windows >= xp sp1) tiene deshabilitada la capacidad de usar raw sockets que son necesarios para la mayoria de estos ataques, por lo que ataques de DDoS que usen estos ataques son poco probables (aunque posibles), por lo que lo que queda es hacer pruebas desde *nix

Implementacion del ataque de TCP window size = 0
http://www.phrack.org/issues.html?issue=66&id=9
Presentado en Phr4ck, configuracion por default para el comportamiento de Linux, BSD y Windows.






Comments