Getty Images
Les organisations utilisant les nouvelles versions du framework Java d’Oracle se sont réveillées mercredi avec un avis inquiétant : une vulnérabilité critique peut permettre aux adversaires de falsifier facilement des certificats et des signatures TLS, des messages d’authentification à deux facteurs et des informations d’identification d’autorisation générées par une gamme d’applications ouvertes largement utilisées. normes.
La vulnérabilité, qu’Oracle a corrigée mardi, affecte la mise en œuvre par la société de l’algorithme de signature numérique à courbe elliptique dans les versions Java 15 et supérieures. ECDSA est un algorithme qui utilise les principes de la cryptographie à courbe elliptique pour authentifier numériquement les messages. Un avantage clé d’ECDSA est la plus petite taille des clés qu’il génère, par rapport à RSA ou à d’autres algorithmes de chiffrement, ce qui le rend idéal pour une utilisation dans des normes telles que 2FA basé sur FIDO, le Security Assertion Markup Language, OpenID et JSON.
Doctor Who et le papier psychique
Neil Madden, le chercheur de la société de sécurité ForgeRock qui a découvert la vulnérabilité, l’a comparée aux cartes d’identité vierges qui apparaissent régulièrement dans l’émission de science-fiction Doctor Who. Le papier psychique dont les cartes sont faites permet à la personne qui la regarde de voir ce que le protagoniste veut qu’elle voie.
“Il s’avère que certaines versions récentes de Java étaient vulnérables à un type d’astuce similaire, dans la mise en œuvre de signatures ECDSA largement utilisées”, a écrit Madden. “Si vous exécutez l’une des versions vulnérables, un attaquant peut facilement falsifier certains types de certificats SSL et de poignées de main (permettant l’interception et la modification des communications), des JWT signés, des assertions SAML ou des jetons d’identification OIDC, et même des messages d’authentification WebAuthn. Le tout en utilisant l’équivalent numérique d’une feuille de papier vierge.
Publicité
Il a continué:
« Il est difficile d’exagérer la gravité de ce bogue. Si vous utilisez des signatures ECDSA pour l’un de ces mécanismes de sécurité, un attaquant peut les contourner de manière triviale et complète si votre serveur exécute une version Java 15, 16, 17 ou 18 avant la mise à jour critique du correctif (CPU) d’avril 2022. Pour le contexte, presque tous les appareils WebAuthn/FIDO dans le monde réel (y compris Yubikeys utilisent des signatures ECDSA et de nombreux fournisseurs OIDC utilisent des JWT signés ECDSA.
Le bogue, suivi sous le nom de CVE-2022-21449, porte un indice de gravité de 7,5 sur 10 possibles, mais Madden a déclaré que, sur la base de son évaluation, il évaluerait la gravité à un parfait 10 “en raison du large éventail d’impacts sur différentes fonctionnalités dans un contexte de gestion des accès. Dans sa forme la plus sinistre, le bogue pourrait être exploité par quelqu’un en dehors d’un réseau vulnérable sans aucune vérification.
D’autres experts en sécurité ont également eu de vives réactions, l’un d’entre eux le déclarant “le bogue crypto de l’année”.
Bien. C’est le bug crypto de l’année. Notez-le pour avril. Java 15-18 ECDSA ne vérifie pas que la coordonnée x aléatoire et la preuve de signature ne sont pas nulles ; une signature (0,0) valide tout message. Casse JWT, SAML, etc. https://t.co/t2WgnS0g3A
– Thomas H.Ptacek (@tqbf) 20 avril 2022
Un facteur atténuant est que les versions Java 15 et supérieures ne semblent pas être aussi largement utilisées que les versions antérieures. Les données collectées en février et mars 2021 auprès de la société de sécurité Snyk ont montré que Java 15, la dernière version à l’époque, représentait 12 % des déploiements. Alors que Madden a déclaré que la faille d’implémentation ECDSA spécifique n’affectait que Java 15 et versions ultérieures, Oracle a également répertorié les versions 7, 8 et 11 comme vulnérables. Madden a déclaré que l’écart peut résulter de bogues de chiffrement distincts corrigés dans les versions précédentes.
a/0 = signature valide
Les signatures ECDSA reposent sur un nombre pseudo-aléatoire, généralement noté K, qui est utilisé pour dériver deux nombres supplémentaires, R et S. Pour vérifier qu’une signature est valide, une partie doit vérifier l’équation impliquant R et S, la clé publique du signataire, et un hachage cryptographique du message. Lorsque les deux membres de l’équation sont égaux, la signature est valide.
Publicité
Dans un article publié mercredi, la société de sécurité Sophos a expliqué plus en détail le processus :
S1. Sélectionnez un entier aléatoire aléatoire K entre 1 et N-1 inclus.
S2. Calculez R à partir de K en utilisant la multiplication par courbe elliptique.
S3. Dans le cas improbable où R est égal à zéro, revenez à l’étape 1 et recommencez.
S4. Calculez S à partir de K, R, le hachage à signer et la clé privée.
S5. Dans le cas peu probable où S est égal à zéro, revenez à l’étape 1 et recommencez.
Pour que le processus fonctionne correctement, ni R ni S ne peuvent jamais être un zéro. C’est parce qu’un côté de l’équation est R, et l’autre est multiplié par R et une valeur de S. Si les valeurs sont toutes les deux 0, le contrôle de vérification se traduit par 0 = 0 X (autres valeurs de la clé privée et du hachage), qui sera vrai quelles que soient les valeurs supplémentaires. Cela signifie qu’un adversaire n’a qu’à soumettre une signature vierge pour réussir le contrôle de vérification.
Madden a écrit:
Devinez quel chèque Java a oublié ?
C’est exact. L’implémentation Java de la vérification de signature ECDSA n’a pas vérifié si R ou S étaient nuls, vous pouvez donc produire une valeur de signature dans laquelle ils sont tous les deux 0 (encodés de manière appropriée) et Java l’accepterait comme signature valide pour tout message et pour tout public clé. L’équivalent numérique d’une carte d’identité vierge.
Vous trouverez ci-dessous une session JShell interactive créée par Madden qui montre une implémentation vulnérable acceptant une signature vierge comme valide lors de la vérification d’un message et d’une clé publique :
| Bienvenue dans JShell — Version 17.0.1 | Pour une introduction tapez : /help intro jshell> importer java.security.*
jshell> var clés = KeyPairGenerator.getInstance(“EC”).generateKeyPair()
clés ==> java.security.KeyPair@626b2d4a jshell> var blankSignature = nouvel octet[64]
blankSignature ==> octet[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, … , 0, 0, 0, 0, 0, 0, 0, 0 } jshell> var sig = Signature.getInstance(“SHA256WithECDSAInP1363Format”)
sig ==> Objet signature : SHA256WithECDSAInP1363Format
jshell> sig.initVerify(keys.getPublic())
jshell> sig.update(“Bonjour, le monde”.getBytes())
jshell> sig.verify(blankSignature)
$8 ==> true // Oups, ça n’aurait pas dû être vérifié…
Les organisations qui utilisent l’une des versions concernées de Java pour valider les signatures doivent accorder une priorité élevée aux correctifs. Il sera également important de surveiller les avis des fabricants d’applications et de produits pour voir si l’une de leurs marchandises est rendue vulnérable. Bien que la menace de CVE-2022-21449 semble limitée aux nouvelles versions de Java, sa gravité est suffisamment élevée pour justifier la vigilance.
