Cómo funcionan las conexiones TCP/IP
El Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP) es una tecnología fundamental para las redes informáticas modernas. Es la forma en que (la gran mayoría de las veces) su ordenador suele solicitar y recibir información a través de una red e Internet. Se completa con la comprobación de errores, la retransmisión de datos perdidos/corruptos y varias otras características importantes que, literalmente, hacen que Internet, tal y como la conocemos, sea fiable y funcional. Sin embargo, para entender cómo se abusa de él, primero debemos entender cómo funciona.
En aras de la brevedad, no entraremos en el proceso completo de conexión TCP/IP. Sólo nos centraremos en el proceso inicial del apretón de manos TCP de tres vías, ya que es todo lo que es relevante para el tema de este escrito.
Los anfitriones de una red que quieran intercambiar datos utilizando TCP deben negociar primero una conexión. Aquí es donde entra en juego el handshake TCP de tres vías. El proceso de handshake permite a ambos hosts reconocer el envío y la recepción exitosa de las comunicaciones de red, así como establecer su respectiva sesión en previsión del intercambio de datos de la aplicación.
Fig. 1) TCP three-way handshake
En la Figura 1, vemos a un Cliente estableciendo una conexión TCP con un Servidor. El primer paso es que el Cliente envíe un paquete de sincronización o SYN. Este paquete tiene dos funciones principales, la primera es probar la capacidad de alcanzar el recurso remoto. Si este paquete se envía con éxito, también indica al Servidor que un Cliente remoto quiere comenzar el proceso de negociación de la conexión para el intercambio de datos. El servidor responde emitiendo un paquete de sincronización y reconocimiento, o SYN-ACK, dirigido al cliente que inicia la conexión. La parte final del intercambio de tres vías consiste en que el cliente responda al SYN-ACK con un paquete de reconocimiento final, o ACK. Una vez completado este handshake, la conexión está lista para ser utilizada por la aplicación para la transmisión bidireccional de datos.
El método más común para transportar las comunicaciones TCP es sobre el Protocolo de Internet o IP. Esto significa que los paquetes TCP se comunican entre el cliente y el servidor utilizando datagramas IP, dirigidos utilizando direcciones IP para cada uno de los dispositivos.
Cómo funciona este ataque
Los atacantes convierten en arma este proceso de handshake suplantando las direcciones IP de origen de los paquetes SYN. Esta suplantación hace que el servidor envíe el paquete SYN-ACK a la IP víctima, que el servidor cree que solicitó la inicialización de la sesión, actuando como reflector.
Fig. 2) Reflejo SYN-ACK
En la Figura 2, se puede ver una visualización muy sencilla de este ataque. Sin embargo, esto no muestra cómo es un escenario de ataque real. La realidad es que TCP fue diseñado para operar en redes poco fiables, lo que significa que un único SYN falsificado puede provocar que un servidor envíe múltiples SYN-ACKs en rápida sucesión si no recibe el ACK final del handshake. El número de SYN-ACKs a enviar y la rapidez con la que se envían es una métrica configurable, por lo que es difícil estimar con exactitud cuántos SYN-ACKs puede recibir una víctima objetivo en relación con el volumen de paquetes SYN falsificados que fueron enviados por los atacantes.
Ancho de banda bajo vs PPS alto
Los ataques SYN-ACK no son los típicos ataques de reflexión. Uno de los principales atractivos de los ataques de reflexión basados en UDP es su factor de amplificación, o el tamaño del paquete que llega a la víctima frente al tamaño del paquete que debe enviar un atacante. En muchos casos, el factor de amplificación es muchas veces superior al de la petición original. En el caso de la reflexión de CLDAP, por ejemplo, el paquete resultante es unas 50-70 veces mayor que el paquete que el atacante debe enviar para provocar la reflexión. Los ataques de amplificación suelen considerarse volumétricos, normalmente con el objetivo de saturar los enlaces de red utilizados por los servidores y aplicaciones objetivo.
En el caso de las reflexiones SYN-ACK, el tamaño del paquete entregado a la víctima es casi del mismo tamaño que el paquete enviado por el atacante. Decimos «casi el mismo tamaño» porque es posible, y muy probable, que mientras el atacante envía un paquete SYN de longitud mínima, algunos routers de la red entre el atacante y la víctima también modifiquen el paquete TCP para añadir información de enlace adicional, como la opción TCP de tamaño de segmento máximo (MSS), aumentando el tamaño absoluto del tráfico observado por la víctima. Esta opción supone 4 bytes adicionales por paquete en comparación con lo que envió el atacante.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) Amplificación SYN-ACK de 4 bytes
Esto no significa que este ataque no sea una amenaza. Durante varios ataques coordinados contra clientes de Akamai, se observaron múltiples casos de inundaciones de paquetes por segundo (PPS) elevados utilizando tráfico SYN-ACK reflejado. Aunque es menos probable que el tráfico de bajo ancho de banda sature los enlaces, el alto PPS puede causar problemas a los equipos de red que intentan procesar y enrutar el diluvio de SYN-ACKS que se precipitan a través de las redes.
Lo que un atacante puede y no puede controlar
Los atacantes de SYN-ACK dependen de las configuraciones TCP de sus reflectores y de cómo manejan sus conexiones TCP. Esto significa que los atacantes están limitados en lo que pueden reflejar a la víctima. Los investigadores de Akamai dedicaron tiempo a realizar pruebas contra varios servicios habilitados para TCP expuestos en máquinas de todo Internet para ver qué combinación de opciones de banderas TCP & podría dar lugar a los escenarios de ataque más impactantes. Cubriremos algunos escenarios de ataque, cómo se diferencian y cómo los atacantes pueden aprovechar los ataques SYN-ACK en el futuro.
Opciones TCP y SYN-ACKS rellenos
Los atacantes no pueden controlar el contenido de un paquete SYN-ACK. Aunque hemos visto inundaciones SYN rellenas durante años, la idea de un SYN-ACK rellenado no es algo que esperemos. En el mundo real, cuando se lanzaban ataques SYN-ACK, los paquetes que llegaban a las redes de las víctimas tenían una longitud predecible de 44 bytes. Como se ha comentado anteriormente, esto nos informa de que lo más probable es que los atacantes estuvieran enviando paquetes SYN sin opciones de 40 bytes, y que las opciones MSS fueran establecidas por el equipo de red en tránsito. Esto resulta en un pequeño factor de amplificación, pero queríamos probar cuán grande podíamos obtener SYN-ACKs de servidores reales.
Las pruebas se realizaron utilizando diferentes variaciones de opciones TCP. El objetivo de las pruebas era poder identificar las opciones que podían usarse de forma fiable y dar lugar a una respuesta SYN-ACK más grande de servidores elegidos al azar en todo Internet. Las opciones que podrían ser utilizadas por un atacante resultando en SYN-ACKs más grandes son Tamaño Máximo de Segmento (MSS), Timestamp (TS) , ACK Selectivo (SAckOK), Escala de Ventana (WScale), & cookies TCP Fast Open (TFO).
Simplemente utilizando opciones válidas, un atacante podría consumir aproximadamente un 62% más de ancho de banda que con un paquete SYN mínimo (72 bytes frente a 44 bytes). Utilizando estas opciones, las cabeceras disminuyen el ratio de amplificación (un 10% de amplificación se convierte en un 6-7%); sin embargo, todavía es posible conseguir la amplificación simplemente omitiendo la opción MSS, ya que se establecerá en tránsito independientemente de que el atacante la envíe o no.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Fig. 4) Relleno SYN-ACK con TFO
Durante las pruebas, fue posible aprovechar el TS, SAckOK, WSCale, & las opciones TCP de TFO (y el relleno NOP) para emitir un paquete SYN de 68 bytes que resultó en una respuesta SYN-ACK de 72 bytes que se entregó a la víctima, como se ve en la figura 4. Si un host no soporta TFO, un atacante todavía puede empujar un paquete SYN de 56 bytes que resulta en un SYN-ACK de 60 bytes que se enruta a la red de la víctima, como se ve a continuación en la figura 5.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
Fig. 5) Relleno SYN-ACK menos TFO
Ampliación SYN-ACK
Es posible una pequeña cantidad de amplificación utilizando ataques SYN-ACK, pero es posible aumentar este factor de amplificación apuntando al espacio IP que está asignado pero desocupado (lo que significa que la IP es enrutable pero ninguna máquina está actualmente desplegada y/o manejando el tráfico de red). Este escenario permite a los atacantes aprovechar al máximo los esfuerzos de retransmisión de TCP, lo que a su vez aumenta los factores de amplificación y el consumo de ancho de banda.
Cuando una máquina normal recibe un SYN-ACK fuera de estado de un reflector, responderá con un paquete RST como se muestra a continuación en la Figura 6. Este paquete RST será recibido por el reflector, y la sesión TCP en el reflector será asesinada.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) un SYN-ACK fuera de estado desencadena una respuesta RST
Si este paquete SYN-ACK está destinado a una dirección IP que está asignada pero desocupada, el SYN-ACK será enrutado (impactando en el equipo de red a lo largo del camino) pero nunca llegará a una máquina real que emitiría un RST. Esta falta de paquete RST hará que el reflector asuma la entrega fallida del SYN-ACK y comience los intentos de retransmisión.
En las pruebas, el número de intentos de retransmisión suele estar entre 5 y 7 paquetes SYN-ACK enviados a la víctima por cada SYN enviado. Si suponemos que un atacante envía un SYN de 40 bytes, podemos esperar que entre 5 y 7 SYN-ACK de 44 bytes atraviesen la red de las víctimas. En el peor de los casos, con 7 paquetes recibidos, esto resulta en que una petición de 40 bytes genera 308 bytes de paquetes que llegan a las fronteras de la víctima, un factor de amplificación del 770%. Utilizando las cabeceras de las opciones TCP para generar SYN-ACKs más grandes, un atacante podría elevar esas cifras a 56 bytes, lo que resultaría en 420 bytes de tráfico reflejado, un factor de amplificación del 750%.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN resulta en 6 SYN-ACKS
TFO, padding, y amplificación
TCP Fast Open (TFO) está siendo discutido en más detalle aquí para cubrir algunos casos de borde interesantes observados en las pruebas. Usando las cookies TFO, es posible desencadenar respuestas más grandes (12 bytes adicionales por SYN-ACK); sin embargo, debido a los descuidos en la implementación de TFO, estas medidas pueden alterar los factores de amplificación y, bajo diferentes escenarios, los ataques habilitados para TFO pueden ser más deseables.
Los atacantes que intenten aprovechar los reflectores habilitados para TFO sólo pueden encontrarlo fructífero en ciertas circunstancias. Estas circunstancias serían los casos en los que no hay ningún espacio IP que no esté siendo manejado por una máquina viva, si un atacante debe dirigir paquetes SYN-ACK reflejados a máquinas reales que responderán con paquetes RST, la amplificación de la retransmisión TCP es esencialmente discutible ya que el reflector dejará de enviar SYN-ACKs al recibir la respuesta RST de las máquinas de la víctima.
Para hacer esta propuesta aún menos deseable, los hosts habilitados para TFO no incluirán la opción de cabecera de 12 bytes para la cookie TFO en paquetes SYN-ACK adicionales más allá del primer paquete emitido. Lo que esto significa en resumen es que la amplificación en este escenario no es una serie de paquetes de 72 bytes que golpean a la víctima. En las pruebas del mundo real, se observó que el primer SYN-ACK será de 72 bytes, pero los siguientes 5-6 intentos de retransmisión omitirán esta opción TCP y resultarán en un paquete de 60 bytes. En este caso, un paquete de 72 bytes resulta en un reflejo de 432 bytes; esencialmente, el único beneficio son los 12 bytes adicionales del primer paquete frente a un reflejo sin la opción de cookie TFO.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Omisión de la cookie TFO después de la primera respuesta
Los hosts habilitados para TFO restablecen sus medidas de la cookie del apretón de manos al recibir un RST de la(s) máquina(s) víctima(s) que es(son) objetivo. Lo que esto significa es que un atacante que se dirija a máquinas reales que utilicen reflectores habilitados para TFO podría provocar de forma fiable la llegada de una serie de paquetes SYN-ACK de 72 bytes a los puntos finales de las víctimas.
El factor de amplificación es de sólo 4 bytes, asumiendo que una petición de 68 bytes del atacante resulta en un SYN-ACK de 72 bytes que llega a la víctima seguido de un paquete RST de la víctima al reflector. Si esto sucede continuamente, entonces las sesiones TCP que se inician en el reflector a través del atacante siempre resultarán en un paquete SYN-ACK que incluye los bytes adicionales que son la opción de la cookie TFO.
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) Inclusión de cookies TFO después de RST
Preocupaciones de mitigación
Mitigar un reflejo SYN-ACK puede ser complicado y debe hacerse con cuidado. Es muy fácil sobre mitigar este tipo de ataque y causar un daño autoinfligido a clientes reales y sesiones TCP a través de las redes de producción. Estas sesiones afectadas se traducirían en problemas de conectividad, rendimiento degradado y bloqueo de hosts/usuarios legítimos en sus redes. Estas medidas de sobre mitigación pueden tener efectos más largos y más impactantes que el propio ataque.
En muchos casos, la sobre mitigación de los ataques de impacto TCP también puede tener resultados inesperados para las víctimas. Durante las inundaciones SYN, por ejemplo, es habitual que cuando los servicios reales empiezan a tener problemas de conectividad, aparezca una oleada de ataques secundarios en toda la red. En estos casos, la «segunda oleada» es cualquier cosa menos eso y suele ser el resultado de clientes/usuarios reales que intentan establecer conexiones legítimas sin éxito; esto se traduce en una oleada de paquetes SYN más alta de lo normal, ya que esos clientes afectados siguen intentando retransmitir los paquetes SYN no reconocidos.
La mitigación excesiva de un ataque SYN-ACK podría causar problemas y resultados similares, especialmente si la mitigación se produce en un punto de la red en el que los clientes reales están haciendo peticiones salientes legítimas.
La solución REAL para los ataques de reflexión
Como ocurre con la mayoría de los ataques de suplantación de identidad, la solución real no es algo que esté bajo el control de una sola organización. Para abordar realmente este y otros problemas asociados con las capacidades de suplantación de identidad tenemos que mirar al IETF y a los operadores de red. El IETF ha publicado la norma BCP38, que describe cómo los operadores de red pueden identificar y evitar el enrutamiento de tráfico falsificado. A fin de cuentas, es algo que los operadores de red deben implementar y hacer cumplir si realmente esperamos ver desaparecer este tipo de ataques de suplantación/reflejo, o al menos que sean significativamente más difíciles de orquestar.
Resumen final
Los ataques SYN-ACK reflejados no son algo nuevo; en realidad son algo tan antiguo como el propio TCP. Su falta de popularidad tiene más que ver con que otros ataques reflejados basados en UDP son mucho más preocupantes e impactantes y, en general, un mejor conjunto de herramientas para los atacantes. No son un efecto secundario de una implementación defectuosa, no son un exploit, son un síntoma de que la suplantación de IP a través de Internet sigue siendo posible casi 20 años después de que se redactara y finalizara la solución propuesta para los propietarios y operadores de redes.
Dicho esto, los viejos ataques pueden seguir siendo dolorosos, y los SYN-ACK reflejados no son una excepción. Las organizaciones deberían considerar la posibilidad de analizar sus capacidades y opciones de mitigación, ya que los equipos de red pueden tener dificultades para manejar las inundaciones de tráfico de alto PPS a través de las fronteras y las redes.
Es importante destacar la posibilidad real de mitigar en exceso los ataques de esta naturaleza y garantizar que los intentos de luchar contra este tipo de ataques no den lugar a cortes autoimpuestos… una tarea que es mucho más fácil de decir que de hacer.