Vulnérabilité faible du protocole SSL v3 et TLS v1 en mode CBC

Introduction

Ce document décrit comment désactiver le chiffrement en mode CBC (Cipher Block Chaining) sur le dispositif de sécurité de la messagerie Cisco (ESA). Un audit/analyse de sécurité peut signaler qu'un ESA présente une vulnérabilité de mode CBC faible du protocole SSL (Secure Sockets Layer) v3/TLS (Transport Layer Security) v1.

Attention : Si vous exécutez un code plus ancien d'AsyncOS pour la sécurité de la messagerie, il est recommandé de mettre à niveau vers la version 11.0.3 ou ultérieure.  Consultez les notes de version de Cisco Email Security pour connaître nos dernières versions et informations.  Si vous avez besoin d'aide pour les mises à niveau ou la désactivation des chiffrements, ouvrez un dossier d'assistance.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur AsyncOS for Email Security (toute révision), un ESA Cisco et un ESA virtuel.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

• La conformité à la norme PCI DSS (Payment Card Industry Data Security Standard) nécessite la désactivation du chiffrement CBC.
• Un audit/analyse de sécurité a identifié une vulnérabilité potentielle avec les protocoles SSL v3/TLS v1 qui utilisent le mode CBC. 

Conseil : SSL Version 3.0 (RFC-6101) est un protocole obsolète et non sécurisé. Il existe une vulnérabilité dans SSLv3 CVE-2014-3566 connue sous le nom d'attaque Padding Oracle On Downgraded Legacy Encryption (POODLE), ID de bogue Cisco CSCur27131. Il est recommandé de désactiver SSL v3 pendant que vous modifiez les chiffrements et utilisez TLS uniquement, puis de sélectionner l'option 3 (TLS v1). Consultez l'ID de bogue Cisco CSCur27131 fourni pour plus de détails.

Les protocoles SSL v3 et TLS v1 sont utilisés afin d'assurer l'intégrité, l'authenticité et la confidentialité d'autres protocoles tels que HTTP et LDAP (Lightweight Directory Access Protocol). Ils fournissent ces services avec l'utilisation du chiffrement pour la confidentialité, des certificats x509 pour l'authenticité et de la fonctionnalité de chiffrement unidirectionnel pour l'intégrité. Pour chiffrer les données, SSL et TLS peuvent utiliser des algorithmes de chiffrement par blocs qui ne peuvent chiffrer qu'un bloc fixe de données d'origine en un bloc chiffré de même taille. Notez que ces chiffrements obtiendront toujours le même bloc résultant pour le même bloc de données d'origine. Afin d'obtenir une différence de sortie, la sortie du cryptage est soumise à une opération OU exclusif avec encore un autre bloc de même taille appelé vecteurs d'initialisation (IV). CBC utilise un IV pour le bloc initial et le résultat du bloc précédent pour chaque bloc suivant afin d'obtenir la différence dans la sortie du chiffrement par bloc.

Dans l'implémentation SSL v3 et TLS v1, l'utilisation du mode CBC était médiocre, car l'ensemble du trafic partage une session CBC avec un seul ensemble d'interfaces IV initiales. Le reste des IV est, comme mentionné précédemment, le résultat du chiffrement des blocs précédents. Les perfusions intraveineuses suivantes sont à la disposition des écouteurs. Cela permet à un attaquant d'injecter du trafic arbitraire dans le flux en texte clair (à chiffrer par le client) afin de vérifier qu'il devine le texte en clair qui précède le bloc injecté. Si l'hypothèse de l'attaquant est correcte, alors la sortie du chiffrement est la même pour deux blocs.

Pour les données à faible entropie, il est possible de deviner le bloc de texte en clair avec un nombre relativement faible de tentatives. Par exemple, pour les données qui ont 1000 possibilités, le nombre de tentatives peut être de 500.

Exigences

Plusieurs conditions doivent être remplies pour que l'exploit fonctionne :

1. La connexion SSL/TLS doit utiliser l'un des chiffrements par blocs qui utilisent les modes CBC, tels que DES ou AES. Les canaux qui utilisent des chiffrements de flux, tels que RC4, ne sont pas sujets à la faille. Une grande partie des connexions SSL/TLS utilisent RC4.
2. La vulnérabilité ne peut être exploitée que par une personne qui intercepte des données sur la connexion SSL/TLS et qui envoie également activement de nouvelles données sur cette connexion. L'exploitation de la faille entraîne l'arrêt de la connexion SSL/TLS. Le pirate doit continuer à surveiller et à utiliser les nouvelles connexions jusqu'à ce que suffisamment de données soient collectées pour déchiffrer le message.
3. Comme la connexion est interrompue à chaque fois, le client SSL/TLS doit pouvoir continuer à rétablir le canal SSL/TLS suffisamment longtemps pour que le message soit déchiffré.
4. L'application doit renvoyer les mêmes données sur chaque connexion SSL/TLS qu'elle crée et l'écouteur doit pouvoir les localiser dans le flux de données. Les protocoles comme IMAP/SSL qui ont un ensemble fixe de messages pour se connecter répondent à cette exigence. La navigation Web générale ne fonctionne pas.

Menace

La vulnérabilité CBC est une vulnérabilité avec TLS v1. Cette vulnérabilité existe depuis le début de 2004 et a été résolue dans les versions ultérieures de TLS v1.1 et TLS v1.2.

Avant AsyncOS 9.6 pour la sécurité de la messagerie, ESA utilisait des algorithmes de chiffrement TLS v1.0 et CBC. Avec la version d'AsyncOS 9.6, l'ESA introduit TLS v1.2. Cependant, les chiffrements en mode CBC peuvent être désactivés et seuls les chiffrements RC4 peuvent être utilisés qui ne sont pas sujets à la faille.

En outre, si SSLv2 est activé, cela peut déclencher un faux positif pour cette vulnérabilité. Il est très important que SSL v2 soit désactivé.

Solution

Attention : Si vous exécutez un code plus ancien d'AsyncOS pour la sécurité de la messagerie, il est recommandé de mettre à niveau vers la version 11.0.3 ou ultérieure.  Consultez les notes de version de Cisco Email Security pour connaître nos dernières versions et informations.  Si vous avez besoin d'aide pour les mises à niveau ou la désactivation des chiffrements, ouvrez un dossier d'assistance.

Désactivez les chiffrements en mode CBC afin de ne laisser que les chiffrements RC4 activés. Configurez le périphérique pour qu'il utilise uniquement TLS v1 ou TLS v1/TLS v1.2 :

1. Connectez-vous à la CLI.
2. Entrez la commande sslconfig.
3. Entrez la commande GUI.
4. Choisissez l'option numéro 3 pour « TLS v1 » ou comme indiqué dans AsyncOS 9.6 « TLS v1/TLS v1.2 ».
5. Entrez ce chiffre :

   MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

6. Entrez la commande : INBOUND.
7. Choisissez l'option numéro 3 pour « TLS v1 » ou comme indiqué dans AsyncOS 9.6 « TLS v1/TLS v1.2 ».
8. Entrez ce chiffre :

   MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

9. Entrez la commande OUTBOUND.
10. Choisissez l'option numéro 3 pour « TLS v1 » ou comme indiqué dans AsyncOS 9.6 « TLS v1/TLS v1.2 ».
11. Entrez ce chiffre :

    MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

12. Appuyez sur Entrée jusqu'à ce que vous reveniez à l'invite hostname.
13. Entrez la commande commit.
14. Finalisez la validation de vos modifications.

L'ESA est maintenant configuré pour prendre en charge uniquement TLS v1, ou TLSv1/TLS v1.2, avec des chiffrements RC4 alors qu'il désactive tout filtre CBC.

Voici la liste des chiffrements utilisés lorsque vous définissez RC4 : -SSLv2. Notez qu'il n'y a pas de chiffrement en mode CBC dans la liste.

ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

Bien que cet exploit soit très peu préoccupant en raison de sa complexité et de ses exigences d'exploitation, la performance de ces étapes est une grande garantie pour la prévention des exploits possibles, ainsi que pour passer des scans de sécurité stricts.

Informations connexes

• Appliance de sécurisation de la messagerie Cisco - Guides de l'utilisateur final
• Assistance et documentation techniques - Cisco Systems