Resumen

  • RFC 3128 unió el ataque de fragmento diminuto con el de fragmentos solapados para alterar bytes de puerto que un filtro ya creía haber autorizado.
  • La defensa añadió una condición de longitud: el fragmento TCP con desplazamiento cero debe contener la cabecera mínima completa, además de mantenerse el rechazo del desplazamiento uno.
  • El resultado dependía de la política y del algoritmo de reensamblaje; superar el filtro no demostraba una conexión completa ni una vulnerabilidad presente en todos los sistemas.

La escena parecía sencilla. Una red permitía conexiones entrantes hacia un servicio concreto y prohibía que otros puertos, destinados a conexiones salientes, recibieran nuevas sesiones. El filtro miraba el primer fragmento, encontraba el puerto autorizado y dejaba avanzar el datagrama.

Sin embargo, el puerto observado no tenía por qué ser el puerto definitivo.

El ejemplo de RFC 3128 empezaba con un fragmento de desplazamiento cero y al menos dieciséis bytes de cabecera TCP. Era una representación bastante completa: puerto de origen, puerto de destino, número de secuencia y los campos posteriores necesarios para reconocer el inicio de una conexión. Nada obligaba al filtro a rechazarlo.

Después llegaba otro fragmento también situado en cero, pero de solo ocho bytes de transporte. Al cubrir otra vez los primeros bytes podía sustituir los puertos y el número de secuencia, sin incluir los indicadores TCP que aparecían más adelante. Un tercer fragmento completaba el conjunto. Si la implementación del host daba prioridad a los bytes del solapamiento corto, la cabecera reconstruida conservaba parte de la primera versión y adoptaba de la segunda un puerto distinto.

La seguridad se había decidido sobre una vista y ejecutado sobre otra.

Ese mecanismo respondía a una defensa previa. RFC 1858 había descrito los fragmentos diminutos, que ocultan campos de transporte fuera de la primera pieza, y los fragmentos solapados, que explotan diferencias en la elección de bytes repetidos. Su Método Indirecto bloqueaba fragmentos TCP con desplazamiento uno. Como los desplazamientos IPv4 se cuentan en unidades de ocho bytes, esa regla impedía una forma conocida de colocar los indicadores TCP justo después de una primera porción mínima.

RFC 3128 descubrió que el atacante no necesitaba empezar el reemplazo en uno. Podía reiniciar en cero. El primer fragmento seguía mostrando una cabecera autorizable; el segundo volvía a escribir únicamente la parte temprana. Dos ataques que por separado parecían contenidos producían juntos una brecha.

No era un truco puramente sintáctico. Exponía una división de control. El emisor decidía dónde cortar y qué bytes repetir. El filtro interpretaba lo visible en el perímetro. La pila IP del destino elegía cómo combinar los intervalos. TCP determinaba si el segmento resultante era válido. El servicio decidía si aceptaba una conexión. Cada actor controlaba una etapa, y ninguna etapa podía demostrar por sí sola el efecto final.

Por eso el RFC limitó cuidadosamente su afirmación. El resultado dependía de la implementación exacta del reensamblaje. IPv4 había normalizado la posibilidad de recibir piezas desordenadas y RFC 815 ofrecía un algoritmo práctico para rellenar huecos y gestionar superposiciones. Pero no existía una garantía de que todos los equipos del camino resolvieran cada byte repetido del mismo modo.

La corrección fue precisa. Si el protocolo es TCP, el desplazamiento vale cero y la longitud de transporte es inferior al mínimo de una cabecera completa, el filtro debe descartar el paquete. Además, debe seguir descartando el desplazamiento uno. Así, una segunda pieza corta que vuelve al inicio ya no puede presentarse como base suficiente para una decisión de acceso.

Esta regla convierte una suposición en un invariante. Antes, el filtro esperaba que el primer fragmento contuviera lo importante. Después, debía comprobar que todos los campos mínimos usados por la política estaban presentes. La distinción importa porque las listas de control describen puertos, indicadores y direcciones, no fragmentos abstractos.

La corrección tampoco fue una promesa de seguridad total. No definió una única política de solapamiento para IPv4. No demostró que todos los productos implementaran el Método Indirecto. No probó que una secuencia admitida completara el saludo TCP o llegara a una aplicación. El RFC describió una capacidad de evasión bajo condiciones concretas, no un inventario de compromisos.

La evolución posterior endureció algunos límites. RFC 5722 ordenó descartar datagramas IPv6 con fragmentos solapados. RFC 7112 exigió que el primer fragmento IPv6 incluyera toda la cadena de cabeceras. RFC 6274 revisó las amenazas heredadas de IPv4 y RFC 8900 explicó por qué la fragmentación seguía siendo frágil en redes llenas de equipos intermedios con comportamientos distintos.

Esos documentos posteriores no prueban la explotación de RFC 3128 ni permiten trasladar reglas IPv6 a todo el pasado de IPv4. Sí muestran la persistencia del problema arquitectónico: un control es débil cuando valida una forma intermedia y deja que otra autoridad cambie después los campos que justificaron la autorización.

La misma estructura aparece en otros niveles. Un proxy y un servidor pueden discrepar al normalizar una ruta. Un sistema de detección puede decodificar una entrada una vez y la aplicación hacerlo de nuevo. Una pasarela de esquema puede validar un objeto antes de que una biblioteca combine campos duplicados de otra manera. No son el mismo ataque, pero comparten el fallo de autoridad: el objeto de la regla no es estable.

La lección histórica de RFC 3128 es, por tanto, probatoria. El registro del filtro acredita lo que el filtro vio. No acredita automáticamente qué bytes recibió TCP, si una aplicación escuchaba o si hubo daño. Reconstruir el resultado exige observar el conjunto de fragmentos y la política real del host. Una autorización parcial no debe narrarse como un efecto completo.

Fuentes