Contexte
Le 1er novembre 2022, OpenSSL a publié un avis concernant deux failles de sécurité de gravité élevée : CVE-2022-3786 (« X.509 Débordement de tampon de longueur variable d’adresse e-mail ») et CVE-2022-3602 (« X.509 Débordement de tampon de 4 octets d’adresse e-mail »). Ces vulnérabilités affectent OpenSSL version 3.0.0 et versions ultérieures, et ont été corrigées dans OpenSSL 3.0.7.
Quelle est la solution ?
Les détails de vulnérabilité suivants ont été publiés dans l’avis de sécurité OpenSSL plus tôt dans la journée :
Un débordement de tampon peut être déclenché lors de la vérification du certificat X.509, en particulier lors de la vérification des contraintes de nom. Cela se produit après la vérification de la signature de la chaîne de certificats et nécessite soit qu’une autorité de certification ait signé un certificat malveillant, soit qu’une application continue la vérification du certificat malgré l’échec de la construction d’un chemin vers un émetteur de confiance. Un hacker peut créer une adresse e-mail malveillante dans un certificat pour faire déborder un nombre arbitraire d’octets contenant le caractère `.’ (caractère décimal 46) sur la pile. Ce débordement de tampon pourrait entraîner un plantage (provoquant un déni de service). Dans un client TLS, cela peut être déclenché par la connexion à un serveur malveillant. Dans un serveur TLS, cela peut être déclenché si le serveur demande l’authentification du client et qu’un client malveillant se connecte.
Un débordement de tampon peut être déclenché lors de la vérification du certificat X.509, en particulier lors de la vérification des contraintes de nom. Cela se produit après la vérification de la signature de la chaîne de certificats et nécessite soit qu’une autorité de certification ait signé le certificat malveillant, soit que l’application continue la vérification du certificat malgré l’échec de la construction d’un chemin vers un émetteur de confiance. Un hacker peut créer une adresse e-mail malveillante pour faire déborder quatre octets contrôlés par le hacker sur la pile. Ce débordement de tampon pourrait entraîner un plantage (provoquant un déni de service) ou potentiellement une exécution de code à distance. De nombreuses plateformes mettent en œuvre des mesures de protection contre le débordement de pile, ce qui permet d’atténuer le risque d’exécution de code à distance. Le risque peut être atténué davantage en fonction de la disposition de la pile pour une plateforme ou un compilateur donné. Les annonces préalables de CVE-2022-3602 décrivaient ce problème comme étant CRITIQUE. Une analyse plus approfondie basée sur certains des facteurs atténuants décrits ci-dessus a conduit à la rétrogradation de ce problème au niveau HAUT. Les utilisateurs sont toujours encouragés à passer à une nouvelle version dès que possible. Dans un client TLS, cela peut être déclenché par la connexion à un serveur malveillant. Dans un serveur TLS, cela peut être déclenché si le serveur demande l’authentification du client et qu’un client malveillant se connecte.
Quelles sont les versions concernées ?
Les versions OpenSSL 3.0.0 à 3.0.6 sont concernées par ces vulnérabilités. Toute application OpenSSL 3.0 qui vérifie les certificats X.509 reçus de sources non fiables doit être considérée comme vulnérable. Cela inclut les clients TLS et les serveurs TLS qui sont configurés pour utiliser l’authentification client TLS. Les versions OpenSSL 1.0.2, 1.1.1 et les autres versions antérieures ne sont pas concernées.
Que faire pour vous protéger ?
Les utilisateurs d’OpenSSL 3.0.0 à 3.0.6 sont encouragés à passer à la version 3.0.7 dès que possible. Si vous obtenez votre copie d’OpenSSL auprès de votre fournisseur de système d’exploitation ou d’un autre tiers, vous devez lui demander une version mise à jour dès que possible.
Les utilisateurs exploitant des serveurs TLS peuvent envisager de désactiver l’authentification du client TLS jusqu’à ce que les correctifs soient appliqués.
Nous avons également publié un blog proposant les étapes à suivre pour protéger votre entreprise.
Zscaler Cloud n’est pas affecté
Nous avons terminé notre examen et publié un message de confiance pour informer nos clients que les composants de Zscaler Cloud ne sont pas affectés par cette vulnérabilité.
L’un des principaux avantages de l’adoption d’une plateforme SSE cloud native, contrairement aux appliances NGFW traditionnelles ou aux machines virtuelles, réside dans le fait que Zscaler évite aux clients finaux la charge opérationnelle liée à l’application de correctifs logiciels sur une multitude d’appliances matérielles traditionnelles et de machines virtuelles. Une bonne illustration de cet avantage a également été observée plus tôt cette année lorsqu’il ne nous a fallu que quelques jours pour corriger la vulnérabilité OpenSSL CVE-2022-0778 de mars 2022.
Comment Zscaler protège les utilisateurs contre cette vulnérabilité
Pour l’instant, aucune tentative d’exploitation réelle n’a été signalée concernant ces vulnérabilités, mais les chercheurs en sécurité ont publié une preuve de concept (POC) d’exploitation réussie. ThreatLabz surveille activement les menaces et assurera une couverture contre les menaces ciblant les utilisateurs finaux protégés par Zscaler. Même si ce problème peut potentiellement affecter à la fois les clients TLS et les serveurs TLS, la probabilité qu’un client exploite un serveur à l’aide d’un certificat TLS client malveillant est beaucoup plus faible, étant donné que mTLS (TLS mutuel dans lequel un serveur authentifie également un client) n’est pas largement utilisé.
L’architecture basée sur un proxy et le service d’inspection SSL de Zscaler sont bien placés pour défendre les utilisateurs finaux contre les tentatives d’exploitation menées à l’aide de certificats de serveur malveillants. En tant qu’intermédiaire de confiance (ou MITM, « man-in-the-middle »), Zscaler analyse et valide tous les certificats de serveur, de manière centralisée dans le cloud, comme si Zscaler était le navigateur client du serveur TLS de destination, et émet un nouveau certificat de serveur signé par l’autorité de certification de Zscaler ou du client, empêchant ainsi le certificat malveillant d’arriver à l’utilisateur final.
Tant que les clients ont activé l’inspection SSL/TLS, Zscaler les défendra contre la menace comme illustré ci-dessous :
1. Le hacker héberge un site malveillant desservant le certificat X.509 spécialement conçu qui déclenche la vulnérabilité d’OpenSSL.
2. L’utilisateur final est amené à accéder au site malveillant via Zscaler avec l’inspection TLS activée.
3. Zscaler interrompt immédiatement la connexion si le nom du serveur a une mauvaise réputation.
4. Dans le cas contraire, Zscaler mettra fin à la demande de prise de contact TLS du client et initiera sa propre prise de contact avec le serveur de destination.
5. Zscaler valide le certificat envoyé par le serveur après le message ServerHello. Étant donné que Zscaler n’est pas affecté par la vulnérabilité OpenSSL, l’infrastructure de Zscaler elle-même est sûre.
6. Zscaler génère un certificat de domaine et l’envoie à l’utilisateur final. Étant donné que Zscaler ne délivre que des certificats X509 correctement conçus, la tentative d’exploitation est effectivement neutralisée. Le certificat malveillant ne parviendra jamais à l’utilisateur final.
Figure 1 : l’inspection TLS de Zscaler empêche la tentative d’exploitation de la vulnérabilité OpenSSL.
Consultez notre article de blog récent pour en savoir plus sur le fonctionnement de l’inspection SSL et les principales responsabilités assumées en tant que proxy SSL.
Comment Zscaler aide les entreprises à sécuriser les charges de travail affectées par cette vulnérabilité
Pour les charges de travail, Posture Control de Zscaler permet aux entreprises d’analyser tous leurs environnements AWS, Azure et GCP pour les aider à identifier et hiérarchiser les actifs qui requièrent une attention particulière. 12 % de nos clients ont obtenu des résultats immédiats et ont découvert que certaines de leurs charges de travail étaient vulnérables à ces problèmes. La plupart des charges de travail vulnérables se trouvaient spécifiquement dans les actifs publics.
Références
