Nous entendons souvent parler de force de mot de passe, de Single Sign On, de clés de chiffrement, mais finalement, combien de codes connaissons nous? En parlant indifféremment du monde réel et du monde informatique.
Je me suis intéressé à dénombrer le nombre de fois ou je dois taper un code pour me permettre d'accéder à une ressource ou à une donnée en déroulant une journée type.
Ma voiture a un code (4 chiffres) pour démarrer. Une fois arrivé au travail j'allume généralement mon téléphone (PIN, 4 chiffres). J'allume mon ordinateur qui me demande le mot de passe (+10 caractères) puis la messagerie (+10 caractères), puis un outil métier (+10 caractères). Mon téléphone fixe a un code pour écouter les messages reçus en mon absence (4 chiffres). Si j'ai besoin, je peux imprimer des documents (code à 4 chiffres) sur une imprimante réseau dans le couloir ou bien scanner des documents (autre code à 4 chiffres).
Je me connecte sur différentes messageries et forums on-line, la personnelle (+10 caractères), la secondaire (+10 caractères) et souvent une de mes identités poubelles pour regarder un peu le type de spams qui circulent (+10 caractères). J'ai besoin de me connecter à des sites professionnels ou des machines liées à mon métier. Mettons en moyenne 5 à 6 mots de passes. La majorité des machines de tests ont un mot de passe par défaut, toutefois.
Je peux utiliser ensuite ma carte bleue pour manger (PIN, 4 chiffres), et il m'arrive de me connecter sur le site de ma banque (code à 6 chiffres).
Lorsque je me connecte sur blogspot pour écrire ce texte, j'ai encore un code différent (+10 caractères).
Le soir, je dois mettre le code de mon immeuble (5 chiffres) puis celui de l'ascenseur (5 chiffres également). Si je rallume mon ordinateur personnel, j'ai le code LUKS (+10 caractères) puis le mot de passe (+10 caractères).
Je ne parle pas du code permettant d'accéder au vestiaire sportif, du code des casiers, du code des cadenas de mes valises et des codes d'immeubles de mes amis. J'aurais pu également citer de nombreuses cartes de fidélités de magasin, cartes dont je me passe, puisque le fait de donner mon code client à la caisse est suffisant pour me reconnaître. J'arrête là mon inventaire à la Prévert, pouvant encore le continuer longtemps.
Existe t'il une solution à l'explosion de ces codes? Je ne pense pas. Est ce qu'une telle solution est elle souhaitable? Je ne pense pas non plus. Je pense que nous avons besoin de plusieurs identités différentes: pourquoi le code de mon immeuble serait lié à celui de mon PIN de carte bleue ou encore le mot de passe de ma session linux?
Je ne pose pas ces questions innocemment. L'ambient intelligence nous promet un monde d'objets interconnectés. Nous nous en approchons toujours plus (l'électronique est déjà de partout, la communication entre ces objets augmente), comment gérerons nous les problématiques d'authentification? Faut-il qu'un téléphone portable serve à payer, à entrer dans son immeuble, à se géolocaliser sans action volontaire d'authentification? De plus l'authentification doit bien entendu être différente afin que l'utilisateur soit conscient de la requête. Il ne faudrait pas qu'un utilisateur tape un PIN de manière automatique sans pouvoir différencier une requête de payement, de signature ou d'ouverture de porte...
Les services proposés sont enthousiasmants, mais comment en limiter les risques?
jeudi 26 novembre 2009
vendredi 6 novembre 2009
MiTM sur SSL/TLS; faille protocolaire
La nouvelle est tombée il y a deux jours, il est possible de faire un MiTM sur du SSL/TLS. LEs journalistes d'internet vont encore parler de faille terrible, de big one, etc etc..
Oublions un peu les journaux du net et voyons plutôt les détails.
Tout d'abord, la source. L'article d'origine est situé sur le blog d'extended subset, qui contient les deux documents originaux les plus importants, le pdf schématique et l'article. Sur cette page, sont disponibles également des captures tcpdump.
Explication, de la faille, en deux temps. Tout d'abord, SSL est censé protéger contre tout type de MiTM, en intercalant entre le serveur et le client une couche de chiffrement . La couche SSL s'occupe donc des problématiques de chiffrement, échange de clés, etc... Entre autre problématique, celle de la renégociation des clés ou des méthodes de chiffrement. La faille se situe dans cette renégociation.
Ensuite, le SSL existe en deux méthodes, authentification serveur (ce qui est forcément le cas) et authentification côté client (ce qui est particulièrement rare). L'authent côté serveur permet au client d'authentifier le serveur ET de chiffrer les communications. L'authent côté client permet au serveur d'authentifier le client.
La couche applicative utilise ce tuyau authentifié et chiffré pour envoyer ses données.
Ceci étant posé, un MiTM reste possible ! La méthode exposée permet d'ajouter une quantité arbitraire de données en début de dialogue. Ce début de dialogue sera vu par le serveur non seulement comme légitime, mais en plus il sera authentifié!
Précisons les détails dans le cas d'une négociation HTTPs. Le schéma est celui-ci:
client --- MiTM --- serveur.
Le client envoie une requête au serveur. Le MiTM l'intercepte, puis négocie les clés de sessions entre le serveur et lui même. Il envoie une requête:
GET /secure/evil.html
X-swallow-this: <-- (sans retour chariot) Le MiTM redemande une négociation de clés, mais cette fois-ci, il route tous les paquets entre le client et le serveur. Le client imagine qu'il s'agit de la négo initiale des clés de sessions, de la méthode de chiffrement, etc et il envoie sa requête:
Eventuellement, le serveur demande le certificat client; du fait même du protocole, le serveur demande le certificat client _après_ la requête (les détails expliquant pourquoi sont dans le pdf.). La requête est authentifiée par le certificat client, et le serveur exécute aussi /secure/evil.html
SSL est donc entièrement battu: le SSL côté serveur est abusé, l'authent par login/pass est forwardée, et l'authent SSL cliente est elle aussi forwardée. Bien sûr, le MiTM ne voit pas la requête cliente (elle est chiffrée) ni la réponse du serveur (qui est chiffrée aussi). L'essentiel reste que l'attaquant, le MiTM, ait pu ajouter un entête choisi dans le dialogue SSL. La faille de sécurité est donc avérée. Il s'agit de plus d'une faille protocolaire puisque de bout en bout les normes ont été respectées.
Maintenant que ceci est posé, quels contremesures disposons nous?
1/ Interdire la renégociation SSL. Un patch pour openSSL est disponible. La question se pose alors: La renégociation lors d'un dialogue SSL est il 'mandatory' ? ou bien peut-on vivre sans? Si la renégo n'est pas nécessaire, alors c'est le meilleur moyen à court terme.
2/ Attendre une modification de la norme ce sur quoi l'IETF travaille actuellement. Puis attendre une modification des clients et serveurs.
3/ Pour les applis développées maison implémentant SSL, alors il faut également interdire la renégociation en cours de dialogue. Si une raison forte impose la renégociation des clés (comme la durée du dialogue ou le volume de données transférées) alors il faut casser la session applicative et en reprendre une nouvelle, ce qui peut être compliqué à mettre en oeuvre.
4/ Ajouter un firewall est complètement illusoire, même si cela reste des propositions qui sont faite comme j'ai pu lire sur internet :( (et là, sécurité FAIL, on connaît la chanson). Une faille protocolaire, au même titre que les canaux cachés, traversera aisément les firewalls puisque ces deux failles reposent sur un strict respect de la norme.
En conclusion, ce n'est pas le big one, mais un sérieux coup porté à la confiance apportée à SSL. Conclusion, si vous êtes un serveur, ne faites pas une confiance aveugle aux données clients pour la simple raison qu'elles sont chiffrées via SSL/TLS...
EDIT: 12/11/2009.
Le blog de sid en parle. Il contient plusieurs liens intéressants.
Oublions un peu les journaux du net et voyons plutôt les détails.
Tout d'abord, la source. L'article d'origine est situé sur le blog d'extended subset, qui contient les deux documents originaux les plus importants, le pdf schématique et l'article. Sur cette page, sont disponibles également des captures tcpdump.
Explication, de la faille, en deux temps. Tout d'abord, SSL est censé protéger contre tout type de MiTM, en intercalant entre le serveur et le client une couche de chiffrement . La couche SSL s'occupe donc des problématiques de chiffrement, échange de clés, etc... Entre autre problématique, celle de la renégociation des clés ou des méthodes de chiffrement. La faille se situe dans cette renégociation.
Ensuite, le SSL existe en deux méthodes, authentification serveur (ce qui est forcément le cas) et authentification côté client (ce qui est particulièrement rare). L'authent côté serveur permet au client d'authentifier le serveur ET de chiffrer les communications. L'authent côté client permet au serveur d'authentifier le client.
La couche applicative utilise ce tuyau authentifié et chiffré pour envoyer ses données.
Ceci étant posé, un MiTM reste possible ! La méthode exposée permet d'ajouter une quantité arbitraire de données en début de dialogue. Ce début de dialogue sera vu par le serveur non seulement comme légitime, mais en plus il sera authentifié!
Précisons les détails dans le cas d'une négociation HTTPs. Le schéma est celui-ci:
client --- MiTM --- serveur.
Le client envoie une requête au serveur. Le MiTM l'intercepte, puis négocie les clés de sessions entre le serveur et lui même. Il envoie une requête:
GET /secure/evil.html
X-swallow-this: <-- (sans retour chariot) Le MiTM redemande une négociation de clés, mais cette fois-ci, il route tous les paquets entre le client et le serveur. Le client imagine qu'il s'agit de la négo initiale des clés de sessions, de la méthode de chiffrement, etc et il envoie sa requête:
GET /secure/good.htmlLe serveur, lui concatène l'ensemble (puisque rien n'interdit la renégo en cours de dialogue applicatif) et voit donc la requête:
Host: thishost
Authent: authent-codes
Cookie: Cookies, etc..
GET /secure/evil.htmlOu l'on voit bien que la requête cliente est avalée dans l'entête X-swallow-this, mais que le reste des en-têtes du client (authent éventuelle, cookies, etc..) sont ajoutées. La requête est légitime, elle est chiffrée, et est donc effectuée par le serveur qui imagine dialoguer avec le client!
X-swallow-this: GET /secure/good.html
Host: thishost
Authent: authent-codes
Cookie: Cookies, etc..
Eventuellement, le serveur demande le certificat client; du fait même du protocole, le serveur demande le certificat client _après_ la requête (les détails expliquant pourquoi sont dans le pdf.). La requête est authentifiée par le certificat client, et le serveur exécute aussi /secure/evil.html
SSL est donc entièrement battu: le SSL côté serveur est abusé, l'authent par login/pass est forwardée, et l'authent SSL cliente est elle aussi forwardée. Bien sûr, le MiTM ne voit pas la requête cliente (elle est chiffrée) ni la réponse du serveur (qui est chiffrée aussi). L'essentiel reste que l'attaquant, le MiTM, ait pu ajouter un entête choisi dans le dialogue SSL. La faille de sécurité est donc avérée. Il s'agit de plus d'une faille protocolaire puisque de bout en bout les normes ont été respectées.
Maintenant que ceci est posé, quels contremesures disposons nous?
1/ Interdire la renégociation SSL. Un patch pour openSSL est disponible. La question se pose alors: La renégociation lors d'un dialogue SSL est il 'mandatory' ? ou bien peut-on vivre sans? Si la renégo n'est pas nécessaire, alors c'est le meilleur moyen à court terme.
2/ Attendre une modification de la norme ce sur quoi l'IETF travaille actuellement. Puis attendre une modification des clients et serveurs.
3/ Pour les applis développées maison implémentant SSL, alors il faut également interdire la renégociation en cours de dialogue. Si une raison forte impose la renégociation des clés (comme la durée du dialogue ou le volume de données transférées) alors il faut casser la session applicative et en reprendre une nouvelle, ce qui peut être compliqué à mettre en oeuvre.
4/ Ajouter un firewall est complètement illusoire, même si cela reste des propositions qui sont faite comme j'ai pu lire sur internet :( (et là, sécurité FAIL, on connaît la chanson). Une faille protocolaire, au même titre que les canaux cachés, traversera aisément les firewalls puisque ces deux failles reposent sur un strict respect de la norme.
En conclusion, ce n'est pas le big one, mais un sérieux coup porté à la confiance apportée à SSL. Conclusion, si vous êtes un serveur, ne faites pas une confiance aveugle aux données clients pour la simple raison qu'elles sont chiffrées via SSL/TLS...
EDIT: 12/11/2009.
Le blog de sid en parle. Il contient plusieurs liens intéressants.
Inscription à :
Articles (Atom)