DROWN : un tiers de tous les serveurs HTTPS vulnérables

Le par  |  8 commentaire(s) Source : The DROWN Attack
DROWN-logo

De l'ordre de 33 % des serveurs HTTPS sont à risque en raison d'une vulnérabilité de sécurité découverte dans OpenSSL.

Après notamment Heartbleed et POODLE, le nouveau nom qui fait peur pour la bibliothèque de chiffrement OpenSSL est DROWN. En réalité, une sorte d'acronyme pour Decrypting RSA using Obsolete and Weakened eNcryption. Tremblez… selon une estimation, un tiers de tous les serveurs HTTPS sont à risque, soit aux alentours de 11,5 millions de serveurs.

Pour autant, le projet OpenSSL - qui propose une série de patchs pour la correction de plusieurs vulnérabilités - ne distingue pas DROWN par un niveau de dangerosité critique mais élevé. Les versions affectées sont celles antérieures à 1.0.2 et 1.0.1. Il existe désormais des versions 1.0.2g et 1.0.1s à déployer.

Avec la mise à jour proposée, OpenSSL désactive par défaut le vieux protocole SSLv2 et supprime la possibilité de forcer des chiffrements d'exportation (SSLv2 EXPORT). Une attaque qualifiée de multi-protocoles, et de type man-in-the-middle, permet en effet de déchiffrer des sessions TLS (communications HTTPS) en utilisant un serveur prenant en charge SSLv2 et des suites de chiffrement d'exportation.

DROWN

On comprend donc que le souci est au niveau du support du protocole SSLv2 qui est pourtant obsolète depuis belle lurette. Sauf que ce support par des serveurs ne semblait pas forcément être un souci dans la mesure où la plupart des clients récents ne l'utilisent pas.

Pour la quinzaine de chercheurs universitaires à l'origine de la découverte de DROWN, l'autorisation de connexions SSLv2 est " étonnamment commune " à cause d'une mauvaise configuration et des paramètres par défaut inappropriés du serveur.

DROWN-1

Ils pointent aussi de doigt le fait que pour un serveur, sa clé privée peut être utilisée sur un autre serveur qui autorise des connexions SSLv2, et ce même pour un autre protocole. " Beaucoup d'entreprises réutilisent le même certificat et la clé sur leurs serveurs Web et email, par exemple. Dans ce cas, si le serveur email prend en charge SSLv2 mais pas le serveur Web, un attaquant peut tirer parti du serveur email pour casser les connexions SSL au serveur Web. "

DROWN-2

Évidemment, maintenant que les chercheurs publient les détails de leur trouvaille, le risque est autrement plus élevé que lorsque l'attaque DROWN était tapie dans l'ombre mais a priori pas exploitée dans la nature. Qui plus est, l'attaque ne demande pas des ressources énormes. Sur Amazon EC2, l'exécution des calculs pour une attaque complète revient à près de 440 $ et dure moins de 8 heures. Et beaucoup moins si d'autres bugs OpenSSL sont présents : moins d'une minute depuis un seul PC.

Du côté des utilisateurs et des navigateurs, il n'y a pas grand-chose à faire, si ce n'est de vérifier la vulnérabilité ou non d'un site HTTPS à une attaque DROWN grâce à cet outil en ligne. Une liste de sites populaires vulnérables donne une indication de l'ampleur de la menace (Yahoo, Dailymotion, BuzzFeed, Flickr, Samsung, NBA, ASUS, Le Monde...). La balle est dans le camp de ceux qui opèrent les serveurs afin qu'ils mettent en place les mesures de protection adéquates.

Complément d'information

Vos commentaires

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1883542
La liste des sites vulnérables est impressionnante...
Le #1883543
Morpheus005 a écrit :

La liste des sites vulnérables est impressionnantes...


Par contre l'outil de test est un peu décevant, à installer et faire tourner soi-même si on veut vraiment avoir un résultat (sinon il vérifie juste si on est ou pas dans la liste des sites vulnérables connus)
Le #1883544
bugmenot a écrit :

Morpheus005 a écrit :

La liste des sites vulnérables est impressionnantes...


Par contre l'outil de test est un peu décevant, à installer et faire tourner soi-même si on veut vraiment avoir un résultat (sinon il vérifie juste si on est ou pas dans la liste des sites vulnérables connus)


Absolument! j'ai quand meme pu voir que certains FAI Francais étaient vulnérables...
Le #1883583
Patch openssl et libssl déja dispo sur les dépots debian !

https://security-tracker.debian.org/tracker/CVE-2016-0705
Le #1883593
Comme pour tout, la sécurité a ses limites, sa vulnérabilité !
Quand quelqu'un voudra vous vendre une "sécurité informatique" à toutes épreuves, vous réfléchirez à deux fois avant d'accorder crédit à ses propos
Le #1883594
patché de mon côté, même si ça fait longtemps que mes infras n'acceptent que du TLS (parceque pour le coup, faut aussi virer SSLv3 hein… POODLE anyone? ).

Ce qui est hallucinant quand même:

* Y'en a qui autorisent encore des connexions en SSLv2 (et v3) alors que ça fait longtemps que ces protocoles sont dépassés - probablement de la rétrocompat' avec des vieux bousins qui ne supportent pas TLS (mmmh, IE6? )
* Que ça n'ait pas été viré d'OpenSSL depuis le temps… faudrait que je checke si LibreSSL a conservé le support de ce machin. Bon après, y'avait encore du code pour le support VAX/VMS dans OpenSSL au moment d'Heartbleed. Un vrai musée

@DeepBlueOcean: la sécurité informatique c'est avant tout une veille technologique constante. Il faut savoir être à la fois proactif *et* réactif. Ce qui était considéré comme secure il y a X mois ne l'est plus forcément de nos jours. Mais un adminsys consciencieux, ça se paye, et beaucoup de boîtes s'en tamponnent le coquillard…
Le #1883611
lidstah a écrit :

patché de mon côté, même si ça fait longtemps que mes infras n'acceptent que du TLS (parceque pour le coup, faut aussi virer SSLv3 hein… POODLE anyone? ).

Ce qui est hallucinant quand même:

* Y'en a qui autorisent encore des connexions en SSLv2 (et v3) alors que ça fait longtemps que ces protocoles sont dépassés - probablement de la rétrocompat' avec des vieux bousins qui ne supportent pas TLS (mmmh, IE6? )
* Que ça n'ait pas été viré d'OpenSSL depuis le temps… faudrait que je checke si LibreSSL a conservé le support de ce machin. Bon après, y'avait encore du code pour le support VAX/VMS dans OpenSSL au moment d'Heartbleed. Un vrai musée

@DeepBlueOcean: la sécurité informatique c'est avant tout une veille technologique constante. Il faut savoir être à la fois proactif *et* réactif. Ce qui était considéré comme secure il y a X mois ne l'est plus forcément de nos jours. Mais un adminsys consciencieux, ça se paye, et beaucoup de boîtes s'en tamponnent le coquillard…


" beaucoup de boîtes s'en tamponnent le coquillard"
=>C'est parce que beaucoup de clients s'en fichent aussi, la sécurité c'est peu vendeur...
Le #1883623
bugmenot a écrit :

lidstah a écrit :

patché de mon côté, même si ça fait longtemps que mes infras n'acceptent que du TLS (parceque pour le coup, faut aussi virer SSLv3 hein… POODLE anyone? ).

Ce qui est hallucinant quand même:

* Y'en a qui autorisent encore des connexions en SSLv2 (et v3) alors que ça fait longtemps que ces protocoles sont dépassés - probablement de la rétrocompat' avec des vieux bousins qui ne supportent pas TLS (mmmh, IE6? )
* Que ça n'ait pas été viré d'OpenSSL depuis le temps… faudrait que je checke si LibreSSL a conservé le support de ce machin. Bon après, y'avait encore du code pour le support VAX/VMS dans OpenSSL au moment d'Heartbleed. Un vrai musée

@DeepBlueOcean: la sécurité informatique c'est avant tout une veille technologique constante. Il faut savoir être à la fois proactif *et* réactif. Ce qui était considéré comme secure il y a X mois ne l'est plus forcément de nos jours. Mais un adminsys consciencieux, ça se paye, et beaucoup de boîtes s'en tamponnent le coquillard…


" beaucoup de boîtes s'en tamponnent le coquillard"
=>C'est parce que beaucoup de clients s'en fichent aussi, la sécurité c'est peu vendeur...


Ouais, le client il veut que ce soit vite en prod'… *shrug*
Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]