Imaginez une seconde que vous êtes un hacker qui vient de prendre le contrôle d’un accès Wi-Fi dans un café !
Vous n’avez pas besoin d’être là-bas en personne, vous avez juste besoin de vous connecter à la borne Wi-Fi en tant que “root” (le nom que UNIX donne pour l’administrateur système).
Si vous êtes capable de faire ceci, alors vous pouvez tout à fait espionner, vous infiltrer et agir sur le trafic internet d’à peu près n’importe qui.
Cependant, les clients de ce café, qui utilisent une connexion HTTPS, seront hors de votre portée car leur trafic est crypté.
Cela est vrai, du moins en théorie.
En effet, en agissant sur le trafic depuis votre point d’accès au réseau pirate, vous pouvez interférer sur la manière avec laquelle les connexions HTTPS sont établies.
Cela signifie que vous pouvez duper les deux extrémités de la connexion (en général, le navigateur et le serveur), en dégradant fortement leur sécurité, et en utilisant une ancienne version moins sécurisée que HTTPS, connue sous le nom de SSL 3.0.
Si vous pouvez réaliser cette opération, vous serez alors capable de récupérer des données confidentielles, grâce à un bug connu sous le nom de CVE-2014-3566.
Ce nom n’étant pas très accrocheur, les experts de Google qui travaillent sur cette faille, l’ont surnommé POODLE, une contraction de : Padding Oracle On Downgraded Legacy Encryption
Waouf, Waouf !!
Comment SSL 3.0 fonctionne
En schématisant, POODLE fonctionne car le cryptage des données au sein des paquets SSL 3.0 sont arrangés comme suit :
Le MAC (Message Authentication Code) est un code d’authentification ou encore une vérification cryptographique, qui permet de s’assurer que le cryptage des données n’a pas été altéré en cours de route.
Le padding, quant à lui, se compose d’une séquence d’octets supplémentaires, qui servent à la finalisation du cryptage pour permettre, ainsi, à l’algorithme de codage de fonctionner correctement.
Le padding n’est pas nécessaire si la connexion utilise ce que nous appelons, un algorithme de chiffrement à flot (stream cipher), tel que RC4. En effet, cet algorithme permet le codage d’un octet à plusieurs millions d’octets à la fois. Cependant, si la connexion HTTPS est configurée en utilisant SSL 3.0, avec un cryptage du type AES-CBC ou 3DES-CBC, le codage est alors réalisé par séquence fixe, car AES et 3DES, sont des algorithmes de chiffrement par bloc, qui ne peuvent prendre en charge qu’un bloc à la fois : 8 octets pour 3DES et 16 octets pour AES.
Le padding avec SSL 3.0 est réalisé en ajoutant zéro ou plusieurs octets, jusqu’à ce que la taille des données soit un octet plus petit qu’un multiple de la taille du bloc de chiffrement.
Enfin, un dernier octet est rajouté, indiquant la quantité d’octets de padding qui ont été ajoutés auparavant.
Utiliser le dernier octet pour signaler la taille totale du padding est plutôt pratique, car cela facilite la tâche de l’autre côté de la connexion, pour se débarrasser du padding par la suite, en effectuant les actions suivantes :
- Décryptage de toutes les données (données utilisateurs, MAC et padding)
- Isoler le dernier octet pour obtenir le nombre d’octets exacts utilisés pour le padding (le compteur de padding).
- Isoler les octets utilisés pour le padding
- Isoler le MAC pour récupérer enfin les données confidentielles
- Vérifier que le MAC correspond bien à la clé de départ de ces données confidentielles.
A noter que si les données et le MAC forment déjà un multiple de la taille du bloc de chiffrement, vous ne pouvez pas les laisser comme cela et ne rien ajouter. En effet, vous devez obligatoirement ajouter au moins un octet, même pour indiquer que vous avez ajouté zéro octet de padding !
Ainsi, si nous avons 16 octets de données, plus un MAC de 16 octets, et que nous cryptons avec AES (c’est-à-dire avec des blocs de 16 octets), nous aurons besoin de 15 octets de padding, auquel nous rajouterons un dernier octet (avec la valeur 15, le compteur de padding), pour finaliser le codage et arriver au 48 octets, à savoir un multiple exact de la taille des blocs sous chiffrement AES :
Failles cryptographiques dans SSL 3.0
Vous avez sans doute déjà une vague idée des failles dans SSL 3.0 à partir du diagramme présenté plus haut.
Tout d’abord, les octets de padding et le compteur de padding ne sont pas intégrés dans le MAC, et ensuite, les 15 octets de padding peuvent contenir n’importe quelle séquence, sans subir aucune vérification ou validation.
Ainsi, si vous falsifier les derniers 16 octets de la totalité des donnée cryptées, en remplaçant ces derniers par n’importe quoi au moment où ils traversent votre routeur Wi-Fi piraté, vous avez 1 chance sur 256 que la totalité des 48 octets de la séquence de données soit acceptée par le serveur.
Si le dernier octet dans le dernier bloc que vous avez modifié, correspond au moment du décodage à la valeur 15, alors le serveur va tout simplement isoler le dernier octet, et sans plus réfléchir isoler de manière correcte les 15 autres octets du padding, en oubliant merveilleusement que les octets de padding sont différents de ceux que le navigateur de l’utilisateur a laissés auparavant.
Ainsi le MAC peut sans problème valider les données confidentielles, et le paquet sera accepté malgré une altération durant le processus.
Au final, cela peut ne pas ressembler à un faille cryptographique, car seules des données qui vont être de toutes les façons détruites ont été modifiées.
Cependant, une alarme devrait pourtant commencer à retentir : n’importe quelle modification devrait toujours être signalée, et en cas d’incohérence au niveau des données reçues, le paquet doit être refusé.
Altérations volontaires
A présent, imaginez qu’au lieu d’altérer, de manière aléatoire, ces 16 derniers octets, vous essayez de les altérer délibérément.
Que se passerait-il si vous copiez les 16 premiers octets cryptés et les écriviez par-dessus les octets de padding, et qu’au final vous essayiez de faire passer cette séquence ?
Si le serveur accepte votre séquence de données modifiées, vous saurez alors que le dernier octet du bloc que vous avez copiez, une fois décodé, correspond à la valeur 15. Dans le cas contraire, le serveur aura extrait le mauvais MAC, et la vérification des données aura échoué.
Vous avez juste dupé le serveur, pour qu’il vous fournisse des informations concernant les données cryptées que vous aviez copiées et envoyées.
Plus clairement, si le serveur rapporte une erreur, vous savez que le dernier octet du premier bloc de 16 octets n’a pas comme valeur 15.
Cela ne ressemble pas vraiment à une réelle perte de données, mais dans ce cas, la taille n’a pas d’importance. En effet, un processus de cryptage efficace ne doit absolument rien laisser filtrer.
Vous ne devriez pas être capable d’extraire la moindre donnée concernant le texte en clair provenant d’un paquet de données SSL 3.0, et ce en jouant tout simplement avec la séquence de cryptage des données.
Pour résumé, nous avons un problème ici !
Cryptage par enchainement de blocs (Cipher Block Chaining)
En fait, la description faite plus haut n’est pas tout à fait juste. En effet, nous avons oublié d’aborder un aspect du cryptage par bloc utilisé par SSL 3.0, à savoir qu’il utilise le CBC (cryptage par enchainement de blocs).
Il s’agit d’une amélioration en terme de sécurité, qui ajoute l’opération logique XOR entre le précèdent bloc de données cryptées, et l’actuel bloc de données en clair, avant d’effectuer le cryptage de chaque bloc.
Le premier bloc de données en clair, qui n’a pas de bloc déjà cryptés sur lequel se baser, va utiliser une séquence aléatoire de démarrage, connue sous le nom de « Initialisation Vector » ou « IV ».
CBC garantit que même le traitement de 2 blocs identiques, tels que des séquences remplies de zéro, ne donnera pas un bloc crypté reconnaissable par son pattern récurrent.
Ce phénomène s’explique par l’injection, au démarrage, d’un “Initialisation Vector”, et au caractère aléatoire qui se répand tout au long du cryptage de chaque bloc.
Ainsi, lorsque le serveur décode votre copie falsifiée des 16 premiers octets cryptés que vous aviez écrit par-dessus le bloc de padding à la fin de la séquence globale, il le décrypte et applique l’opération XOR avec les 16 précédents octets de données cryptées (qui se retrouvent être le MAC cryptées, la séquence de 16 octets au milieu, sur le diagramme plus haut).
Paradoxalement, cela vous donne plus de chance d’apprendre quelque chose au sujet de ce dernier octet du bloc que vous avez copié.
Comme expliqué plus haut, le décryptage direct vous disait seulement si le dernier octet avait comme valeur 15 ou non.
A présent, avec CBC, le dernier octet est décrypté et soumit à l’opération XOR avec ce qui est principalement un nombre aléatoire.
En d’autres mots, il ne s’agira pas toujours d’un octet en clair de valeur 15 qui donnera 15 après décodage, permettant ainsi d’activer le processus POODLE et de dévoiler le contenu de l’octet.
En fait, si vous pouvez, d’une quelconque manière, convaincre le navigateur de l’utilisateur de générer la même requête HTTPS plusieurs fois de suite, par exemple en simulant une erreur qui l’oblige ainsi à refaire l’envoi, vous aurez alors de nouveau 1 chance sur 256, à chaque fois, de mettre la main sur le contenu de ce dernier octet.
En effet, cela vient du fait que le “IV” aléatoire signifie, en fait, que vous aurez une séquence cryptée différente à chaque fois.
Tôt ou tard, vous allez finir par découvrir qui se cache derrière le 16ème octet du texte en clair original.
Découvrir le texte en clair un octet après l’autre
Si vous pouvez duper le navigateur de l’utilisateur, en visitant une séquence d’URLs (par exemple, en utilisant votre point d’accès Wi-Fi piraté pour injecter du JavaScript dans la page Web), vous pourrez tout à fait créer une séquence de requêtes SSL 3.0, avec un décalage d’un caractère au niveau des données confidentielles.
Ainsi, vous pouvez découvrir le nouveau 16ème octet du bloc, qui auparavant était le 15ème, et ainsi de suite , …
Un moyen de contrôler la position d’un contenu connu ou inconnu avec des paquets SSL 3.0, est de générer des séries de requêtes de téléchargement, dans lesquelles vous émettez une demande pour un fichier plus long d’un caractère à chaque fois.
Vous pouvez alors prédire à quel endroit le nom de fichier apparaitra dans chaque requête HTTP. Ainsi, presque systématiquement, vous découvrirez où l’entête HTTP, incluant les données que vous voulez dérober et décrypter, se trouvent (comme par exemple les cookies de session) :
Vous contrôlez les données en vert, car elles sont déterminées par l’URL dans la requête web. Les donnes en rouge représentent le contenu des données confidentielles, inséré par le navigateur de l’utilisateur que vous voulez attaquer grâce à POODLE.
Quoi faire ?
Le problème avec SSL 3.0 est son processus de padding, dépourvu de protocoles d’authentification et de vérification.
SSL 3.0 est une ancienne version pour la sécurité des protocoles, aussi ancienne qu’XP, en fait !
Il a été remplacé, il y a longtemps, par des alternatives plus efficaces comme TLS 1.0, TLS 1.1 et TLS 1.2.
Envisagez donc de ne plus l’utiliser définitivement.
Vous pouvez indiquer à votre navigateur de ne plus utiliser des connexions SSL 3.0, évitant ainsi qu’un pirate dans un café, ne dégrade votre session HTTPS à ses propres fins.
Vous pouvez indiquer également à vos serveurs de ne plus offrir ou accepter de connexions SSL 3.0, afin de ne plus être dupé en acceptant des séquences malveillantes, de type POODLE, qui dégraderont la sécurité de vos requêtes web.
Attention, soyez prudents : si vous utilisez un serveur qui refuse SSL 3.0, même quand les utilisateurs le réclament, ces derniers, qui peuvent aussi être vos propres clients, ne pourront plus avoir accès à vos pages HTTPS.
Cependant quand WordPress.com VIP, le service sur lequel Naked Security est hébergé, nous écrit pour nous informer qu’il ne propose plus SSL 3.0 sur tous leur sites, cela nous indique qu’un 1 utilisateur sur 1000 est en réalité concerné.
Cet utilisateur sur 1000 a en fait un plus gros problème que POODLE : la plupart d’entre eux, utilisent SSL 3.0 car ils sont toujours avec IE6 et XP !
Mais ceci est une autre histoire, …
Billet inspiré de : “POODLE attack takes bytes out of your encrypted data – here’s what to do” de Paul Ducklin de Naked Security
Qu’en pensez-vous ? Laissez un commentaire.