OpenSSL est une bibliothèque de logiciels open source largement utilisée pour mettre en œuvre des communications sécurisées sur des réseaux informatiques. Dans quelle mesure est-il largement utilisé ? Eh bien, il est probable que si vous avez déjà accédé à une page Web HTTPS, vous l'avez fait via un cryptage OpenSSL. La bibliothèque fournit des fonctions et des protocoles cryptographiques pour le cryptage, le déchiffrement, l'authentification et la vérification des signatures numériques. OpenSSL peut être trouvé presque partout où il est nécessaire de sécuriser les serveurs Web, les serveurs de messagerie, les réseaux privés virtuels (VPN) et d'autres types de communication réseau.
En regardant le paragraphe ci-dessus, il devrait être clair à quel point OpenSSL est important pour le bon fonctionnement d'Internet. Il s'agit d'un composant essentiel de l'infrastructure de sécurité de nombreux systèmes et applications informatiques. Il aide à protéger les données sensibles contre tout accès non autorisé et contribue à garantir l’intégrité et l’authenticité des communications réseau. C'est pourquoi les responsables de la bibliothèque prennent les vulnérabilités très au sérieux et tentent de les corriger le plus rapidement possible. Imaginer des attaquants accéder aux lignes de communication sécurisées de l’infrastructure du World Wide Web est presque impensable.
Dans cet article, nous examinerons les vulnérabilités à l'origine du patch 3.0.7 d'OpenSSL en octobre 2022 et verrons ce que nous pouvons apprendre de la façon dont les responsables d'OpenSSL ont résolu le problème.
Les vulnérabilités
Le 25 octobre 2022, le projet OpenSSL a publié un consultatif avertissant qu'un nouveau patch sera bientôt disponible pour résoudre certains problèmes critique vulnérabilités. La balise « critique » implique que les vulnérabilités sont susceptibles d'être exploitables et que le vol de clés privées et/ou RCE sur les serveurs concernés est probable.
Une semaine plus tard, le 1er novembre 2022, le projet OpenSSL a publié à la fois le nouveau patch 3.0.7 et le vulnérabilités spécifiques ils cherchaient à réparer. Entre-temps, la notation des vulnérabilités a été abaissée de critique à « haute gravité ».
Alors, quelles sont ces vulnérabilités ?
CVE-2022-3602 – Dépassement de tampon de 509 octets de l'adresse électronique X.4 – Lors de la vérification du certificat X.509, en particulier lors de la vérification des contraintes de nom, un dépassement de tampon de quatre octets peut se produire. Quatre octets contrôlés par un attaquant sur la pile peuvent être dépassés par un attaquant utilisant une adresse e-mail malveillante. Un crash (entraînant un déni de service) ou potentiellement une exécution de code à distance pourrait être provoqué par ce débordement de tampon. Initialement, il était classé comme critique, mais des tests supplémentaires ont montré que de nombreuses plates-formes utilisent des protections contre le débordement de pile pour réduire le risque d'exécution de code à distance.
CVE-2022-3786 – Dépassement de tampon de longueur variable de l'adresse e-mail X.509 – Lors de la vérification du certificat X.509, en particulier lors de la vérification des contraintes de nom, un dépassement de tampon peut se produire. Un attaquant peut créer une adresse e-mail malveillante dans un certificat pour remplir la pile avec n'importe quel nombre d'octets contenant le caractère « . », qui est le nombre décimal 46. Un crash pourrait survenir suite à ce débordement de tampon (provoquant un déni de service).
Juste pour réitérer la gravité de ces vulnérabilitésC'est le cas, la CISA, l'agence américaine de cybersécurité et de sécurité des infrastructures, a publié un consultatif le même jour qu'OpenSSL, encourageinvitant les utilisateurs et les administrateurs à consulter les Documentation OpenSSL et mise à niveau, le cas échéant, vers le nouveau patch 3.0.7.
Comme indiqué précédemment, le RCE (exécution de code à distance) sur les systèmes d'exploitation ou les serveurs de messagerie exécutant OpenSSL serait très mauvais, il est donc logique de révéler uniquement le vulnérabilités une fois qu'un correctif approprié a été trouvé et proposé.
What Happens Next
Dès que l’avis initial a été publié, les gens ont commencé à se bousculer. « Pas de panique » était une expression courante à l'époque montrant à quel point les gens ont pris au sérieux la nouvelle selon laquelle OpenSSL était critique vulnérabilités.
Dès que l'avis a été publié, toutes les parties prenantes concernées se sont efforcées de déterminer quelle version d'OpenSSL était utilisée dans leur serveur, système d'exploitation, application, package, etc. Au-delà de la simple utilisation interne d'OpenSSL, les utilisateurs devaient également déterminer si l'un de leurs tiers les fournisseurs ou prestataires de services utilisaient une version vulnérable d’OpenSSL. À l’époque, si vous n’étiez pas sûr de la version que vous utilisiez ou de la version utilisée par vos fournisseurs et prestataires de services, il était jugé plus sûr de mettre une application hors ligne plutôt que de risquer un RCE potentiel.
Étant donné que l'avis donnait à l'avance le calendrier du correctif, cela donnait aux gens le temps de comprendre leur propre infrastructure et celle de leurs fournisseurs et prestataires de services. L'idée était de planifier tout ce qui était nécessaire en termes d'infrastructure impliquée pour que dès la sortie du patch, la mise à niveau, si nécessaire, puisse avoir lieu.
Comment géreriez-vous cela ?
Disons maintenant que vous êtes ingénieur dans une entreprise qui, à votre connaissance, utilise OpenSSL dans ses serveurs. Dès que l'avis est publié, vous devez déterminer quelle version de la bibliothèque est utilisée et où (y compris tout code existant s'il est toujours en cours d'exécution), puis déterminer la même chose pour n'importe lequel de vos fournisseurs ou prestataires de services.
C'est là qu'un SBOM pourrait vraiment être utile. Un SBOM signifie une nomenclature logicielle et il s'agit d'une liste de tous les composants et dépendances logicielles qui composent un produit logiciel particulier. Un SBOM comprend généralement des informations telles que les noms et les versions de tous les composants logiciels (voir où je veux en venir), leurs sources et licences, ainsi que toutes les vulnérabilités ou problèmes de sécurité connus associés à chaque composant.
Si vous, en tant qu'ingénieur responsable que vous êtes, vous êtes assuré d'avoir un SBOM mis à jour pour chacun de vos produits, alors trouver où vous utilisez OpenSSL et quelle version est utilisée aurait été une simple question d'exécuter une recherche sur le fichier SBOM. . Si vous vous êtes également assuré de demander des SBOM mis à jour à n'importe quel fournisseur ou prestataire de services avec lequel votre entreprise travaillait, vous auriez pu y effectuer la même recherche également.
Puisqu'on vous a dit que les vulnérabilités n'affectaient que les versions comprises entre 3.0.0 et 3.0.6, il vous suffit de vérifier quelles versions vous utilisiez pour savoir quelles applications devaient être supprimées ou mises à jour avec le nouveau correctif – 3.0.7. XNUMX.
Juste pour montrer à quel point la liste des systèmes d'exploitation et des applications d'entreprise bien connus utilisant OpenSSL est longue, consultez ceci liste publié en tant que service public afin que les gens sachent à quel point ils devraient être inquiets.
Comment un hub de sécurité basé sur des preuves peut-il vous aider
Dans le cadre de l'évolution du paysage de la cybersécurité, y compris des mesures de grande envergure vulnérabilités, nous assistons actuellement l'évolution de la sécurité des applications vers la sécurité de la chaîne d'approvisionnement logicielle. Une nouvelle génération d’outils et de technologies a été développée pour tenter de résoudre ces problèmes. En offrant une plate-forme d'assurance continue de la sécurité du code basée sur des preuves qui peut garantir la fiabilité du cycle de vie du développement logiciel et des composants logiciels, les outils et solutions automatisés aident les organisations à atteindre un nouveau niveau de sécurité. La cartographie continue des dépendances et des vulnérabilités simplifie la correction ou l'application des correctifs lorsqu'ils sont disponibles.
Scribe est un hub de sécurité de la chaîne d'approvisionnement logicielle. Il rassemble des preuves et les présente pour chaque build qui passe par votre pipeline CI/CD. L'objectif de la solution Scribe était de faciliter le respect des réglementations et des meilleures pratiques européennes et américaines pour améliorer la transparence des logiciels et favoriser la confiance entre les développeurs de logiciels et les utilisateurs. La plateforme permet de créer et de partager des SBOM complets ainsi que d'autres informations sur la sécurité. De plus, la plate-forme peut confirmer que la version que vous consultez est conforme à la fois au cadre SSDF du NIST et aux exigences SLSA niveau 3. Vous n'avez plus besoin de chercher à savoir où vous utilisez quelle version de quelle bibliothèque, car vous disposez d'un magasin de preuves avec un SBOM pour chacune de vos versions. Désormais, le comprendre est aussi simple que de rechercher une phrase particulière dans un document texte.
Un dernier mot : préparez-vous à la prochaine grande divulgation de vulnérabilité
L'histoire du projet OpenSSL du patch 3.0.7 nous offre deux points de vue, tout aussi importants, sur la manière de gérer les vulnérabilités potentiellement critiques.
Du côté concerné – l’entreprise ou le projet potentiellement compromis par ces vulnérabilités – nous avons informé la transparence. Ils ne divulguent pas immédiatement les informations susceptibles de causer un préjudice, mais ils divulguent tout ce qu'ils peuvent dès qu'ils se rendent compte d'un problème. Non seulement ils offrent également un calendrier de résolution en plus d’autant d’informations que possible sur le problème. Une fois qu’un correctif ou une correction existe, ils n’hésitent pas à révéler exactement ce qui n’allait pas et comment il pourrait potentiellement être exploité. Ce type de transparence encourage la confiance. Les utilisateurs et les clients veulent savoir et sentir que l’entreprise se soucie davantage d’eux, ou du moins autant, que de ses résultats financiers ou de son conseil d’administration.
En 2014, le projet OpenSSL a été victime d'un bug critique baptisé 'CoeurSaigne» – une faille critique dans l'implémentation TLS/DTLS d'OpenSSL qui permettait à un attaquant d'obtenir des secrets tels que des clés de chiffrement, des mots de passe et d'autres informations sensibles à partir des serveurs concernés. Heartbleed a montré ce qu'une vulnérabilité critique d'OpenSSL peut faire en affectant une grande variété de programmes et de distributions Linux. Essayer d’identifier et de réparer chaque système vulnérable a donné des mois de maux de tête aux équipes de sécurité. La mise en œuvre d'un outil, comme un SBOM, qui pourrait rendre plus rapide et plus simple la mise à jour et les correctifs de votre logiciel serait une aubaine pour l'équipe de cybersécurité de toute entreprise.
Du point de vue de la correction – savoir exactement avec quoi vous devez travailler – quelle version des packages que vous utilisez et où est essentielle pour pouvoir gérer une telle urgence potentielle. En prenant Log4J comme exemple, certaines entreprises tentent encore de déterminer si elles sont ou non concernées par cette vulnérabilité plus d'un an après sa découverte.
Le fait que vous ne devez pas vous soucier uniquement de vos logiciels et de vos serveurs, mais également de ceux des fournisseurs tiers que vous utilisez ou des fournisseurs de services avec lesquels vous travaillez, même en utilisant des connexions API, signifie que nous, tous d'entre nous, avons vraiment besoin de construire un réseau de confiance entre nous. Cette confiance devrait reposer autant que possible sur des preuves concrètes. Créez et suivez vos propres SBOM et ceux de toute entreprise avec laquelle vous travaillez, partagez ces SBOM et faites preuve de bonne foi en annonçant et en corrigeant toute vulnérabilité exploitable dont vous avez connaissance.
Il faudrait que nous travaillions tous ensemble pour parvenir à un monde où le partage de telles preuves serait aussi courant que le partage des dernières relations publiques de l'entreprise sur les réseaux sociaux. Sans cette confiance, nous ne faisons que préparer le terrain pour que la prochaine grande vulnérabilité critique brise l’infrastructure interconnectée pour laquelle nous travaillons tous si dur.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
