¿Por qué necesitamos Números de secuencia iniciales aleatorios en el proceso 3-Way Handshake?

Recuerda que en el establecimiento de la conexión TCP, existen 3 intercambios de mensajes donde se define el valor del Número de secuencia inicial. Este valor sirve para identificar todos los bytes que se envían dentro de una sesión entre 2 dispositivos. El campo de Número de secuencia es un valor de 32 bits dentro del header TCP, esto permite tener alrededor de 4 mil millones de valores diferentes de Números de secuencia. Alguna vez te preguntaste ¿por qué necesitamos que estos valores sean aleatorios?

Establecimiento de la conexión TCP

Supongamos la situación en la que no se tiene números de secuencia aleatorios y todas las conexiones comienzan con el valor ISN 0 como reflejamos en la imagen 1.

Cuando se inicia la conexión desde una computadora “A” hacia un servidor “B”, la computadora envía su mensaje SYN con un valor de ISN = 0, el servidor responde con el mensaje SYN +ACK, que también contiene un valor de ISN =0 y un valor de Número de ACK igual al Número de secuencia inicial recibido +1, en este caso el valor de Número de ACK será igual a 1. Finalmente la computadora “A”, finaliza el establecimiento de la conexión con el mensaje ACK que lleva el campo Número de ACK con un valor igual al número de secuencial inicial del mensaje (SYN+ACK) +1. Una vez finalizado el proceso 3-Way Handshake, se determina que el primer byte de datos desde la computadora “A” hacia el servidor “B” lleve el número de secuencia 1.

Problema identificado

Ya se tiene establecida la sesión y se envían los primeros 1000 bytes de datos de aplicación comenzando con el número de secuencia de 1. Supongamos que existe algún problema en la red y el paquete enviado no llega al servidor como vemos en la imagen 2.

Debido a este problema, se reenvía el paquete, esta vez el paquete si llega al destino y los bytes 1 al 1000 se entregan a la aplicación y se finaliza la sesión entre la computadora «A» y el servidor «B». Esto lo vemos en la imagen 3.

En la imagen 4, una nueva sesión se establece entre la computadora «A» y el servidor «B» y casualmente se establece con los mismos sockets que fueron usados en la sesión anterior ya finalizada.

Al no utilizar Números de secuencia iniciales aleatorios, se vuelve a determinar en el proceso 3-Way Handshake que el primer byte de datos de aplicación llevara el Número de secuencia de 1. Se envían los bytes 1 al 500.

Sorpresivamente, el paquete que se asumía perdido en la anterior sesión, llega al servidor antes que llegue el paquete que pertenece a la sesión activa (paquete en tránsito). Al recibir el paquete que se asumía perdido y que corresponde a la sesión ya finalizada, el servidor lo recibe como si perteneciera a la sesión activa, esto debido a que el paquete lleva el mismo socket de la sesión activa y también lleva el Número de secuencia que el servidor esperaba recibir, por lo tanto lo acepta y lo procesa provocando resultados inesperados.

Un paquete que pertenece a otra sesión o un paquete inyectado por un atacante, podría provocar un reinicio de sesión, corromper la información, o se podría finalizar una sesión que debería estar activa. Este es un método que fue aprovechado por los atacantes para secuestrar sesiones TCP, ya que los sockets pueden determinarse fácilmente y los números de secuencia al no ser aleatorios, podían ser rastreados y por lo tanto se podían inyectar paquetes a una sesión en particular.

Generación de Números de secuencia iniciales aleatorios

Al pasar del tiempo se ha ido mejorando esta capacidad para determinar el mejor Número de secuencia inicial, de manera que no pueda ser determinado fácilmente por los atacantes y no se tengan los errores que fueron explicados.

Según el RFC 793, el ISN debería incrementarse en «1» cada 4 microsegundos hasta llegar a su máximo valor de 4.294.967.295 donde nuevamente vuelve el contador a 0. Al iniciar cualquier sesión TCP se tomaría un valor generado de ese timer, esto evita que se tengan mismos Números de secuencia iniciales y soluciona el problema descrito anteriormente. Sin embargo se mantiene el problema de que los atacantes pueden descifrar el Número de secuencia, ya que se tienen valores de ISN predecibles.

Por estos motivos es que se utilizan Números de secuencia aleatorios que no sean fáciles de predecir y que permitan evitar los ataques de TCP y que paquetes de otra sesión ingresen erróneamente a nuevas sesiones. La forma en la cual se determinan los Números de secuencia iniciales, varía de acuerdo a cada implementación de TCP en los diversos sistemas operativos.