Attaque par extension de longueur

En cryptographie et en sécurité informatique , une attaque par extension de longueur est un type d' attaque où un attaquant peut utiliser Hash ( message ₁ ) et la longueur du message ₁ pour calculer Hash ( message ₁ ‖ message ₂ ) pour un message ₂ contrôlé par l'attaquant , sans avoir besoin de connaître le contenu du message _1. Cela est problématique lorsque le hachage est utilisé comme code d'authentification de message avec la construction Hash ( secret ‖ message ), et message et que la longueur du secret est connue, car un attaquant peut inclure des informations supplémentaires à la fin du message et produire un hachage valide sans connaître le secret. Les algorithmes comme MD5 , SHA-1 et la plupart des SHA-2 qui sont basés sur la construction Merkle–Damgård sont sensibles à ce type d'attaque. Les versions tronquées de SHA-2, y compris SHA-384 et SHA-512/256 ne sont pas sensibles, pas plus que l' algorithme SHA-3 . HMAC utilise également une construction différente et n'est donc pas vulnérable aux attaques par extension de longueur. Enfin, il suffit d'effectuer un hachage ( message ‖ secret ) pour ne pas être affecté.

Les fonctions de hachage vulnérables fonctionnent en prenant le message d'entrée et en l'utilisant pour transformer un état interne. Une fois que toutes les entrées ont été traitées, le condensé de hachage est généré en affichant l'état interne de la fonction. Il est possible de reconstruire l'état interne à partir du condensé de hachage, qui peut ensuite être utilisé pour traiter les nouvelles données. De cette manière, on peut étendre le message et calculer le hachage qui constitue une signature valide pour le nouveau message.

Un serveur permettant de livrer des gaufres d'un type spécifié à un utilisateur spécifique à un endroit donné pourrait être mis en œuvre pour gérer les requêtes du format donné :

Données originales : count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo Signature originale : 6d5f807e23db210bc254a28be2d6759a0f5f5d99 

Le serveur exécuterait la requête donnée (pour livrer dix gaufres de type eggo à l'emplacement donné pour l'utilisateur « 1 ») seulement si la signature est valide pour l'utilisateur. La signature utilisée ici est un MAC , signé avec une clé inconnue de l'attaquant.

Il est possible pour un attaquant de modifier la requête dans cet exemple en changeant la gaufre demandée de « eggo » à « liege ». Cela peut être fait en tirant parti d'une flexibilité dans le format du message si le contenu dupliqué dans la chaîne de requête donne la préférence à cette dernière valeur. Cette flexibilité n'indique pas une exploitation du format du message, car le format du message n'a jamais été conçu pour être sécurisé cryptographiquement en premier lieu, sans l'algorithme de signature pour l'aider.

Nouvelles données souhaitées : count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo &waffle=liege

Pour signer ce nouveau message, l'attaquant doit généralement connaître la clé avec laquelle le message a été signé et générer une nouvelle signature en générant un nouveau MAC. Cependant, avec une attaque par extension de longueur, il est possible d'introduire le hachage (la signature donnée ci-dessus) dans l'état de la fonction de hachage et de continuer là où la requête d'origine s'était arrêtée, tant que la longueur de la requête d'origine est connue. Dans cette requête, la longueur de la clé d'origine était de 14 octets, ce qui pourrait être déterminé en essayant des requêtes falsifiées avec différentes longueurs supposées et en vérifiant quelle longueur aboutit à une requête que le serveur accepte comme valide.

Le message tel qu'il est introduit dans la fonction de hachage est souvent complété , car de nombreux algorithmes ne peuvent fonctionner que sur des messages d'entrée dont la longueur est un multiple d'une taille donnée. Le contenu de ce remplissage est toujours spécifié par la fonction de hachage utilisée. L'attaquant doit inclure tous ces bits de remplissage dans son message falsifié avant que les états internes de son message et de l'original ne s'alignent. Ainsi, l'attaquant construit un message légèrement différent en utilisant ces règles de remplissage :

Nouvelles données : 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\x00\x00\x00\x00 
\x00\x00\x00\x02\x28&waffle=liège

Ce message inclut tout le remplissage qui a été ajouté au message d'origine à l'intérieur de la fonction de hachage avant leur charge utile (dans ce cas, un 0x80 suivi d'un certain nombre de 0x00 et d'une longueur de message, 0x228 = 552 = (14+55)*8, qui est la longueur de la clé plus le message d'origine, ajouté à la fin). L'attaquant sait que l'état derrière la paire clé/message hachée pour le message d'origine est identique à celui du nouveau message jusqu'au "&" final. L'attaquant connaît également le condensé de hachage à ce stade, ce qui signifie qu'il connaît l'état interne de la fonction de hachage à ce stade. Il est alors trivial d'initialiser un algorithme de hachage à ce stade, de saisir les derniers caractères et de générer un nouveau condensé qui peut signer son nouveau message sans la clé d'origine.

Nouvelle signature : 0e41270260895979317fff3898ab85668953aaa2 

En combinant la nouvelle signature et les nouvelles données dans une nouvelle demande, le serveur verra la demande falsifiée comme une demande valide car la signature est la même que celle qui aurait été générée si le mot de passe était connu.