HTTPCSLeader européen de la cyber sécurité

Faille de sécurité Heartbleed

HeartBleed OPENSSL : Explication et exploit [FR]


1.HeartBleed
1.2. Est-elle une faille aussi dangereuse que ça ?
1.2.1. L'exploit du bug est-il détectable par les IDS ?
1.2.2. Origine
1.2.3. Qui l'a découverte ?
1.2.4. Pourquoi ce nom bizarre ?
1.3. Identification de la faille
1.3.1. Est-ce la fin précoce de SSL ?
1.3.2. Quelles sont les versions OpenSSL affectées ?
1.4. Comment savoir que mon serveur en est vulnérable ?
1.4.1. Y a -t-il un outil pour tester si mon serveur est vulnérable ?
1.4.2. Je n'utilise ni Apache ni Nginx: suis-je en sécurité ?
1.5. Mon serveur est affecté: que devrais-je faire ?
2. Détails techniques
2.1. Introduction aux protocoles SSL & TLS
2.1.1. Fonctionnement du protocole SSL/TLS
2.2. L'extension HeartBeat
2.2.1. Le format de Heartbeat Hello
2.2.2. Le protocole Heartbeat
2.2.3. Les messages Heartbeat
3. Preuve de concept
3.1. Organisation du code
3.2 Résultats obtenus
3.2.1 Remarque sur la performace
3.3. Conclusion
Bibliographie

1.HeartBleed

Par son développement constant, l'Internet est non seulement la convoitise des utilisateurs malveillants de tout bord, mais il est également devenu la victime de son propre progrès.

Dangereuse, incroyable, très importante ... tels sont les qualificatifs donnés par les experts de la sécurité informatique à la faille HeartBleed qui vient d'être publiée ce 07 avril 2014. [1]

Au delà des soubresauts médiatiques, nous tentons de clarifier les tenants et les aboutissants de cette faille et de répondre aux questions que les clients de notre produit HTTPCS pourraient se poser sans trouver nécessairement de réponse dans la littérature dédiée à ce sujet; ce qui sera le contenu de la première partie de ce document. Ensuite, nous passerons aux détails techniques qui entourent ce bug, pour finir avec une mise en place d'une preuve de concept qui sensibiliserait nos clients HTTPCS sur la nécessité d'installer le patch remédiant à cette faille.

1.2. Est-elle une faille aussi dangereuse que ça ?

Théoriquement, on pourrait récupérer tout de la mémoire du serveur qui en est vulnérable, y compris des données aussi sensibles que les certificats X.509, et ce sans avoir recours à des privilèges particuliers.[2]

1.2.1. L'exploit du bug est-il détectable par les IDS ?
Non. D'ailleurs c'est l'une des raisons pour laquelle HeartBleed est qualifiée comme l'une des plus dangereuses failles par les experts en sécurité.

1.2.2. Origine
La faille HeartBleed fut introduite par Stephen Henson juste une heure avant le réveillon de la Saint-Sylvestre de l'an 2011. Pour être plus précis, c'était Robin Seggelmann, qui était alors un étudiant préparant sa thèse de doctorat à l'université de Duisburg-Essen, qui a conçu l'extention HeartBeat pour OpenSSL (déja spécificée dans le standard SSL2.0) et l'a suggérée au développeur en chef du projet OpenSSL Stephen Henson qui n'a pas détecté la faille dans le code qu'il venait de recevoir. Voilà donc pour la petite histoire.

1.2.3. Qui l'a découverte ?
La faille est découverte le 07 avril, 2014 par Neel Mehta qui travaillait alors pour le groupe Google Security et a recommandé la rectification du bug ainsi que la mise à jour de la version OpenSSl en cours [1]. Deux de ses collègues ont procédé à la correction.

1.2.4. Pourquoi ce nom bizarre ?
C'est la question des curieux. Afin de comprendre pourquoi le coeur (heart) d'un serveur saigne (bleed), il suffit de patienter un peu jusqu'à ce que nous arriverons au Chapitre 2 qui suit.

1.3. Identification de la faille

Si vous êtes développeur, cette section est faite pour vous. Sur le site de Github vous pouvez chercher le dépôt du code source du projet OpenSSL et vous pointer sur ce fichier:

openssl -> openssl -> blob -> master -> ssl -> t1_lib.c

Tout comme vous pouvez cliquer directement sur ce lien, où vous pouvez voir où se situe la faille en vous positionnant sur la ligne 1480 où vous pouvez lire ce bout de code:

buffer = OPENSSL_malloc(1 + 2 + payload + padding);

C'est cette ligne qui est à l'origine de la faille car elle permet de lire des zones mémoires aléatoires du serveur du moment où aucun contrôle n'a été effectué avant d'allouer la zone mémoire indiquée par la variable buffer.

1.3.1. Est-ce la fin précoce de SSL ?
Non. Il faut comprendre que SSL n'est qu'un protocole. Ce n'est pas ce standard qui pose problème mais ses (car il en existe plusieurs) implémentations . Plus précisément, seule OpenSSL, qui en est une variante opensource se trouve affectée par notre fameuse faille HeartBleed.

1.3.2. Quelles sont les versions OpenSSL affectées ?
Sont affectées les versions allant de 1.0.1 (14 mars 2012) à 1.0.2 (24 février 2014 (beta)).

VersionDate
1.0.114 mars 2012
1.0.2 (beta)24 février 2014
TABLEAU 1.1: Les versions OpenSSL vulnérables

Evidemment, il faut compter la liste de versions existantes entre les deux que nous venons de mentionner. Autrement dit, il faut ajouter à celà toutes les versions OpenSSL 1.0.1ω , où ω ∈ {a, b, c, d, e, f}.

1.4. Comment savoir que mon serveur en est vulnérable ?

Maintenant que vous savez que seule l'implémentation OpenSSL du protocole SSL/TLS qui est affectée par HeartBleed, vous comprenez bien que seuls les serveurs web qui en font usage (d'OpenSSL) sont vulnérables.

Si vous utilisez, comme la majorité, les serveurs web Apache ou Nginx, forte est la probabilité que votre machine en est atteinte. En effet, une étude a montré que 70% des machines font appels à ces deux serveurs web qui utilisent OpenSSL: [3]


Apache Ngnix
FIGURE 1.1: Utilisation des serveurs web à travers le monde

Selon une étude récente, 17.5% des sites faisant appel au protocole SSL ont fonfiguré l'extention HeartBeat avant la découverte de la faille HeartBleed [4]. Nous le rappelons quand même, si votre machine utilise le protocole SSL il n'y a aucune raison de vous inquiéter si OpenSSL n'y est pas déployée dans votre réseau: par exemple le serveur IIS (Internet Information Services) de MicroSoft utilise sa propre implémentation du protocole SSL qui est SChannel qui n'intègre pas l'extension HeartBeat de la même façon qu'OpenSSL le fait.



Apache Ngnix HeartBeat
FIGURE 1.2: Configuration de l'extension HeartBeat par adresses IP


1.4.1. Y a -t-il un outil pour tester si mon serveur est vulnérable ?
Des logiciels et des applications en ligne sont déjà mis en place pour tester la vulnérabilité ou non de votre serveur à la faille HeartBleed. HTTPCS a développé son propre outils simple d'utilisation et efficace. Nous vous invitons à l'utiliser.

1.4.2. Je n'utilise ni Apache ni Nginx: suis-je en sécurité ?
Pas nécessairement. Il faut bien vérifier l'architecture de votre réseaux. Prenons un bon exemple pour clarifier la situation: l'organisme qui héberge le fameux site StackOverFlow possède un réseaux où toutes les applications .NET sont hébergées sur des serveurs IIS [5] alors que la répartition des charges est assurée par HAProxy et la terminaison SSL est léguée pour Nginx. En résumé, comme nous l'avons dit, il faut bien vérifier l'architecture réseau que vous avez déployée même si au premier abord il vous semble que vous n'utilisez pas Apache ou Nginx.

1.5. Mon serveur est affecté: que devrais-je faire ?

Il vous faut logiqment mettre à jour la version d'OpenSSL que vous utilisez à la version 1.0.1g. Sur une machine Linux vous pouvez exécuter cette commande:

sudo apt -get install openssl -server

Au cas où vous ne souhaitez pas passer à une nouvelle version pour une raison ou une autre, vous pouvez simplement corriger le bug vous-même et compiler votre outil OpenSSL.

Il ne faut surtout pas oublier de modifier vos mots de passe.

2. Détails techniques

2.1. Introduction aux protocoles SSL & TLS

Le protocole SSL a été introduit en 1994 par la société NetScape sous sa version 2.0 afin de sécuriser les opérations de payement en ligne [6]. Vu les failles de sécurité détectées, la version SSL3.0 a vite été mise en place. Au cours de la même année (1999), le protocole TLS a vu le jour et a été implémenté sous sa première version TLS1.0. Ce dernier n'est autre qu'une mise à jour de la version SSL3.0 elle-même.

2.1.1. Fonctionnement du protocole SSL/TLS
Le protocole SSL/TLS assure le cryptage, l'authentification ainsi que l'intégrité des données échangéees.

La procédure SSL/TLS-handshake est précédée par TCP-handshake qui se trouve suivie d'un ensemble d'opérations plus ou moins compliquées lors desquelles des éléments importants sont négociés: négociation des types de chiffrement, authentification, échange de clés et établissement d'une session. Vu que la réalisation de ce procédé est lourde, au lieu de l'effectuer pour chaque nouvelle requête, une technique a été mise en place pour les protocoles HTTP et TCP; elle est appelée keep-alive et permet donc le maintien de la session afin d'effectuer une chaîne de requête évitant ainsi la création d'un canal de communication avec réinitialisation de la connexion pour chaque requête. Le protocole SSL/TLS a mis en place une technique similaire mais plus performante, et ce grâce à l'extension HeartBeat.


SSL TLS Handshake
FIGURE 2.1: Le protocole SSL/TLS handshake classique [9]


2.2. L'extention HeartBeat

HeartBeat est une extension ajoutée au protocole SSL/TLS afin de maintenir une session de communication entre deux machines en vie pour la durée du temps requis. Elle sert aussi à détecter si un destinataire n'est pas en panne avant que l'émetteur ne lui envoie des données.

2.2.1. Le format de Heartbeat Hello
Une machine peut déclarer qu'elle supporte l'extension HeartBeat et si elle souhaite ou non recevoir des réponses à ses requêtes du type de cette exension grâce à cette structure de données:

enum {
   peer_allowed_to_send (1),
   peer_not_allowed_to_send (2),
  (255)
} HeartbeatMode;

struct {
   HeartbeatMode mode;
} HeartbeatExtension;

Le champ peer_allowed_to_send est mis à ON si la machine souhaite recevoir des réponses quant à ses requêtes HeartBeat. Ce qui devra ensuite être souligné par le mode en mettant HeartBeatMode à 1 ou 2, selon le cas.

2.2.2. Le protocole Heartbeat
Le protocole HeartBeat est défini suivant ces 2 messages:

enum {
  heartbeat_request(1),
  heartbeat_response (2),
  (255)
} HeartbeatMessageType

La longueur totale du message HeartbeatMessage ne doit pas dépasser 64 ko, c'est à dire la taille de max_fragment_length [7]. Le contenu plus en détails de ce message est listé dans la sous-section suivante.

2.2.3. Les messages HeartBeat
struct {
  HeartbeatMessageType type;
  uint16 payload_length;
  opaque payload[HeartbeatMessage.payload_length];
  opaque padding[padding_length];
} HeartbeatMessage;

Où:

♦ Type: heartbeat_request/heartbeat_response, il est toujours de longueur d'un (1) octet.
♦ Payload: contenu arbitraire, il est toujours de longueur 2 octets.
♦ Padding: contenu arbitraire toujours ignoré par le récepteur.
♦ padding_length=TLSPlaintext.length - payload_length - 3 pour TLS
                                      et
  DTLSPlaintext.length- payload_length - 3 pour DTLS.
♦ padding_length>=16. [8]

3. Preuve de concept

Télécharger HTTPCS-HeartBleed (Merci de vous connecter)


3.1. Organisation du code


Structure du code
FIGURE 3.1: Structure de l'outil HTTPCS-HeartBleed


3.2. Résultats obtenus

Après l'exécution du programme:


exécution
FIGURE 3.2. Exécution de l'outil HTTPCS-HeartBleed


... nous avons botenu les résultats suivants (nous ne vous en montrons qu'un tout petit échantillon):


résultats
FIGURE 3.3. Données récupérées depuis la cible (échantillon)


3.2.1. Remarque sur la performance
Afin de tirer une meilleure performance du code, nous pouvons l'automatiser de façon à pouvoir l'exécuter pendant plusieurs heures, et balayer ainsi une large zone mémoire du serveur ciblé et augmenter la chance de récupérer des données plus ou moins sensibles. Pour des raisons d'éthique et juridiques, nous nous sommes contentés d'une seule attaque.

3.3. Conclusion

Il est remarquable que cette faille qui date depuis la fin de l'année 2011, n'a pu être communiquée qu'en avril 2014, et ce malgré son envergure et sa dangerosité. Dans un sens, c'est encore plus décevant pour un logiciel opensource supposé être plus fiable qu'un logiciel propriétaire vu la communauté de développeurs dont il est censé bénéficier. Comment se fait-il que nous sommes arrivés là ?

Justement, une explication partielle réside dans le fait que le développement d'OpenSSL est pris en charge par deux développeurs uniquement, pour ne pas dire un -puisque seul Stephan Henson y travaille à plein temps-, la révision du code ne peut pas être efficace dans ces conditions.

Nous disons que l'explication est partielle car vu la nature libre de ce logiciel, mais aussi son domaine d'application, il est censé être suivi de près par les développeurs en sécurité, sauf que ce n'est pas le cas, malheureusement. Plus que jamais, cette faille montre la nécessité de ne faire confiance qu'aux logiciels opensource ayant bénéficié d'une large communauté d'informaticiens ; de même, l'organisme faisant usage de tels types de logiciels doit en réviser le code (ce qui est un luxe que ne possède que peu d'entreprises).

Ceux qui ont été victimes de cette faille durant ces 2 dernières années n'ont, pourtant, fait que suivre les bonnes pratiques en vigueur, à savoir la mise à jour de leur version précédente à 1.0.1. Une question se pose alors: si vous mettez à jour votre version d'OpenSSL: êtes-vous à l'abri d'un drâme ? Si oui, jusqu'à quand ?

Bibliographie

[1]: OpenSSL Security Advisory Neel MEHTA, https://www.openssl.org/news/secadv_20140407.txt, April 7th , 2014
[2]: The Heartbleed Bug, Codenomicon, http://heartbleed.com/ , April 7th , 2014
[3]: April 2014 Web Server Survey, NetCraft, http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html , April , 2014
[4]: Half a million widely trusted websites vulnerable to Heartbleed bug, NetCraft, http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html , April, 2014
[5]: Stackoverflow.com: the road to SSL, Nick Craver, http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/, April 23rd , 2013
[6]: History of SSL, IBM, http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzain%2Frzainhistory.htm
[7]: RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions IETF, http://tools.ietf.org/html/rfc6066, Page 8, January, 2011
[8]: RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension IETF, http://tools.ietf.org/html/rfc6520, Page 5, February, 2012
[9]: RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0, http://tools.ietf.org/html/rfc6101, August 2011

Tester la sécurité de mon site web

HTTPCS Scanner screenshot desktop HTTPCS Scanner screenshot tablet HTTPCS Scanner screenshot phone