L'attaque d'extension de longueur est une attaque liée aux propriétés de certains types de fonctions de hachage (telles que MD5, SHA-1 et SHA-2). En termes simples, cette attaque exploite le fait qu'en connaissant H(message) et la longueur du message, nous pouvons facilement calculer H(message || padding || extension) sans connaître le message lui-même. Où "||" représente la connexion, "padding" est ajouté conformément aux dispositions de la fonction de hachage.
En effet, ces fonctions de hachage utilisent une structure Merkle-Damgård, qui découpe l'entrée en blocs, et le hachage de chaque bloc dépend du hachage du bloc précédent. Cela signifie qu'une fois que nous avons calculé le hachage d'un certain message, nous disposons d'un état à partir duquel nous pouvons commencer et ajouter d'autres blocs.
Un mode de vérification côté serveur
Pour faciliter la description des scénarios de vulnérabilité, nous supposons d'abord qu'il existe un tel mode d'authentification côté serveur, c'est-à-dire que lorsqu'un utilisateur tente de se connecter, le serveur transmettra un hachage spécifique basé sur l'ID, le nom et un identifiant de l'utilisateur. Clé de 30 bits connue uniquement du serveur. L'algorithme génère une valeur de hachage et l'envoie au client. Par la suite, lorsque le client tente d'accéder à certaines interfaces, comme l'interface de modification des autorisations des utilisateurs, le serveur régénérera un hachage pour vérification basé sur l'ID du rôle, le nom du rôle, les autorisations du rôle et la même clé de 30 bits du front- fin du POST. Si le hachage téléchargé est cohérent avec le hachage généré par le serveur, la vérification est considérée comme réussie et les nouvelles autorisations de rôle seront écrites dans la base de données.
Pour faciliter la compréhension, voici quelques codes simples rédigés selon la description à titre d'exemple :
Penser au-delà de l'autorité
En raison des failles du mode de vérification, l'attaquant peut contourner la vérification des autorisations en reconstruisant la demande de transaction sans connaître la SecretKey. L'idée centrale d'une attaque non autorisée est d'exploiter les caractéristiques des attaques par extension de longueur. L'attaquant doit d'abord obtenir la valeur de hachage d'origine et calculer la longueur des données d'origine grâce à un algorithme itératif simple. Une fois ces informations obtenues, des paramètres supplémentaires non autorisés peuvent être ajoutés aux données d'origine et le même algorithme de hachage peut être utilisé pour générer des hachages malveillants.
Principe d'attaque par extension de longueur
L'attaque d'extension de longueur se produit en raison du mécanisme interne d'une partie de la fonction de hachage. Ces fonctions divisent d'abord les données en morceaux de longueur fixe avant de traiter les données d'entrée, puis complètent à la fin de chaque morceau pour répondre à des exigences spécifiques. Cette conception permet à un attaquant de construire une nouvelle valeur de hachage efficace en complétant et en ajoutant de nouvelles données tout en connaissant la valeur de hachage et la longueur du message d'origine.
Prenons l'exemple de SHA-256, qui fonctionne sur des blocs de 512 bits. Pour les données dont la longueur n'est pas un multiple de 512 bits, un remplissage est requis. Ses règles de remplissage sont les suivantes :
Ajoutez un bit "1" à la fin des données ;
Ajoutez un certain nombre de bits "0" pour que la longueur des données modulo 512 soit égale à 448 (pour plus de détails, voir [1] ）；
Ajoutez un bloc de 64 bits à la fin, indiquant la longueur des données d'origine.
En bref, un "1" suivi de m "0", plus un entier de 64 ou 128 bits, est ajouté à la fin du message pour produire un message de remplissage d'une longueur de 512*n. L'entier ajouté correspond à la longueur du message d'origine. Ensuite, le message complété sera haché en n blocs de 512 bits.
Méthode de construction
Dans cet exemple, nous utiliserons le code mentionné dans l'image ci-dessus comme scénario spécifique, où la chaîne de données est data="user_id=1&user_name=aa" et la clé est SecretKey="Length_extension\ _attack\ _secrète". Le serveur analysera le champ de données dans les données téléchargées et analysera les paramètres requis user_id et user_name via le séparateur &. S'il existe un champ de rôle, le serveur obtiendra également la valeur de ce champ. Le serveur hachera ensuite tous les champs avec la SecretKey et comparera avec le hachage de vérification téléchargé. Si les valeurs de hachage sont cohérentes, le paramètre est considéré comme conforme aux règles et utilisé directement.
Tout d'abord, nous nous connectons à l'interface loginHandler pour obtenir la valeur de hachage hash="37d310d3465506486431fb2c2eb163f0f470479703f66dc9e5fdead8a3390c68" générée à l'aide de SHA-256 en fonction des données et de SecretKey.
Ensuite, nous examinerons la difficulté de craquer. En prenant notre situation de test comme exemple, selon le principe de l'attaque par extension de longueur, tant que nous connaissons la longueur de H(message) et du message, nous pouvons ajouter de nouvelles données via une attaque par extension de longueur. Le message d'origine = SecretKey + data, maintenant nous avons déjà H(message) en main. Il suffit de connaître la longueur du message pour construire une nouvelle valeur de hachage. Puisque SecretKey est une clé de 30 bits, seules 30 itérations sont nécessaires pour connaître la longueur du message réel. Par conséquent, nous pouvons facilement construire une nouvelle valeur de hachage. Puisque nous devons utiliser les autorisations d'administrateur, nous devons intégrer le champ malveillant "&role=admin" dans les données d'origine.
Nous pouvons utiliser la fonctionnalité d'attaque par extension de longueur pour ajouter de nouvelles données et générer une nouvelle valeur de hachage sans connaître la SecretKey. Une bibliothèque qui implémente déjà cette fonctionnalité est utilisée ici [2] pour terminer le test. Utilisez ensuite l'outil pour générer une nouvelle valeur de hachage.
Étant donné que la vérification de l'interface de adminActionHandler vérifie le hachage en fonction de l'utilisateur_id, de l'utilisateur_name et du rôle téléchargés, les données que nous avons téléchargées à ce moment sont user_id=1, user_name=aa\x80\x00\x00\x00. \ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x70 et role=admin, comme indiqué dans la figure suivante :
La valeur de hachage est 84ae4ae437eeabf3bd8a26294392770b86f64a81998194156ac003d58a21acd0. Après cela, vous pouvez appeler l'interface adminActionHandler. Après avoir reçu les données, le serveur comparera le hachage téléchargé avec sha256 (SecretKey + fakeData). Après avoir réussi la vérification, certaines opérations sensibles seront effectuées. De cette façon, nous avons réussi à contourner la vérification côté serveur en utilisant l'attaque par extension de longueur et à réaliser l'opération non autorisée.
Autres scénarios d'attaque possibles
1. Vérification de l'intégrité du fichier : Si l'intégrité du fichier est vérifiée en concaténant la clé et le contenu du fichier, puis en le hachant, un attaquant peut alors développer le fichier et générer un hachage valide, contournant ainsi les contrôles d'intégrité ;
2. Sécurité des applications Web : Dans les applications Web, si une fonction de hachage susceptible d'être attaquée par extension de longueur est utilisée pour vérifier les données soumises par l'utilisateur, les attaquants peuvent en profiter pour soumettre des données malveillantes ;
3. Signatures numériques : Dans certains schémas de signature numérique, si la signature est générée en concaténant la clé privée et le message, puis en la hachant, l'attaquant peut alors développer le message et générer une signature valide ;
4. Stockage du mot de passe : Bien que cela ne soit pas courant, si un mot de passe est stocké en concaténant une clé (par exemple un sel) et un mot de passe, puis en le hachant, un attaquant peut alors tenter de le déchiffrer à l'aide d'un mot de passe d'attaque par extension de longueur.
Comment prévenir
1. Choisissez une fonction de hachage qui n'est pas sensible aux attaques par extension de longueur, comme SHA-3 ;
**2. Utilisez HMAC : **HMAC nécessite une clé et un message en entrée. Le résultat de sortie dépend à la fois de la clé et du message, de sorte que l'attaquant ne peut pas effectuer une attaque d'extension de longueur sans connaître la clé. ;
**3. Renforcez la vérification de l'autorité : **Ajoutez des étapes supplémentaires de vérification de l'autorité côté serveur, telles que l'utilisation de l'authentification multifacteur.
Voici les caractéristiques de certains algorithmes de hachage couramment utilisés :
Une défense efficace contre les attaques par extension de longueur consiste à utiliser des fonctions de hachage qui sont immunisées contre de telles attaques, telles que SHA-3 et BLAKE2. De plus, il peut également être protégé via la structure HMAC (code d'authentification de message haché à clé). Ces mesures peuvent améliorer efficacement la sécurité du système et garantir l’intégrité des données et la stabilité des applications.
Lien de référence :
[1]
[2]
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Dangers cachés des fonctions de hachage : attaques par extension de longueur et risques de sécurité côté serveur
Introduction
L'attaque d'extension de longueur est une attaque liée aux propriétés de certains types de fonctions de hachage (telles que MD5, SHA-1 et SHA-2). En termes simples, cette attaque exploite le fait qu'en connaissant H(message) et la longueur du message, nous pouvons facilement calculer H(message || padding || extension) sans connaître le message lui-même. Où "||" représente la connexion, "padding" est ajouté conformément aux dispositions de la fonction de hachage.
En effet, ces fonctions de hachage utilisent une structure Merkle-Damgård, qui découpe l'entrée en blocs, et le hachage de chaque bloc dépend du hachage du bloc précédent. Cela signifie qu'une fois que nous avons calculé le hachage d'un certain message, nous disposons d'un état à partir duquel nous pouvons commencer et ajouter d'autres blocs.
Un mode de vérification côté serveur
Pour faciliter la description des scénarios de vulnérabilité, nous supposons d'abord qu'il existe un tel mode d'authentification côté serveur, c'est-à-dire que lorsqu'un utilisateur tente de se connecter, le serveur transmettra un hachage spécifique basé sur l'ID, le nom et un identifiant de l'utilisateur. Clé de 30 bits connue uniquement du serveur. L'algorithme génère une valeur de hachage et l'envoie au client. Par la suite, lorsque le client tente d'accéder à certaines interfaces, comme l'interface de modification des autorisations des utilisateurs, le serveur régénérera un hachage pour vérification basé sur l'ID du rôle, le nom du rôle, les autorisations du rôle et la même clé de 30 bits du front- fin du POST. Si le hachage téléchargé est cohérent avec le hachage généré par le serveur, la vérification est considérée comme réussie et les nouvelles autorisations de rôle seront écrites dans la base de données.
Pour faciliter la compréhension, voici quelques codes simples rédigés selon la description à titre d'exemple :
Penser au-delà de l'autorité
En raison des failles du mode de vérification, l'attaquant peut contourner la vérification des autorisations en reconstruisant la demande de transaction sans connaître la SecretKey. L'idée centrale d'une attaque non autorisée est d'exploiter les caractéristiques des attaques par extension de longueur. L'attaquant doit d'abord obtenir la valeur de hachage d'origine et calculer la longueur des données d'origine grâce à un algorithme itératif simple. Une fois ces informations obtenues, des paramètres supplémentaires non autorisés peuvent être ajoutés aux données d'origine et le même algorithme de hachage peut être utilisé pour générer des hachages malveillants.
Principe d'attaque par extension de longueur
L'attaque d'extension de longueur se produit en raison du mécanisme interne d'une partie de la fonction de hachage. Ces fonctions divisent d'abord les données en morceaux de longueur fixe avant de traiter les données d'entrée, puis complètent à la fin de chaque morceau pour répondre à des exigences spécifiques. Cette conception permet à un attaquant de construire une nouvelle valeur de hachage efficace en complétant et en ajoutant de nouvelles données tout en connaissant la valeur de hachage et la longueur du message d'origine.
Prenons l'exemple de SHA-256, qui fonctionne sur des blocs de 512 bits. Pour les données dont la longueur n'est pas un multiple de 512 bits, un remplissage est requis. Ses règles de remplissage sont les suivantes :
Ajoutez un bit "1" à la fin des données ;
Ajoutez un certain nombre de bits "0" pour que la longueur des données modulo 512 soit égale à 448 (pour plus de détails, voir [1] ）；
Ajoutez un bloc de 64 bits à la fin, indiquant la longueur des données d'origine.
En bref, un "1" suivi de m "0", plus un entier de 64 ou 128 bits, est ajouté à la fin du message pour produire un message de remplissage d'une longueur de 512*n. L'entier ajouté correspond à la longueur du message d'origine. Ensuite, le message complété sera haché en n blocs de 512 bits.
Méthode de construction
Dans cet exemple, nous utiliserons le code mentionné dans l'image ci-dessus comme scénario spécifique, où la chaîne de données est data="user_id=1&user_name=aa" et la clé est SecretKey="Length_extension\ _attack\ _secrète". Le serveur analysera le champ de données dans les données téléchargées et analysera les paramètres requis user_id et user_name via le séparateur &. S'il existe un champ de rôle, le serveur obtiendra également la valeur de ce champ. Le serveur hachera ensuite tous les champs avec la SecretKey et comparera avec le hachage de vérification téléchargé. Si les valeurs de hachage sont cohérentes, le paramètre est considéré comme conforme aux règles et utilisé directement.
Tout d'abord, nous nous connectons à l'interface loginHandler pour obtenir la valeur de hachage hash="37d310d3465506486431fb2c2eb163f0f470479703f66dc9e5fdead8a3390c68" générée à l'aide de SHA-256 en fonction des données et de SecretKey.
Ensuite, nous examinerons la difficulté de craquer. En prenant notre situation de test comme exemple, selon le principe de l'attaque par extension de longueur, tant que nous connaissons la longueur de H(message) et du message, nous pouvons ajouter de nouvelles données via une attaque par extension de longueur. Le message d'origine = SecretKey + data, maintenant nous avons déjà H(message) en main. Il suffit de connaître la longueur du message pour construire une nouvelle valeur de hachage. Puisque SecretKey est une clé de 30 bits, seules 30 itérations sont nécessaires pour connaître la longueur du message réel. Par conséquent, nous pouvons facilement construire une nouvelle valeur de hachage. Puisque nous devons utiliser les autorisations d'administrateur, nous devons intégrer le champ malveillant "&role=admin" dans les données d'origine.
Nous pouvons utiliser la fonctionnalité d'attaque par extension de longueur pour ajouter de nouvelles données et générer une nouvelle valeur de hachage sans connaître la SecretKey. Une bibliothèque qui implémente déjà cette fonctionnalité est utilisée ici [2] pour terminer le test. Utilisez ensuite l'outil pour générer une nouvelle valeur de hachage.
Étant donné que la vérification de l'interface de adminActionHandler vérifie le hachage en fonction de l'utilisateur_id, de l'utilisateur_name et du rôle téléchargés, les données que nous avons téléchargées à ce moment sont user_id=1, user_name=aa\x80\x00\x00\x00. \ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x70 et role=admin, comme indiqué dans la figure suivante :
La valeur de hachage est 84ae4ae437eeabf3bd8a26294392770b86f64a81998194156ac003d58a21acd0. Après cela, vous pouvez appeler l'interface adminActionHandler. Après avoir reçu les données, le serveur comparera le hachage téléchargé avec sha256 (SecretKey + fakeData). Après avoir réussi la vérification, certaines opérations sensibles seront effectuées. De cette façon, nous avons réussi à contourner la vérification côté serveur en utilisant l'attaque par extension de longueur et à réaliser l'opération non autorisée.
Autres scénarios d'attaque possibles
1. Vérification de l'intégrité du fichier : Si l'intégrité du fichier est vérifiée en concaténant la clé et le contenu du fichier, puis en le hachant, un attaquant peut alors développer le fichier et générer un hachage valide, contournant ainsi les contrôles d'intégrité ;
2. Sécurité des applications Web : Dans les applications Web, si une fonction de hachage susceptible d'être attaquée par extension de longueur est utilisée pour vérifier les données soumises par l'utilisateur, les attaquants peuvent en profiter pour soumettre des données malveillantes ;
3. Signatures numériques : Dans certains schémas de signature numérique, si la signature est générée en concaténant la clé privée et le message, puis en la hachant, l'attaquant peut alors développer le message et générer une signature valide ;
4. Stockage du mot de passe : Bien que cela ne soit pas courant, si un mot de passe est stocké en concaténant une clé (par exemple un sel) et un mot de passe, puis en le hachant, un attaquant peut alors tenter de le déchiffrer à l'aide d'un mot de passe d'attaque par extension de longueur.
Comment prévenir
1. Choisissez une fonction de hachage qui n'est pas sensible aux attaques par extension de longueur, comme SHA-3 ;
**2. Utilisez HMAC : **HMAC nécessite une clé et un message en entrée. Le résultat de sortie dépend à la fois de la clé et du message, de sorte que l'attaquant ne peut pas effectuer une attaque d'extension de longueur sans connaître la clé. ;
**3. Renforcez la vérification de l'autorité : **Ajoutez des étapes supplémentaires de vérification de l'autorité côté serveur, telles que l'utilisation de l'authentification multifacteur.
Voici les caractéristiques de certains algorithmes de hachage couramment utilisés :
| Algorithme | Résistance aux collisions | Attaque de collision avec préfixe sélectionné | Résistance aux préimages | Attaque d'extension de longueur | | --- | --- | --- | --- | --- | | MD5 | 2 ^ 18 | 2 ^ 39 | 2 ^ 123,4 | Vulnérable | | SHA-1 | 2^61,2 | 2^63,4 | 2^160 | Vulnérable| | SHA-256 (SHA-2) | 2^65,5 | - | 2^254,9 | Vulnérable| | SHA-512 (SHA-2) | 2^32,5 | - | 2^511,5 | Vulnérable| | SHA-3 | 2^50 | - | inconnu | non vulnérable | | BLAKE2s | 2^112 | - | 2^241 | Non vulnérable| | BLAKE2b | 2^224 | - | 2^481 | non vulnérable|
Conclusion
Une défense efficace contre les attaques par extension de longueur consiste à utiliser des fonctions de hachage qui sont immunisées contre de telles attaques, telles que SHA-3 et BLAKE2. De plus, il peut également être protégé via la structure HMAC (code d'authentification de message haché à clé). Ces mesures peuvent améliorer efficacement la sécurité du système et garantir l’intégrité des données et la stabilité des applications.
Lien de référence :
[1]
[2]