Secuestro de TCP

Secuestro de TCP : una variación del ataque Man -in-the-Middle en el que un atacante puede espiar los paquetes de los miembros de la red y enviar sus propios paquetes a la red. El ataque utiliza las funciones de establecimiento de conexión del protocolo TCP y puede llevarse a cabo tanto durante un "triple protocolo de enlace" como durante una conexión establecida.

El problema de la posible suplantación de mensajes TCP es importante, ya que el análisis de los protocolos FTP y TELNET implementados sobre la base del protocolo TCP mostró que el problema de identificación de paquetes FTP y TELNET es asignado por completo por estos protocolos al nivel de transporte, es decir , a TCP.

Estableciendo una conexión TCP

Para identificar un paquete TCP en el encabezado TCP, hay dos identificadores de 32 bits que también desempeñan la función de un contador de paquetes: el número de secuencia y el número de reconocimiento. En el caso de que el host A quiera establecer una conexión TCP con el host B, el llamado. "apretón de manos triple", durante el cual los hosts intercambian los siguientes paquetes:

el host A envía un paquete al host B con el bit SYN establecido y el valor de 32 bits de ISSa en el campo Número de secuencia
el host B responde al host A con un paquete con bits SYN y ACK establecidos , ISSb de 32 bits en el campo Número de secuencia y (ISSa+1) en el campo ACK
el host A responde al host B con un paquete con el bit ACK establecido, el valor (ISSa+1) en el campo Número de secuencia y el valor (ISSb+1) en el campo ACK.

Este paquete completa la configuración de la conexión, por lo que en el siguiente paquete, el host A envía información útil al host B

el host A responde al host B con un paquete con el bit ACK establecido, el valor (ISSa+1) en el campo Número de secuencia y el valor (ISSb+1) en el campo ACK. Toda la información útil está incluida en este paquete.

Principio de ataque

Teniendo en cuenta el esquema de configuración de la conexión descrito anteriormente, puede ver que los únicos identificadores por los que el host final puede distinguir entre suscriptores TCP y conexiones TCP son los campos Número de secuencia y Número de reconocimiento. Por lo tanto, si un atacante determina los valores ISSa e ISSb para una conexión determinada, puede generar un paquete TCP falso que será aceptado y procesado por el host final.

Un tipo de ataque implica que el atacante incrusta el bit de control RST (Reinicio) en el paquete TCP. De acuerdo con RFC 793 , esta bandera le dice al host de destino que abandone la conexión sin más comunicación. Según el campo Número de secuencia, el host de destino determina si procesar o ignorar el comando de reinicio, y se prohíbe que el destino envíe una respuesta con el bit RST establecido. Es importante tener en cuenta que el host de destino solo autentica la solicitud RST contra el número de secuencia y cierra la conexión si se encuentra dentro de la ventana TCP actual. Y aunque el host de destino puede calcular el número de reconocimiento, no es necesario que lo haga, y la mayoría de las pilas de TCP simplemente ignoran este paso.

Un paquete RST recibido siempre terminará la conexión. Las conexiones a largo plazo, como las conexiones BGP entre enrutadores, son extremadamente vulnerables a este tipo de ataques. En primer lugar, el atacante tendrá tiempo suficiente para implementar un paquete cuidadosamente planificado y, por otro lado, DoS causará grandes pérdidas . Los enrutadores tienen que reconfigurar la tabla vecina, lo que puede llevar varios minutos en la vida real.

Menos obvio es el hecho de que el indicador SYN también puede bloquear la conexión. De acuerdo con RFC 793 , cuando se establece el indicador SYN cuando se establece una conexión, el campo Número de secuencia contiene un valor inicial que se usará más adelante. Si posteriormente se recibe un paquete SYN en esta conexión, RFC 793 lo tratará como un error. Como resultado, el destinatario deberá cancelar la conexión enviando un paquete RST. A diferencia de un paquete RST, el host responderá a un paquete SYN enviando un paquete RST. Esto abre la posibilidad de otro ataque DoS. Posteriormente, el atacante puede utilizar el ancho de banda de la víctima. Este ataque es particularmente exitoso en las líneas ADSL .

Si bien los ataques RST y SYN no utilizan la carga útil de un datagrama IP , una tercera técnica inyecta los datos en una conexión existente. El atacante puede insertar cualquier dato que provoque la terminación de la conexión, o crear cuidadosamente datos que conduzcan a una condición de error, o realizar alguna función en beneficio del atacante. Es posible que la víctima ni siquiera se dé cuenta de estas manipulaciones. Por ejemplo, los protocolos FTP y TelNET no comprueban la dirección IP del remitente , y por tanto, si se genera con éxito una petición TCP falsa, responderán a la dirección IP real del atacante, que interceptará por completo la conexión.

Entonces, para llevar a cabo un ataque, necesita conocer dos parámetros de conexión TCP. En caso de que un atacante pueda espiar directamente el canal de comunicación entre los hosts A y B, estos parámetros se determinan mediante un simple análisis de tráfico. De lo contrario, debe recurrir a métodos más complejos.

Estimación matemática del parámetro ISN

Este método se basa en la suposición de que la elección de los parámetros iniciales ISSa e ISSb (el llamado ISN - Initial Sequence Number) al establecer una conexión depende de alguna manera del tiempo. Lo mejor desde el punto de vista de la seguridad sería elegir un ISN que sea completamente arbitrario, lo que haría prácticamente inaplicable la predicción, sin embargo, en la descripción del protocolo TCP en RFC 793, se recomienda aumentar el valor de este contador. por 1 cada 4 microsegundos, lo que hace trivial la predicción de este valor. En la práctica, el análisis del código fuente de los kernels de Linux más antiguos , así como el comportamiento del sistema operativo Windows NT 4.0 y anteriores, confirma la dependencia funcional del valor ISN elegido en el tiempo.

En el caso general, si existe tal dependencia, se expresará mediante alguna fórmula de la forma ISN = F(mcsec), donde mcsec es el número de microsegundos según el reloj del hardware del sistema operativo en estudio.

Por lo tanto, el atacante necesita realizar algún análisis de la función del valor ISN asignado frente al tiempo. Para ello, se envía una serie de solicitudes ordinarias para crear una conexión TCP al SO de la red objeto de estudio y se recibe el número de respuestas correspondiente con los valores actuales del ISN del sistema operativo en cada momento del tiempo. Al mismo tiempo, se miden los intervalos de tiempo (en microsegundos) para la llegada de las respuestas a las solicitudes. Construyendo una tabla de dependencia de los ISN obtenidos con el tiempo t transcurrido desde el inicio del experimento, y aproximándola con cualquier herramienta matemática, obtenemos, con un error comparable al error de los datos iniciales, una continua función del cambio en ISN de t, válida para un intervalo de tiempo dado: ISN(t) = F (t);

Esta fórmula nos permitirá utilizar el valor del ISN anterior, midiendo el tiempo transcurrido desde su nombramiento, para obtener el valor del ISN actual en el momento dado.

En el futuro, el atacante solo necesita monitorear el comportamiento de los hosts bajo investigación y, habiendo calculado el momento de creación de la conexión, estimar aproximadamente el rango de valores de los valores ISSa e ISSb elegidos por los hosts. Dado que este método es aproximado, no se puede evitar cierta enumeración; sin embargo, el modelado matemático permite muchos órdenes de magnitud (de ~ a ~ ) para reducir la cantidad de paquetes que necesita un atacante para llevar a cabo un ataque exitoso. $2^{64}$ ${\ estilo de visualización 100 ^ {2}}$

Reemplazo de ventanas

Sin embargo, no siempre es posible realizar una evaluación matemática preliminar de los valores de ISN. Además, en algunos casos, el valor se elige para que sea más o menos independiente del tiempo y, por lo tanto, la evaluación matemática es difícil o imposible. En este caso, hay que recurrir a métodos más crudos como la enumeración de todos los valores posibles de estos parámetros. Sin embargo, tras un estudio cuidadoso del estándar RFC 793 , la situación se simplifica un poco.

Lo primero que hay que mencionar es el mecanismo de ventanas en el protocolo TCP. Los paquetes pueden adelantarse unos a otros cuando se distribuyen a través de Internet. Para no perder los paquetes que llegaron antes que los predecesores, el destinatario establece una llamada ventana en la que puede restablecer el orden de los paquetes. Por lo tanto, si el valor del campo Número de secuencia se encuentra dentro de la ventana del receptor, TCP aceptará y procesará este paquete. Esto reduce en gran medida el número de intentos que tiene que hacer el atacante: se reduce de a . $2^{32}$ $2^{32}/tamaño de ventana$

Dependiendo del sistema operativo, el tamaño de la ventana puede variar entre bytes ( Windows XP con SP2 ) y 5840 bytes ( Linux kernel 2.4 y 2.6). ${\ estilo de visualización 65535}$

La ventana disminuirá la cantidad de números de secuencia que el atacante necesita usar. En el caso de Windows XP, este número se reduce a . En otras palabras, el atacante solo tendría que generar paquetes de ataque para inyectar el paquete RST y, por lo tanto, colapsar la conexión. Este es un número muy pequeño. ${\ estilo de visualización 65000}$ ${\ estilo de visualización 65000}$

Las cosas empeoran aún más si los participantes en la conexión admiten una ventana de tamaño variable. Esta característica de TCP aumenta la probabilidad de encontrar un número de secuencia adecuado en poco tiempo. El cambio de tamaño de la ventana está diseñado para conexiones que requieren una ventana más grande debido a la alta latencia o al ancho de banda ocupado. Para permitir que todos transmitan sin superposiciones, esta tecnología amplía la dimensión de la ventana a 14 bits (Microsoft Windows), es decir, a . ${\ estilo de visualización 16384}$

Sin embargo, el atacante tendrá que superar un obstáculo más: la dirección IP/ puerto cuádruple de origen y destino . La dirección IP no es un problema: el atacante generalmente sabe a quién se dirige; el puerto de destino también se determina fácilmente. Es un poco más difícil determinar el puerto de origen, que en teoría puede oscilar entre 0 y 65535. En la práctica, los puertos por debajo de 1024 y por encima del umbral determinado por el sistema operativo se reservan para tareas especiales.

Linux con kernel versión 2.4 o 2.6 usa números de a como puerto de remitente . $32768$ ${\ estilo de visualización 61000}$

Para placer del atacante, las opciones restantes no se distribuyen al azar; el núcleo los distribuye de acuerdo con un esquema específico. Por lo tanto, el atacante no tendrá muchos problemas para predecir el puerto de origen. Solo hay unas pocas excepciones, como OpenBSD , que las asigna arbitrariamente. Por ejemplo, Windows XP comienza en el puerto de la primera conexión e incrementa el puerto en 1 para cada conexión subsiguiente. Linux ( Fedora Core 3 con kernel 2.6.9 en particular) con aumentos nuevamente en orden. Los sistemas de Cisco aumentan el valor del puerto en 512 por cada nueva conexión, pero esto no hace que el mecanismo sea más seguro. ${\ estilo de visualización 28232}$ $1050$ $32768$

Un atacante no necesita adivinar el número de puerto si se conoce el número de conexiones en la máquina de la víctima. Por lo general, todo lo que un atacante debe hacer es comenzar con el primer valor y probar, digamos, 50 puertos. Tampoco es difícil para un atacante averiguar el sistema operativo de la víctima. Entonces, de hecho, la definición del puerto no es un obstáculo serio.