Avant de sécuriser les systèmes, nous devons comprendre ce que nous essayons de sécuriser et comment le faire. Aujourd’hui, nous explorons deux nouvelles vulnérabilités OpenSSL qui ont attiré l’attention de la communauté ce mois-ci.
Plus important encore, vous apprendrez à les corriger et à quel point ils ont un impact.
Quand tu sais que ça va arriver
Le 1er novembre 2022, l’équipe OpenSSL a publié un avis détaillant deux vulnérabilités très graves, CVE-2022-3602 et CVE-2022-3786 .
CVE-2022-3602 a été pré-annoncé comme un bogue critique, mais a ensuite été rétrogradé à élevé, provoquant des vagues de haine de la part de la communauté. Il est important de se rappeler que CVE-2022-3602 a été signalé en privé par Polar Bear le 17 octobre et, un jour plus tard, Viktor Dukhovni a signalé CVE-2022-3786 .
Il s’agit du premier problème à atteindre ce niveau de gravité depuis la fameuse vulnérabilité Heartbleed (CVE-2014-0160).
Dans cet article, nous détaillerons les deux nouvelles vulnérabilités OpenSSL, mais nous nous concentrerons sur les détails techniques de CVE-2022-3602.
Qu’est-ce qu’OpenSSL et comment est-il utilisé ?
La bibliothèque OpenSSL est employée pour des fonctions cryptographiques, notamment dans le cadre de connexions réseau.
Par exemple, les serveurs Web utilisent fréquemment OpenSSL pour créer des connexions chiffrées. OpenSSL est également utilisé par les serveurs de messagerie et les technologies VPN comme OpenVPN pour créer des canaux de communication sécurisés. Une large gamme de produits, y compris des périphériques réseau, des systèmes embarqués et des images de conteneurs, inclut la bibliothèque.
OpenSSL a trois composants principaux :
- libcrypto – une bibliothèque cryptographique avec la mise en œuvre de nombreux protocoles
- libssl – une bibliothèque implémentant tous les protocoles TLS jusqu’à TLSv1.3
- OpenSSL – un utilitaire de ligne de commande pour diverses opérations (par exemple, la génération de certificats)
Quelles sont ces vulnérabilités ?
Ces vulnérabilités sont des problèmes de corruption de mémoire , également connus sous le nom de buffer overrun/overflow, dans lesquels les attaquants peuvent être en mesure d’exécuter du code arbitraire sur la machine d’une victime et de la prendre en charge.
CVE-2022-3786
Débordement de tampon de longueur variable d’adresse e-mail X.509
La vulnérabilité réside dans l’analyse d’un certificat TLS après validation. Cela entraîne un débordement de quatre octets sur la pile. Un attaquant peut créer une adresse email illicite dans un certificat pour faire déborder un nombre d’octets contenant le ‘.’ (décimal 46) caractère sur la pile.
CVE-2022-3602
Adresse e-mail X.509 Débordement de mémoire tampon de 4 octets
CVE-2022-3602 est causé après l’analyse d’un certificat TLS. La différence est que la vulnérabilité se produit après la vérification de la contrainte de nom. Il est utile de noter qu’une autorité de certification de confiance devrait signer un certificat malveillant pour réussir.
Les statistiques, ou comment comprendre le niveau de menace
Quelle est donc l’ampleur du problème ?
De toute évidence, nous n’avons pas de nouvelle version de Heartbleed. Les exemples ci-dessous montrent comment moins d’instances sont affectées par rapport à Heartbleed. Nous avons collecté des données sur les instances qui exécutent des versions vulnérables d’OpenSSL de Shodan .
Comme vous pouvez le constater, il existe environ 550 000 instances exécutant des versions vulnérables d’OpenSSL. Il est important de noter que toutes ces instances ne sont pas réellement vulnérables car des facteurs importants tels que la disposition de la pile et les protections jouent un rôle majeur.
La plupart d’entre eux utilisent OpenSSL 3.0.0 où la fonction de décodage punycode a été introduite pour la première fois.
Les dernières versions d’OpenSSL sont incluses dans les versions les plus récentes de plusieurs distributions Linux populaires, telles que Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 et Fedora 36.
Docker estime également qu’environ 1 000 référentiels d’images pourraient être impactés sur diverses images Docker Official Images et Docker Verified Publisher.
Akamai a réalisé une étude sur son infrastructure où ils ont découvert qu’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 dans une certaine mesure d’une version vulnérable d’OpenSSL variait de 0,2 % à 33 %.
La communauté de la sécurité a beaucoup de travail à faire au cours des deux prochains mois. (Pourquoi cela arrive-t-il toujours à la fin de l’année ?)
Plongez en profondeur dans CVE-2022-3602
En plus d’un déni de service (DoS), ce CVE peut conduire à un RCE. Comprenons comment cette vulnérabilité fonctionne en détail. Pour cela, nous devons décompresser là où tout a commencé.
Ok, mais où est l’erreur des développeurs qui a conduit à cela ?
Les programmeurs ont une blague du genre « Si le code fonctionne, n’y touchez pas ! », sauf que cette fois nous l’appliquons dans un contexte de sécurité. Les développeurs d’OpenSSL ont introduit dans OpenSSL 3.0.0 une nouvelle fonction appelée ossl_punycode_decode qui fournit une fonctionnalité de décodage des noms de domaine punycode.
Maintenant, vous vous demandez peut-être ce qu’est le punycode et comment il cause une telle vulnérabilité à haut risque.
Punycode est une syntaxe d’encodage de transfert simple et efficace conçue pour être utilisée avec les noms de domaine internationalisés dans les applications (IDNA). Il transforme de manière unique et réversible une chaîne Unicode en une chaîne ASCII.
Les ordinateurs convertissent les domaines IDNA en domaines Punycode. Dans OpenSSL, le décodage ossl punycode prend un tampon de chaîne d’un domaine punycode et le convertit en Unicode pour un traitement supplémentaire.
Étant donné que cette vulnérabilité est un débordement de mémoire tampon, quelque part, les données dépassent la mémoire tampon et entraînent l’écrasement des emplacements de mémoire adjacents.
Dans CVE-2022-3602, cela se produit lors de la vérification du certificat X.509 . Cette vulnérabilité de codage apparaît dans la fonction de décodage ossl punycode , où elle est utilisée pour convertir les domaines Punycode en Unicode.
Cette vulnérabilité de codage permet à des attaquants distants d’exécuter du code sur la machine à l’aide d’un certificat TLS malveillant signé.
Vous pouvez voir le référentiel avec la fonction vulnérable ici .
Même si un attaquant réussit à surmonter tous les autres défis, il ne peut écrire qu’un seul élément de 4 octets dans la pile. Quatre octets étaient souvent suffisants pour remplacer un pointeur de retour sur une pile et exécuter du code arbitraire à l’époque, mais pas aujourd’hui. C’est parce que des protections telles que ASLR et Canaries arrêteront facilement cette attaque.
Comment savoir si je suis vulnérable ?
Il existe plusieurs façons de savoir si votre instance utilise une version vulnérable. Vous devez d’abord savoir que seules les versions OpenSSL 3.0.0-3.0.6 sont vulnérables à ces CVE. Passons en revue toutes les méthodes et détectons ces versions vulnérables.
Si vous souhaitez vérifier manuellement votre ou vos machines, vous devrez suivre une série d’étapes pour détecter la version d’OpenSSL en cours d’exécution.
Système
Taper ce qui suit dans un système d’exploitation Linux nous montrera la version OpenSSL utilisée sur le système. Si la version est comprise entre 3.0.0 et 3.0.6, vous êtes à risque et devez mettre à jour immédiatement.
Lié dynamiquement
Ensuite, nous devons creuser plus profondément et rechercher des processus chargés dynamiquement. Nous allons le faire en utilisant la commande lsof .
lsof | grep libssl.so.3
Nous avons également constaté que ces scripts étaient utiles pour la détection
Analyseur Linux et *Nix (script bash) : https://github.com/MalwareTech/SpookySSLTools/blob/main/openssl_scan.sh
Analyseur Windows (PowerShell) : https://github.com/MalwareTech/SpookySSLTools/blob/main/openssl_scan.ps1
Source : malwaretech.com
Logiciel lié statiquement
Vient maintenant la partie la plus difficile, car les logiciels compilés statiquement lsof ne détecteront pas les versions d’OpenSSL ni ces scripts. C’est pourquoi, pour les logiciels compilés statiquement , nous devrons utiliser la commande readelf .
readelf -a [binary] | grep -i osslpunycodedecode
Une autre méthode que nous avons trouvée utile consiste à appliquer l’expression régulière ci-dessous directement sur le binaire :
Unix-like: strings /path/to/executable | grep “^OpenSSL\s*[0-9].[0-9].[0-9]”
Windows: select-string -Path C:\path\to\executable.exe -Pattern “OpenSSL\s*[0-9].[0-9].[0-9]” -AllMatches | % { $.Matches } | % { $.Value }
Source : malwaretech.com
Je suis vulnérable, que dois-je faire maintenant ?
La bonne partie est qu’il est très facile de patcher votre système. Vous pouvez facilement atténuer la menace en mettant à jour la version d’OpenSSL.
Suivez ces étapes pour mettre à jour votre version OpenSSL vers 3.0.7
- wget https://www.openssl.org/source/openssl-3.0.7.tar.gz
- chmod +x openssl-3.0.7.tar.gz
- tar -zxf openssl-3.0.7.tar.gz
- cd ouvressl-3.0.7/
- ./config
- sudo apt installer faire gcc
- faire sudo
- faire un test sudo
- sudo mv /usr/bin/openssl ~/tmp
- sudo faire installer
- sudo ldconfig /usr/local/lib64/
- sudo ln -s /usr/local/bin/openssl /usr/bin/openssl
- sudo ldconfig
Après toutes ces commandes, nous obtenons la version OpenSSL 3.0.7 et nous avons maintenant une longueur d’avance sur les attaquants.
Prérequis d’exploitation
Maintenant que nous avons appris à patcher notre système, voyons les conditions dont nous avons besoin pour une attaque réussie. Il y a deux conditions importantes pour qu’une attaque réussie ait lieu.
- Premièrement et le plus important, l’attaque s’appuie soit sur une autorité de certification (CA) pour signer le certificat malveillant, soit sur l’utilisateur pour ignorer les avertissements et l’application pour ne pas vérifier correctement le certificat.
- Ensuite, les dispositions de pile et les protections apparaissent. Si la première condition échoue, ces deux facteurs peuvent facilement faire disparaître la menace.
Compte tenu de ce qui précède, ainsi que du fait que ces attaques sont complexes et difficiles à réaliser, nous pensons qu’il est très difficile d’obtenir l’exécution de code à distance (RCE) avec CVE-2022-3602.
À quel point devriez-vous être inquiet ?
Grâce à des personnes ouvertes d’esprit qui ont travaillé pour améliorer la sécurité, nous avons maintenant des protections (ASLR, stack NX, stack cookies) qui rendent l’exploitation des débordements de stack très complexe et difficile à réaliser. De plus, étant donné que cette vulnérabilité est pratiquement côté client, vous pouvez vous attendre à recevoir des avertissements. Ces CVE sont donc parfaits pour les utilisateurs qui cliquent sur « oui » sur tout sans lire au préalable.
Pour répondre à la question, il ne faut pas la négliger et penser qu’il est trop difficile pour un attaquant d’exploiter ces CVE. Vous devriez faire une mise à jour de sécurité vers OpenSSL 3.0.7 dès que possible.
FAQ
Q : Toutes les versions d’OpenSSL sont-elles vulnérables à ces vulnérabilités ?
R : Non, les bogues ont été introduits dans le cadre de la fonctionnalité de décodage Punycode (actuellement utilisé uniquement pour traiter les contraintes de nom d’adresse e-mail dans les certificats X.509). Ce code a été introduit pour la première fois dans OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1 et les autres versions antérieures ne sont pas affectées.
Q : Dois-je remplacer les certificats de mon serveur TLS ?
R : Non.
Q : Ces vulnérabilités sont-elles les mêmes que celles de Heartbleed ?
R : Non, en raison de la condition préalable qu’un client ou un serveur doit être configuré pour vérifier une adresse e-mail malveillante dans un certificat.
Q : Était-il possible de prévenir ces vulnérabilités plus tôt ?
R : La réponse est OUI . Cette vulnérabilité aurait pu être trouvée plus tôt avec un peu de fuzzing.
Q : Quel est le score CVSS pour ces vulnérabilités ?
R : Les deux CVE ont reçu un score CVSS de 7,5 (élevé).
Conclusion
De nombreuses personnes de la communauté de la cybersécurité ont critiqué la manière dont OpenSSL a géré l’annonce et la correction de ces vulnérabilités. Ils ont mis un peu de stress sur les gens en l’annonçant comme CRITIQUE et en rétrogradant plus tard à ÉLEVÉ.
Peut-être qu’il aurait été bien d’avoir un aperçu de la rétrogradation, mais, quand vous avez une petite équipe de sécurité qui doit trier et analyser jusqu’au dernier moment, ce n’est pas facile.
Nous devons apprécier leurs efforts pour rendre cela public et que nous n’avons pas rencontré de scénario où la vulnérabilité est mise à jour au dernier moment.
Cette annonce préalable a donné aux entreprises le temps de se préparer au pire et de cartographier leurs actifs critiques pour une solution rapide.
