Suite aux failles récentes "Heartbleed" et "Shellshock", largement médiatisées, une nouvelle vulnérabilité, "Poodle", a été dévoilée cette nuit par Google.
Si elle ne peut être exploitée à grande échelle, elle est jugée critique, elle concerne tous les systèmes d'exploitation, et peut être mise en œuvre dans le cas d'une attaque ciblée.
Décryptage d'une faille d'encryption ...

Référence de la vulnérabilité

CVE-2014-3566

Date de publication

le 15/10/2014, vers 1h du matin, heure française.

Descriptif succinct de la faille

Les mécanismes d'encryption ont été conçus pour assurer la rétrocompatibilité, les versions successives des protocoles d'encryption sont :
- SSL 1.0 (1994, jamais mis en œuvre par Netscape, n'est pas implémenté dans les logiciels)
- SSL 2.0 (1995, première version implémentée universellement)
- SSL 3.0 (1996)
- TLS 1.0 (1999)
- TLS 1.1 (2006)
- TLS 1.2 (2008)

Le client et le serveur négocient entre eux le protocole d'encryption qui sera utilisé pour l'échange, en partant du plus récent, TLS 1.2, et en descendant chronologiquement dans la liste si l'une des deux parties ne supporte pas le protocole proposé.
Il est aussi possible, pour une attaque "Man In The Middle", d'influencer le choix du protocole négocié à la baisse, en interférant dans les échanges initiaux.
Si le protocole négocié est SSL, non sûr et obsolète, alors il est possible pour l'attaquant d'intercepter les échanges cryptés, et de voler le cookie de session du visiteur, ce qui lui permettra de prendre la place du visiteur, et d'utiliser la session qu'il a établi sur le serveur.

Il est important de préciser que Poodle est une faille protocolaire, et non pas une erreur d'implémentation d'une librairie quelconque.
Tous les logiciels utilisant l'encryption, quelque soit leur éditeur, sont impactés.
Tous les OS sont donc touchés, qu'ils soient Windows ou Linux, appliances, etc.

Types d'attaques possibles

- vol de session HTTP sur des sites de toute nature (bancaire, financier, données de santé, réseaux sociaux, etc)
- envoi de spam ou de mails forgés (lorsque la faille est exploitée sur un échange SMTP)
- possiblement, vol de session VPN

Correctifs possibles

La faille a actuellement moins de 24h, les éditeurs n'ont pour le moment pas réagi.
S'il est probable que des patches voient le jour à moyen terme, il est possible que leur application soit disruptive pour le SI des entreprises.

La seule solution fiable consiste à interdire, côté serveurs et clients, l'usage de protocoles antérieurs à TLS 1.0.

En effet, étant donné que nous sommes sur un défaut de conception des protocoles d'encryption, et qu'il subsiste des raisons légitimes pour lesquelles clients et serveurs peuvent être amenés à négocier un protocole faible comme SSL 3.0, un correctif visant à carrément désactiver les protocoles antérieurs pourrait être disruptif et casser la rétro-compatibilité, légitime.

Exploitation de la faille

Il n'est pas envisageable que la faille soit utilisée à une grande échelle, puisqu'elle n'est pas automatisable.
Elle est donc moins exploitable que les failles récentes "Heartbleed" ou "Shellshock".
Au-delà d'un intérêt purement académique, nous pouvons par contre très bien imaginer une attaque ciblée, visant une institution ou une entreprise en particulier, afin de nuire à sa réputation (désinformation) ou d'avoir accès à des sites web de l'entreprise (vol d'informations, usurpation d'identité, etc)

Pour résumer, la criticité de la faille est maximale, tout comme pour Heartbleed ou Shellshock, mais son exploitation est réduite, puisque les hackers doivent cibler un SI en particulier.

Stratégie de déploiement préconisée

Un certain nombre de logiciels de type "legacy" ne supportent pas le protocole TLS, c'est notamment le cas d'Internet Explorer 6.
Désactiver l'usage du protocole SSL x.0 côté serveurs HTTP implique que les navigateurs Internet Explorer 6 ne pourront plus établir de session cryptées avec les sites.
Internet Explorer 6 ne représentant qu'une très faible part de navigateurs, constamment en recul (Cloudflare indique que seul 0,65% de son trafic crypté utilise SSL 3.0), il est donc envisageable d'interdire ce protocole-là pour le trafic web visiteurs, en préconisant aux visiteurs de se débarrasser d'un navigateur web devenu obsolète.

Toutefois, son déploiement dans un contexte "corporate" est plus problématique :
- encore beaucoup d'entreprises restent attachées à Windows XP et IE 6, parce que certains progiciels utilisés au quotidien ne sont pleinement compatibles qu'avec ce navigateur-là
- les SI des entreprises sont rarement indépendants, et utilisent des interconnexions avec leurs partenaires. Exemples : connexions bancaires, portails ou API partenaires
- l'encryption des données est aussi utilisée pour l'interconnexion des succursales ou pour le travail à domicile (VPN)
- elle est aussi utilisée pour les échanges mail, qui sont par nature intermittents et aléatoires, et il n'est aucunement garanti que les interlocuteurs ont des serveurs mail à jour, qui suivent les normes de sécurité et les "best practices"; il y a donc un risque que forcer la suppression de SSL entraine une impossibilité de communiquer avec certains des interlocuteurs de l'entreprise
- à l'intérieur du SI même, il est possible que certaines applications, soit à cause de leur ancienneté, soit parce que les développeurs n'ont pas suivi les best practices, n'utilisent pas TLS. Exemple classique : le développeur a codé les appels à une API ou à un service interne en utilisant un tutoriel obsolète ou écrit par un débutant, trouvé sur Google.

Dans ce cadre-là, il convient de déployer les mesures correctives progressivement et avec une grande prudence, en restant à l'écoute des dysfonctionnements signalés par les utilisateurs des services, et en planifiant les interventions avec les équipes applicatives :
- tout d'abord, interdire SSL sur le trafic "public", les serveurs web externes ou les loadbalancers, puisqu'ils sont les plus susceptibles d'être ciblés par une attaque Man In The Middle, et que les risques de disruption sont réduits
- planifier ces interventions avec les partenaires s'il s'agit d'un portail web corporate ou si le SI fait appel à des portails / APIs externes
- déployer les correctifs sur les serveurs mail externes, pour les mêmes raisons, en faisant attentions aux problèmes remontés par les interlocuteurs, qui peuvent avoir des configurations "legacy" (par exemple, Lotus Domino est encore largement utilisé en entreprise, et certaines versions n'utilisent que SSL, TLS étant optionnel)
- cartographier les applications et services internes utilisant l'encryption sur le réseau "privé", et planifier les interventions avec les équipes applicatives pour le SI de l'entreprise : même si les risques d'attaque sont moindres pour le trafic interne, il s'agit de mettre en conformité les services pour qu'ils respectent des standards de sécurité acceptables
- toute intervention doit être suivie d'une VSR (Vérification des Services Réguliers), afin de valider qu'il n'y pas de problèmes de communication entre les serveurs, les APIs, entre le front-office et le back-office, etc

Quelques mesures à prendre sur Linux (Debian et Ubuntu)

Comme dit précédemment, il ne s'agit aucunement de déployer un patch de sécurité, mais de "durcir" la configuration des services.
Il n'est donc pas possible de compter sur un système de mises à jour (apt-get upgrade, yum update), mais sur un travail d'administration, de configuration.
Lorsqu'un patch sortira, il modifiera les fichiers de configuration des logiciels, et non pas les binaires. Il s'agira alors d'écraser la configuration actuelle (impensable dans le cadre d'une mise à jour), ou d'ajouter les paramètres recommandés à la main.

N'oublions pas que ces paramètres doivent faire l'objet d'un déploiement contrôlé, pour préserver la continuité des services, aussi bien sur le SI de l'entreprise lui-même, que vis à vis de ses interconnexions avec les partenaires et interlocuteurs.

Apache HTTPD Server

If you're running Apache, just include the following line in your configuration among the other SSL directives:

SSLProtocol All -SSLv2 -SSLv3

And restart the server, e.g.

sudo service apache2 restart

Nginx server

If you're running Nginx, just include the following line in your configuration among the other SSL directives:

ssl_protocols: TLSv1 TLSv1.1 TLSv1.2;

And restart the server, e.g.

sudo service apache2 restart

Postfix SMTP

For 'opportunistic SSL' (encryption policy not enforced and plain is acceptable too), you don't need to change anything. Even SSLv2 is better than plain, so if you need to secure your server you should be using 'mandatory SSL' mode anyway.
For 'mandatory SSL' mode being configured already, just add/change the smtpd_tls_mandatory_protocols setting:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

and restart Postfix:

sudo postfix restart

Ressources documentaires (en anglais)

- Le billet original de Google :
http://googleonlinesecurity.blogspot.fr/2014/10/this-poodle-bites-exploiting-ssl-30.html
- La page wikipedia de TLS et de ses liens de filliation avec SSL :
http://fr.wikipedia.org/wiki/Transport_Layer_Security
- Le billet de Vulture Register publié la même nuit :
http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/
- L'analyse de la vulnérabilité par CloudFlare :
https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
- Le CVE chez RedHat :
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-3566
- Ask Ubuntu :
http://askubuntu.com/questions/537196/how-do-i-patch-of-workaround-sslv3-poodle-vulnerability-cve-2014-3566

Partager l'article