petite déf, pour que tout le monde soit ok ;):
Un CA est une autorité de certification, c'est à dire une entité à qui l'on fait confiance et qui est habilitée à délivrer des certificats signés à d'autres entités, sites etc
Une certificat peut etre assimilé la carte d'identité d'un site, c'est un ensemble d'informations et une clé publique qui permettent au site de prouver que c'est lui par le biais et lors d'échanges cryptographiques
rootCA->CA intermediaire->site(ex: paypal.com)
la verification s'effectue comme suit:
- le site correspond bien au sujet du certificat
- son certificat n'est pas expiré
- il est bien signé par un CA
- le CA fait partie des tiers de confiance
Un des problèmes est que tout le monde se préoccupe des validations de signatures par le CA mais au final, cela nous permet juste de dire que la chaine est valide au sens "complète" (chacun s'est fait valider par une instance supérieure "à priori" de confiance). Ainsi, la chaine suivante est elle aussi valide:
rootCA->intermediaire->hacker.com
si hacker.com décide de signer un certificat valide pour paypal on obtient la chaine:
rootCA->intermediaire->hacker.com->paypal.com
il ne manque qu'une chose: hacker.com n'est pas paypal et par conséquent ne peut pas utiliser son certificat ''pour le site paypal.com''
En fait ce n'est pas tellement un problème et c'est la qu'entrent en jeu les défauts de configurations. La plupart des CA n'explicitant pas la contrainte CA=false pour les sites dont ils signent les certificats, les implémentations de SSL n'ont plus tenu compte de ce champ. Le résultat est évident: n'importe quel site avec un certificat valide peut agir en CA et signer des certificats pour n'importe quel autre domaine! Il suffit que le certificat soit présenté dans une chaine, les navigateurs web se contenteront de valider la chaine entière (soit-disant "chaine de confiance").
L'auteur présente SSLsniff qu'il a mis au point et maintient depuis quelques années.
Avec cet outil, l'attaquant intercepte une connexion standard. Génère et signe avec un quelconque certificat validé un certificat pour le site que voulait visiter la cible. Il n'a plus qu'a fournir la chaine entière au client pour que son browser la valide sans broncher.
L'attaquant peut alors assurer la connexion entre le client et le site légitime en déchiffrant les communications et rechiffrant à l'autre extrémité (ce type d'écoute furtive où l'on ne bloque pas les échanges s'appelle Man In The Middle[MITM]).
Dans la continuité de la présentation Moxie Marlinspike aborde le SSL stripping, cette technique, relativement simple à expliquer, consiste à s'attaquer à SSL AVANT de rencontrer SSL. Comme il l'explique, dans les faits on ne rencontre presque jamais SSL de front, on arrive sur une page sécurisée via un lien (exemple: consulter le panier, confirmer la commande etc...) ou par une redirection 302 (typiquement les webmails: peu de gens se connectent directement en https dessus, c'est le webmail qui redirige sur du https). L'idée est donc d'exploiter cette redirection pour amener la victime sur le site du hacker qui lui présentera le site tel quel. L'attaquant agit ainsi en tant que proxy, mais pour le coup, la liaison entre le client et l'attaquant sera en HTTP(en clair) et le HTTPS ne sera utilisé qu'entre l'attaquant et le siteweb détourné.
dernier élément de contournement: le Certificat x509
il contient 5 informations qui nous intéressent plus que les autres:
- l'entité qui a délivré le certificat
- la période de validité du certificat
- le sujet (entité a qui il est délivré)
- la clé publique
- la signature du CA
Mais là encore, ce n'est pas un problème, et pour nous en convaincre Moxie retourne dans le passé:
Au début, les démarches d'obtention de certificat étaient tels que Mr Péguillan nous l'a appris pour obtenir des biclés: identification, notaire, appels téléphoniques etc... bref obtenir un certificat pour une entité autre que nous était impossible. A présent c'est plus ou moins 3clics sur le site d'un CA pour s'enregistrer, résultat on peut valider n'importe quel domaine en ligne et obtenir un certificat valide pour ce domaine.
Donc lors de la phase de présentation, le client vérifie le sujet. Cette section du certificat contient de nombreuses informations sous forme arborescente, mais là encore, chacun a utilisé ce qu'il voulait et au final seul le "Common Name" est utilisé pour la validation. Moxie cite Bob Jueneman qui résume très bien la rigueur dans l'utilisation des informations "sujet":
“There is nothing in any of these standards that would prevent me from including a 1 gigabit MPEG movie of me playing with my cat as one of the RDN components of the DN in my certificate."
Donc si vous suivez, lors de la présentation du certificat, il suffira de présenter au client un nom (CN) identique au site qu'il veut visiter. D'un autre coté, on peut enregistrer très facilement un nom de domaine et le faire valider pour avoir un certificat.
La solution se trouve dans l'implémentation de SSL, le Common Name est une chaine de caractère, que se passe-t-il si on fournit un certificat pour www.paypal.com\0hacker.com ??
Et oui, c'est là que ça fait mal, à peu près tous les navigateurs vont s'arrêter au caractère null '\0' et interpréter le CN du certificat comme étant www.paypal.com. L'inconvénient et que cela force à faire des attaques très ciblés ou un certificat pour chaque site, pas génial en somme -_-.
Pas de problème rassure Moxie, les implémentations de SSL, tiennent compte des wildcards (caractères joker), et là: C'est le drame! :D
on enregistre un nom de domaine *\0.hacker.com ou *~.hacker.com pour faire signer un certificat valide que l'on peu présenter à la place de n'importe quel site et le navigateur n'y verra que du feu o_O. Il faut savoir qu'il n'y pas que les navigateurs que l'on peut tromper puisque l'on retrouve ssl implémenté dans l'instant messaging (AIM,msn etc..) et les clients de messagerie.
Moxie fini par une réflexion sur ce que l'on pourrait craindre comme réaction:
ce serait vraiment pas de chance si une autorités venait à (ou même réussir à) révoquer des certificats universels ou avec \0 et de là à revoir l'implémentation de ASN.1.... no comment.
voila pour ce looong billet, j'espère avoir été assez clair dans les explications, si vous n'avez pas compris quelque chose n'hésitez pas à me contacter, j'apporterais des compléments en commentaire, pour ceux qui sont à l'aise avec ces notions et veulent en savoir plus (notamment sur le contre d'OCSP par rapport aux révocations de certificats) je vous invite à aller voir la vidéo de la présentation et les slides sur le site du blackhat2009
Aucun commentaire:
Enregistrer un commentaire