(modifié le 26 novembre 2015 à 18:02)

La veille de la mort de Windows XP le web est en ébullition depuis quelques heures !

Non pas à cause d'XP mais à cause d'une faille très critique concernant certaines versions de la bibliothèque de chiffrement OpenSSL, portant le CVE-2014-0160 et connue sous le nom de heartbleed. Cette faille serait active depuis décembre 2011...

Autant le dire, cette faille est énorme et se place en tête de toutes celles découvertes ces derniers temps, sur le plan de la confidentialité, criticité et facilité d'exploitation. Selon Netcraft les 2/3 utilisent Apache ou Nginx et seraient potentiellement touchés.

Comment cette faille fonctionne, comment s'en protéger et vos serveurs sont-ils touchés ?

Que permet cette faille ?

Tout part du module d'extension heartbeat inclut dans OpenSSL et précisé dans la rfc6520.

En envoyant un paquet forgé un client peut récupérer des bribes de la mémoire, jusqu'à 64K de la RAM du serveur web exécutant SSL. Les clients peuvent tenter des reconnexions dans l'espoir de garder une connexion SSL active et obtenir de nombreuses informations. Cela peut être des variables stockées en mémoire et éventuellement les clés/certificats. En cause, une fonction de copie de mémoire qui copie davantage de mémoire qu'elle ne devrait avant de renvoyer le tout au client....

Cette faille est vicieuse car elle ne laisse aucune trace, rien dans les fichiers de log. Impossible de savoir ce qui a potentiellement été dérobé.

Identifiants, mots de passe, bref... tout y passe. Yahoo est également concerné comme nous le confirme pyrou, lecteur du blog :

Tant que Yahoo n'a pas remédié au problème, ne vous connectez pas à votre compte Yahoo afin que vos informations ne circulent pas en ram.

MàJ : Yahoo a appliqué le patch en soirée sur ses serveurs, toujours est-il que la faille a fonctionné pendant de longues heures...

En complément je vous invite à lire ce billet qui détaille l'exploit.

Version impactées

Version touchées par le bug :

• 1.0.1, 1.0.1a à 1.0.1f (incluse)
• 1.02 bêtas

Version non touchées : 0.9.x, 1.0.0 ainsi que les versions dans lesquelles le bug a été corrigé (à partir de 1.0.1g et à partir de  1.0.2 beta 2).

Et mon Synology dans tout ça ?

Màj du 10/04/2014 : Synology vient de déployer DSM 5.0-4458 Update 2 qui corrige l'exploit Heartbleed

MàJ du 11/04/2014 : Synology précise que les NAS sous DSM 4.2 et 4.3 recevront une mise à jour corrective d'ici une semaine. Ceux sous DSM 4.1 sont priés de migrer sous 4.2 et DSM 4.0 n'est pas affecté par la brèche. Les serveurs MyDS (quickconnect) ont bien été patchés

Concernant Synology DSM est également impacté suivant sa version. Synology confirme travailler à la correction de myds.synology.com, en attendant filtrez les accès depuis l'extérieur, à défaut de les désactiver. Rien de déclaré pour l'instant sur la page Synology Sécurity. Ce que j'ai pu constaté c'est que sur un synology DS211 (ARM) il semble faillible alors que sur un DS412+ (Intel64) il ne l'est pas, alors que la version de DSM est identique en DSM 5.0-4458 Update 1.

Votre serveur est touché ?

De nombreux sites stockant des idenfiants bitcoins sont affectés et je sens qu'il va y avoir du vol de portefeuille dans l'air. Pour savoir si votre serveur est impacté (ou ne l'est plus) vous pouvez le vérifier avec :

1. Heartbleeder ou sa version compilée
2. Le script python https://gist.github.com/takeshixx/10107280
3. Depuis des sites web (déconseillé car on ne sait pas ce qu'il advient des URLs testées):
   • https://www.ssllabs.com/ssltest/ (qualys)
   • http://possible.lv/tools/hb/
   • https://filippo.io/Heartbleed/
   • https://lastpass.com/heartbleed/
4. Si vous utilisez suricata un script est dispo
5. Avec nmap

Les certificats SSL sont eux aussi potentiellement affecté... et ça va faire mal de révoquer tout ça! Si votre certificat SSL dépend d'une autorité de certification il va falloir qu'elle signe un nouveau certificat que vous aurez généré.

Ne trainez pas à faire vos mises à jour système et pensez aussi à activer le Perfect Forward Secrecy sur votre serveur pour monter un cran la sécurité (cela ne suffisait pas face à la faille heartbleed cela dit), cela évitait à une personne malveillante de déchiffrer du contenu volé avant le correctif. Si vous recompilez le paquet il faut utiliser l'argument -DOPENSSL_NO_HEARTBEATS pour ne pas activer le module heartbeat.

Pour connaître la version de votre package OpenSSL entrez dans un terminal et regardez la version ainsi que la date de compilation :

# openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Sat Feb 1 22:14:33 UTC 2014

Sur un serveur Debian un apt-get update && apt-get upgrade suffit. Mais il faut absolument redémarrer le serveur (ou les services concernés) :

Les paquets suivants seront mis à jour :
  libssl1.0.0 openssh-client openssh-server openssl ssh

Outil de configuration des paquets

 ┌───────────────────┤ Configuration de libssl1.0.0:i386 ├───────────────────┐
 │                                                                           │
 │ Cette version d'OpenSSL corrige certaines failles de sécurité. Les        │
 │ services n'utiliseront pas ces correctifs tant qu'ils n'auront pas été    │
 │ redémarrés. Veuillez noter que le redémarrage du serveur SSH (sshd)       │
 │ n'affectera aucune connexion existante.                                   │
 │                                                                           │
 │ Veuillez vérifier et corriger si nécessaire la liste des services devant  │
 │ être redémarrés. Les noms des services doivent être identiques aux noms   │
 │ des scripts présents dans /etc/init.d et doivent être séparés par des     │
 │ espaces. Si la liste est vide, aucun service ne sera redémarré.           │
 │                                                                           │
 │ Si d'autres services ne fonctionnent plus correctement après cette mise   │
 │ à jour, ils devront être redémarrés. Il est fortement recommandé de       │
 │ redémarrer le système pour éviter les problèmes liés à SSL.               │

Une fois le serveur redémarrer la date de compilation du package SSL doit être du 8 Avril 2014 (ou postérieure). Notez que la version ne changera pas :

# openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Apr 8 10:05:11 UTC 2014

Et voilà, une belle frayeur.

pour plus d'infos techniques (payload, heartbeat, etc) rdv chez stackexchange, branchez-vous et zdnet