Agence nationale
de la sécurité des
systèmes d'information
No CERTA-2011-ACT-039
| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
|
Paris, le 30 septembre
2011 No CERTA-2011-ACT-039 |
Affaire suivie par :
CERTA
Objet : Bulletin d'actualité
2011-39
| Conditions d'utilisation de ce document : | http://www.certa.ssi.gouv.fr/certa/apropos.html |
| Dernière version de ce document : | http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-039 |
Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-039.pdf
Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-039/
Elle repose sur une faiblesse des algorithmes de chiffrement par blocs chaînés (Cypher Block Chaining ou CBC) connue depuis de nombreuses années. Cette vulnérabilité est en partie à l'origine de la création de TLSv1.1. Afin de bien comprendre le fonctionnement de cette faiblesse, il convient de rappeler le principe des algorithmes de chiffrement de type CBC.
Le chiffrement s'effectue ensuite sur chacun de ces blocs. Cependant, afin d'éviter que deux blocs identiques aient un chiffré identique, chacun des blocs est préalablement transformé. Cette transformation est usuellement une opération « ou exclusif » et fait intervenir un bloc spécial, appelé vecteur d'initialisation, propre à chaque bloc de données à chiffrer. L'algorithme de chiffrement est donc une fonction de la clé, du texte clair et du vecteur d'initialisation.
La création de ces vecteurs d'initialisation peut être effectuée de différentes façons. Dans le cadre de SSLv3.0 et TLSv1.0, le bloc d'initialisation est simplement le résultat du chiffrement du bloc précédent. Le premier bloc d'initialisation est, quant à lui, aléatoire.
La connaissance de l'ensemble du chiffré permet de déterminer à chaque étape, sauf la première, le vecteur d'initialisation utilisé. Il devient alors possible de vérifier diverses hypothèses quant au contenu du texte clair et de mener des attaques par force brute.
Bien entendu, ce type d'attaque n'est pas envisageable dans la pratique. Cependant, il est possible d'exploiter le principe de base afin d'obtenir des résultats dans un temps raisonnable.
Supposons connaître pour un bloc donné sa version chiffrée, le vecteur d'initialisation associé ainsi que l'ensemble des octets du bloc non chiffré moins un octet. Il devient alors évident qu'une attaque par force brute pour déterminer l'octet manquant est tout à fait possible (il suffit de tester 256 possibilités différentes).
Ce type d'attaque est intéressant dans le cas où un attaquant est capable de demander le chiffrement de données connues auxquelles sera concaténé un secret (non connu de l'attaquant) : en modifiant la taille des données qu'il fournit, l'attaquant est capable de se ramener au cas précédemment exposé. Il pourra alors décrypter le secret.
L'attaque décrite ci-dessus s'adapte très bien au protocole HTTPS et au vol de fichiers de session (cookies). En effet, lors de l'envoi d'une requête HTTPS vers un serveur, le navigateur concatène automatiquement à la requête l'ensemble des cookies dont il dispose pour le domaine cible. Ainsi, en faisant varier la longueur de l'adresse réticulaire demandée, l'attaquant est capable d'obtenir un bloc contenant une partie de la requête effectuée (connue) et le premier caractère du cookie (non-connu). Une fois ce caractère déterminé, il modifie de nouveau la taille de l'URL cible pour obtenir un nouveau bloc contenant le second caractère du cookie et ainsi de suite jusqu'à obtenir l'ensemble du cookie. Bien entendu, cette technique nécessite que l'utilisateur victime soit connecté au serveur cible et que l'attaquant dispose d'un moyen d'effectuer des requêtes vers ce serveur depuis la machine de la victime. Il lui est aussi nécessaire d'intercepter le trafic chiffré.
Des correctifs sont aussi disponibles (ou en cours de développement) pour les différents produits concernés. Il est conseillé d'appliquer ces mises à jour au plus vite.
Le CERTA rappelle qu'il est impératif de ne pas effectuer d'opérations sensibles sur l'Internet depuis un réseau non sûr.
http://technet.microsoft.com/en-us/security/advisory/2588513
https://bugzilla.mozilla.org/show_bug.cgi?id=665814
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389
Lors du premier volet de cette série d'articles, nous avons abordé l'élévation de privilège d'administration locale vers l'administration Active Directory. Un profil spécifique d'attaquant va déployer de grands efforts afin de parvenir à ce niveau de privilège : le voleur d'informations.
Ainsi, depuis le poste d'un simple utilisateur compromis via une simple pièce jointe type PDF ou un site malveillant, l'attaquant obtient (trop souvent facilement) le contrôle d'un ou plusieurs compte d'administration du domaine. A ce stade, l'attaquant détient les clés lui permettant d'accéder aux données de tous les utilisateurs du domaine : le comité exécutif, le cabinet d'un ministère, un chercheur...
En effet, les informations que l'attaquant recherche peuvent être disséminées dans différents systèmes : les serveurs de fichiers ou de messagerie, les dossiers personnels sur un portable, les différentes applications métier. L'obtention des privilèges d'administration du domaine va permettre à l'attaquant d'accéder sans effort à toutes les données du système d'information dont le contrôle d'accès est assuré via Active Directory.
Reprenons notre énumération des attaques rencontrées.
Depuis des années, des outils existent pour extraire les secrets d'une machine. Parmi ces secrets, on va retrouver par exemple :
Ces outils donnent immédiatement accès à tous les mots de passe (chiffrés de façon réversible). Ils peuvent être immédiatement utilisés.
Il est important de bien comprendre que cette extraction de secrets n'est accessible qu'aux seuls administrateurs d'un poste. Ces outils n'exploitent donc pas de vulnérabilités du système d'exploitation. Par définition, l'administrateur d'un système a accès à tous les secrets de celui-ci.
Cette attaque met en évidence un principe simple : lorsque l'on confie un secret à une machine, on le confie implicitement à tous les administrateurs de cette machine. Si un secret d'une machine (compte de service sur un portable, tâche planifiée sur un serveur) expose un secret aussi puissant qu'un mot de passe d'administration du domaine, il conviendra d'en restreindre strictement l'accès physique ainsi que les droits d'administration.
Le processus LSASS détient les condensats des mots de passe de différentes sessions ouvertes sur le système. Les outils de type « Pass the hash » permettent à l'attaquant de rejouer des authentifications en utilisant ce condensat. Cette attaque est assez proche de l'attaque « énumération des sessions de la machine compromise » décrite la semaine dernière avec l'avantage important de ne pas être liée à une machine. Le condensat du mot de passe peut être réutilisé sur n'importe que système du domaine tant que le mot de passe n'est pas changé.
La prévention de cette attaque est identique à l'attaque « énumération des sessions » :
Plus spécifiquement sur cette attaque, on s'attachera à renouveler régulièrement les mots de passe des comptes puissants.
Dans la période du 23 au 29 septembre 2011, le CERTA a émis les publications suivantes :
Durant la même période, les publications suivantes ont été mises à jour :