Vulnérabilité Heartbleed : Risques au sein de votre réseau

2 mai 2014
Oliver Tavakoli
Chief Technology Officer
Vulnérabilité Heartbleed : Risques au sein de votre réseau

On a beaucoup parlé de l'impact mondial de Heartbleed. Tout d'abord, nous avons eu droit à toutes les descriptions de Heartbleed - ma préférée étant celle de xkcd. Ensuite, nous avons vu des avertissements indiquant que nous devions changer notre mot de passe sur les sites web publics. Puis il y a eu un avertissement selon lequel, puisque les clés privées des certificats pouvaient être récupérées en exploitant Heartbleed, nous devions changer nos mots de passe maintenant, attendre que les sites web changent leurs certificats et ensuite changer à nouveau nos mots de passe.

Ce qui a reçu beaucoup moins d'attention, c'est le fait que de nombreux produits d'entreprise courants (par exemple, les routeurs, les pare-feu, les proxies web) au sein de notre infrastructure sont également susceptibles d'être affectés par Heartbleed. Les bulletins de Cisco, Juniper Networks et Blue Coat indiquent une utilisation répandue d'OpenSSL, le logiciel dans lequel se trouve le bogue Heartbleed, dans ces produits. Même les systèmes de contrôle industriel d'entreprises telles que Siemens présentent cette vulnérabilité, sur laquelle Arik Hesseldahl a récemment écrit sur Re/code.net. Et, contrairement aux sites web publics, dont beaucoup ont déjà fait l'objet de mises à jour pour corriger le bogue, la disponibilité et le déploiement de correctifs pour tous vos systèmes d'infrastructure vous touchent de manière inattendue, notamment par la nécessité de passer à des versions de logiciels plus récentes que celles que vous utilisez probablement, ce qui nécessite des cycles de test avant que vous puissiez les déployer.

Comment fonctionne le bug Heartbleed
Comment fonctionne le bug Heartbleed par xkcd

Évaluation de la vulnérabilité Heartbleed dans les réseaux internes

Pour commencer, si les adresses IP utilisées pour gérer vos routeurs, pare-feu et autres systèmes d'infrastructure sont accessibles depuis l'internet sans accès VPN (considéré comme une mauvaise pratique de sécurité), vous devriez être très inquiet et avoir soit supprimé l'accès direct, soit corrigé votre système à ce jour. En supposant que les adresses IP de gestion ne soient accessibles que depuis l'intérieur de votre réseau, le scénario le plus défavorable est le suivant :

  1. Un pirate s'introduit dans votre réseau via malware ou une autre forme d'attaque ;
  2. L'attaquant effectue une reconnaissance et trouve les interfaces de gestion de vos systèmes d'infrastructure ;
  3. L'attaquant utilise la présence de Heartbleed dans ces systèmes d'infrastructure pour lire la mémoire des systèmes, récupérer les informations d'identification administratives récemment utilisées pour se connecter au système et, éventuellement, même la clé privée du certificat sécurisant la connexion ; \N- L'attaquant utilise la présence de Heartbleed dans ces systèmes d'infrastructure pour lire la mémoire des systèmes.
  4. L'attaquant utilise les informations d'identification volées pour se connecter et reconfigurer le système ou, s'il ne s'agit pas uniquement d'informations d'identification de compte local, pour accéder à d'autres ressources non liées.

Évaluation pas à pas des risques liés à la vulnérabilité Heartbleed

Étape 1 : Supposons un compromis

‍Acceptezque cela puisse vous arriver ; les organisations ont malware des violations tout le temps, nous devrions donc supposer que cela s'est produit ou peut se produire.

Étape 2 : Mise en œuvre d'une solution de détection des menaces

Nous espérons que vous disposez d'une solution de sécurité pour détecter les scans effectués lors de la phase de reconnaissance d'une attaque ciblée. Si ce n'est pas le cas, nous vous en proposons une à évaluer et à déployer.

Étape 3 : Protection contre les exploits internes de Heartbleed

Un attaquant qui se trouve maintenant à l'intérieur de votre réseau et qui utilise Heartbleed pour accéder à votre système d'infrastructure est évidemment très inquiétant. Ce serait formidable si vous disposiez d'une solution de sécurité capable de détecter de telles attaques à l'intérieur de votre réseau. Si ce n'est pas le cas, nous nous ferons un plaisir de vous en fournir une que vous pourrez évaluer et déployer ;-) Alors que la plupart des articles de presse récents se sont concentrés sur le vol de clés privées, la perte de la clé privée s'avère moins menaçante dans un réseau d'entreprise.

Pour utiliser la clé privée, l'attaquant doit soit écouter les autres connexions au même système, soit être en mesure d'usurper l'identité du système. À l'époque des concentrateurs, lorsque l'Ethernet était vraiment un média partagé, il suffisait de placer la carte d'interface réseau en mode "promiscuous" pour écouter le trafic d'une autre machine. Mais avec les commutateurs, vous ne voyez que le trafic diffusé, multidiffusé ou destiné à votre machine.

La méthode classique d'usurpation d'identité est l'ARP et ne fonctionne que sur le sous-réseau où se trouve l'hôte de l'attaquant. Si les interfaces de gestion des systèmes se trouvent sur un sous-réseau distinct, souvent même sur un VLAN distinct, l'usurpation d'identité par ARP ne fonctionnera pas. Ainsi, même si le pirate peut accéder à la clé privée du système, l'exploitation de la disponibilité de la clé privée n'est pas aussi simple qu'il n'y paraît. Le contraste est saisissant avec le problème posé par Heartbleed aux sites web publics : ils ne peuvent pas supposer que le trafic ne peut pas être espionné en amont et, avec toutes les astuces DNS existantes, ils ne peuvent pas non plus supposer que quelqu'un ne sera pas en mesure d'usurper leur identité avec succès.

Étape 4 : Gérer les informations d'identification et la sécurité de l'identité

C'est à ce moment-là que la véritable inquiétude s'installe. Si vous avez suivi les meilleures pratiques de sécurité et intégré l'authentification administrative sur vos systèmes d'infrastructure avec une infrastructure standard de gestion des identités (par exemple Active Directory), les informations d'identification qui ont été volées seront probablement les clés du royaume. Elles peuvent être utilisées pour accéder au système lui-même ou à tout ce à quoi les administrateurs du système peuvent accéder.

Identifier la surface d'attaque Heartbleed dans vos réseaux internes

Vous pouvez patcher tous vos routeurs, commutateurs et pare-feu, mais vous oubliez de patcher une imprimante dans un endroit obscur qui a la même intégration d'authentification que votre infrastructure la plus importante.

Ce n'est qu'une question de temps - en fait, c'est probablement déjà le cas - avant que nous ne voyions des attaques ciblées qui utilisent Heartbleed comme l'une des armes de l'arsenal des attaquants pour acquérir les informations d'identification des comptes clés et les utiliser pour accéder aux joyaux de la couronne.

En d'autres termes, Heartbleed est aussi désordonné à l'intérieur qu'à l'extérieur.

Foire aux questions

Qu'est-ce que Heartbleed (CVE-2014-0160) ?

Heartbleed est un bogue de sécurité dans la bibliothèque OpenSSL, qui permet à des pirates de lire des données sensibles dans la mémoire d'un serveur.

Quelles sont les mesures à prendre pour appliquer les correctifs Heartbleed aux systèmes internes ?

Pour corriger Heartbleed, les organisations doivent mettre à jour leurs bibliothèques OpenSSL avec la dernière version qui corrige le bogue. En outre, elles doivent révoquer et réémettre les certificats SSL/TLS et réinitialiser les mots de passe si nécessaire afin de s'assurer qu'aucun identifiant compromis n'est utilisé.

Comment les attaquants exploitent-ils Heartbleed dans les réseaux internes ?

Les attaquants exploitent Heartbleed en envoyant des requêtes élaborées à un serveur vulnérable, qui répond alors avec des données sensibles provenant de sa mémoire. Il peut s'agir de noms d'utilisateur, de mots de passe, de clés privées et d'autres informations confidentielles.

Comment les solutions de sécurité peuvent-elles contribuer à atténuer les risques liés à Heartbleed ?

Les solutions de sécurité telles que les systèmes de détection d'intrusion (IDS), les pare-feu et les outils de gestion des vulnérabilités peuvent aider à détecter et à bloquer les exploits Heartbleed. Des mises à jour et des correctifs réguliers de ces solutions sont essentiels pour se protéger contre les vulnérabilités connues.

Y a-t-il eu des incidents récents impliquant des exploits Heartbleed ?

Bien que Heartbleed ait été le plus important en 2014, des incidents occasionnels se produisent encore lorsque les systèmes ne sont pas corrigés. Une surveillance régulière des avis de sécurité et des rapports d'incidents permet de se tenir informé des exploits récents.

Comment les organisations peuvent-elles détecter les vulnérabilités Heartbleed au sein de leur réseau ?

Les organisations peuvent détecter les vulnérabilités Heartbleed en utilisant des scanners de vulnérabilité et des outils conçus pour vérifier la présence du bogue Heartbleed dans leurs systèmes. Des audits réguliers et des évaluations automatisées de la sécurité sont également efficaces.

Quels sont les risques liés à l'absence de traitement de Heartbleed dans les systèmes internes ?

Si l'on ne s'occupe pas de Heartbleed, les systèmes internes sont vulnérables aux violations de données, aux accès non autorisés et à la perte potentielle d'informations sensibles. Cela peut entraîner des pertes financières, des atteintes à la réputation et des problèmes de conformité.

Quels sont les types d'infrastructures les plus menacés par Heartbleed ?

Les serveurs et les appareils utilisant des versions vulnérables d'OpenSSL sont les plus exposés. Il s'agit notamment des serveurs web, des serveurs de messagerie et de tous les appareils en réseau qui utilisent les versions d'OpenSSL concernées.

Comment les solutions de sécurité peuvent-elles contribuer à atténuer les risques liés à Heartbleed ?

Les effets à long terme comprennent une sensibilisation accrue à la nécessité d'effectuer des mises à jour régulières de la sécurité et d'améliorer les pratiques de sécurité. Les organisations peuvent également mettre en œuvre des contrôles plus stricts et des programmes de gestion des vulnérabilités plus rigoureux.

Quelles sont les meilleures pratiques permettant de prévenir les exploits Heartbleed dans les réseaux internes ?

Les meilleures pratiques consistent à maintenir OpenSSL à jour, à rechercher régulièrement les vulnérabilités, à mettre en place des contrôles d'accès stricts et à sensibiliser le personnel à l'hygiène de sécurité. Des audits de sécurité réguliers et des plans de réponse aux incidents sont également essentiels.