SSL/TLS, quèsaco ?
SSL est un protocole de sécurisation des échanges réseaux initialement créé par Netscape. Il est notamment utilisé pour les connexions HTTPS (paiement en ligne par exemple). SSL permet l'authentification des participants et le chiffrement des données.
Il existe deux modes de SSL : serveur ou client.
En SSL serveur, seul le serveur possède un bi-clé (couple clé publique/clé privée qui identifie une entité). Autrement dit, le client peut authentifier le serveur, mais le serveur ne sait pas qui est le client. C'est le mode utilisé pour le paiement en ligne. Le serveur n'a pas besoin de savoir qui vous êtes, mais vous avez besoin de savoir que le serveur est bien qui il prétend être.
En SSL client, le client possède aussi son bi-clé, ce qui permet au serveur de l'authentifier. C'est une authentification mutuelle (utilisée pour la déclaration des impôts en France par exemple).
Bon, et l'homme du milieu alors ?
C'est un type d'attaque qui consiste à se placer entre un client et un serveur et à se faire passer pour l'un afin d'abuser l'autre. Dans notre cas, il s'agit d'abuser le serveur.
Mais SSL n'est pas protégé contre ça ?
Si. Mais une « faille » a été découverte.
Pour faire simple, une communication SSL débute par une négociation durant laquelle le client et le serveur se font coucou et se demandent comment ça va s'échangent des infos (algorithmes de chiffrement connus, certificats, calcul de la clé de session...). Bref, ils se mettent d'accord pour la suite.
Un fois que cet échange est fini correctement des deux côtés, le client peut envoyer ses données qui seront automatiquement chiffrées.
Jusque là, ça va. Seulement parfois, le serveur doit demander une renégociation. C'est le cas par exemple quand on veut passer d'une connexion SSL serveur en SSL client. Ou quand le client propose des algorithmes de sécurité trop faibles pour le serveur.
Là encore, c'est prévu par le protocole, pas de souci.
Et alors, cette faille ?
J'y arrive.
Prenons l'exemple d'un serveur web tout ce qu'il y a de plus classique.
Aline Nehat reçoit un courriel de sa banque lui demandant de vérifier qu'elle accède bien à son compte en ligne. Le courriel est bien fait, il y a même un lien direct vers le site de la banque ! Aline clique donc dessus et arrive sur le site de sa banque. Comme d'habitude, elle demande à s'authentifier.
Comme vous l'avez deviné, notre chère Aline est victime d'un phishing. Elle n'est pas réellement sur le site de sa banque mais sur une contrefaçon parfaite, qui se place ainsi en « homme du milieu ». Cet intrus met la requête d'Aline en attente et démarre une session SSL serveur sur le véritable site de la banque.
Cependant, il met deux (ou plus) requêtes HTTP dans les données (c'est parfaitement faisable en HTTP 1.1 avec du keepalive). La première demande une page requérant une authentification client, donc une renégociation SSL. Le serveur démarre alors une renégociation SSL, sur la même connexion.
À partir de là, l'intrus envoie la requête initiale d'Aline (qu'il avait mise de côté) au serveur et se content de relayer les messages entre les deux.
Ça y est, l'attaque a eu lieu. Vous ne l'avez pas vue passer ? Aline et le vrai serveur non plus.
Et moi non plus, elle est où l'attaque ?
Regardons la scène au ralenti du point de vue du « vrai » serveur :
- Il voit une demande de connexion sur son port SSL. La requête vient de l'intrus, mais il n'y a rien de suspicieux ici, donc il négocie et ouvre le canal SSL.
- Il reçoit une suite de requêtes HTTP (de l'intrus) qu'il commence à analyser. La première demande une page pour laquelle il faut du SSL client. Pas de problème, il met les requêtes de côté et lance une renégociation
- L'authentification se passe bien, il reprend donc les données qu'il a mises au chaud et exécute les requêtes.
Vous voyez le truc ?
Toujours pas ? Relisez les 3 étapes précédentes.
Lentement.
Laissez-les infuser en vous.
Vous ne voyez vraiment pas ? Bon, d'accord, parce que je suis gentil :
Le serveur vient d'exécuter des requêtes forgées par l'intrus sur une connexion authentifiée avec Aline.
Tout vient du fait que le serveur met en attente la requête initiale qui déclenche la renégociation, puis l'exécute une fois la renégociation effectuée. Seulement, la requête initiale n'est pas couverte par l'authentification client, puisqu'elle est reçue avant.
Pourquoi le serveur fait-il comme ça ? Parce qu'il n'a pas le choix. Il ne peut pas demander au client de réémettre la requête une fois la renégo validée. Il n'y a pas de code HTTP pour ça. Le serveur est donc bien obligé de réutiliser la requête initiale.
Ce problème est identifié depuis Août, et les découvreurs ont dès lors commencé à analyser les implications et corrections possibles.
Un premier patch pour OpenSSL existe : il désactive toute renégociation. C'est brutal, mais c'est le seul moyen efficace pour le moment.
Notes :
- Je n'ai pris l'exemple du phishing qu'afin de scénariser l'histoire. On pourrait imaginer d'autres moyen pour qu'Aline aille sur l'intrus (DNS spoofing par exemple)
- Bien que je n'aie présenté qu'un exemple avec un serveur HTTP, le principe reste valide avec d'autres protocoles.
Sources :
- Message sur la ML de l'IETF
- Message sur Slashdot
- Site avec des explications d'un co-découvreur (indépendamment de l'IETF)
- Patch OpenSSL
# DNS Spoofing
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: DNS Spoofing
Posté par Olivier Serve (site web personnel) . Évalué à 4.
[^] # Re: DNS Spoofing
Posté par thedude . Évalué à 3.
Le navigateur ne gueulera pas, ta machine croit avoir resolu logitelnet.socgen.fr vers la bonne adresse. Le certif etait lie au domaine et pas a l'ip, le navigateur sera ravi de ne pas t'emmerder avec des popups te disant que tu vas mourir.
[^] # Re: DNS Spoofing
Posté par Olivier Serve (site web personnel) . Évalué à 2.
# SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Zenitram (site web personnel) . Évalué à 9.
Je pense que j'ai décroché au moment où tu dis que "La première demande une page pour laquelle il faut du SSL client."
Hors, pour une banque, c'est que le serveur qui a une clé privée, pas le client. La banque n'utilise pas de certificat du client, seul le serveur doit être authentifié (et après tu tapes ton code).
Donc que vient faire cette demande dans l'histoire?
Ca manque d'un schéma sur les paquets légitimes, ceux forgés etc... Car on s'y perd (moi en tous cas).
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Olivier Serve (site web personnel) . Évalué à 3.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Si cette faille touchait le SSL serveur, ça donnerait ça :
- Quelqu'un fait de l'empoisonnement DNS pour te faire croire que c'est lui la Société Générale ;
- tu te connectes comme d'habitude sur ce que tu crois être le site de la Société Générale : dans ta barre d'URL, l'adresse du site habituel, que tu as bien vérifiée ;
- tu te connectes en réalité au serveur de Quelqu'un ;
- lui se connecte au serveur de la Société Générale ;
- il arrive à établir la connexion en te présentant le certificat habituel de la Société Générale et en ayant connaissance de la clef de chiffrement utilisée.
Là, ça touche le SSL client, donc c'est plutôt :
- Quelqu'un fait du typo-squatting sur un nom voisin de celui de la Banque Sérieuse qui identifie ses clients par certificat ;
- tu te connectes par erreur, ou en suivant un lien de phishing, sur ce que tu crois être le site de la Banque Sérieuse, sans t'apercevoir que l'adresse est légèrement différente ;
- tu te connectes en réalité au serveur de Quelqu'un ;
- il se connecte au serveur de la Banque Sérieuse ;
- il arrive à établir la connexion en te présentant son certificat – valide pour son site –, en présentant à la Banque Sérieuse ton certificat client, et en ayant connaissance de la clef de chiffrement utilisée.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Olivier Serve (site web personnel) . Évalué à 3.
1) Une renégo peut avoir lieu aussi si le serveur demande un changement d'algorithmes. C'est assez rare avec des sites web, moins avec des services web.
2) L'intrus n'a jamais connaissance de la clé de chiffrement utilisée entre Aline et sa banque. Il se contente d'injecter des requêtes HTTP nécessitant une authentification client avant que l'authentification n'ait lieu. Et ces requêtes sont exécutées après l'authentification (et sont donc acceptées).
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par thedude . Évalué à 4.
??
Et ca donnerais quoi si cette faille touchait le buffer overflow? Ou le XSS?
Cette faille ne touche pas le ssl serveur, quelle est la pertinence de rever a ce qu'elle pourrait faire si elle touchait le ssl serveur?
ensuite, cette faille ne donne pas connaissance de la cle de chiffrement ou quoi, ca permet "juste" d'injecter un certain nombre de requete a la connexion, mais vu la facon dont c'est decrit, je vois pas comment l'attaquant peut comprendre une quelconque reponse, vu qu'il n'a certainement pas connaissance de la cle de session (vu que la pre master key est generee par le client initial et echangee en utilisant la cle publique du serveur).
Et ca requiert du dns spoofing/poisonning/ce que tu veux, vu que le certif presente au client etant l'original, ca va gueuler chez le client si l'hote n'est pas celui du serveur.
C'est tres certainement un gros souci (si on en arrive a utiliser du SSL client, c'est qu'on a un gros besoin de securite, vu le pot de pus que c'est a gerer), mais on est tres tres tres loin de ce que tu racontes la.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Autrement dit il a un accès en écriture seule au système d'information (limité par les droits de l'utilisateur).
Par contre tu as raison (ça m'avait échappé sur le coup), mon scénario ne marche pas. En effet, le client reçoit le certificat du serveur original, qui n'est pas censé correspondre au nom de domaine de l'intrus. Il faut donc du DNS spoofing/cache poisonning/... pour que ça marche.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par thedude . Évalué à 8.
Ce qui est interessant a faire sur un site d'ebanking, c'est de se faire des virements et des trucs de ce genre. Et ca se fait grand minimun en 2-3 requetes, avec un bout de challenge response dedans, donc meme en bourrant toutes tes requetes a l'affilee, ca va pas aller pisser bien loin.
Pour faire une analogie avec la banque et le monde physique, ca revient un peu a avoir enorme coffre avec une porte a sens unique qui peut laisser rentrer n'importe qui sous certaines conditions tres precises, en profiter pour faire rentrer a la bourrin 150 demenageurs bretons pour porter les lingots, mais etre incapable de ressortir dudit coffre.
L'entree est gratuite, la sortie payante.
Les banques utilisent de toutes facons relativement peu le ssl client, parce que c'est un merdier pas possible de gerer les certifs et que ces cons de clients ont toutes les chances de se le faire piquer sur leur windows zombie et que ca va flooder leur support de "ca marche pas!!!".
Ils preferent en general un systeme d'otp via les petits porte cles base sur un chiffrement symetrique, si ce con de client se fait piquer ses cles, tu lui en renvoit un nouveau et c'est marre, beaucoup plus simple.
La comme ca en fait, j'ai du mal a voir quelle application directe on peut faire de cette attaque.
C'est un peu comme de l'ip spoofing, tu peux envoyer autant de paquet que tu veux en te faisant passer pour x.x.x.x, si t'as pas la reponse aux dits paquets, ca t'avance pas enormement quand meme.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Olivier Serve (site web personnel) . Évalué à 2.
En fait, il est plus facile d'exploiter cette attaque avec des services web (SOAP/REST/...) car ils sont en général plutôt prévus pour accepter des requêtes unitaires.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Larry Cow . Évalué à 3.
Ceci dit, ça ne réglerait que le problème d'un domaine Unicode qui chercherait à se faire passer pour un domaine ASCII connu. Un domaine Unicode pourrait facilement ressembler à un autre domaine Unicode.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Jaimz . Évalué à 2.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Olivier Serve (site web personnel) . Évalué à 10.
Aline Intrus Banque
|----(client hello)--->| |
| | |----(client hello)--->|
| | | |
| | |<---(server hello)----|
| | |<----(certificat)-----|
| | |<-(server hello done)-|
| | | |
| | |--(client key xchge)->|
| | |--(chg cipher spec)-->|
| | |- - - (finished)- - ->|
| | | |
| | |<--(chg cipher spec)--|
| | |<- - - (finished)- - -|
| | | |
| | |- (GET /priv/evil)- ->| (requêtes forgées)
| | | |
| | |<----(hello req)------| (renégo initiée par le serveur)
| | | |
| `-|----(client hello)--->| (requête d'Aline rejouée par l'intrus)
| | |
|<---(server hello)----|<---(server hello)----|
|<----(certificat)-----|<----(certificat)-----|
|<-----(cert req)------|<-----(cert req)------|
|<-(server hello done)-|<-(server hello done)-|
| | |
|----(certificat)----->|----(certificat)----->|
|--(client key xchge)->|--(client key xchge)->|
|----(cert verif)----->|----(cert verif)----->|
|--(chg cipher spec)-->|--(chg cipher spec)-->|
|- - - (finished)- - ->|- - - (finished)- - ->|
| | |
|<--(chg cipher spec)--|<--(chg cipher spec)--|
|<- - - - - - - - -(finished)- - - - - - - - -|
| | |
|<- - - - - - - -(HTTP/1.1 OK)- - - - - - - - | (réponse à la requête forgée)
| | |
|- - - - - -(GET /priv HTTP/1.1)- - - - - - ->|
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par thedude . Évalué à 10.
Deja cette attaque ne passe pas le mecanisme de login applicatif du site, mais uniquement le tunnel SSL client.
SSL Client refuse en effet le handshake si le certif n'est pas le bon.
Mais derriere, faut quand meme se logger sur le site de la banque (en utilisant ledit tunnel ssl).
Bref, passons.
Le Mechant se met entre alice et banque.
Il met ne place du dns poisonning et attend peinard en buvant des bieres qu'alice aille sur socgen.fr, ce qui la redigera vers la machine de Mechant.
Mechant fait une copie parfaite de logitelnet et se contente pour l'instant de rediriger 1:1 ce qu'envoie alice a la banque.
Il recoit d'un cote, rebalance de l'autre, sans se poser de question.
A un moment, alice va sur une page qui requiert du SSL client. La Mechant va sortir de sa taniere.
Il ne va pas rediriger tout de suite la requete d'alice vers la SG, mais plutot les faire preceder de qq requetes forgees, qui elles aussi requiert du SSL Client, style "vire 2 000 000 de dollars sur le compte 007" et les balancer a la SG.
On a donc "requete http pour 1 millions de dollars sur mon compte", "requete pour 1 million sur le compte de maman" et "requete legitime d'alice", le tout bourre dans une seule requete HTTP (la legitime d'alice tant qu'a faire), apparement c'est valide.
La sg recoit cette requete 3-en-1 pour du ssl client, elle va donc lancer le handshake SSL. Et comme elle doit bien traiter cette requetes un jour, elle la met de cote pour la traiter une fois le handshake fini.
Mechant ne peut pas passer le handshake parce qu'il n'est pas alice et n'a pas son certif.
Mais alice venant de faire une requete SSL Client, sa machine ne va donc pas s'etonner de recevoir en reponse un handshake (alice non plus d'ailleurs. Oui alice est tres geek et sait comment se passe un handshake ssl).
Mechant se contente donc de retourner a Alice exactement ce que la banque lui demande dans le handshake.
Donc echange de random, generation de cle symetrique chiffrees avec les cles publique de l'autre.
A ce niveau, mechant est redevenu un routeur. Il fait suivre, et ne peut de toutes facons rien lire, parce que c'est chiffre avec des cles publique et n'a pas les cles privees correspondantes.
A la fin du handshake, les 2 parties (alice et banque) ont leur cle symetrique, elles sont passees sous le nez de mechant qui ne peut pas les lire.
Handshake fini, avec succes, banque reprend donc les 3 requetes qui ont initie le handshake, vire un million a mechant, un million a ma maman (oui, c'est moi le mechant dans l'histoire, et alice est une bonne salope, je tiens a le preciser) et ensuite traite la requete d'alice.
Mechant recoit la reponse a ses requetes de virement, les drop (il ne peut pas les renvoyer a alice, elle ne les a pas faites). Il ne peut PAS les lire. Il n'a pas la cle.
Mechant recoit la reponse a la requete d'alice et la renvoit.
Bref, il reprend son boulot de routeur a forwarder strictement ce qu'il recoit.
Au final:
Tout marche tres bien, le protocole EST efficace.
Le probleme ici est la possibilite de bourrer plusieurs requetes dans une seule.
Ensuite, ca ne passe que la creation du tunnel SSL, j'ose esperer qu'une quelconque banque deployant du SSL client va AUSSI mettre une page de login.
Dans ce cas les premieres requetes du mechant seront reboutee parce que pas encore logge, et par la suite il ne peut plus rien faire, donc il est baise.
Bref, le monde ne va pas s'ecrouler demain.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par octane . Évalué à 4.
Si si, et c'est là ou l'attaque est percutante.
L'attaquant peut forger un début de requête, mais pas la suite.
Alice pense envoyer un entête HTTP:
GET /secure/moncompte.html
Host: mabanque
Authent: mon-authent-que-j'ai
Cookie: blablabla
Mais l'attaquant peut ajouter en préambule quelque chose. L'idée de l'attaquant c'est d'ajouter une ligne d'entête 'avaleuse', cf:
GET /secure/moncompte/virement-plein-de-pepetes
X-blackhole: -- attention il n'y a pas de retour chariot ici.
Puis il lance les renégos, etc...
La requête parvenant à la banque sera donc:
GET /secure/moncompte/virement-plein-de-pepetes
X-blackhole: GET /secure/moncompte.html
Host: mabanque
Authent: mon-authent-que-j'ai
Cookie: blablabla
HTTP-ptotocolairement parlant, c'est valide. Les lignes d'entete démarrant par X sont ignorées, et l'attaquant récupère du même coup les credentials d'authent, les cookies éventuels, etc etc..
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Pire, en forgeant une requête terminée par un header incomplet (« X-Plop: » qui va permettre d'effacer la première ligne de la requête d'Aline tout en conservant les autres en-têtes), l'intrus profite de tous les cookies du client. Pour une seule requête, certes.
[^] # Re: SSL et moi, on n'est pas amis, trop idiot pour ça.
Posté par Alex . Évalué à 1.
néanmoins en pratique, à part dans certaines entreprises, personne ne m'a jamais filé un certificat pour pouvoir m'authentifié (même pas ma banque... et tout d'un coup je me dis que cest tant mieu ;) )
# La mafia est partout !
Posté par windu.2b . Évalué à 9.
J'aurais plutôt dit : « « homme au milieu », non ?
[^] # Re: La mafia est partout !
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Cela dit, j'ai toujours entendu parler d'« homme du milieu » en français. Même si ce n'est pas une référence absolue, wikipédia est d'accord : http://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu
[^] # Re: La mafia est partout !
Posté par maxix . Évalué à 2.
# Ça mériterait une dépêche
Posté par Carl Chenet (site web personnel) . Évalué à 6.
[^] # Re: Ça mériterait une dépêche
Posté par mansuetus (site web personnel) . Évalué à 3.
# et en désactivant HTTP 1.1?
Posté par Bertrand Mathieu . Évalué à 1.
[^] # Re: et en désactivant HTTP 1.1?
Posté par elloco (site web personnel) . Évalué à 1.
[^] # Re: et en désactivant HTTP 1.1?
Posté par Alex . Évalué à 1.
Si c'est le cas, c'est transparent pour le client, mais c'est relativement lourd.
Ceci dit je ne connais aucun site public qui me propose une authentification par certificat (mais ça doit bien éxister je suppose), et dans les entreprises proposant ce genre de service, il est rarement possible d'établir une session ssl si l'on ne présente pas son certificat
[^] # Re: et en désactivant HTTP 1.1?
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Au hasard, en France, l'administration des impôts. Plus certains services administratifs (Système d'Immatriculation des Véhicules par exemple).
En Belgique, la carte d'identité électronique permet(tra ?) de s'authentifier sur des sites administratifs et repose sur ce principe.
et dans les entreprises proposant ce genre de service, il est rarement possible d'établir une session ssl si l'on ne présente pas son certificat.
Tu as rarement du SSL client uniquement. C'est plus souvent un mélange de SSL serveur & client pour les parties vraiment sensibles.
[^] # Re: et en désactivant HTTP 1.1?
Posté par Alex . Évalué à 1.
C'est vrai que j'avais oublié les sites en gouv, pourtant ils n'ont même pas de certificats ev
C'est plus souvent un mélange de SSL serveur & client pour les parties vraiment sensibles.
Oui ça allait de soit
[^] # Re: et en désactivant HTTP 1.1?
Posté par Alex . Évalué à 1.
[^] # Re: et en désactivant HTTP 1.1?
Posté par Olivier Serve (site web personnel) . Évalué à 2.
D'ailleurs, j'ai pris l'exemple du HTTP parce que c'est ce qui parle le plus, mais sur du LDAP le problème est identique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.