[LACNIC/Seguridad] Processing of IPv6 "atomic" fragments (Fwd: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-00.txt)

[Iván Arce]

On 2/3/12 7:24 PM, Fernando Gont wrote:
>> Creo que ambas soluciones serian viables pero que la
>> recomendada podría crear la dependencia de que otros hosts también la
>> implementen (y no tengan un contador global incrementado de a uno) para
>> evitar ataques similares al idles scan con fragmentos ipv6. 
> 
> No entendí lo de la "dependencia". 

No me sorprende porque no fue para nada claro mi comentario  :)

> Te referis a que algunas
> implementaciones podrían caer en el error de utilizar un contador
> global, o te referis a otra cosa?

Me refiero a que en algún momento dado seguramente habrá hosts que
implementen el algoritmo recomendado y hosts que sigan con la
implementación actual de un contador global. Pensando en ese escenario
se me ocurrió que ese podría dar una situación similar a la que se
utiliza para hacer un Idle Scan:

Supongamos que el host A implementa el algoritmo recomendado en la
seccion 3.2 (un contador por destino que se inicializa con un numero
pseudorandom y se incrementa en 1 por cada fragmento enviado) mientras
que el host B no implementa el algoritmo y simplemente usa un contador
global que se inicializa en 0 y se incrementa 1 enviado por cada
fragmento enviado. Si A y B estan intercambiado paquetes, es trivial
para B adivinar el proximo numero de fragmento que utilizará A en sus
comunicaciones, por tanto la "confidencialidad" de dicha información
depende de que no exista en B ningun mecanismo que un host maligno M
pueda utilizar para exfiltrar el secreto... ese es el principio básico
del que se aprovecha la técnica de idle scan.

De acuerdo a lo indicado en
http://www.ietf.org/id/draft-ietf-6man-ipv6-atomic-fragments-00.txt para
el host M es trivial forzar a que A y B se comuniquen usando fragmentos
atómicos, también es trivial forzar una comunicación entre M y B usando
datagramas fragmentados. Entonces, existe la posibilidad de que M,
utilizando su comunicación con B como oraculo infiera el proximo numero
de frag ID que utilizará A para comunicarse con B ? No lo sé pero a
priori parecería que si, cosa que no sucedería si el algoritmo
recomendado fuera de elegir un número pseudorandom por cada fragmento.

> 
> Otra alternativa posible es generar los I-Ds asi:
> 
> Frag_ID = F(src IP, dst IP, secret1)  +
>           counter[G(src IP, dst IP, secret2)]
> 
> Donde:
> F(): hash
> G(): hash
> counter[]: array de contadores, inicializados al bootear con valores
> aleatorios.
> 
> 
> Esta alternativa es un "termino medio" entre "un contador global" y "un
> contador por destino".

Otra alternativa es usar un PRNG global y para cada destino guardar los
últimos "n" frag IDs usados para asegurarse de no tener colisiones, con
0  <= n <= K. El caso más simple es n := 0

Por supuesto que cada una de estas opciones tiene distinto impacto sobre
la eficiencia del stack del host que las implemente y si la degradación
de performace es importante entonces se abre la puerta a otro tipo de
ataque de denegación de servicio porque aparentemente forzar la
fragmentación es trivial...

>>
>>> The number and content of the headers preceding the Fragment
>>> header of different fragments of the same original packet may
>>> differ.  Whatever headers are present, preceding the Fragment
>>> header in each fragment packet, are processed when the packets
>>> arrive, prior to queueing the fragments for reassembly.  Only
>>> those headers in the Offset zero fragment packet are retained in
>>> the reassembled packet.
>>>
>>> The Next Header values in the Fragment headers of different
>>> fragments of the same original packet may differ.  Only the value
>>> from the Offset zero fragment packet is used for reassembly.
>>
>> Parecería que eso abre la puerta a la "inserción y/o solapamiento de
>> headers" que incluso se procesarían silenciosamente ?! No entiendo del
>> todo las implicancias de eso en un escenario en el que se usan Fragment
>> IDs predecibles pero sospecho que no son buenas...
> 
> Coincido. *En principio* ("en teoría"), al menos desde la parte
> fragmentada en adelante esto se evitaría gracias a lo especificado por
> RFC 5722. 

Claro pero si se aplica tu recomendación para procesar fragmentos
atómicos como si fueran datagramas no fragmentados, el solapamiento
desde la parte fragmentada en adelante no se detectaría mas porque el
datagrama atómico nunca entra en la cola para el reensamblado.

> En lo que hace a la parte anterior al fragmento... dejame
> pensarlo un poco, ya que no habia evaluado el tema.

Bueno, a eso es a lo que me refiero con inserción de headers. La parte
anterior al fragmento puede incluir headers que se procesarían antes de
tratar de reensamblar todos los fragmentos, despues cuando los
fragmentos se reensamblan y se determina que hay solapamiento se tira
todo a la basura...y sin embargo los headers insertados ya fueron
procesados por el stack. El escenario en el que estaba pensando es uno
en el que los ID de fragmento son predecibles por un tercero y por tanto
spoofeando datagramas fragmentados se podrían insertar headers en las
comunicaciones entre dos hosts.


> 
> * Intencionalmente* el I-D no menciona con detalles el siguiente escenario:
>                Conexion TCP
>            A <--------------> B
> 
> 
> Un atacante (en cualquier otro punto de la red) podria spoofear un
> ICMPv6 "Packet Too Big" a A, con un "MTU" < 1280. Tal como lo menciona
> RFC 2460, "A" deberia empezar a enviar todos sus paquetes con un frag
> header (serían "ataomic fragments"). Si los Frag ID utilizados por "A"
> son predecibles, entonces el atacante podria enviar fragmentos
> spoofeados a "B", de modo que colisionen con los fragmento legitimos
> enviados por "A". Resultado: DoS.
> 

Bueno, es precisamente en ese escenario que yo estaba pensando si
existiría un ataque con implicancias mayores que denegación de servicio.
Cualquier header que modifique una máquina de estados en el stack de
destino y cuyo procesamiento no se idempotente es candidato a ser usando
en un ataque con implicacias mayores que DoS.

> La propuesta en cuestion previene dicho ataque, ya que al ser los
> paquetes legitimos de tipo "atomic fragments", nunca se mezclarian con
> los fragmentos maliciosos enviados por el atacante.

Que nunca se mezclen no significa que no persista el potencial de
problemas...

> 
>>> Additionally, any fragments already queued with the
>>> same set {IPV6 Source Address, IPv6 Destination Address, Fragment
>>> Identification} should not be discarded upon receipt of the
>>> "colliding" IPv6 atomic fragment, since IPv6 atomic fragments do
>>>  not really interfere with "normal" fragmented traffic.
>>

Esto no me queda claro, en principio se me ocurre que que entre A y B no
pueden existir 2 tipos de comunicaciones simultaneas, una con fragmentos
atómicos y otra con fragmentos "normales"  toda usando el mismo frag ID.
Es más el RFC5722 prohibe que un host cree fragmentos solapados y la
comunicación con fragmentos normales necesariamente tiene un fragmento
con Offset=0 que se solaparía con el fragmento atómico si este estuviera
en la cola de reemsamblado...
La situación en la que existen al mismo tiempo dos datagramas con el
mismo frag ID con offset=0, uno con MF=0 y otro con MF=1 esta prohibida
por el RFC 5722...

Mas alla de eso, me parece que no se puede atender el problema de los
fragmentos atómicos sin tener resuelto el problemas de los ID de
fragmento predecibles porque sino cualquier algoritmo a recomendar
también tiene que ser analizado desde el punto de vista de un atacante
con la posibilidad de insertar datagramas con Frag ID válidos en
cualquier momento.

>> La posibilidad de adivinar un fragment ID y mandar un paquete spoofeado
>> con un header espurio invalida la presunción de que todos los headers se
>> procesan en orden no?
> 
> Me perdi en esta ultima...
> 
> Adivines o no el Frag ID, todo lo que se encuentra previo al Frag header
> va a ser procesado por el destinatario. 


Claro, pero si el Frag Id es predecible y después encontrás fragmentos
solapados con Frag ID válido SABES que estas sufriendo un ataque y que
no deberías haber procesado headers que ya procesaste. Si uno de esos
headers modificaba la forma en que deberías procesar los siguientes
(motivo por el cual el RFC requiere que se procesen en orden) ahora ya
es demasiado tarde.

-ivan