Tema destacado: Últimos eventos sobre seguridad/inseguridad
 Autor
|
Tema: Ataques a la implementacion de TCP _ Outpost24 (Leído 2,382 veces)
|
sirdarckcat
Troll Buena Onda y
CoAdmin
 Desconectado
Mensajes: 6.947
Lavando Platos
|
Bueno, platicando con Anon, quede en un trato  Se permitira tratar de este tema en el foro de bugs y exploits.. solo aqui, y solo lo estrictamente relacionado con el tema. Por motivos mas de suerte que de merito, he llegado a tener conocimiento del funcionamiento de algunos de los ataques a TCP que Outpost24 encontro.. pero no los explicare yo. Pueden leer mas aqui: http://www.darkreading.com/blog.asp?blog_sectionid=403&doc_id=164939&WT.svl=tease2_2Se dara este hilo como investigacion moderada, es decir, comentarios que no aporten realmente algo de suma importancia, seran borrados.. esto significa que aunque tu post sea util, si no es muy relevante, se borrara.. les suplico no me odien. En fin.. los detalles de los ataques no los revelare, solo tratare de decirles que X cosa no es util ok? La entrevista que contiene algunos detalles importantes esta aqui: http://debeveiligingsupdate.nl/audio/bevupd_0003.mp3Para 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.pdfObviamente deben saber bien TCP/IP, por lo que leer los RFCs, les sera de gran ayuda. En fin.. suerte! PD. Esto significa que si el contenido tiene errores, no aporta nada nuevo (tiene que ser nuevo! no vale leerlo en otro lado y copiarlo).. se pide reflexion y analisis. Se ponen estas limitaciones porque el tema de denegacion de servicio esta mal visto en este foro, por lo que se tratara de mostrar si se puede tener una discusion al respecto meramente academica. |
|
|
|
« Última modificación: 25 Octubre 2008, 07:06 por sirdarckcat »
|
En línea
|
|
|
|
AlbertoBSD
Estudiante y
Colaborador
Desconectado
Mensajes: 1.955
Anonymous & Paranoid
|
Bien, he estado leyendo sobre el tema, sinceramente les comento que no tengo mucho de haberme enterado de este 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. Viendo que hay muchos enlaces sin referenciar, hay que agregar el enlace con la información mas Ordenada que es el de fyodor: http://insecure.org/stf/tcp-dos-attack-explained.html Ahora 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 Bien, pero lo anterior son noticias que ya estaban publicadas y solo se agregan como referencia de lecturas. Ok, el principal punto de partida es la SockStress que usa Cisco, para dar credibilidad a las múltiples Vulnerabilidades en la Pila TCP, bien como menciono sdc se ocupa tener conocimiento de la Pila TCP, los cuales son aportados por sus respectivos RFC’s, Ahora si las vulnerabilidades existen, que ya cisco ha comprobado que si, estas están ahí, en la mayoría de los sistemas Operativos, esto desde hace mucho tiempo. Buscando en referencias libres (No propietarias) he estado analizado en el código fuente de linux dentro de los archivos tcp.c entre otros, prestando especial atención a los comentarios, he notado algunos comentarios, como que hay que tener cuidado con el tamaño del Window, y otras cosas mas. La verdad no he dado con nada En especifico, pero se que debe de estar ahí, listo para ser encontrado. Espero que alguien que conozca mas sobre la Pila de TCP nos de una idea mas clara de que estamos buscando y en donde. Saludos y gracias de antemano por cualquier aporte útil |
|
|
|
« Última modificación: 25 Octubre 2008, 09:30 por Anon »
|
En línea
|
|
|
|
sirdarckcat
Troll Buena Onda y
CoAdmin
Desconectado
Mensajes: 6.947
Lavando Platos
|
Solo un dato. 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. Estuve viendo el codigo de tcp.c y parece ser que no esta ahi, ya intentaste buscando en los headers del kernel? http://google.com/codesearch?hl=en&q=show:JEzAT53q5_I:3HCYIejbVm0&ct=rdl&cs_p=http://kernel.org/pub/linux/kernel/v2.4/linux-2.4.34.1.tar.bz2&cs_f=linux-2.4.34.1/include/netY bueno, tcp.c no es el unico archivo que se encarga de tcp: http://google.com/codesearch?hl=en&q=show:KZ9Soue5FXU:XVhSDH-WFlE&ct=rdl&cs_p=http://kernel.org/pub/linux/kernel/v2.4/linux-2.4.34.1.tar.bz2&cs_f=linux-2.4.34.1/net/ipv4Mientras tanto, para poder hacer pruebas pues.. se necesitaria iptables para evitar que tu computadora responda a los paquetes: http://linux.die.net/man/8/iptablesTambien algo como pcap para capturar los paquetes: http://linux.die.net/man/3/pcapY para mandarlos raw: http://linux.die.net/man/7/rawUsando 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 (los timers tambien son evil jaja). Saludos!! PD. Vale mencionar que aunque estos ataques se estan haciendo contra linux, windows tambien es vulnerable a este mismo ataque. |
|
|
|
« Última modificación: 25 Octubre 2008, 19:24 por sirdarckcat »
|
En línea
|
|
|
|
sirdarckcat
Troll Buena Onda y
CoAdmin
Desconectado
Mensajes: 6.947
Lavando Platos
|
Acabo de ver que uno de los ataques es publico: 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) Parecen diferentes, pero son lo mismo. --edit-- Explico rapido. 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. Desafortunadamente este ataque necesita de muchas conexiones en ESTABLISHED, cosa que es facil detectable por muchos firewalls =P 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.. jajaja, 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. Saludos!! --edit2-- Cabe mencionar, que 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 |
|
|
|
« Última modificación: 25 Octubre 2008, 22:09 por sirdarckcat »
|
En línea
|
|
|
|
AlbertoBSD
Estudiante y
Colaborador
Desconectado
Mensajes: 1.955
Anonymous & Paranoid
|
Bueno ya en estos momentos, después de a ver dormido poco tiempo  y de unas cuantas porciones de Taurina y Cafeína  ya saben a que me refiero, lamentablemente sigo casi donde empecé, después de haberlo meditado, se que conseguir algo funcional es posible, tomara tiempo lo se pero tarde o temprano se podrá llegar a algo. He estado haciendo algunas pruebas desde una maquina con FreeBSD instalado, de Firewall uso el PF (PacketFilter) y realizo las pruebas usando C con Libnet y Libpcap, tomando como base algunos de los ejemplos que vienen en la Documentasen de libnet, sin embargo hasta el momento todo ha sido infructuoso. I've been seeing ones and zeros, ups no, he estado leyendo varios documentos para darme una idea mas generalizada de donde están las fallas en la Pila TCP, He estado leyendo sobre los métodos de DoS anteriores en Seguridad en TCP-IP para darme una idea de donde ya no es casi probable que estén los errores. El método descrito anteriormente, sobre modificar el windowing para poder mantener la conecion Activa por mucho tiempo, tiene lógica, sin embargo falta algo para hacerlo funcionar. Ya no he buscado mas en los comentarios de la Implementación de TCP de linux, sin embargo si he estado leyendo partes interesantes en los RFC. Cabe mencionar que 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.pdfSi bien, parece que no vamos a ningún lado, se necesitan nuevas ideas, comentarios y aportaciones para poder llegar a algo. Un saludos a todos. |
|
|
|
|
En línea
|
|
|
|
sirdarckcat
Troll Buena Onda y
CoAdmin
Desconectado
Mensajes: 6.947
Lavando Platos
|
En esos slides no hablan de los ataques, solo te da una introduccion a ataques viejos, pero te dicen como hacer las conexiones TCP stateless Ahora ve tu ventaja, puedes tener muchisimas conexiones con el servidor.. Los de outpost24 descubrieron el primer bug haciendo un PortScan.. desafortunadamente tienes BSD, y no se como lo tengas montado, pero 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 =D ) 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). Saludos!! |
|
|
|
« Última modificación: 26 Octubre 2008, 06:02 por sirdarckcat »
|
En línea
|
|
|
|
WHK
吴阿卡
Ex-Staff
Desconectado
Mensajes: 4.113
The Hacktivism is not a crime
|
Así es, tal como lo explica el título de este tema Fidor (el lider del proyecto Nmap) ha encontrado algunas fallas en este protocolo tan masivamente utilizado tanto para servidores como para computadores personales. La explicación técnica está acá: TCP Resource Exhaustion and Botched Disclosurehttp://insecure.org/stf/tcp-dos-attack-explained.htmlAunque 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/Esta noticia me llegó por correo desde la siguiente fuente: http://www.secuobs.com/news/18122008-letdown_complemento_dos_tcp_outpost.shtmlPueden usar el traductor de gogole si no entienden algo. |
|
|
|
|
En línea
|
|
|
|
AlbertoBSD
Estudiante y
Colaborador
Desconectado
Mensajes: 1.955
Anonymous & Paranoid
|
Bueno, lo interesante de esto seria analizar como llegar a ello, la verdad ya habiamos hablado un poco de ello hace unos meses, sin embargo por falta de tiempo, ya he incurrido en ello.
Saludos.
|
|
|
|
|
En línea
|
|
|
|
Ivanchuk
Desconectado
Mensajes: 466
LLVM
|
Mire este hilo y me colgué de vuelta con los programitas tcp/ip  .. tengo que estudiar!!!, pero bueno siempre hay un huequito de tiempo para probar estas cosas . Estuve viendo el link que puso sdc, a saber, http://erratasec.blogspot.com/2008/10/tcp-dos-probably-real.htmlSi lo que encontraron estos flacos va por ese lado, puede estar relacionado con el calculo del RTO y las funciones para calcularlo (RTT -> SRTT), aclaro que todavia no estoy ducho en las funciones que se usan pero investigare al respecto. O sea el tiempo que espera el server para enviar la retransmision del paquete. Mirando el source code de linux encontre esto en linux/net/ipv4/tcp_input.c tcp_init_metrics(), * A bit of theory. RTT is time passed after "normal" sized packet
* is sent until it is ACKed. In normal circumstances sending small
* packets force peer to delay ACKs and calculation is correct too.
* The algorithm is adaptive and, provided we follow specs, it
* NEVER underestimate RTT. BUT! If peer tries to make some clever
* tricks sort of "quick acks" for time long enough to decrease RTT
* to low value, and then abruptly stops to do it and starts to delay
* ACKs, wait for troubles.
*/
El primer calculo de RTT se hace durante el handshake SYN-SYN|ACK. El rfc2988 puede ayudar con un poco de teoria (recien lo encuentro  ). Por otro lado si miran en el mismo fuente tcp_ack_saw_tstamp(),
* Changed: reset backoff as soon as we see the first valid sample.
* If we do not, we get strongly overestimated rto. With timestamps
* samples are accepted even from very old segments: f.e., when rtt=1
* increases to 8, we retransmit 5 times and after 8 seconds delayed
* answer arrives rto becomes 120 seconds! If at least one of segments
* in window is lost... Voila. --ANK (010210)
*/
Habra que hacer la prueba, comenzar alguna conexion a mano (libnet), filtrar los paquetes recibidos como decia Fyodor (insecure.org) con iptables para evitar RSTs por parte del SO, ackear rapido al principio y subitamente ackear cada vez mas lento cosa de testear la variacion de la funcion de calculo del RTO. Es simplemente una idea déjà escrita en los comentarios... pero estaria bueno probarla quand même. Hay dejo la inquietud, de mi parte cuando tenga tiempo me voy a poner a hechar codigo.... Saludos! |
|
|
|
« Última modificación: 14 Enero 2009, 13:29 por Ivanchuk »
|
En línea
|
|
|
|
AlbertoBSD
Estudiante y
Colaborador
Desconectado
Mensajes: 1.955
Anonymous & Paranoid
|
Bueno del tema ya casi no se ha hablado pero visto algunas aplicaciones por ahi que se estan acercando mas dichos ataques pero no he visto alguna que haga lo del RTO, me pondré a ver si estas próximos días llego a algo.
saludos
|
|
|
|
|
En línea
|
|
|
|
|
|
sirdarckcat
Troll Buena Onda y
CoAdmin
Desconectado
Mensajes: 6.947
Lavando Platos
|
Implementacion del ataque de TCP window size = 0 http://www.phrack.org/issues.html?issue=66&id=9Presentado en Phr4ck, configuracion por default para el comportamiento de Linux, BSD y Windows. |
|
|
|
« Última modificación: 22 Junio 2009, 09:02 por sirdarckcat »
|
En línea
|
|
|
|
AlbertoBSD
Estudiante y
Colaborador
Desconectado
Mensajes: 1.955
Anonymous & Paranoid
|
El codigo parece bueno, trate de usarlo en FreeBSD y me marca algunos errores Ya lo provare en linux, ahora cabe mencionar que un amigo tiene en un servidor el puerto charge open, ya saben ese que te conectas y te arrorja datos de manera masiva, entonces este ataque podra generar que el agote sus recursos con unas cuantas conexiones de este tipo de ataque. Saludos |
|
|
|
|
En línea
|
|
|
|
|
berz3k
|
Haz probado algo ya Anon? estoy montando apenas mi box, aunque tengo Ubuntu y Fedora no residentes.
-berz3k.
|
|
|
|
|
En línea
|
|
|
|
|
 |
