Article rédigé dans le cadre de la Hacker’s Challenge et sponsorisé par Radware
On en parle un peu moins que les autres, et pourtant, elles existent bel et bien. Il s’agit comme vous avez pu le deviner en lisant le merveilleux titre de cet article, des attaques TLS/SSL !
Mais avant de rentrer dans le coeur du sujet, il faut bien garder à l’esprit que les protocoles TLS (Transport Layer Security) et SSL (Secure Socket Layer) sont d’abord là pour permettre un chiffrement de la connexion entre un client et un serveur. Donc par exemple (mais pas que) entre votre navigateur et le serveur qui héberge le site web que vous visitez. En chiffrant cette connexion, on s’assure ainsi qu’aucun tiers ne viendra lire ou modifier son contenu, ce qui est fort convenable surtout quand ces données sont vos mots de passe, vos numéros de carte de crédit, vos emails ou un simple cookie d’authentification.
Fonctionnant sur un principe de clé publique, SSL/TLS permet au client de s’assurer que le serveur est bien celui qu’il prêtant être et vice versa. Lorsque la connexion sécurisée est établie, le serveur envoie son certificat SSL au client qui vérifie auprès d’une Autorité de Certification (les fameux CA) que ce certificat est bien valide.
En marge de tout cela, il y a aussi le PFS (Perfect Forward Secrecy) qui garantie que les clés de sessions utilisées dans une communication chiffrée ne sont pas compromises, même si la clé privée du serveur a été éventée. Alors comment ça fonctionne ? Et bien pour chaque session initiée par le client, une clé unique et éphémère est générée. Cette clé sera utilisée uniquement dans le cadre de cette session et ne pourra donc pas, en cas d’interception, être utilisée pour les sessions suivantes.
Évidemment, SSL/TLS est un protocole qu’on connait bien, car on le retrouve sous la forme d’un petit cadenas dans nos navigateurs, mais il est aussi utilisé par d’autres services que HTTP, comme le FTP, la VoIP, le VPN, le SMTP…etc.
Toutefois, malgré ces mesures de sécurité, SSL subit aussi son lot d’attaques, aussi bien du côté serveur que du côté client. Je vais donc vous en présenter quelques-unes ainsi que les solutions pour les éviter.
Alors celle là, vous en avez peut-être entendu parler via mon site, car j’avais fait plusieurs articles à ce sujet fin 2014. POODLE (caniche en anglais) pour « Padding Oracle On Downgraded Legacy Encryption » tire avantage du fait que SSL 3.0 est encore supporté sur de nombreuses machines, pour dégrader l’ensemble des connexions chiffrées vers la version la moins sécurisée. Ainsi, il est possible de déchiffrer simplement les cookies sécurisés envoyés au travers d’une connexion SSL.
Il n’y a pas vraiment de patch contre cela, mais une solution simple : Arrêter d’utiliser SSL 3.0 et lui préférer TLS >= 1.2. Sur les clients, mettez aussi à jour les navigateurs vers la version la plus récente qui protège contre la dégradation du chiffrement des connexions. Si toutefois, pour des raisons de compatibilité vous deviez conserver un navigateur ancien, assurez-vous de désactiver les protocoles SSL 2.0 et 3.0 sur la machine.
Apparu fin 2011, BEAST pour « Browser Exploit Against SSL/TLS » touche SSL 3.0 et TLS 1.0. Quelqu’un de mal intentionné peut déchiffrer les données échangées entre les 2 parties, grâce à une vulnérabilité dans l’implémentation du mode CBC (Cipher Block Chaining) de TLS 1.0. L’attaque se fait côté client grâce à une technique de Man in the Middle qui consiste à injecter des paquets spécialement forgés pour l’occasion dans le flux TLS.
Cela permet à l’attaquant de déchiffrer l’ensemble du contenu sécurisé en comparant simplement ce qu’il a injecté (en clair) avec ce même contenu, même cette fois chiffré. (Principe XOR)
Pour éviter le problème, passez à TLS 1.1 ou 1.2.
Oui, toutes ces attaques ont des acronymes rigolos. D’ailleurs CRIME ça veut dire « Compression Ratio Info-leak Made Easy » et ça profite d’une vulnérabilité au niveau de la compression TLS découverte en 2012. Le principe même de compression consiste (grosso modo) à retravailler le contenu pour ne pas avoir de redondance pour gagner de la place.
Ainsi, L’attaquant en position Man In The Middle, injecte des caractères aléatoires dans un cookie forgé et observe les différences de taille de compression avec le cookie légitime (et chiffré) dans les réponses qu’il intercepte. Si les caractères qu’il soumet sont présents dans le cookie qu’il veut intercepter, la réponse qu’il obtient est plus légère (car compressée). Au contraire, si le caractère n’est pas présent, la réponse est plus lourde. Cela lui permet de bruteforcer la clé contenue dans un cookie en testant un à un ses caractères.
Pour éviter le souci, il faut utiliser un navigateur récent.
BREACH pour « Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext » (ouf) est une technique découverte en 2013 semblable à CRIME à l’exception prêt que BREACH cible la compression HTTP là ou CRIME cible la compression TLS. Après sur les détails, ça se passe à peu près pareil.
Pour contourner le problème, il faut entre autres, désactiver la compression HTTP, rendre la taille des réponses HTTP aléatoires en ajoutant un nombre aléatoire de bytes dans chacune d’entre elles, limiter le nombre de requêtes (pour bloquer le bruteforce)…etc.
HEIST
HEIST (HTTP Encrypted Information can be Stolen through TCP-windows) est l’évolution naturelle de BREACH et CRIME et permet grâce à un JavaScript malicieux de dérober des données sensibles, toujours grâce au système de compression présent dans TLS.
BREACH + CRIME + HEIST, ça commençait à faire beaucoup, c’est pourquoi il a été décidé en 2014 d’abandonner tout simplement le support de la compression dans TLS1.3.
Heartbleed (CVE-2014-0160)
Sans doute la plus connue, car elle a été très largement médiatisée. Il s’agit simplement d’une vulnérabilité découverte dans l’extension heartbeat d’OpenSSL qui permet est utilisée pour garder active une connexion en envoyant des petits « battements de coeur » (heartbeat) entre le client et le serveur. Ce battement de coeur envoyé par le client dans ses requêtes contient une certaine quantité d’informations (données + tailles des données) et le serveur doit répondre avec le même « heartbeat » (données + tailles).
Seulement voilà, à cause de cette faille, il est possible de forger une requête donnée + taille des données un peu spéciales, car plus grande à laquelle le serveur va répondre en utilisant des données aléatoires contenues dans sa mémoire. Ainsi l’attaquant aura accès à une jolie fuite d’informations non chiffrée. Je vous laisse imaginer ce qu’elle peut contenir comme données personnelles, documents en transit et informations importantes.
Pour prévenir de la faille Heartbleed, il faut mettre à jour vers la dernière version d’OpenSSL. Toutefois si cela n’est pas possible, vous pouvez recompiler OpenSSL avec le flag « -DOPENSSL_NO_HEARTBEATS ».
Découverte en 2015, mais présente depuis le milieu des années 90, FREAK (« Factoring RSA Export Keys ») profite comme POODLE ouf DROWN, une fois encore, du support dans ancien protocole SSL dans les versions récentes de TLS.
SWEET32 comme BEAST profite d’une faiblesse dans le mode CBC où sont encore utilisé de vieux ciphers comme TripleDES et Blowfish, vulnérable à des attaques par collision. En collectant et analysant au maximum 32 GB de data chiffrée, un attaquant peut trouver la clé privée et déchiffrer le contenu.
Les attaques de Déni de service
Il en existe aussi de plusieurs types et permet de saturer le serveur assez rapidement. Je pense d’abord au flood HTTPS… Même principe qu’avec le HTTP sauf que là c’est du contenu chiffré qui sert à saturer le serveur. Aussi, à l’aide de requêtes SYN non chiffrées envoyées en masse, il est possible d’engorger le process de SYN-ACK Handshake (établissement d’une connexion entre le client et le serveur). Rebelote au niveau des renégociations SSL (servant à obtenir de nouvelles clés de chiffrement) qu’il est possible de multiplier à l’infini pour saturer le serveur.
Cette attaque est sans doute l’une des plus récentes et touche tous les services qui reposent sur SSL/TLS, que ce soit HTTPS ou d’autres.
Pour être réalisable, cette attaque profite d’une mauvaise configuration des serveurs supportant encore SSLv2 (qui est totalement troué). Un attaquant peut alors déchiffrer des connexions TLS récentes entre des clients et des serveurs totalement à jour en envoyant des requêtes SSLv2 forgées avec la même clé privée que celle échangée entre des serveurs légitimes.
Pour contrer cette attaque, il faut stopper toute utilisation de SSLv2 et vous assurer que vos logiciels sont à jour… Apache, Postfix, Nginx, Debian, Red Hat, Microsoft IIS, ou les libs comme OpenSSL ou la Network Security Services (NSS). Évitez aussi tout échange de clé privée entre vos serveurs.
Tout ce que je vous ai décrit dans cet article n’est qu’une petite partie de ce qui existe et de ce qui existera. Je n’ai pas parlé d’autres aspects qui concerne plus le chiffrement comme RC4 NOMORE, de la génération de nombres aléatoires ou des courbes elliptiques Barreto-Naehrig.
L’adoption massive du SSL (grâce notamment à l’arrivée du HTTP2) est un progrès formidable pour la sécurisation de nos communications, mais ce genre de vulnérabilité est aussi une arme formidable dans les mains des cybercriminels et un bon moyen de masquer (ou en tout cas, complexifier) certaines attaques afin de les rendre indétectables aux yeux de certaines sondes ou d’outils d’analyse posés sur le réseau ou sur les applicatifs.
Heureusement, il existe des outils pro comme ceux de Radware qui permettent de faire de la détection avancée d’attaques sur SSL/TLS de manière transparente, et de les empêcher ou de les atténuer (dans le cas d’un DoS) sans pour autant impacter la rapidité des échanges.
J’espère que cet article vous aura intéressé. Aussi, si vous remarquez quelques petites imprécisions, n’hésitez pas à me contacter pour que j’améliore tout cela grâce à vous. D’avance merci.
Next time, toujours dans le cadre de l’évènement Hacker’s Challenge, je vous causerai Attaques DDoS. Et si tout ça vous donne envie de découvrir toutes ses techniques de hack en live et de les voir exploitées, pour pouvez vous inscrire ici
Bon week-end !
publicite par Radware