Por Fausto Cepeda 

Dos investigadores (Jack C. Louis y Robert E. Lee) han expuesto la posible existencia de una debilidad en la pila TCP/IP de todos los sistemas operativos e inclusive de dispositivos como los ruteadores que podría generar una negación de servicio tirando a los sistemas que cuenten con una pila TCP/IP. Tenemos un problema serio. 

Aún no hay mucha información detallada al respecto, pero la debilidad parece grave por el potencial que tiene y que es similar a la seriedad que en su momento representó el ataque SYN Flood. Este nuevo ataque, conocido popularmente como  Sockstress (el término no es realmente nuevo), lo que hace básicamente es consumir los recursos de un sistema provocando diversos efectos como paralización del sistema operativo o pérdida total de comunicación vía red, entre otros. 

Recapitulemos. La semana pasada, el blog de Robert Lee informó que había disponible un podcast donde se describía esta debilidad en las pilas de TCP/IP. En mi opinión, fue un anuncio irresponsable ya que los investigadores no dieron un aviso previo a los fabricantes para publicar una solución y lo que hicieron fue simplemente anunciar su descubrimiento a la comunidad, lo que produce que ahora tengamos un ataque de día cero. 

En fin, realizando un pentest, estos dos investigadores se percataron de que al hacer sus pruebas varios equipos “escaneados” se encontraron en una situación de negación de servicio, es decir, no respondían. Investigando, se dieron cuenta de que al programar su propia versión de la pila TCP/IP que hicieron para el pentest, establecían una sesión TCP (después de haber realizado el TCP handshake) y lo que hacían después (por error) era enviar a los equipos el mensaje de “no tengo espacio en el buffer, espera un momento” y así mantuvieron los mensajes hasta agotar los recursos de los equipos; su error dio pie al descubrimiento de la debilidad. Me explico. 

Mi equipo “atacante” desea afectar al servidor web “víctima” que escucha peticiones por el puerto 80. “Atacante” tiene una pila TCP/IP especialmente implementada para llevar a cabo el ataque Sockstress y contacta exitosamente a “víctima”, terminando sin problemas el TCP handshake. Aquí viene lo interesante. Ahora “víctima” tiene apartados recursos para seguir hablando con “atacante” y está esperando paquetes de “atacante” para continuar con la comunicación. Pero “atacante” le dice a “víctima” que sus buffers están llenos y que no puede enviar nada; es entonces que “víctima” se queda esperando con recursos ya apartados. Si esto sucede con una conexión, no hay problema. Pero si “atacante” empieza a hacer n peticiones, esto causará que “víctima” empiece a agotar sus recursos porque mantiene n peticiones en espera con recursos apartados que no son liberados porque estarán esperando comunicación de “atacante” que nunca llegará ya que siempre responderá que “mis buffers están llenos, por favor espera”; obviamente los buffers de “atacante” no están llenos pero eso es lo que la pila TCP/IP especialmente diseñada continúa diciendo, es decir, miente. Entonces tenemos a “víctima” con n peticiones en espera y en aumento que consumen recursos y por su lado “atacante” no debe de mantener las n peticiones (porque tiene su respuesta predeterminada de “buffers llenos”); esto impide que al propio “atacante” se le agoten sus recursos haciéndose a sí mismo el ataque de negación de servicio. 

Los ataques de antaño (SYN Flood) también consumían recursos de la víctima pero durante el TCP handshake (en su momento se le dio una solución, si bien no perfecta, aceptable y funcional); y este nuevo ataque sucede después del TCP handshake. 

Este ataque de Sockstress afecta principalmente a servidores, porque están dando un servicio vía red, escuchando peticiones de potenciales atacantes; sin embargo recordemos que todos los sistemas operativos (incluyendo los de los ruteadores) tienen una pila TCP/IP y bastaría con que escucharan en un puerto para poder ser afectados…al menos en teoría.  

Podemos decir que una manera de defendernos de este ataque es identificar la dirección IP del atacante y bloquearla. ¿Solucionado? Tal vez no; lo que se teme es que un atacante pueda crear un botnet (varios sistemas comprometidos a la orden del atacante), y que el servidor “víctima” esté recibiendo estos ataques de Sockstress no de uno, sino de muchos equipos…qué hacer? ¿Bloquear a todas esas IP y seguir bloqueando las nuevas IP que estén atacándonos? Impráctico tal vez. 

¿Soluciones? Por el momento ninguna funcional y realmente efectiva; esperemos que los fabricantes emitan algún tipo de parche que lo neutralice al igual que se hizo en su momento con el viejo ataque de Syn Flood. Tal vez los IDS (Snort) o IPS puedan ayudarnos, pero habría que probarlo. Hay varias referencias a este ataque como las de Slashdot y el SANS. Los investigadores darán mayor explicación de este ataque en una conferencia en Finlandia. Por cierto, he leído en foros de usuarios que la pila TCP/IP del sistema operativo OpenBSD no es vulnerable a este ataque; no lo puedo confirmar. 

Conclusión. Este ataque tiene el potencial de hacer una negación de servicio. Actualmente los atacantes no están interesados en tirar servicios sino en conseguir dinero fácil con troyanos o phising, por ejemplo. A menos que encuentren la manera de hacer dinero con este Sockstress (extorsión: dame dinero o te tiro tu servicio), tal vez sólo debamos preocuparnos por los crackers que deseen demostrar que “ellos saben cómo hacerlo” y lo hagan por orgullo, como antaño. Hasta le fecha (08/10/2008), no he visto noticias que indiquen un posible ataque presente o en el futuro cercano. Pero debemos estar atentos. 

Fausto Cepeda es ingeniero en Sistemas Computacionales por el ITESM, CCM. Es Maestro de Seguridad de la Información por la Universidad de Londres en el Reino Unido. Ha sido Consultor de Seguridad y actualmente es Analista de Sistemas en la Oficina de Seguridad Informática del Banco de México. También cuenta con la certificación de seguridad CISSP (Certified Information Systems Security Professional.