Las cookies cifradas son vulnerables al relleno de ataques de Oracle

La respuesta corta es que no puede confiar en el cifrado para garantizar la integridad de un mensaje. Consulte aquí, por ejemplo.

Para demostrar por qué esa afirmación general también es cierta para el ejemplo específico de esta pregunta, veamos cómo un atacante puede modificar un mensaje cifrado. En aras de la simplicidad, voy a suponer que está utilizando el cifrado AES-CBC. Consideremos la siguiente cadena:

  

{"Name":"Ryan Archer","Crime":"First Degree Murder","Judge 1":"Afred E Newman Jr","Verdict":"Not Guilty"}

Cuando un AES-CBC cifra la cadena anterior, se cifrará en los siguientes bloques de 16 bytes:

Block 0:   "Name":"Ryan Arc
Block 1:   her","Crime":"Fi
Block 2:   rst Degree Murde
Block 3:   r","Judge 1":"Al
Block 4:   fred E Newman Jr
Block 5:   ","Verdict":"Not
Block 6:   Guilty" 

Y cada bloque de la cadena cifrada se corresponderá con el mismo bloque de la cadena de texto claro original.

Ahora aquí está una característica interesante de CBC. Incluso si no conoce la clave de cifrado, puede modificar el texto cifrado de manera que cuando se descifre, el texto claro se modificará de una manera específica.

Tomemos el ejemplo de arriba. Si alguien estuviera en AES-CBC cifrara esta cadena con alguna clave y no conozco esta clave, si yo XORO los últimos 3 bytes del bloque 4 del texto cifrado con la cadena "No", el impacto en el texto descifrado sería ser de la siguiente manera:

• El bloque 4 se corrompería de forma aleatoria desconocida.
• Los últimos 3 bytes del bloque 5 se XORedarán con la cadena "No"

Entonces, después de descifrar, la cadena se leería de la siguiente manera:

Block 0:   "Name":"Ryan Arc
Block 1:   her","Crime":"Fi
Block 2:   rst Degree Murde
Block 3:   r","Judge 1":"Al
Block 4:   %$#$%@#%$@#%#%#$ (random garbage bytes)
Block 5:   ","Verdict":"
Block 6:   Guilty" 

Y se leería como la siguiente cadena json válida:

  

"Name":"Ryan Archer","Crime":"First Degree Murder","Judge 1":"Al%$#$%@#%$@#%#%#$","Verdict":" Guilty"

El nombre del juez está corrompido al azar, pero el atacante ha modificado con éxito una parte crítica del mensaje: ¡Ryan Archer ahora es culpable de asesinato!

Por supuesto, no todas las cadenas están estructuradas de tal manera y es posible que los bytes aleatorios en el bloque 4 dañen la cadena de modo que ya no sea una cadena json válida. Pero un atacante puede intentar este ataque varias veces con varias modificaciones de la cadena cifrada y, tarde o temprano, obtendrá una cadena json válida.

  

¿Es necesario firmar o fallará una cadena encriptada modificada?   ¿descifrar?

En el mundo de la criptografía, un mensaje modificado se denomina mensaje manipulado. El cifrado por sí solo no proporciona protección contra la manipulación, pero los cifrados en bloque no se usan solos. Los cifrados de bloque se utilizan en diferentes modos, p. ECB, CBC, CTR, GCM, etc. Los diferentes modos tienen diferentes propiedades, algunos de ellos brindan protección contra la manipulación (a.k.a. Autenticated Encryption, es decir, GCM) y otros no.

Si está utilizando un modo de cifrado autenticado, un mensaje manipulado no podrá descifrar. Pero, si está utilizando otros modos como CBC o CTR (estos son los más difundidos en mi experiencia), un mensaje manipulado descifrará felizmente a menos que exista un error de relleno

  

Si no resulta en un json válido que pueda ser analizado en una sesión   estará vacío de la misma manera que lo haría con un inválido   firma.

Esto dependerá de cómo su aplicación maneje un json no válido, y aquí es donde puede aparecer un oráculo de relleno.

  

Mi entendimiento es que los ataques de oráculo de relleno funcionan obteniendo   retroalimentación del servidor. Sería una cadena json vacía cifrada   suficiente?

Se produce un ataque de oráculo de relleno cuando el atacante envía un mensaje alterado y puede distinguir si el relleno es correcto o no. Y esta es la razón por la que dije anteriormente que la forma en que su aplicación maneja un JSON no válido puede derivar en un oráculo de relleno

Imagine que un atacante envía un mensaje manipulado con un relleno incorrecto, su aplicación intentará descifrar el mensaje pero se lanzará una excepción de relleno incorrecta. Después de que el atacante manipule el mensaje de nuevo, pero esta vez es capaz de forjar un relleno correcto, su aplicación descifrará correctamente el mensaje, pero el contenido será JSON no válido, la aplicación intentará analizar el JSON no válido y emitirá un error. no se puede analizar

Si el atacante puede distinguir ambos escenarios porque el estado HTTP devuelto es diferente, o un seguimiento de pila muestra los diferentes mensajes de error, o simplemente cronometrando el tiempo de respuesta. Luego, el atacante tiene un oráculo de relleno y puede recuperar el texto sin formato de la cookie

Para evitar esto, siempre debe proporcionar el mismo mensaje de error cuando el mensaje no se puede descifrar y el mensaje se descifra pero el contenido no es válido. Además, debe asegurarse de que ambos escenarios requieran el mismo tiempo para responder.

OMI, el mejor enfoque sería utilizar un modo de cifrado autenticado que le ofrezca cifrado y firma juntos y deje que el marco de cifrado / biblioteca lo maneje

Por cierto, mencioné un modo de cifrado que nunca debería usarse. Es el BCE, si está utilizando este modo (algunas bibliotecas lo tienen por defecto) cámbielo por es un modo débil

  

¿Es necesario firmar o fallará una cadena encriptada modificada?   ¿descifrar?

La forma clásica (y más rápida) de autenticar su mensaje es usar MAC . Debe usar la firma si necesita no repudiar (lo que probablemente no necesite).

  

Si no resulta en un json válido que pueda ser analizado en una sesión   estará vacío de la misma manera que lo haría con un inválido   firma. los ataques oraculares de [...] relleno funcionan al obtener retroalimentación del   servidor. ¿Sería suficiente una cadena json vacía cifrada?

En relación con el ataque de oráculo de relleno:

AES es un cifrado de bloque. No hay relleno en AES. Si su implementación utiliza un relleno vulnerable (como hace PKCS7), el ataque de Oracle podría ser posible en teoría. Sin embargo, AES es un cifrado CBC (que comienza con un desorden aleatorio), lo que significa que el mismo texto simple dará como resultado un texto cifrado diferente cada vez. Sería muy difícil para el atacante suponer que ha devuelto una cadena json vacía.

Sin embargo, podría ser posible detectar el error de relleno por otros medios. Si está utilizando diferentes códigos de error HTTP en su implementación REST, o si mide el tiempo de respuesta del servidor. MAC te ayudará aquí, ya que el atacante no puede alterar tu mensaje. El mensaje se eliminará de inmediato si el MAC no es válido y el descifrado nunca tiene lugar.

Es posible que desee incluir un tiempo aleatorio en la respuesta para que sea más difícil perfilar sus respuestas y / o devolver el mismo código http para que todo aumente la seguridad, pero creo que esto último causaría más problemas que la ganancia. Por supuesto, no debes revelar que has detectado un error de relleno.