TCP Ilegitimo

RESETEO “ILEGÍTIMO” CONEXIONES TCP

DE

Garcia Canet, Juan Raúl NIF: 20024841-Y 4º Ingenieria en Informática ETSE - UV

Indice 1.- Resumen 2.- Introducción 3.- Fundamentos de TCP 3.1.- El protocolo TCP 3.2.-Funciones de TCP 3.3.- Formato de los Segmentos TCP 3.4.- Funcionamiento de TCP 3.5.- La Ventana Deslizante 4.- Reseteo de Conexiones TCP 4.1.- Cierre de conexión cordial (FIN) 4.2.- Cierre de conexión abrupta o por condición de error “grosera 1” Ejemplo de un ataque 5.- Contramedidas 6.- Referencias

1

La condición de “Error Grosera o grave” se estable ce mediante uun mensaje ICMP que indica el código del error. (p.ej: el código 3 => “Port unreachable). Según el RFC 1122 :”TCP SHOULD abort the connection” (“TCP debería abortar la conexión”)

1.- Resumen El presente trabajo muestra una introducción a los problemas ocasionados por los ataques de reseteo de conexión TCP, y se describen una variedad de dichos ataques, que permiten a un atacante lograr que una conexión TCP sea abortada de forma ilegítima. 2.- Introducción TCP es sin duda el protocolo de transporte más utilizado en la red Internet. De él dependen aplicaciones tales como el correo electrónico, la Web y hasta incluso diversas aplicaciones en tiempo real para su señalización). Cada una de estas aplicaciones depende, en distinto grado, de la “estabilidad” de la conexión TCP correspondiente. Es decir, el error en la conexión TCP utilizada afectará a la aplicación que la esté usando en mayor o menor medida, dependiendo de las características de la aplicación en particular. Como ejemplo, en una conexión HTTP, utilizada por la web, si la conexión TCP fuese abortada, se produciría una interrupción en la transferencia de informació (p. ej: descarga de ficheros o en la visualización de una página web). Sin embargo, este efecto no sería grave, ya que bastaría con reiniciar la transferencia del fichero interrumpida o recargar la página para volver a establecer la conexión. En otro caso, como en VoIP(Voz sobre IP), la interrupción de la conexión TCP (utilizada para señalización) provocaría la pérdida de la comunicación de voz, siendo este efecto “más grave” que en el caso anterior. No obstante, en el caso de los protocolos de ruteo, como BGP, que hacen uso de coenxiones TCP para la transferencia de información de las rutas de encaminamiento, el reseteo de la conexión TCP establecidad para dicho fin sería mucho más grave que en los casos anteriores, ya que el efecto producido sería la eliminación de todas aquellas entradas de la tabla de ruteo que habían sido adquiridas a través de la conexión que ha sido abortada. Ésta situación provocará, en la mayoría de los casos, la pérdidad de la conectividad con todos aquellos sistemas que dependían de las entradas de la tabla que han sido eliminadas. Como se ha podido ver en esta pequeña introducción, el impacto de los ataques de resteo de conexioones TCP varía en función de la aplicación que esté haciendo uso de la conexión TCP atacada. Es pues, evidente, que en aquellos casos en que el correcto funcionamiento de la infraestructura de Internet depende, en gran medida, de una aplicción que esté haciendo uso de los servicios TCP, la protección contra ataques de la índole de los descritos, es de gran importancia. En apartados posteriores veremos en que se basan estos ataques, algunos ejemplo de ataques y las soluciones que se han propuesto para solucionar este tipo de incidencias. 3.- Fundamentos de TCP En el anterior apartado hemos descrito los inconvenientes del ataque de reseteo de conexiones TCP, pero no hemos descrito el motivo por el que se pueden producir dichos ataques. Es el presente apartado introduciremos los conceptos en los que se basa el protocolo TCP para establecer la comunicación entre dos hosts y estableceremos los principios en los que se fundamentan este tipo de ataques descritos.

3.1.- El protocolo TCP El Protocolo de Control de Transmisión (TCP en sus siglas en inglés, Transmission Control Protocol que fue creado entre los años 1973 - 1974 por Vint Cerf y Robert Kahn) es uno de los protocolos fundamentales en Internet. Muchos programas dentro de una red de datos compuesta por ordenadores pueden usar TCP para crear conexiones entre ellos a través de las cuales enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto. TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP, SMTP y SSH. Se documenta a través de IETF RFC 793. 3.2.-Funciones de TCP En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe: libre de errores, sin perdidas y con seguridad. 3.3.- Formato de los Segmentos TCP 15 16

20 by tes

0

Ilustración 1: Cabecera TCP

Explicaremos a continuación, y para no extendernos demasiado, los campos de este segmento que nos van a interesear para este trabajo: Puerto origen y Puerto destino identifican, junto a las direcciones origen y destino del paquete IP, la conexión a la que pertenece el segmento. Número de secuencia (Sequence number) indica el orden, dentro de la transmisión, del primer byte de datos contenido en el segmento. Junto al tamaño total del paquete IP, que permite conocer cuántos bytes de datos se reciben, es posible determinar cuál será el número de secuencia del siguiente segmento. Número acuse de recibo (Acknowledgement number) indica cuál es el byte que el emisor del segmento espera recibir como número de secuencia. Esto implica que todos los bytes transmitidos en segmentos anteriores han

31

llegado de forma satisfactoria. Sólo es significativo cuando el bit ACK del campo FLAGS está a 1 FLAGS: Consta de seis bits, teniendo cada uno de ellos un significado independiente del resto. ACK El campo de acuse de recibo es válido RST Reiniciar la conexión SYN Establecimiento de conexión FIN El emisor llegó al final de su secuencia de datos Ventana (Window) indica cuál es el tamaño de la ventana de recepción del emisor del segmento, es decir, el espacio en memoria disponible en el receptor. Este campo limita la ventana de transmisión del receptor del segmento, limitando el número de bytes que puede transmitir sin recibir reconocimientos. 3.4.- Funcionamiento de TCP Ahora que hemos visto la estructura de los segmentos TCP, veremos cómo se establece la comunicación mediante el protocolo TCP. Las conexiones TCP se componen de tres etapas: establecimiento de conexión, transferencia de datos y fin de la conexión. Para establecer la conexión se usa el procedimiento llamado negociación en tres pasos (3-way handshake). Para la desconexión, en cambio, se usa una negociación en cuatro pasos (4-way handshake) es usada para la desconexión. De modo gráfico la conexión y desconexión TCP se establece de la siguiente manera:

Ilustración 2: Establecimiento de conexión TCP

Ilustración 3: Fin Conexión TCP

TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías:  Bien conocidos: Son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha

de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80)  Registrados y dinámicos/privados. Son, normalmente, empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero también pueden representar servicios que hayan sido registrados por un tercero. También pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Además, no tienen significado fuera de la conexión TCP en la que fueron usados. ¿Cómo se establece la conexión? Habitualmente la conexión se estable entre dos hosts. Una de ellos abre un socket en un determinado puerto y queda la escucha de nuevas conexiones. A esta acción se le suele llamar apertura pasiva y determina el lado servidor de una conexión. Por su parte el cliente, realiza una apertura activa de un puerto enviando un segmento SYN (1r paso) que inidica al servidor que un determinado cleinte desea establecer una conexión. El servidor reponderá con una petición SYN válida con un paquete SYN/ACK (2º paso). En el útlimo paso (3r paso), el cliente deber responder al servidor con un segmento ACK, compleando así la negociación y estableciendo la conexión. A partir de ese momento, cliente y servidor pueden empezar a intercambiar información. Cabe destacar que, durante esta negociación se ha establecido un número de secuencia, generado por ambas partes, que evitará que se puedan establecer conexiones falseadas. Esto es cierto en parte, pues como veremos en el siguiente apartado, es posible suplantar esta comunicación y enviar información falseada. Es en este punto en el que centraremos el contenido de este trabajo. 3.5.- La Ventana Deslizante TCP utiliza un mecanismo bastante simple para el control de flujo de información. Simplemente, cada segmento TCP contiene un campo “Ventana” que indica cuantos bytes de información TCP está dispuesto a recibir. Este mecanismo, impide que un hosts esté contínuamente mandando segmentos al otro de manera que el primero no sea capaz de manejar toda la información produciéndose así una situación de congestión que provocaría la pérdidad de segmentos e información. La siguiente figura ilustra el funcionamiento de la ventana deslizante:

HOST A

A Procesa 1000 bytes

ACK 1500, w in= 2000 000) SEQ 1500 (1 00) SEQ 2500(10 ACK 3500, w in= 0 ACK 3500, w in= 1000 , win= 0 5 5 3 K C A 1000

HOST B

B Deja de enviar

B vuelve a enviar

En este ejemplo el host B se comporta tal y como se espera, es decir, dejando de enviar cuando A ha anunciado una ventana de 0 bytes. Es decir, el host B sólo ha enviado información cuando la ventana TCP lo permitía. Sin embargo, si el Hosta B hubiera continuando enviando información, a pesar de recibir un win=0, el Host A sólo hubiera aceptado aquellos bytes de información con números de secuencia (SEQ) que estuvieran dentro de la ventan de recepción TCP. Dicho de otro modo, TCP considera vaĺidos solamente aquellos segmentos-datos que se encuantran dentro de laventana de recepción, el resto son descartados. A raíza de lo visto, podemos afirmar que la ventana TCP tiene un impacto directo sobre el rendimiento de la conexión ya que la tasa de transferencia de toda conexión queda limitada por la expresión: Máx. Tasa Transf= Ventana / RTT Dónde RTT corresponde a Round-Trip Time (Tiempo de ida y vuelta.

Con el fin de evitar que la ventana TCP imponga un límte artificial en la tasa de transferencia, a menudo, se suele utilizar un tamaño de ventana superior al necesario. Es en este punto dónde encontramos el punto débil del sistema, ya que cuanto mayor es el tamaño de la ventana más probabilidades hay que un atacante pueda falsificar un segmento TCP con un número de secuencia tal que sea aceptado como ”válido2” por el sistema atacado. Como se puede adivinar, si un atacante logra adivinar un número de secuencia correcto, sería capaz de realizar cualquier tipo de operación que puedan realizar los sistemas que han establecido la comunicación legítimamamente (incluyendo el envió de segmentos RST que permitirán abortar la conexión TCP actual). Como se puede ver, una característica que, a priori, podría considerarse una gran ventaja, se convierte en un problema con graves implicaciones para la seguridad. 4.- Reseteo de Conexiones TCP Ya hemos analizado a los participante en el caso que nos ocupa, que como recordamos, se trata del reseteo de conexiones TCP de manera ilegítima. Antes de entrar en detalla, veremos la diferencia entre el cierre de una conexión TCP de manera cordial (FIN) y el cierre de conexión TCP debido a una condición de error “grosera”(RST) 4.1.- Cierre de conexión cordial (FIN) En la cabecera TCP mostrada en la Ilustración 1 podemos ver que existen una serie de flags que indican el tipo de segmento TCP que se está enviando. Cuando uno de los hosts decide cerrar la conexión, genralmente el cliente cuando ha terminado de enviar los datos, envía un segmento con el bit FIN activo, situación que indica el servidor que la conexión desea abortarse. En este momento se realiza la negociación del cierre mediante 4 pasos (véase Ilustración 3). Finalizada la negociación, la conexión queda abortada de mútuo acuerdo. 4.2.- Cierre de conexión abrupta o por condición de error “grosera 3” 2

3

Como se ha mencionado anteriormente, un segmento se considera válido si su número de secuencia se encuentra dentro de la ventana TCP. La condición de “Error Grosera o grave” se estable ce mediante uun mensaje ICMP que indica el código del error. (p.ej: el código 3 => “Port unreachable). Según el RFC 1122 :”TCP

A diferencia del cierre de conexión “cordial”, la conexión abrupta se produce cuando existe una condiciónn de error en alguno de los hosts. Por ejemplo, si un host A desea establecer una conexión (envía segmento SYN) a un puerto determinado de otro sistema en el que no existe ningún proceso escuchando, el sistema destino (host B) enviará un segmento RST, puesto que se considera un error. De acuerdo con lo esablecido en el RFC 793, el segmento tendrá en su campo ACK el valor correspondiente para el acuse de recibo del segmento SYN enviado por A (en caso que el segmento SYN no tuviera datos, dicho valor sería el número de secuencia del segmento SYN incrementado en una unidad). Otro posible ejmeplo podrñía ser aquél en que el proceso que mantiene una conexión TCP termina de forma anormal y, como consecuencia, se abortan todas la conexiones que tenía establecidas. Una vez visto esto, podemos entrar de lleno en el tema que nos ocupa. Según la exposición hecha anteriormente, resulta obvio concluir que, si un atacante es capaz de falsificar un segmento RST con los siguientes datos:  IP origen,  IP destino,  Puerto Origen,  Puerto destino,  Número de secuencia que se encuentre dentro de laventana de recepción del sistema atacado. El resultado sería: La conexión TCP en cuestión sería abortada de forma ilegítima. Son muchos los datos que un atacante debería conecer para poder aprovecharse de esta vulnerabilidad. No obstante, no es tan difícil el conocimiento de estos datos. Supongamos que el atancante conoce la identidad de los dos extremos en una conexión: En ese caso las IP's de los sistemas sería conocida En lo que respecta al puerto utilizado por el “servidor”, lo más seguro es que coincida con uno de los “well-know port”(puerto bien conocido)correspondiente al servicio en cuestión (p.ej: HTTP=>80; SMPT=>25...) Así pues, lo único realmente desconocido es el “puerto del cliente”, lo cuaĺ forzaría al atacante a probar las 655364 combinaciones posibles para dicho puerto. Sin embargo, hay dos consideraciones que deberemos tratar respecto a dicha afirmación: 1.- La mayoría de los sitemas operativos eligen los puertos efímeros (puertos TCP utilizados para conexiones salientes) de una porcióon del rango total de puertos disponibles: Sistema Operativo Linux Kernel 2.6 y MS Windows Solaris y AIX FreeBSD y OpenBSD

4

Puertos efímeros 1024 - 4999 32768 - 65535 1024 - 49151

SHOULD abort the connection” (“TCP debería abortar la conexión”) En la cabecera TCP el número de puesrt (origen/destino) se indica con una cadena de 16 bits, lo cuál nos lleva a un número de 216 =65536

NetBSD

49152 - 65535

2.- Muchas implementaciones eligen sus puesrtos de forma incremental. Es decir, si una conexión saliente usa el puerto 1025, la siguiente usará el 1025, etc. De esta manera, es posible, en ciertas situaciones, que un atacante pueda saber el número de puerto TCP del cliente de la conexión atacada. Si estas condiciones se cumplen, el atacante tendría, las IP's y los puesrtos. Ya sólo le quedaría por averigar o adivinar el número de secuencia válido para lograr que el segmento RST falsificado sea aceptado y, como consecuencia, la conexión abortada. Hay que decir que el tiempo que el ataque necesitará dependerá de dos parámetros:  Ancho de banda del atacante  El tamaño de la venata TCP usada por el sistema atacado ¿Cómo se realizaría el ataque? Como ya hemos detallado, para la realización del ataque nos hará falta un segmento TCP (con el bit RST activo) falsificado con los valores (IP origen, IP destino, Puerto origen, Puerto destino) correctos y con un número de secuencia que se encuentre dentro de la ventana de recepción del sistema atacado. Escenario 1: El sistema atacado no está recibiendo información y por tanto la ventana TCP está inmóvil. El atacante deberá escanear todo el espacio de números de secuencia TCP, enviando segmentos TCP cuyos números de secuencia estarían separados entre sí por un valor aproximado al tamaño de la ventana utilizada por el sistema en cuestión. Escenario 2: El sistema objetivo está recibiendo información, y en este caso, la ventana está en movimiento con una velocidad promedio igual a la tasa de transferencia promedio de la conexión TCP. En esta situación tendremos dos posibles formas de realizar el ataque. 1ª Forma: Consiste, al igual que la descrita en el Escenario 1, en enviar sucesivos segmentos RST con distintos números de secuencia, pero esta vez tendrán en cuenta tanto el tamaño de la ventan TCP como la tasa de transferencia de datos de la conexión (en resumen, el movimiento de la ventana) 2ª Forma: El atacante envía segmentos RST a intervalos regulares, pero todos ellos con el mismo número de secuencia. En este caso, en lugar de intentar “acertar en laventana TCP”, lo que estaría haciendo es esperar a que la ventana “se mueva” sobre los segmentos RST que está enviando.

Ejemplo de ataque: Escenario del ataque

1024

SEGMENTO RST

Para ilustrar el ataque http://www.gont.com.ar

usaremos

la

herramienta

tcp-reset

disponible

en

Asumiremos que la conexión TCP a atacar no está transfiriendo datos (es decir, se encuentra incativa). También consideraremos que el atacante conoce los cutro valores que definen una conexión TCP (IP origen, IP destino, Puesrto origen, Puerto destino), y el tamaño de la ventana utilizada por el sistema objetivo del ataque. tcp-reset -c 192.168.0.1:1024 -s 172.16.0.1:80 -t client -r 60 -W 400 -c: Permite especificar los datos correspondientes al “cliente”, que en este caso, suponemos que el cliente posee la dirección 192.168.0.1 y que usa el puesrto 1024 para la conexión TCP. -s: Permite especificar la información del “servidor”, que en este caso posee la dirección 172.16.0.1 y el número de puerto 80. -t (target): Permite indicar cuál será el destinatario de los segmentos RST. -r: Permite especificar el kilobits por segundo, el ancho de banda que se desea utilizar para el ataque. -W: Especifica el tamaño de la ventana usada por el cliente. De este modo la herramienta tcp-reset barrerá todo el espacio de los números de

secuencia mediante saltos del tamaño especificado por -W (400. Una vez realizado el barrido, devolverá el control al atacante. 5.- Contramedidas Para evitar el atqeu de reseteo de conexiones TCP existen variedad de contramedidas. La primera de ellas puede ser la elección aleatoria de los puertos TCP para conexiones salientes. de esta manera, si se eligen los puertos efímeros de forma aleatoria dentro del rango 1024-65536, sería virtualmente imposible para un atacante adivinar “ a ciegas5”, el puesrto usado por el cliente, y como consecuencia, tanto el tiempo como la cantidad de paquetes requeridos para realizar el ataque en cuestión serían notablemente más elevados. Así mismo. la IETF ha propuesto una modificación al procesamiento de los segmentos RST, para disminuir considerablemente las posibilidades de éxito de un atacante frente a este ataque: Punto 1: En caso de recibir un segmento RST con un número de secuencia fuera de la venta TCP, el mismo sería descartado. (RFC 793) Punto 2: Si el segmento RST recibido contiene como número de secuencia TCP, el próximo número de secuencia que se espera recibir, se abortará la conexión tCp corespondiente. Punto 3: Si el segmento RST recibido contiene un número de secuencia TCP que se encuentra dentro de la ventana TCP, pero no cumple con la condición del punto 2, se responderá a dicho segmnento con RST con un ACK. Comentarios a estos puntos: El punto 1 establece lo que ya está definido en el RFC 793 y no merece mayor comentario. El punto 2, establece un requerimiento más estricto que al actualmente establecido en el RFC 793, que simplemnete exige que el segmnento RST se encuentre dentro de la venta de recepción, mientras que en la propuesta actual se exige, además, que el número de secuencia sea el próximo número de secuencia esperado. Finalmente, el punto 3, establece el concepto de “challenge ACK” (ó “desafío ACK”), que permite mitigar los ataques de reseteo de conexión, y al mismo tiempo matener la funcionalidad de reseteo de conexión para aquellos casos legítimos.

+

5

Estando fuera del camino que siguen los paquetes correspondientes a la conexión a ser atacada.

Ilustraremos el desfío ACK mediante le siguiente gráfico:

HOST B Dibujo 1: "challenge ACKs frente a RST ilegítimo"

Se envia un RST con el número de secuencia perteneciente a la ventana de recepción del sistema atacado. Si embargo, según el punto 3 de la nueva especificación, se enviará un ACK ya que el número de secuencia del RST enviado no coincide con el siguiente número de secuencia esperado

En este punto sí se cerraria la conexión de forma legítima 6.- Referencias Dafal, M. 2006. Improving TCP's Resitance to Blind In-window Attacks. IETF InternetDraft http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt Gont, F. 2007. ICMP attacks against TCP. IETF Internet Draft http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-02.txt Larsen, M., Gont, F. 2007. Port Randomization. IETF Internet-Draft http://www.ietf.org/internet-drafts/draft-larsen-tsvwg-port-randomization-01.txt Boletín de Seguridad UNAM-CERT 2004-006. Vulnerabilidades en TCP http://www.lugro.org.ar/pipermail/lugro-mix/2004-April/000481.html Gont's Website: http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html Wikipedia: http://es.wikipedia.org/wiki/Transmission_Control_Protocol Montañana, R. 2007.(Apuntes de Redes) Tema 5: El Nivel de Transporte en Internet http://www.uv.es/montanan/redes/redes_05.pdf Montañana, R. 2007.(Material Auxiliar) Cap 3: La capa de enlace

http://www.uv.es/montanan/redes/cap_03.rtf