Une préparation efficace face à la vulnérabilité d'OpenSSL 3.x.
Mise à jour (1er novembre 2022) : La diffusion de contenu d'Akamai via HTTP et HTTPS n'est pas affectée par cette vulnérabilité, car les serveurs utilisent une version d'OpenSSL non touchée. En outre, les systèmes Akamai utilisent des mécanismes de protection de l'infrastructure conforme aux normes du secteur, qui atténueraient le vecteur d'attaque décrit. Akamai applique les correctifs à tous les systèmes internes potentiellement concernés, mais d'après nos prévisions, ces efforts n'entraîneront aucun temps d'arrêt pour nos clients.
Le 25 octobre, l'équipe de projet d'OpenSSL a annoncé la publication d'un correctif de sécurité pour une vulnérabilité critique dans OpenSSL version 3.x. Ce correctif doit être publié le 1er novembre 2022, entre 13 h et 17 h UTC.
Cette annonce a fait beaucoup de bruit en raison de l'utilisation étendue d'OpenSSL. Avec cet article, nous espérons surmonter le vacarme afin de fournir un peu de contexte ainsi que des conseils pour détecter et atténuer la menace sans spéculation. La première partie de ce billet décrit OpenSSL et la portée de la vulnérabilité. La deuxième partie décrit l'utilisation d'OpenSSL dans les applications et fournit des outils pour détecter les ressources vulnérables. N'hésitez pas à passer directement à cette partie, si vous le souhaitez.
Remarque : ce billet de blog couvre un incident en cours d'évolution et sera mis à jour à mesure de l'arrivée de nouvelles informations et de la publication du correctif.
Quelle est la portée de cette vulnérabilité ?
Cette vulnérabilité a suscité des inquiétudes au sein de la communauté de sécurité, car il est inhabituel pour l'équipe d'OpenSSL de noter une vulnérabilité comme critique, même si elle a ensuite été rétrogradée comme "élevée." Depuis l'introduction de ces étiquettes de vulnérabilité après Heartbleed (une vulnérabilité ayant entraîné une fuite de mémoire et une possible divulgation de données sensibles), il n'y en a eu qu'une seule autre (CVE-2016-6309) qui a été classée comme "critique."
D'après les critères de l'équipe d'OpenSSL, pour être classée comme critique, une vulnérabilité doit affecter les configurations courantes et être susceptible d'être exploitable. Ces vulnérabilités peuvent inclure par exemple « une divulgation significative du contenu de la mémoire du serveur (révélant potentiellement des informations des utilisateurs), ou des vulnérabilités qui peuvent être facilement exploitées à distance pour compromettre les clés privées de serveur ou avec lesquelles l'exécution de code à distance est considérée comme probable dans des situations courantes ».
Dans la mesure où la bibliothèque OpenSSL est très répandue, toute vulnérabilité qu'elle contiendrait pourrait s'avérer dangereuse. Cependant, bien qu'il soit nécessaire de rester vigilant, il n'y a pas encore de raison de paniquer. La bibliothèque OpenSSL est très courante, mais sa version la plus répandue est la 1.X.X, or cette vulnérabilité affecte uniquement les versions OpenSSL 3.0.0 et supérieures (publiées seulement en septembre 2021). Par conséquent, cette vulnérabilité sera probablement moins courante que la distribution de la bibliothèque OpenSSL elle-même.
Nous avons exécuté nos outils de détection sur certains de nos réseaux gérés et nous en avons tiré les conclusions suivantes :
Environ 50 % des environnements surveillés avaient au moins une machine avec au moins un processus qui dépend d'une version vulnérable d'OpenSSL.
Parmi ces réseaux, le pourcentage de machines du réseau qui dépendaient d'une version vulnérable d'OpenSSL allait de 0,2 % à 33 %.
La couverture médiane était de 6,1 % et la moyenne était de 11,3 % avec un écart-type de 11,6 %.
Ces statistiques ne prennent pas en compte l'utilisation de versions non vulnérables d'OpenSSL. Le seul indicateur mesuré concerne les machines avec au moins un processus qui dépend d'une version vulnérable d'OpenSSL (3.0–3.6). Les autres processus exécutés sur la même machine n'ont pas été pris en compte.
Qu'est-ce qu'OpenSSL ?
OpenSSL est une boîte à outils logicielle open source. Par conséquent, les versions OpenSSL sont essentiellement des publications de code source. Cependant, en matière de détection, cela signifie qu'il existe une multitude de façons dont une application peut dépendre d'OpenSSL, d'où la gravité de cette vulnérabilité.
Tout d'abord, nous devons définir les trois composants d'OpenSSL.
libcrypto : bibliothèque cryptographique avec mise en œuvre de nombreux protocoles (par exemple AES, RSA, ChaCha, etc.)
libssl : bibliothèque mettant en œuvre tous les protocoles TLS jusqu'à la version TLSv1.3
openssl : utilitaire de ligne de commande pour diverses opérations (par exemple, la génération de certificats)
Pour qu'une application s'appuie sur OpenSSL, elle doit appeler une logique de code de libcrypto ou libssl (openssl elle-même étant une application qui s'appuie sur les deux bibliothèques précédentes).
Atténuation de la vulnérabilité d'OpenSSL
La première étape pour atténuer cette menace consiste à détecter les ressources vulnérables. Bien que ce conseil soit fréquemment donné, il est rarement accompagné de méthodes pratiques. Nous fournissons une liste des applications vulnérables connues (ci-dessous), ainsi qu'une méthode générale pour trouver les applications vulnérables dans votre réseau.
Segmentation : pour atténuer la vulnérabilité avant et après le correctif
Bien que l'application du correctif ne soit pas possible immédiatement, étant donné que la dépendance vis-à-vis d'OpenSSL provient essentiellement de logiciels de fournisseurs (qui doivent appliquer eux-mêmes le correctif), nous pouvons malgré tout tirer parti de la visibilité que la détection peut nous offrir. Ainsi, nous pouvons utiliser la segmentation et le routage pour réduire la portée des attaques des pirates qui exploiteraient cette vulnérabilité.
Nous pouvons imposer d'autres restrictions sur les ressources connectées à Internet, sous la forme d'une zone démilitarisée (plus stricte).
Nous pouvons augmenter la segmentation du domaine, de sorte qu'une machine interne compromise ne puisse pas être utilisée pour attaquer l'ensemble du réseau. Cette méthode peut également être utilisée pour réduire la surface d'attaque d'une machine vulnérable à la partie du réseau avec laquelle elle a réellement besoin de communiquer.
En outre, nous pouvons tirer parti de cette visibilité et de cette détection pour créer un plan d'action de correction et garantir qu'aucun aspect n'est ignoré. Une fois les correctifs publiés et le processus de correction terminé, nous pourrons exécuter à nouveau la logique de détection et comparer les résultats. Dans l'idéal, il ne restera plus aucune machine vulnérable.
Quelles sont les applications vulnérables connues ?
BoringSSL (utilisée dans Google Chrome) et LibreSSL sont deux bibliothèques basées sur le code OpenSSL et qui ne sont pas encore affectées par la vulnérabilité à venir.
Différentes distributions Linux s'appuient fréquemment sur la bibliothèque OpenSSL. Si vous exécutez un environnement Linux, vous pouvez vérifier si vous utilisez l'une des versions suivantes, qui sont associées aux versions d'OpenSSL vulnérables.
Red Hat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
Si vous utilisez une distribution Linux qui ne figure pas dans cette liste, vous n'êtes pas nécessairement à l'abri des vulnérabilités. Si vous avez activement mis à jour la bibliothèque (dans le cadre d'une commande de mise à niveau d'un gestionnaire de package, par exemple), vous serez également vulnérable. Vous pouvez saisir « openssl version » dans votre terminal pour rechercher la version de la bibliothèque.
Docker a également publié son avis concernant le correctif à venir, estimant qu'environ 1 000 référentiels d'images pourraient être affectés sur diverses images Docker Official Images et Docker Verified Publisher. Cela inclut les images qui sont basées sur des variations des distributions Linux mentionnées ci-dessus.
Certains cadres pourraient également être affectés. Node.js v18.x et v19.x utilisent OpenSSL 3 et sont donc considérés comme affectés par la vulnérabilité. Toute nouvelle information à ce sujet sera publiée dans cet .
Un autre sujet d'inquiétude pour les développeurs réside dans le langage de programmation Golang. Les bibliothèques de fichiers binaires Go sont liées de façon statique, ce qui aurait pu obliger les développeurs Go à recompiler leurs logiciels. Lorsque l'équipe Golang a annoncé la publication de nouvelles versions mineures incluant des correctifs de sécurité à la même date que le prochain correctif OpenSSL, de nombreuses personnes ont supposé que les deux étaient liés. Ne vous inquiétez pas : c'était une fausse alerte. Les versions de Golang sont sans rapport avec la vulnérabilité à venir.
La liste des applications vulnérables devrait s'allonger au cours des prochains jours. Nous mettrons donc ce billet à jour en conséquence. Les sections suivantes vous fourniront des méthodes et des outils de détection pour vous aider à déterminer quelles applications de votre environnement utilisent OpenSSL 3 et sont donc vulnérables. Si vous le souhaitez, vous pouvez passer directement aux mécanismes de détection.
Méthode générale de détection des applications utilisant OpenSSL 3
Remarque : Cette section présente les détails internes de l'utilisation d'OpenSSL par une application. Si vous vous intéressez uniquement à la méthode de détection, vous pouvez accéder directement à nos règles YARA ou requêtes OSQuery.
OpenSSL peut être lié à une application de manière statique et dynamique. Avec la liaison statique, le code source d'OpenSSL est inclus dans le code de l'application et les deux sont compilés ensemble dans le même fichier binaire. Avec la liaison dynamique, OpenSSL est compilé séparément dans une bibliothèque partagée (libssl.dll et libcrypto.dll sous Windows ; libssl.so et libcrypto.so sous Linux). Le code de l'application contient alors des références dans la bibliothèque partagée, qui sont résolues par le système d'exploitation lorsqu'il charge l'application.
Que cela signifie-t-il pour la détection ? En pratique, une méthode pour détecter les fichiers binaires compilés de façon statique suffira. Pourquoi ? En effet, si une application en cours d'exécution charge OpenSSL de façon dynamique, ou même si elle charge de façon dynamique une bibliothèque qui charge à son tour OpenSSL de façon dynamique (et ainsi de suite), une bibliothèque OpenSSL compilée de façon statique finira par être chargée. Comme tous les chargements dynamiques sont effectués dans le cadre du même processus, il suffit de parcourir la liste des bibliothèques chargées dans chaque processus pour trouver celle qui est compilée de façon statique.
Nous devons donc comprendre à quoi ressemble une bibliothèque OpenSSL compilée de façon statique. Heureusement, c'est assez simple. Toutes les compilations statiques d'OpenSSL contiennent une chaîne de version, qui se présente comme suit : OpenSSL 3.0.6 11 Oct 2022, où 3.0.6 correspond au numéro de la version. La détection de cette chaîne est assez simple et peut se faire avec Regex ou YARA.
Cette méthode n'est sans doute pas parfaite. Comme OpenSSL est un code open source, les utilisateurs peuvent facilement modifier la logique de gestion des versions en fonction de leurs besoins (ce qui entraîne l'échec de notre méthode de détection). Nous n'avons vu ce problème se produire qu'une seule fois (avec Cisco, qui utilisait la chaîne CiscoSSL 1.1.1k.7.2.225 à la place), mais il peut se produire également avec d'autres fournisseurs.
Que dois-je faire ?
Même si nous n'en saurons pas beaucoup plus avant la publication du correctif, les défenseurs peuvent prendre certaines mesures préventives pour s'y préparer. Notre équipe a créé des utilitaires que vous pouvez exécuter dans votre environnement pour gagner en visibilité et faciliter l'atténuation. Les clients d'Akamai Guardicore Segmentation disposant de sa fonctionnalité d'informations activée peuvent facilement exécuter cette logique dans leur environnement.
YARA
La règle principale que nous pouvons écrire concerne la chaîne que nous avons mentionnée ci-dessus. Pour plus de concision, nous limiterons notre détection aux versions d'OpenSSL qui sont affectées par le correctif, mais nous pouvons facilement modifier nos critères.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
Si nous ne voulons pas nous appuyer sur cette chaîne, nous pouvons également rechercher l'application principale qui dépend d'OpenSSL, mais en analysant les importations de l'exécutable. Cependant, il ne faut pas oublier que cette méthode est moins infaillible.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
À l'aide des requêtes ci-dessus, nous pouvons également utiliser la table YARA d'osquery pour exécuter ces règles sur tous les processus en cours d'exécution.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
Bien sûr, vous pouvez également intégrer les autres règles YARA que nous avons mentionnées, ou ajouter plus ou moins de filtres pour réduire ou élargir le nombre de fichiers vérifiés.
Synthèse
L'équipe d'OpenSSL a adopté une approche intéressante en informant les équipes de sécurité de la publication à venir du correctif. Cette annonce a donné aux défenseurs le temps de se préparer et de mettre en file d'attente les ressources critiques pour l'application du correctif. Ce billet de blog est précisément destiné à vous y aider, en localisant les applications et les ressources auxquelles le correctif devra être appliqué le jour de sa publication.
Cette histoire n'est pas encore terminée, c'est pourquoi nous mettrons à jour ce billet de blog à mesure que de nouvelles informations seront publiées, alors n'oubliez pas de le consulter régulièrement. Vous pouvez également nous suivre sur Twitter pour obtenir plus d'informations en temps réel.