Quels clients se sont révélés vulnérables à Heartbleed?
Sur plusieurspages , il est réitéré que les attaquants peuvent obtenir jusqu'à 64 Ko de mémoire du serveur ou du client qui utilisent une implémentation OpenSSL vulnérable à Heartbleed (CVE-2014-0160 ). Il y a des dizainessuroutils qui révèlent le bogue dans les applications serveur.
Jusqu'à présent, je n'ai pas vu un seul outil qui exploite le bogue dans les applications clientes. Est-il si difficile d'exploiter le bogue chez les clients? Les clients sont-ils réellement vulnérables ou non?
En fait, oui , les clients sont vulnérables. Jusqu'à présent, l'attention s'est concentrée sur les serveurs car ils sont beaucoup plus ouverts à l'exploitation. (Presque) tout le monde peut se connecter à un serveur public HTTP/SMTP/....
Ce blog décrit le fonctionnement réel du bogue (il mentionne dtls_process_heartbeat(), mais tls_process_heartbeat() est affecté de la même manière). Cette fonction est utilisée à la fois pour les clients et les applications serveur, donc les clients devraient être vulnérables aussi.
Selon la RFC 6520, les battements cardiaques ne doivent pas être envoyés pendant les poignées de main. En pratique, OpenSSL accepte les battements de cœur juste après l'envoi d'un ServerHello (c'est ce que fait ssltest.py de Jared Stafford). Après des tests supplémentaires, j'ai découvert que les serveurs peuvent abuser des clients en envoyant un Heartbeat juste après l'envoi du ServerHello aussi. Il déclenche le même bug.
Une preuve de concept peut être trouvée dans mon référentiel à https://github.com/Lekensteyn/pacemaker . De son README:
Les clients suivants ont été testés par rapport à 1.0.1f et une fuite de mémoire avant la prise de contact:
- MariaDB 5.5.36
- wget 1.15 (fuite de mémoire des connexions antérieures et de son propre état)
- curl 7.36.0 (https, FTP/IMAP/POP3/SMTP avec --ftp-ssl)
- git 1.9.1 (clone/Push testé, fuites peu)
- nginx 1.4.7 (en mode proxy, fuit la mémoire des requêtes précédentes)
- liens 2.8 (fuit le contenu des visites précédentes!)
- KDE 4.12.4 (kioclient, Dolphin, testé https et ftps avec kde4-ftps-kio)
- Exim 4.82 (SMTP sortant)
Il a été démontré que 64 Ko de mémoire (65 535 octets) peuvent en effet être retournés. Il a également été démontré que les clients (wget, KDE Dolphin, ...) peuvent divulguer des données comme les requêtes précédentes contenant éventuellement des mots de passe.
J'ai écrit un module Metasploit pour tester cela, son examen est en cours, mais devrait toucher la branche principale assez rapidement. À ce stade, la première version est fusionnée dans la branche principale.
Contrairement à l'attaque côté serveur, vous devez implémenter la plupart de TLS car la réponse de pulsation est chiffrée par rapport à la clé de session SSL. J'ai testé avec wget, curl et la ligne de commande openssl. Un tidbit intéressant est que contre wget et openssl (1), l'attaque réussit indépendamment de la validation du certificat. Le binaire curl nécessite -k ou un certificat valide pour garder la session ouverte suffisamment longtemps pour que l'attaque fonctionne. Contre ces tests relativement synthétiques, je pourrais divulguer de manière fiable la clé de session TLS (AES-128-CBC), mais cela ne fournit pas grand-chose puisque le serveur connaît la même clé pendant la prise de contact.
EDIT1 : On dirait que le code du stimulateur cardiaque accomplit cela sans faire la poignée de main TLS complète (encore mieux!). Je serais intéressé par les résultats des tests que les gens pourraient avoir entre les implémentations. IOW, le stimulateur cardiaque réussit-il dans les cas où le client se déconnecterait autrement en raison d'un certificat auto-signé?
EDIT2 : La méthode utilisée par @Lekensteyn dans le stimulateur cardiaque (envoyer un battement de coeur après le serveur Hello) est une meilleure approche car la validation CA n'est pas un problème. J'ai soumis un nouveau PR Metasploit qui utilise par défaut ce mode et préserve le chemin du code de négociation TLS à l'aide de l'option NEGOTIATE_TLS (définir NEGOTIATE_TLS true pour l'ancien mode). Accessoires à @Lekensteyn!
Il est possible d'exploiter le bogue dans les clients. Ce testeur peut être utilisé pour donner une URL 'diabolique' à des clients arbitraires et voir s'ils prennent l'appât ou non. J'ai trouvé 3 des 100 meilleurs sites Web (je ne les nommerai pas ici) qui récupèrent les URL à l'aide de clients qui étaient vulnérables en date du 2014-04-09.
Si vous avez un appareil Android Android, vous pouvez installer l'une des applications Heartbleed qui testent la vulnérabilité, comme celle-ci:
https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector
J'ai testé cela sur deux Android, un avec 4.3 et un avec 4.4, et les deux signalent être vulnérables, mais pour les deux OpenSSL n'est pas utilisé, donc tout va bien ....
Donc tout va bien. Très bien, aucune application n'utilise OpenSSL. Mais que faire si j'installe une application qui l'utilise? Serai-je prévenu? Je suppose que non!
Le téléphone 4.4 est tout nouveau de Sony, et après la première utilisation, il a téléchargé une mise à jour du système, mais je suppose que ce n'est pas assez important pour être réparé?!