stringtranslate.com

Ataque de extensión de longitud

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 utilizar 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 . Esto es problemático cuando el hash se utiliza como código de autenticación de mensajes con la construcción Hash ( secretomensaje ), [1] y mensaje y se conoce la longitud del secreto , porque un atacante puede incluir información adicional al final del mensaje y producir un hash válido sin conocer el secreto. Algoritmos como MD5 , SHA-1 y la mayoría de SHA-2 que se basan en la construcción Merkle-Damgård son susceptibles a este tipo de ataque. [1] [2] [3] Las versiones truncadas de SHA-2, incluidos SHA-384 y SHA-512/256, no son susceptibles, [4] ni lo es el algoritmo SHA-3 . [5] HMAC también utiliza una construcción diferente y por lo tanto no es vulnerable a ataques de extensión de longitud. [6] Por último, simplemente realizar Hash ( mensajesecreto ) es suficiente para no verse afectado.

Explicación

Las funciones hash vulnerables funcionan tomando el mensaje de entrada y usándolo para transformar un estado interno. Una vez procesada toda la entrada, se genera el resumen hash generando el estado interno de la función. Es posible reconstruir el estado interno a partir del resumen hash, que luego puede usarse para procesar los nuevos datos. De esta manera, se puede ampliar 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á la solicitud dada (entregar diez gofres de tipo eggo a la ubicación indicada 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 para el atacante. [nota 1]

Es posible que un atacante modifique la solicitud en este ejemplo cambiando el gofre solicitado de " eggo " a " liege ". Esto se puede hacer aprovechando la flexibilidad en el formato del mensaje si el contenido duplicado en la cadena de consulta da preferencia al último valor. Esta flexibilidad no indica un exploit 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 que lo ayude.

Nuevos datos 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 conocer 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 proporcionada anteriormente) en el estado de la función hash y continuar donde lo dejó la solicitud original, siempre y cuando se conozca 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.

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 sean múltiplos de un tamaño determinado. El contenido de este relleno siempre está especificado por la función hash utilizada. El atacante debe incluir todos estos bits de relleno en su mensaje falsificado antes de que los estados internos de su mensaje y el original se alineen. Por tanto, el atacante construye un mensaje ligeramente diferente utilizando estas reglas de relleno:

Nuevos datos: 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=lieja

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 una cantidad de 0x00 y una longitud del mensaje, 0x228 = 552 = (14+55)* 8, que es la longitud de la clave más el mensaje original, añadido al final). El atacante sabe que el estado detrás del par clave hash/mensaje del mensaje original es idéntico al del mensaje nuevo hasta el "&" final. El atacante también conoce el resumen hash en este punto, lo que significa que conoce el estado interno de la función 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.

Notas

  1. ^ Este ejemplo también es vulnerable a un ataque de repetición , al enviar la misma solicitud y firma por segunda vez.

Referencias

  1. ^ ab Vũ, Hoàng (30 de marzo de 2012). "Revisión del ataque de extensión de longitud MD5: la paz interior de Vũ". Archivado desde el original el 29 de octubre de 2014 . Consultado el 27 de octubre de 2017 .
  2. ^ Duong, tailandés; Rizzo, Juliano (28 de septiembre de 2009). "Vulnerabilidad de falsificación de firma API de Flickr" (PDF) . Consultado el 18 de marzo de 2023 .
  3. ^ Meyer, Christopher (30 de julio de 2012). "Ataques de extensión de longitud de hash" . Consultado el 27 de octubre de 2017 .
  4. ^ Bostrom, Michael (29 de octubre de 2015). "size_t sí importa: explicación de los ataques de extensión de longitud de hash" (PDF) . Consultado el 23 de noviembre de 2020 .
  5. ^ 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 la extensión de longitud, por lo que no necesita la construcción anidada HMAC. En cambio, el cálculo MAC se puede realizar simplemente anteponiendo al mensaje la clave.
  6. ^ Lawson, Nate (29 de octubre de 2009). "Deje de usar hashes con clave insegura, use HMAC" . Consultado el 27 de octubre de 2017 .