Audit de code : Quelques vulnérabilités cryptographiques
1. Utilisation de fonctions de hachage obsolètes comme MD5, SHA1 :
Le hachage est l’opération consistant à calculer, à partir d’une donnée fournie en entrée une empreinte unique servant à identifier rapidement la donnée initiale. Cette fonction doit éviter les collisions (et résister aux préimages). Une collision dans une fonction de hachage est le fait de trouver un couple de données distinctes ayant une empreinte est identique.
En êtes-vous vraiment sûr ?
L’Hébergement / Externalisation / Cloud ne protège pas de tout. Il reste un transfert de moyens vers un prestataire ou l’utilisation de moyens du prestataire, avec des services réalisés par celui-ci ou par vous-même, dans le cadre d’un contrat.
En cas de force majeure (incendie d’une ou plusieurs salles ou du site, incendie / explosion / terrorisme dans le voisinage, …) le site peut devenir indisponible, voire éteint, inaccessible pour le client lui-même.
Le prestataire est certes une forme d’assurance, si les moyens à mettre en œuvre sont déterminés à l’avance. Elle peut éventuellement indemniser, mais de combien par rapport à la perte d’exploitation de votre activité, au bout de combien de temps ? Que s’est-il passé entre-temps ?
Une faille qualifiée de « grave » (possibilité de créer des collisions à la demande) est découverte et indique que MD5 devrait être mis de côté au profit de fonctions plus robustes. En 2005, Xiaoyun Wang et Hongbo ont publié un article [1] dans lequel ils décrivent un algorithme qui peut trouver deux séquences différentes de 128 octets avec le même MD5. Par exemple, la paire :
Ces deux blocs ont le même hachage MD5 79054025255fb1a26e4bc422aef54eb4. L’algorithme utilisé pour générer cette paire a été utilisé par plusieurs chercheurs pour créer des fichiers avec des hachages MD5 identiques.
Les algorithmes de hachage cryptographique tels que MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (il utilise SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 et SHA-1 ne sont plus considérés comme sécurisés. Avec ces algorithmes, il est trop facile de créer des collisions ou de trouver la donnée associée à une empreinte.
⚠️ Il n’est pas recommandé d’utiliser la fonction md5() ou la fonction sha1() dans vos applications PHP.
2. Mauvais choix du mode d’opération dans les fonctions de chiffrement
Le chiffrement des données avec un algorithme de chiffrement par blocs comme AES nécessite le choix du mode d’opération. Les bonnes pratiques préconisent de choisir un mode d’opération comme le GCM (Galois Counter Mode). A l’inverse, il est fortement déconseillé d’utiliser :
– Le mode ECB (Electronic Codebook). Ce mode est vulnérable car il n’assure pas une confidentialité élevée des messages chiffrés.
– Le CBC (Cipher Block Chaining) avec PKCS # 5 (ou PKCS # 7) est vulnérable aux attaques du type Padding Oracle Attack.
✔️ Il est conseillé d’utiliser la méthode openssl_encrypt() avec le GCM comme mode de chiffrement.
3. Mauvaise utilisation de vecteur d’initialisation IV dans les fonctions de chiffrement
Le but d’un vecteur d’initialisation IV est de garantir que le même texte en clair chiffré deux fois produira deux textes chiffrés différents. L’IV doit être aléatoire et imprévisible. Sinon, il expose la valeur chiffrée à des attaques de crypto-analyse comme « Chosen-Plaintext Attacks« . Il faut éviter les vecteurs d’initialisation codés en dur comme l’utilisation d’une suite de zéros ainsi que l’utilisation de la clef de chiffrement comme un vecteur d’initialisation. Pour chaque session, la génération d’un vecteur d’initialisation doit être toujours associée à un algorithme de génération aléatoire suffisamment sécurisé.
✔️ Il est conseillé d’utiliser la méthode random_bytes() pour générer les vecteurs d’initialisation.
4. L’utilisation de générateurs aléatoires faibles
En relation avec le troisième point, la génération des valeurs prévisibles dans un contexte nécessitant une imprévisibilité permet à un attaquant de deviner la prochaine valeur aléatoire générée. Dans ce contexte, un attaquant peut tenter de prédire le jeton de réinitialisation du mot de passe afin d’obtenir les privilèges d’un autre utilisateur.
Les deux fonctions rand() et mt_rand() reposent sur un générateur de nombres pseudo-aléatoires faible. En effet, elles ne génèrent pas des valeurs sécurisées d’un point de vue cryptographique, et ne doivent pas être utilisées dans un contexte de chiffrement de données. Nous recommandons l’utilisation de random_int() ou random_bytes().
⚠️ Evitez d’utiliser la fonction rand() et mt_rand() dans vos applications PHP.
Certaines failles de sécurité ne sont pas forcément liées aux quatre vulnérabilités illustrées.
Au vu des vulnérabilités présentées ci-dessus, la réalisation d’un audit de code s’avère indispensable pour obtenir une assurance complémentaire contre les fuites d’information et les altérations de données.
Réference :
[1] Wang, Xiaoyun & Yu, Hongbo. (2005). How to Break MD5 and Other Hash Functions. Lecture Notes in Computer Science. 3494. 561-561. 10.1007/11426639_2.
CoESSI réalise des audits de code pour ses clients et accompagne fréquemment les développeurs dans la mise en place d’une démarche de développement sécurisé.
En savoir plus
Retrouvez des liens utiles pour apprendre à nous connaitre ou nous contacter.
Qui sommes-nous ?
Nous sommes un cabinet de cybersécurité et de protection de la vie privée créé en 2010
Contactez-nous
Nos spécialistes pourront vous proposer la bonne solution sous 48h