La suite Microsoft Office sera-t-elle interdite aux states ? Un juge Texan a prononcé sa sentence mardi dernier, lors d'une affaire de violation de brevet. La société canadienne i4i accuse ainsi la firme de Redmond (Microsoft quoi) de violer un brevet qu'elle a déposé en 1998, relatif aux formats XML.
Sachant que Word 2003 et 2007 (et 2010) se basent sur les formats .docx qui reposent sur du XML, le juge a fixé à 290 millions de dollars les dommages et intérêts.
Face à cette interdiction un peu gênante, Microsoft compte bien faire appel : preuves à l'appui, ils estiment n'avoir violé aucun brevet, et qualifient même d'invalide celui revendiqué par i4i.
En fin de compte, Office n'est pas la seule suite à se baser sur des formats XML, à ma connaissance toutes autres les suites existantes le sont : OpenOffice et ses dérivés et ancêtres, KOffice, etc. Que va-t-il donc se passer pour tous ces logiciels libres ou non, dont les développeurs n'ont surement pas les moyens de payer de telles indemnités ?
Est-ce la fin du monde des suites bureautiques ?
[Source]
jeudi 13 août 2009
Apple ferme les yeux...
... surement pour se protéger des éclats de verre que peuvent projeter certains iPhones. L'actu se retrouve partout dans les medias, mais en tant qu'experts en sécurité, on rigole bien en voyant ça. Après des failles logicielles, les produits vendus par Apple sont victimes de surchauffes ou d'(ex|im)plosions, comme c'est le cas récemment pour deux iPhones.
Il y a donc manifestement une vulnérabilité sur les écrans de ces téléphones : peut-être à cause d'une surchauffe due à une housse (ou pas), les écrans peuvent se fissurer, voire projeter des éclats de verre. Là encore, Apple semble démentir et incriminer des chocs dus aux utilisateurs... qui de leur côté affirment que leur joujou explose sans qu'on ait fait tomber de pommes dessus.
Des cas de dysfonctionnement ont été recensés de nombreuses fois, souvent à cause de batteries au lithium défectueuses. Des rappels massifs ont déjà été faits il y a quelques années, mais l'histoire continue encore et encore...
Avis aux possesseurs, il vaut mieux surveiller votre téléphone, et s'il commence à faire des bruits bizarres, n'hésitez pas à le lancer sur votre boss. Après tout, l'iPhone est peut-être voué à devenir la prochaine arme des Corses ou d'Al-Qaïda ?
[Source]
Il y a donc manifestement une vulnérabilité sur les écrans de ces téléphones : peut-être à cause d'une surchauffe due à une housse (ou pas), les écrans peuvent se fissurer, voire projeter des éclats de verre. Là encore, Apple semble démentir et incriminer des chocs dus aux utilisateurs... qui de leur côté affirment que leur joujou explose sans qu'on ait fait tomber de pommes dessus.
Des cas de dysfonctionnement ont été recensés de nombreuses fois, souvent à cause de batteries au lithium défectueuses. Des rappels massifs ont déjà été faits il y a quelques années, mais l'histoire continue encore et encore...
Avis aux possesseurs, il vaut mieux surveiller votre téléphone, et s'il commence à faire des bruits bizarres, n'hésitez pas à le lancer sur votre boss. Après tout, l'iPhone est peut-être voué à devenir la prochaine arme des Corses ou d'Al-Qaïda ?
[Source]
lundi 10 août 2009
british fail
Désolé pour le retard, mais une info qui vaut le coup d'être relayée sur ce blog.
La nouvelle carte d'identité britannique, qui avait déjà fait parler d'elle pour les sommes colossales qu'elle avait engloutie pour rien. En effet, sa réalisation a couté tellement d'argent que les autorités britannique avaient exclu le développement de lecteurs spécifiques pour la carte. Juste une puce sans lecteur, ça s'annonçait déjà bien. Les choses ont avancé et les voilà avec une carte d'identité complètement altérable en 12minutes!!11
prévoir 5milliard pour équiper les gens d'une carte hackable si c'est pas de l'epic fail ca o_O.
avec en bonus la mauvaise foi du home office :) (lisez l'article en anglais)
La nouvelle carte d'identité britannique, qui avait déjà fait parler d'elle pour les sommes colossales qu'elle avait engloutie pour rien. En effet, sa réalisation a couté tellement d'argent que les autorités britannique avaient exclu le développement de lecteurs spécifiques pour la carte. Juste une puce sans lecteur, ça s'annonçait déjà bien. Les choses ont avancé et les voilà avec une carte d'identité complètement altérable en 12minutes!!11
prévoir 5milliard pour équiper les gens d'une carte hackable si c'est pas de l'epic fail ca o_O.
avec en bonus la mauvaise foi du home office :) (lisez l'article en anglais)
It had seen “no evidence” that personal data was accessible or changeable, and the card had "excellent" security, the Home Office said.bref vous trouverez à présent différents articles un peu partout, mais si vous avez la flemme de chercher, en voici un (en francais en plus :) ca faisait longtemps) et un en anglais un peu plus "direct".
mercredi 5 août 2009
Quand l'écureuil part en cahuète...
Une bonne nouvelle pour les gens qui utilisent le webmail squirrelMail. Eh oui en plein dans le mille, c'est le cas de notre école donc vous aussi!
Le serveur du projet s'était un peu fait rentrer dedans mi-juin(ou peut être bien avant même) par des gens tout plein de bonnes intentions :). Après avoir constaté les dégâts, les administrateurs ont innocemment expliqué que "C'est bon, les gens ont pas fait ça pour toucher au code". Ouf! on l'a échappé belle.
Nous voici donc début août et là qu'est ce qu'on apprend? que trois plug-ins ont été modifiés lors de cette attaque. Lesquels me direz vous et l'intérêt?
Les nouveaux modules sont bien entendu dispos avec des hashs pour vérifier leur intégrité. En attendant, vu l'assiduité aux mises à jour de l'école je ne pense pas qu'on ai à s'inquiéter de quoique ce soit ^^.
le site de squirrelMail, l'article
Le serveur du projet s'était un peu fait rentrer dedans mi-juin(ou peut être bien avant même) par des gens tout plein de bonnes intentions :). Après avoir constaté les dégâts, les administrateurs ont innocemment expliqué que "C'est bon, les gens ont pas fait ça pour toucher au code". Ouf! on l'a échappé belle.
Nous voici donc début août et là qu'est ce qu'on apprend? que trois plug-ins ont été modifiés lors de cette attaque. Lesquels me direz vous et l'intérêt?
- sasql-3.2.0
- multilogin-2.4-1.2.9
- change_pass-3.0-1.4.0
The new versions steal passwords, among other things, and send them to an offsite server.Bref toute les versions mises à jour depuis personne-sait-trop-quand n'étaient ni plus ni moins que des collecteurs de mot de passes.
Les nouveaux modules sont bien entendu dispos avec des hashs pour vérifier leur intégrité. En attendant, vu l'assiduité aux mises à jour de l'école je ne pense pas qu'on ai à s'inquiéter de quoique ce soit ^^.
le site de squirrelMail, l'article
mardi 4 août 2009
cloud computing: trop dans les nuages?
Je vais aujourd'hui m'attarder sur une présentation d'Alex Stamos au blackhat 2009 concernant le cloud computing. Pas de réelle vulnérabilité ou d'exploit fantastique mais des considérations sur la sécurité qui valent la réflexion:
Il semblerait que la génération de nombres aléatoires, un problème réglé depuis des années, en redevienne un.
En effet, pour petit rappel, l'ordinateur utilise les périphériques bas niveau pour collecter des données aléatoires. Il se sert ensuite de ce "réservoir" pour obtenir des nombres "vraiment" aléatoires (donc quasiment non prédictibles). Mais le cloud computing serait en train de changer la donne:
Là ou un pc utilise les mouvements de la souris et les touches du claviers pour collecter de l'aléatoire, un serveur ne possède rien de cela. Il peut toutefois utiliser les mouvements du disque dur comme source d'aléa. Mais qu'en est il d'un serveur virtualisé? N'ayant pas accès aux matériels physiques, il ne lui reste que la mesure du temps exacte depuis sa mise en route, ce qui est bien peu et pas assez pour générer des nombres robustes.
Bien sur plus le temps passe et plus les ressources d'éléments aléatoires sont importantes. Mais Alex Stamos s'intéresse aux machines générées à la volée pour une tache particulière. Ces dernières sont éphémère et d'après lui n'ont pas le temps d'atteindre des seuils raisonnables de ressources aléatoire.
Il imagine ainsi un scénario où l'attaquant se crée une machine sur un serveur. Le peu d'entropie l'aidera grandement dans la prédiction des nombres aléatoires et réduira ainsi considérablement le temps de crackage du chiffrement des autres machines virtualisé.
Ce n'est bien sur à l'heure actuelle que de l'extrapolation, mais loin d'être une chimère ce fait mérite d'y porter attention. Juste en petit exemple du défaut d'entropie des systèmes virtualisés je vous cite un commentaire du dernier article:
ca laisse songeur n'est ce pas...
Les deux articles (bien plus complets et abordant pour le second d'autres problèmes que l'aléa) sur cette conférence: ici et là
Il semblerait que la génération de nombres aléatoires, un problème réglé depuis des années, en redevienne un.
En effet, pour petit rappel, l'ordinateur utilise les périphériques bas niveau pour collecter des données aléatoires. Il se sert ensuite de ce "réservoir" pour obtenir des nombres "vraiment" aléatoires (donc quasiment non prédictibles). Mais le cloud computing serait en train de changer la donne:
Là ou un pc utilise les mouvements de la souris et les touches du claviers pour collecter de l'aléatoire, un serveur ne possède rien de cela. Il peut toutefois utiliser les mouvements du disque dur comme source d'aléa. Mais qu'en est il d'un serveur virtualisé? N'ayant pas accès aux matériels physiques, il ne lui reste que la mesure du temps exacte depuis sa mise en route, ce qui est bien peu et pas assez pour générer des nombres robustes.
Bien sur plus le temps passe et plus les ressources d'éléments aléatoires sont importantes. Mais Alex Stamos s'intéresse aux machines générées à la volée pour une tache particulière. Ces dernières sont éphémère et d'après lui n'ont pas le temps d'atteindre des seuils raisonnables de ressources aléatoire.
Il imagine ainsi un scénario où l'attaquant se crée une machine sur un serveur. Le peu d'entropie l'aidera grandement dans la prédiction des nombres aléatoires et réduira ainsi considérablement le temps de crackage du chiffrement des autres machines virtualisé.
Ce n'est bien sur à l'heure actuelle que de l'extrapolation, mais loin d'être une chimère ce fait mérite d'y porter attention. Juste en petit exemple du défaut d'entropie des systèmes virtualisés je vous cite un commentaire du dernier article:
The same problem (lack of randomness) may also affect IP sequence number generation for virtual machines. A quick nmap scan of a Fedora Core 10 system running as a VM ends with:
TCP Sequence Prediction: Difficulty=0 (Trivial joke)
but the same host running Fedora Core 11 natively gives:
TCP Sequence Prediction: Class=random positive increments
Difficulty=939462 (Good luck!)
Cheers,
Dave
ca laisse songeur n'est ce pas...
Les deux articles (bien plus complets et abordant pour le second d'autres problèmes que l'aléa) sur cette conférence: ici et là
lundi 3 août 2009
defcon: la sécu, c'est aussi physique
Un billet au sujet du Defcon cette fois ci, sur le bypass de sécurité physique suivant deux aspects. Le premier concerne le travail réalisé par Ricky Lawshae. Ce dernier s'est intéressé au système de sécurité des portes à accès par badge dans son université du Texas. Au lieu de s'attaquer au crackage du RFID comme beaucoup, il a eu la bonne idée de regarder au niveau des communications entres les portes. Ces dernières communiquent avec un serveur central qui lui même communique avec un programme chargé de gérer les accès de chacun, lever les alertes, etc.. Intercepter ces communications lui a permis de mettre en évidence une grosse faiblesse du mécanisme: les numéros de séquence de la communication TCP sont très très prédictibles (+40 entre chaque dit-il). Du coup, une personne qui intercepte la commande de déverrouillage d'une porte peut sans problème envoyer une nouvelle requête avec le numéro de séquence approprié et l'ip du centre admin, la porte prendra l'ordre pour tout à fait légitime.
Il faut savoir que ce système est utilisé dans pas mal d'universités et d'hôpitaux américains. L'auteur indique que le constructeur aurait pu rendre cette attaque bancale par la simple randomisation des numéros de séquence ou le chiffrement des commandes. Article original par ici!
L'autre conférence concerne un trio d'experts en verrous: Marc Weber Tobias, Toby Bluzmanis et Matt Fiddler.
Ces derniers se sont penchés sur la sécurité des verrous très haut de gamme utilisés dans les milieux à sécurité très renforcée. Ces verrous combinent sécurité mécanique et électronique: chaque clé possède en bout un micro circuit contant un ID unique. Une puce dans le verrou permet d'autoriser ou non à tourner la clé et en prime permet donc de logger qui est passé, où, et quand. A 600/800$ le verrou et 95$ la clé autant dire qu'il faut vraiment avoir quelque chose de critique à protéger.
Pourtant les 3 experts ont réussi à bypasser la vérification électronique avec une technique de vibration dont ils ne veulent pas donner les détails. Tout du moins, pas avant que le constructeur ait accepté un rappel sans conditions ni frais de tous les verrous vendus. A croire que cette technique va vraiment les rendre obsolètes.
Ce n'est pas tout, lorsqu'un verrou est désactivé non seulement la personne n'est pas identifiée puisqu'ils ont réalisé l'attaque de manière purement mécanique (en retirant la batterie de la clé) mais le verrou reste ouvert. Pour remédier à cela, le constructeur a ajouté un ressort refermant le verrou mais au détriment des contacts pour les broches, placés sur un coté de la clé et qui la rendait très difficilement duplicable tout en ajoutant un control supplémentaire. La présentation devait avoir lieu dimanche mais je n'ai pas trouvé à l'heure actuelle de compte rendu de la conférence. Mais si j'arrive à en apprendre plus sur cette technique de vibration nuls doutes qu'un billet y sera consacré!
l'article original
Il faut savoir que ce système est utilisé dans pas mal d'universités et d'hôpitaux américains. L'auteur indique que le constructeur aurait pu rendre cette attaque bancale par la simple randomisation des numéros de séquence ou le chiffrement des commandes. Article original par ici!
L'autre conférence concerne un trio d'experts en verrous: Marc Weber Tobias, Toby Bluzmanis et Matt Fiddler.
Ces derniers se sont penchés sur la sécurité des verrous très haut de gamme utilisés dans les milieux à sécurité très renforcée. Ces verrous combinent sécurité mécanique et électronique: chaque clé possède en bout un micro circuit contant un ID unique. Une puce dans le verrou permet d'autoriser ou non à tourner la clé et en prime permet donc de logger qui est passé, où, et quand. A 600/800$ le verrou et 95$ la clé autant dire qu'il faut vraiment avoir quelque chose de critique à protéger.
Pourtant les 3 experts ont réussi à bypasser la vérification électronique avec une technique de vibration dont ils ne veulent pas donner les détails. Tout du moins, pas avant que le constructeur ait accepté un rappel sans conditions ni frais de tous les verrous vendus. A croire que cette technique va vraiment les rendre obsolètes.
Ce n'est pas tout, lorsqu'un verrou est désactivé non seulement la personne n'est pas identifiée puisqu'ils ont réalisé l'attaque de manière purement mécanique (en retirant la batterie de la clé) mais le verrou reste ouvert. Pour remédier à cela, le constructeur a ajouté un ressort refermant le verrou mais au détriment des contacts pour les broches, placés sur un coté de la clé et qui la rendait très difficilement duplicable tout en ajoutant un control supplémentaire. La présentation devait avoir lieu dimanche mais je n'ai pas trouvé à l'heure actuelle de compte rendu de la conférence. Mais si j'arrive à en apprendre plus sur cette technique de vibration nuls doutes qu'un billet y sera consacré!
l'article original
samedi 1 août 2009
blackhat: comment se jouer de SSL
Premier billet rapportant du blackhat 2009 ou je vais tacher d'aborder le plus simplement possible les moyens de tromper SSL présentés par Moxie Marlinspike. Il faut savoir que ces méthodes reposent sur le laxisme dans l'implémentation du protocole et la configuration des applications l'utilisant. Ainsi la présentation commence par un retour sur les chaines de certifications.
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:
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:
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":
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
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
Inscription à :
Articles (Atom)