Développé à l'origine pour les navigateurs, le protocole SSL / TLS est devenu plus tard la norme de facto pour toutes les communications Internet sécurisées. Maintenant, il est utilisé pour l'administration à distance de l'infrastructure virtuelle déployée dans le cloud, pour transférer les détails de paiement des clients des serveurs de commerce électronique vers des processeurs de paiement tels que PayPal et Amazon, pour envoyer des données locales au stockage dans le cloud, enregistrer la correspondance dans les messageries instantanées et l'authentification du serveur dans les applications mobiles iOS et Android.

La liste des situations où l'échange d'informations hautement sensibles requiert une sécurité maximale est assez impressionnante. Dans cet article, nous examinerons comment la sécurité de ces communications est assurée dans la pratique.

- Protocole SSL / TLS: ils voulaient le meilleur ...
- ... mais il s'est avéré comme toujours: des exemples de vérification de certificat SSL / TLS ayant échoué
- Vulnérabilités logiques du protocole SSL / TLS
- Autres vulnérabilités courantes d'implémentation du protocole SSL / TLS
- La cause première des vulnérabilités dans le protocole SSL / TLS
- Une cuillère de miel dans un baril de goudron

Protocole SSL / TLS: nous voulions le meilleur ...

En théorie, une connexion sécurisée par protocole SSL / TLS devrait garantir la confidentialité, la fiabilité et l'intégrité des communications entre le logiciel client et le serveur, même en présence d'un attaquant avancé actif du réseau: lorsque le réseau est complètement capturé par l'ennemi, le DNS est empoisonné, et les points d'accès et routeurs, commutateurs et WiFi sont contrôlés par un attaquant; un attaquant qui, entre autres, contrôle un backend SSL / TLS. En outre, lorsqu'un logiciel client tente de se connecter à un serveur légitime, un attaquant peut modifier l'adresse réseau du serveur (par exemple, par empoisonnement DNS) et, au lieu d'un serveur légitime, rediriger le client vers son serveur malveillant.

La sécurité des communications dans des conditions aussi difficiles, comme vous le savez, dépend entièrement de l'adéquation de la vérification du certificat cryptographique fourni par le serveur lors de l'établissement de la connexion. Y compris l'adéquation de la mise en œuvre d'un ensemble de chiffres (ciphersuite), que le client et le serveur utilisent lors de l'échange de données. Pour que la connexion SSL / TLS soit complètement sécurisée, le logiciel client, entre autres, doit soigneusement vérifier que:

• certificat délivré par l'organisme de certification actuel;
• sa période de validité n'est pas expirée (ou le certificat n'a pas été révoqué);
• la liste des noms répertoriés dans le certificat contient le domaine auquel vous vous connectez.

... mais cela s'est avéré comme toujours: exemples d'échec de la vérification des certificats SSL / TLS

Cependant, dans de nombreuses applications et bibliothèques pour lesquelles la sécurité des communications est très critique, la procédure de vérification d'un certificat SSL / TLS - et même EV-SSL, un certificat de vérification avancé [4] - est totalement infructueuse. Dans tous les systèmes d'exploitation courants: Linux, Windows, Android et iOS. Parmi les logiciels, bibliothèques et services middleware vulnérables, on peut distinguer les suivants [1]:

• La bibliothèque Java EC2 d'Amazon et tous les clients frontaux basés sur le cloud construits sur cette base.
• SDK commercial d'Amazon et de PayPal, responsable de la livraison des détails de paiement des sites (sur lesquels l'infrastructure de commerce en ligne est déployée) aux passerelles de paiement.
• Des «paniers» intégrés, tels que osCommerce, ZenCart, Ubercart et PrestaShop, qui ne valident pas du tout les certificats.
• Code AdMob utilisé par les logiciels mobiles pour afficher des publicités contextuelles.
• Interface des composants frontaux ElephantDrive et FilesAnywhere, chargés d'interagir avec le stockage cloud.
• La bibliothèque Pusher Android et tous les logiciels qui utilisent l'API Pusher pour contrôler la messagerie instantanée (par exemple, Gaug.es de GitHub).
• Apache HttpClient (version 3.x); Apache Libcloud et toutes les connexions client aux serveurs Apache ActiveMQ, etc.
• Les services middleware SOAP Java, notamment Apache Axis, Axis 2, Codehaus XFire; ainsi que tous les logiciels construits sur la base de ces services middleware.
• Outils d'API Elastic Load Balancing
• Implémentation Weberknecht de WebSockets.
• Ainsi que tous les logiciels mobiles construits sur la base des bibliothèques et des services middleware énumérés ci-dessus (pour comprendre ce que sont les services middleware, voir Fig. 1); y compris le client iOS du fournisseur d'hébergement Rackspace.

Figure 1. Que sont les services middleware

En outre, dans [2], plus d'une centaine d'applications mobiles vulnérables sont répertoriées (voir la Fig. 2). Y compris: Google Cloud Messaging d'Android, Angie's List Business Center Passwords, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (accès à distance), Cisco Technical Support, Cisco Webex, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer , Google Earth, Huntington Mobile (banque), comptable en ligne Intuit Tax, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (client VPN), SouthWest Airlines, Uber, US Bank - Access Online, WesternUnion, WordPress, Yahoo! Finance, Yahoo! Mail

Figure 2. Une petite sélection dans la liste des applications mobiles vulnérables

Vulnérabilités logiques SSL / TLS

Les connexions SSL / TLS de tout cela et de nombreux autres logiciels sont vulnérables à un large éventail d'attaques MiTM. Dans le même temps, une attaque MiTM peut être effectuée, souvent même sans falsifier les certificats et sans voler les clés privées par lesquelles les serveurs signent leurs certificats. Une attaque MiTM peut être effectuée en exploitant simplement les vulnérabilités logiques présentes dans la procédure de vérification du certificat SSL / TLS côté logiciel client. Par conséquent, un attaquant MiTM peut, par exemple, collecter des jetons d'autorisation, des numéros de carte de crédit, des noms, des adresses, etc. - de tout commerçant qui utilise des applications Web de traitement des paiements vulnérables.

Les fournisseurs de logiciels mobiles, qui utilisent l'exemple de code AdMob pour connecter leurs applications au compte AdMob, sont également vulnérables - ils permettent à un attaquant de capturer les informations d'identification et d'accéder à tous ses services Google. Par exemple, en raison d'une vérification incorrecte des certificats dans des messagers tels que Trillian et AIM, un attaquant MiTM peut voler des informations de connexion pour tous les services Google (y compris Gmail), Yahoo!; ainsi qu'aux services Windows Live (y compris SkyDrive). Les autres vulnérabilités qui affectent les logiciels Web modernes sans navigateur incluent: l'utilisation d'expressions régulières incorrectes lors de la comparaison d'un nom d'hôte; ignorer les résultats de la validation du certificat; arrêt accidentel ou intentionnel de la vérification. [1]

Autres vulnérabilités courantes d'implémentation du protocole SSL / TLS

Et bien sûr, nous ne devons pas oublier que même s'il n'y a pas d'erreurs logiques dans la mise en œuvre du protocole SSL / TLS (à moins bien sûr que quelqu'un y croie encore), la protection peut être contournée en volant la clé privée [12], en utilisant 0day- exploits pour des choses telles que les claviers, les navigateurs, les systèmes d'exploitation, les utilitaires et les micrologiciels [3]; en compromettant le routage BGP [10]; ou attaquer SSL / TLS sur du matériel (voir Figure 3) [8] et / ou des canaux de contournement logiciel [9].

Figure 3. Attaque SSL sur le contournement matériel

De plus, les attaquants peuvent mener des attaques MiTM pratiquement invisibles, abusant du mécanisme de mise en cache de session SSL / TLS implémenté dans la classe SSLSessionCache. Ce mécanisme vérifie la validité des certificats uniquement lors de la connexion initiale; il n'est pas non plus capable d'annuler correctement une session de communication après avoir supprimé des certificats de l'appareil. De plus, après le redémarrage de l'appareil Android (via les options «Redémarrer» ou «Éteindre»), vous pouvez continuer à voir le trafic crypté de certaines applications qui n'ont pas démarré après le redémarrage, mais ont fonctionné avant le redémarrage. Ainsi, par exemple, avec Google Maps se produit. Dans [2], il est décrit comment, grâce à ces failles de mise en cache, un attaquant peut définir et supprimer de manière totalement transparente des «certificats invisibles» pour l'utilisateur, puis établir une connexion réseau avec n'importe quelle application.

Figure 4. Rétrospective du chiffrement vulnérable

D'autres vulnérabilités courantes dans l'implémentation du protocole SSL / TLS incluent le chiffrement vulnérable (voir figure 4) [5], la réutilisation de GCM (Galois / Counter Mode; compteur avec authentification Galois) [6], astuce avec CNG (CryptoAPI-NG ) dans Schannel (voir. Fig. 5) [7], vérification incorrecte de la chaîne de confiance [2], vérification incorrecte du nom d'hôte [11].

Figure 5. Astuce CNG: extraire des secrets de Schannel

Une vérification incorrecte de la chaîne de confiance est une situation où l'application Web accepte absolument tout certificat qui indique le nom d'hôte correct, sans vérifier avec quelle autorité de certification elle a été signée. Cela vous permet d'intercepter et de décrypter des mots de passe et / ou des numéros de carte de crédit. Et dans certains cas, même faire une injection de code malveillant. Dans les logiciels Android, cette vulnérabilité pénètre, par exemple, lorsqu'une interface X509TrustManger personnalisée est créée qui ignore les exceptions CertificateException. Ou lorsqu'un développeur de logiciels insère un appel à la méthode SslErrorHandler.proceed () dans le code d'un composant WebViews. [2]

Une vérification de nom d'hôte incorrecte est une situation où une application Web accepte un certificat sans s'assurer que l'hôte d'où provient ce certificat figure dans la liste des hôtes approuvés. Dans les logiciels Android, cette vulnérabilité pénètre, par exemple, lorsqu'une interface HostnameVerifier est créée, qui renvoie VRAI dans toutes les conditions. Ou lorsqu'un développeur de logiciels insère un appel à la méthode SslErrorHandler.proceed () dans le code d'un composant WebViews. [2]

La cause première des vulnérabilités dans le protocole SSL / TLS

La cause principale de la grande majorité de ces vulnérabilités est la terrible conception de l'API des bibliothèques SSL / TLS (y compris JSSE, OpenSSL et GnuTLS). Ainsi que la conception tout aussi terrible des bibliothèques de transfert de données (telles que cURL, Apache HttpClient et urllib), chacune étant un wrapper de haut niveau pour les bibliothèques SSL / TLS. Sans parler des services middleware (tels que Apache Axis, Axis 2 ou Codehaus XFire), qui sont un wrapper de niveau encore plus élevé, et qui augmentent encore plus la «boule de neige» d'une conception terrible. Au lieu de mener un dialogue avec un développeur d'applications (souvent loin de la programmation système) dans un langage qu'il comprend (en termes de confidentialité et d'authentification), abstrait des détails de bas niveau de la mise en œuvre du protocole SSL / TLS, ces API déchargent un tas de paramètres SSL / TLS de bas niveau sur le pauvre type incompréhensible pour lui. Ils nécessitent un logiciel de haut niveau pour exposer correctement les options de bas niveau; implémente les fonctions de vérification du nom d'hôte et s'occupe de l'interprétation des valeurs renvoyées par les opérations de bas niveau.

Par conséquent, les développeurs d'applications utilisent incorrectement l'API SSL / TLS: ils interprètent par erreur la diversité de leurs paramètres, options, effets secondaires et valeurs de retour. Par exemple [1]:

• La bibliothèque PHP du service de paiement flexible d'Amazon tente d'activer la validation du nom d'hôte en définissant le paramètre CURLOPT_SSL_VERIFYHOST sur TRUE (dans la bibliothèque cURL). Cependant, la valeur par défaut correcte pour ce paramètre est 2; si vous lui affectez une valeur TRUE, ce paramètre est invisible pour le développeur auquel la valeur 1 a été affectée, et ainsi de suite. la vérification des certificats est désactivée.
• Bibliothèque PHP PayPal Payments Standard - a la même erreur; De plus, au moment où l'implémentation précédente, vulnérable, a été mise à jour (c'est-à-dire qu'une erreur a été supprimée, une autre a été ajoutée).
• Un autre exemple est Lynx, un navigateur orienté texte. Il vérifie les certificats auto-signés - mais uniquement si la fonction de vérification des certificats GnuTLS renvoie une valeur négative. Cependant, cette fonction renvoie 0 pour certaines erreurs; y compris dans les cas où les certificats sont signés par un organisme non fiable. Pour cette raison, la chaîne de confiance dans Lynx est rompue.

De plus, les développeurs d'applications se méprennent souvent sur le type de sécurité garanti par une bibliothèque SSL / TLS particulière. Par conséquent, dans la nature, on peut rencontrer des cas cliniques où dans des applications qui ont fondamentalement besoin de communications sécurisées (par exemple, interagir avec un processeur de paiement), une bibliothèque SSL / TLS est utilisée qui ne vérifie pas du tout les certificats SSL / TLS. Les cas plus prosaïques, mais encore plus meurtriers, sont lorsque le développeur de l'une des couches logicielles intermédiaires désactive silencieusement la procédure de vérification des certificats SSL / TLS (il peut le faire, par exemple, pour tester le système et après le test, oublier de le réactiver). Dans le même temps, le code de programme de haut niveau utilisant cette couche intermédiaire est sûr que la vérification du certificat est effectuée. T.O. Les erreurs SSL / TLS sont souvent cachées dans les profondeurs d'une ou plusieurs couches intermédiaires de bibliothèques à la fois, ce qui rend presque impossible de détecter ce problème.

Par exemple, dans JSSE (Java Secure Socket Extension), l'interface étendue de l'API SSLSocketFactory ignore silencieusement la vérification du nom d'hôte si le champ "algorithme" du client SSL est défini sur NULL ou sur une chaîne vide, et non sur HTTPS. Bien que ce fait soit mentionné dans le guide de référence JSSE, de nombreuses implémentations de protocole SSL Java utilisent SSLSocketFactory sans effectuer de validation de nom d'hôte ...

Une cuillère de miel dans un baril de goudron

Ainsi, en fait, il s'avère que dans la plupart des logiciels Web modernes sans navigateur, la vérification des certificats SSL / TLS est complètement désactivée ou mise en œuvre de manière incorrecte. La figure 7 montre la classification des vulnérabilités actuelles du protocole SSL / TLS. Certaines de ces vulnérabilités, mais pas toutes, ont été décrites et / ou mentionnées ci-dessus. Vous pouvez vous familiariser avec les vulnérabilités mentionnées mais non décrites en lisant les documents répertoriés dans la bibliographie.

Figure 6. Classification des vulnérabilités pertinentes pour SSL / TLS

Eh bien, afin d'ajouter une cuillerée de miel au baril de goudron, il convient de noter que dans [1], il a été décrit en détail / de manière compréhensible / populaire / compétente comment SSL devrait être mis en œuvre, en référence à la RFC. Nous n'avons jamais trouvé de meilleure description, qui serait techniquement exacte et en même temps compréhensible. Toujours dans [1], les bibliothèques SSL les plus courantes sont analysées, avec une classification en fonction du niveau d'abstraction (bas niveau / haut niveau). Le tout avec des diagrammes et des algorithmes concis en pseudo-code. Les vulnérabilités de produits spécifiques sont décrites en détail, avec un code incorrect et des codes d'erreur. Donc, si tout à coup quelqu'un souhaite à nouveau créer une telle implémentation du cadre SSL / TLS, ce qui sera une exception au dicton "ils voulaient le meilleur, mais il s'est avéré comme toujours", alors [1] est un début idéal pour cela.