Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Détrousser un utilisateur de ses clés

Détrousser un utilisateur de ses clés
2010-09-282013-02-11sécurité applicativefr
Les clés privées stockées sur les postes des administrateurs sont une denrée rare que les cybercriminels convoitent de plus en plus. Avec ces clés, il est possible de signer un code malicieux afin pour augmenter sa virulence ou d'accéder à des sites Internet sensibles. Quels principes...
Publié le 28 Septembre 2010 par Jean-François Audenard dans sécurité applicative
Au lieu d'utiliser le classique "login"et mot de passe, certains sites Internet utilisent un certificat numérique pour authentifier leurs utilisateurs. Avec un tel système, l'utilisateur utilise une clé qui lui a été préalablement été envoyée par la société en charge du site Internet.

Pour de nombreuses personnes, ce type d'authentification c'est le "nec plus ultra" et elles sont très fières d'en parler. Quand je leur explique que ce n'est pas la panacée et leur en  explique les raisons, les dents commencent à grincer.

Vous avez déclaré vos impôts en ligne ?
Si la la réponse est positive, alors vous avez déjà utilisé ce système permettant d'authentifier de façon extrêmement fiable la personne qui déclare. Il faut avouer que la mise en place initiale n'est pas toujours très simple mais a le mérite de fonctionner.
Pour fonctionner, ce fameux sésame s'appuie sur des principes dit de "cryptographie asymétrique", on parle aussi de "chiffrement asymétrique" bien que ce terme soit un peu réducteur.

Cryptographie asymétrique
Ce système, s'appuie sur des mécanismes de chiffrement dans lequel sont utilisées des clés ayant des propriétés spéciales entre-elles. Un tel jeu de clés est constitué de 2 clés associées : l'une est privée, l'autre est publique. En simplifiant à peine, ce que peut faire l'une, l'autre peut le défaire. Un jeu de clé (clé privée + clef publique) est aussi connu sous le nom de biclef.

Clé publique et clé privée.
Un message chiffré avec la clé publique ne pourra être déchiffré qu'avec la clé privée correspondante. Simple non ?
Pour la signature, c'est l'inverse : Pour signer numériquement un message, on utilise la clé privée en guise de "tampon". Pour vérifier l'authenticité du "tampon" on utilise la clé publique correspondante.
Nous reviendrons sur cela prochainement.

Authentification d'un site web via certificat
Quand l'on se connecte à site web sécurisé (compte bancaires, page de paiement d'un site de "e-commerce", le site web est authentifié par le biais de la clé publique qui nous est envoyée lors de l'établissement de la connexion. Avant d'utiliser cette clé, on vérifie si c'est bien celle du site auquel l'on est en train de se connecter : Ça c'est le rôle du certificat.

Dans ce cas de figure, le site Internet démontre qu'il possède bien la clé privée correspondant à celle présente dans le certificat via un principe de signature numérique. Le navigateur envoie un message au site web, celui le signe avec sa clé privé et renvoie le résultat. Le navigateur vérifie la signature avec la clé publique contenue dans le certificat.
Si tout est OK, alors la connexion chiffrée est établie.

Authentification d'un utilisateur via certificat
Si vous avez suivi mes explications ci-dessus, et bien c'est la même chose mais à l'envers !
Le site web envoie un message au navigateur, celui-ci le signe avec la clé privée et renvoie le résultat au site web. Ensuite, le site web vérifie la signature avec la clé publique correspondante.
Si tout est OK, alors l'utilisateur a le droit de se connecter.

Mais c'est blindé cette histoire ? bof... enfin ça dépend !
A première vue, cela semble super sécurisé cette histoire.... Il suffit d'y rajouter des gros mots comme RSA 2048 bits, SSL, TLS et autres trucs que les managers comprennent que dale (enfin 90%) et vous emballez qui vous voulez.... circulez, c'est sécurisé !
Et bien non.... Quelle est la faille me direz-vous ? Et bien elle réside dans le stockage de la clé privée sur le PC de l'utilisateur.

PKCS#12
Afin de stocker en local sur une machine un conteneur spécial est utilisé : la clé privée et sa clé publique correspondante sont écrites dans une archive au PKCS#12. Autrement dit, vous allez retrouver un fichier pour chaque jeu de clés.
Ces clés sont chiffrées via un algorithme comme 3DES (Triple DES). Pour accéder aux clés (et donc les utiliser) il faut montrer patte blanche... en donnant un mot de passe !
Qui connait le mot de passe peut donc utiliser les clés, et même dans certains cas les extraire.

Méthodes pour voler les clés
Il existe trois grandes méthodes pour voler des clés stockées dans une archive PKCS#12.
Attaque #1: Récupération du fichier PKCS#12
L'attaquant fait une copie du fichier PKCS#12 et l'envoie sur le serveur de son choix. Ensuite, il a tout le temps qu'il faut pour deviner le mot de passe via essai successifs. Simple, efficace et très rapide et très discret.
Attaque #2: Bruteforce en local sur le poste
C'est une variante de la méthode précédente dans laquelle l'attaquant va tenter sa chance directement sur la machine. Cela va surement générer une charge CPU plus élevée que d'habitude. Si cela est fait sans trop surcharger la machine, alors peu de chances qu'un utilisateur lambda se rendre compte de quelque chose.
Attaque #2: Sniffing du mot de passe via keylogger
Cette méthode est la plus évoluée. Une fois le fichier PKCS#12 envoyé sur un serveur de son choix, l'attaquant va capturer toutes les données saisies au niveau du navigateur et va les envoyer elles aussi vers son serveur. Il lui suffira de "forcer" (ou d'attendre que) l'utilisateur se connecte au site web concerné.

Conséquences d'un vol de clés privées
Une fois dérobées, ces clés privées peuvent être utilisées de différentes manières. Nous ne retiendrons que les deux les plus évidentes.
Usurpation d'identité
C'est le classique : Avec la clé privée, l'attaquant est en mesure de se connecter aux sites web et de faire ce qu'il souhaite... simple et efficace.
Signature de code malicieux
Dans le cas ou les clés dérobées sont des clés utilisées pour signer numériquement du code (afin d'en certifier la provenance et l'intégrité), l'attaquant pourra signer ses programmes malicieux et ainsi passer au travers de mécanismes de protection présumés forts. C'est un tel détournement qui a été utilisé par le ver Stuxnet qui ciblait les systèmes de contrôle industriel.

Les malwares évolués
Il y a quelques jours de cela, Symantec a mis à nu le cheval de Troie "Infostealer.Nimkey" utilisant ce type de technique (collecte des fichiers PKCS#12 et capture des saisies via sniffing).

Trois recommandations

Conseil #1 : Utilisez des mots de passe "forts" pour protéger vos fichiers PCKS#12. Si vous êtes en mal d'idée pour gérer vos mots de passe, je vous conseille cet article "2 recettes simples pour gérer ses mots de passe".
Conseil #2 : Stocker vos fichiers PKCS#12 dans des clés cryptographiques matérielles : Avec celles-ci, il n'est plus possible de récupérer/copier le fichier et à la 3ième tentative infructueuse de mot de passe elles se verrouillent.
Conseil #3 : N'utilisez pas de certificats clients : Faites de l'OTP (One-Time Password). Suivez les traces du géant Google ("Google se lance dans l'authentification forte") en mettant en place un système basé sur OATH.

8 Commentaires

  • 8 Novembre 2010
    2010-11-08
    par
    Andre G.
    Bonjour,
    Entre un certificat logiciel et un login/mot de passe ingérable, je préfère le premier.
    Il est plus facile à déployer et n'expose pas plus le SI qu'un simple login/mot de passe qui lui est exposé à la force brute depuis Internet.
    La responsabilité de l'utilisateur est primordiale, dans tous les cas. La carte à puce en interne c'est très bien. Pour nos clients c'est cher et compliqué, comme un OTP d'ailleurs.
    André G.
  • 22 Octobre 2010
    2010-11-08
    par
    Bonjour Cédric.
    Merci pour votre retour et ces précisions fort intéressants. Effectivement, mon article avait pour principal objet les certificats stockés en dehors des clefs cryptographiques : Le cas ou les certificats sont stockés en local sur le disque dur de l'utilisateur.

    Oui, les clefs cryptographiques existent et permettent de se prémunir d'attaques comme vous l'expliquez fort bien. C'est d'ailleurs l'une des mes recommandations #2.

    Ai-je été pour autant hâtif comme vous l'évoquez ? Je n'en suis pas convaincu. Votre commentaire aura eu comme intérêt d'éclairer nos lecteurs sur cette alternative matérielle pour sécuriser leurs clefs : C'est mieux mais c'est plus cher.
  • 20 Octobre 2010
    2010-11-08
    par
    Cédric CLEMENT
    Bonjour,

    Les conseils, l'analyse et la conclusion me semblent un peu hâtifs. Les vertus du certificat X.509v3 existent bel et bien et ne sont pas exactement mis en exergue dans cet article. Ses qualités sont d'autant plus pertinentes lorsque celui-ci est associé à un support physique (carte à puce SSCD) afin d'en faire un moyen d'authentification renforcée en protégeant la clé privée associée de manière très sécurisée (bien plus que tout autre moyen, le SSCD utilisé pouvant accessoirement faire l'objet d'une qualification par l'ANSSI). Votre exposé n'évoque que les conteneurs logiciels. Par conséquent, il aboutit à une conclusion quelque peu discutable (Conseil #3).

    Par ailleurs, quelques ambiguïtés dans l'analyse laissent apparaître des imprécisions : lorsqu'un bi-clé est hébergé sur un module cryptographique tel qu'une carte à puce, le bi-clé est généralement directement généré via le SSCD et non importé depuis un PKCS#12 généré en amont. De même, les opérations cryptographiques afférentes sont réalisées directement par la carte à puce (aucune transmission de la clé privée dans la mémoire vive de l'ordinateur) rendant ainsi la compromission de la clé privée impossible. L'exportation de la clé privée ainsi générée directement depuis la carte à puce vers l'ordinateur est impossible (propriété physique du SSCD).

    Cordialement,

    Cédric CLEMENT
  • 19 Octobre 2010
    2010-11-08
    par
    Bonjour, et bravo pour votre article instructif et clair. Pour ceux qui voudraient d'autres informations sur le sujet, vous pouvez lancer la recherche sur le mot "certificats" sur le site http://www.justaskgemalto.com/fr ou pour encore plus d'informations détaillées - en anglais - http://www.gemalto.com/brochures/download/wp-store_pki_credentials.pdf
    Bonne lecture !
    Cordialement,
    TM
  • 1 Octobre 2010
    2010-11-08
    par
    Merci pour ce retour positif !
    Autre pépite encore entendue récemment : Une personne dans la technique (développement d'API) indiquait avoir sécurité un transfert de mot de passe via un chiffrement SHA-1.
    Je me suis empressé d'avoir la corrections qui convenait : Haschage et chiffrement sont peut-être liés/utilisés ensemble mais sont des techniques clairement différentes.
    Fort heureusement, ce choix était néanmoins correct d'un point de vue sécurité... Ce qui n'est cependant pas le cas dans la très grande majorité des cas.
    La vulgarisation et la sensibilisation sont-elles les deux mamelles de la sécurité ? May-be.
    Bon week-end.
    JF

Pages

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage