En criptografía y seguridad informática , un ataque de extensión de longitud es un tipo de ataque en el que un atacante puede usar Hash ( mensaje 1 ) y la longitud del mensaje 1 para calcular Hash ( mensaje 1 ‖ mensaje 2 ) para un mensaje 2 controlado por el atacante , sin necesidad de conocer el contenido del mensaje 1 . Algoritmos como MD5 , SHA-1 y la mayoría de SHA-2 que se basan en elLas construcciones Merkle-Damgård son susceptibles a este tipo de ataque. [1] [2] [3] Las versiones truncadas de SHA-2, incluidas SHA-384 y SHA256 / 512 no son susceptibles, [4] ni el algoritmo SHA-3 . [5]
Cuando una base Merkle-Damgard de hash es mal utilizado como un código de autenticación de mensajes con la construcción H ( secreto ‖ mensaje ), [1] y mensaje y la longitud de secreto es conocido, un ataque de extensión de la longitud permite que cualquiera pueda incluir información adicional al final de el mensaje y producir un hash válido sin conocer el secreto. Dado que HMAC no utiliza esta construcción, los hash de HMAC no son propensos a ataques de extensión de longitud. [6]
Explicación
Las funciones de hash vulnerables funcionan tomando el mensaje de entrada y usándolo para transformar un estado interno. Una vez que se ha procesado toda la entrada, el resumen de hash se genera generando el estado interno de la función. Es posible reconstruir el estado interno a partir del resumen de hash, que luego se puede utilizar para procesar los nuevos datos. De esta manera, se puede extender el mensaje y calcular el hash que es una firma válida para el nuevo mensaje.
Ejemplo
Se podría implementar un servidor para entregar gofres de un tipo específico a un usuario específico en una ubicación para manejar solicitudes del formato dado:
Datos originales: count = 10 & lat = 37.351 & user_id = 1 & long = -119.827 & waffle = eggoFirma original: 6d5f807e23db210bc254a28be2d6759a0f5f5d99
El servidor realizaría la solicitud dada (para entregar diez waffles del tipo eggo a la ubicación dada para el usuario "1") solo si la firma es válida para el usuario. La firma utilizada aquí es una MAC , firmada con una clave desconocida por el atacante. (Este ejemplo también es vulnerable a un ataque de reproducción , al enviar la misma solicitud y firma por segunda vez).
Es posible que un atacante modifique la solicitud, en este ejemplo, cambiando el waffle solicitado de "eggo" a "liege". Esto se puede hacer aprovechando una flexibilidad en el formato del mensaje si el contenido duplicado en la cadena de consulta da preferencia al último valor. Esta flexibilidad no indica una vulnerabilidad en el formato del mensaje, porque el formato del mensaje nunca fue diseñado para ser criptográficamente seguro en primer lugar, sin el algoritmo de firma para ayudarlo.
Datos nuevos deseados: count = 10 & lat = 37.351 & user_id = 1 & long = -119.827 & waffle = eggo & waffle = liege
Para firmar este nuevo mensaje, normalmente el atacante necesitaría saber la clave con la que se firmó el mensaje y generar una nueva firma generando una nueva MAC. Sin embargo, con un ataque de extensión de longitud, es posible introducir el hash (la firma dada arriba) en el estado de la función de hash y continuar donde se quedó la solicitud original, siempre que sepa la longitud de la solicitud original. . En esta solicitud, la longitud de la clave original era de 14 bytes, lo que podría determinarse probando solicitudes falsificadas con varias longitudes supuestas y verificando qué longitud da como resultado una solicitud que el servidor acepta como válida. [ se necesita más explicación ]
El mensaje que se introduce en la función hash a menudo se rellena , ya que muchos algoritmos solo pueden funcionar en mensajes de entrada cuyas longitudes son múltiplos de un tamaño determinado. El contenido de este relleno siempre lo especifica la función hash utilizada. El atacante debe incluir todos estos bits de relleno en su mensaje falsificado antes de que se alineen los estados internos de su mensaje y el original. Por lo tanto, el atacante construye un mensaje ligeramente diferente utilizando estas reglas de relleno:
Datos nuevos: count = 10 & lat = 37.351 & user_id = 1 & long = -119.827 & waffle = eggo \ x80 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x02 \ x28 & waffle = liege
Este mensaje incluye todo el relleno que se agregó al mensaje original dentro de la función hash antes de su carga útil (en este caso, un 0x80 seguido de un número de 0x00 y una longitud del mensaje, 0x228 = 552 = (14 + 55) * 8, que es la longitud de la clave más el mensaje original, que se adjunta al final). El atacante sabe que el estado detrás del par clave / mensaje hash para el mensaje original es idéntico al del mensaje nuevo hasta el final "&". El atacante también conoce el resumen de hash en este punto, lo que significa que conoce el estado interno de la función de hash en ese punto. Entonces es trivial inicializar un algoritmo hash en ese punto, ingresar los últimos caracteres y generar un nuevo resumen que pueda firmar su nuevo mensaje sin la clave original.
Nueva firma: 0e41270260895979317fff3898ab85668953aaa2
Al combinar la nueva firma y los nuevos datos en una nueva solicitud, el servidor verá la solicitud falsificada como una solicitud válida debido a que la firma es la misma que se habría generado si se conociera la contraseña.
Referencias
- ↑ a b Vũ, Hoàng (30 de marzo de 2012). "Ataque de extensión de longitud MD5 revisado - paz interior de Vũ" . Archivado desde el original el 29 de octubre de 2014 . Consultado el 27 de octubre de 2017 .
- ^ Duong, tailandés; Rizzo, Juliano (28 de septiembre de 2009). "Vulnerabilidad de falsificación de firmas de API de Flickr" (PDF) . Consultado el 27 de octubre de 2017 .
- ^ Meyer, Christopher (30 de julio de 2012). "Ataques de extensión de longitud de hash" . Consultado el 27 de octubre de 2017 .
- ^ Bostrom, Michael (29 de octubre de 2015). "size_t sí importa: los ataques de extensión de longitud de hash explicados" (PDF) . Consultado el 23 de noviembre de 2020 .
- ^ Equipo Keccak. "Fortalezas de Keccak - Diseño y seguridad" . Consultado el 27 de octubre de 2017 .
A diferencia de SHA-1 y SHA-2, Keccak no tiene la debilidad de extensión de longitud, por lo que no necesita la construcción anidada HMAC. En cambio, el cálculo de MAC se puede realizar simplemente anteponiendo la clave al mensaje.
- ^ Lawson, Nate (29 de octubre de 2009). "Deje de usar hashes con claves inseguras, use HMAC" . Consultado el 27 de octubre de 2017 .