samedi 29 novembre 2008

[WEB PENTESTING] SSL Capture Password

Nous nous mettons dans le cas d'un audit d'un site WEB utilisant le protocole SSL. Alors que la plupart des internautes y voient une sécurité certaine, l'utilisateur averti connaît les faiblesses de ce protocole quand il est mal configuré. Ce post commencera par évaluer la robustesse de la sécurité de la communication. Dans un second temps, nous exploiterons le protocole s'il peut être affaibli (ou s'il l'est déjà ...).


1 - Quelques informations nécessaires.

Le protocole SSL existe en plusieurs versions. Vous trouverez sur Internet toutes les informations nécesaires. Pour commencer, Wikipédia est certainement un bon début grâce à l'article dédié à ce protocole [ici].
Mais pour la suite, nous avons juste besoin de savoir que nous trouvons principalement sur le WEB :
  • CAS 1 : Des serveurs WEB reposant sur un certificat SSLv2 vulnérable à des attaques de type Man-in-the-Middle ;
  • CAS 2 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 mais supportant aussi le protocole SSLv2. Ils deviennent alors eux aussi vulnérables au mêmes type d'attaque ;
  • CAS 3 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 et ne supportant que ce protocole. Ces serveurs ne sont pas vulnérables sauf si la clé de chiffrement est faible.
Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.


2 - Le serveur audité est-il vulnérable ?

Pour résumer la première partie, la réponse sera "oui" s'il supporte le protocole SSLv2 et/ ou s'il supporte des algorithmes de chiffrement basée sur une clé trop faible.

Pour effectuer nos tests, nous allons étudier l'outil SSLDigger de Foundstone [télécharger].

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

Après avoir lancé l'outil et entré l'adresse du site, appuyez sur le bouton "GO". De suite, nous voyons que le certificat repose sur un algorithme RSA et une clé de chiffrement de 1024 bits : c'est bon ! De plus, nous remarquons qu'il est signé par une entité reconnue.




Mais supporte-t-il aussi des protocoles faibles ? Pour cela, SSLDigger lance automatiquement les tests si vous avez cliqué sur sur "oui" sur la popup apparue à l'ouverture de l'outil. Sinon, vous trouverez un bouton "SSL test" sur l'interface.
Une fois les tests terminés, cliquez sur "oui" pour enregistrer et voir le rapport. En l'occurrence, nous voyons que des protocoles faibles sont supportés (3 exactement) :



Le détails de ces protocoles est donné plus loin dans le rapport. Il est donc techniquement possible de casser la clé de chiffrement après s'être connecté avec l'un des algorithmes comportant une clé de longueur trop faible. Cela se fait à l'aide d'OpenSSL notamment mais ce n'est pas cette voie que nous allons détailler.

Nous allons néanmoins de suite utiliser cette commande pour voir si le site audité supporte le protocole SSLv2 :

openssl s_client -ssl2 -connect www.cible.com:443

Bingo ! Nous nous connectons au serveur en SSLv2. (NB: avec le protocole DES-CBC3-MD5, l'un des protocoles repérés par SSLDigger).



Alors nous pouvons passer à la suite !


3 - Lancement d'une attaque de type Man-in-the-Middle

3.1 - Préparation

Pour mener l'attaque, nous aurons besoin d'un seul outil, Ettercap [télécharger].

Configuration (si vous utilisez ipchains/iptables) :
  1. Ouvrir etter.conf ;

  2. Décommenter les lignes :

    1. redir_command_on

    2. redir_command_off


Le scénario est le suivant :
  • 1 serveur qui correspond à nos critères de la phase 2 ;
  • 1 machine victime qui se connecte vers se serveur après authentification ;
  • 1 machine pirate qui se placera entre les deux machines pour mener une attaque de type MiTM.
3.2 - Lancement de l'attaque

On commence par vérifier que toutes les machines sont localisées (en ligne de commande "T", sur l'interface eth0 "i") :

ettercap -Tqi eth0 // //

On devrait voir l'adresse de la victime et celle du routeur commun (cadre rouge) alors que l'adresse du pirate apparaît en haut (cadre vert) :



L'attaque se lance avec la commande suivante :

ettercap -Tqi eth0 -M arp -l mission /adresse-routeur/ /adresse-victim/

Vous capturerez le compte dès que la victime se connectera sur le site avec son couple login/mot de passe.




Par la suite, nous pouvons retrouver les résultats en lisant le fichier de capture :

etterlog mission.eci

The account is owned! Have fun! :)

6 commentaires:

Anonyme a dit…

Salut,

Sympas comme article, mais ya un truc que j'ai du sauter. Quand tu fais l'attaque MIM, si les données sont chiffrés (car le gars a établit une connexion SSL), où est-ce que tu lui precises de générer un fake certificat ou quoique ce soit, te permettant d'avoir les données en clair ?

Jer001 a dit…

Le "fake certificat" est généré automatiquement par Ettercap à la 2e commande (avec l'option "-M arp").

Anonyme a dit…

Un copier/coller de ton article :
http://ipv1.wordpress.com/2009/02/19/ssl-capture-password/

Jer001 a dit…

Merci de m'avoir prévenu.
C'est terrible de voir ça ...

pierz a dit…

Salut,

Excellent blog, beaucoup d'articles intéressants.

Juste une précision, tu présentes SSLv3/TLS comme n'étant pas vulnérable à l'attaque d'Ettercap. En réalité, Ettercap fait un simple MiTM en présentant un faux certificat que le client devra accepter. On peut donc faire ce type d'attaque sur un serveur qui présente du SSLv3.

La principale grosse vulnérabilité présente dans SSLv2 est que la négociation du chiffrement à lieu avant l'authentification (possibilité de downgrade transparent du protocole si le serveur propose des chiffrements faibles). Ettercap n'exploite pas cette faille.

http://www.yaksman.org/~lweith/ssl.pdf

Jer001 a dit…

C'est vrai Pierz. Dans le cas de SSLv3/TLSv1, nous pouvons aussi mener l'attaque. La seule contrainte est que l'utilisateur devra accepter le certificat qui lui sera présenté (en cliquant sur OK). Sauf dans le cas d'un utilisateur vigilant, il outrepassera généralement l'alerte du navigateur.

Locations of visitors to this page