Social Engineering Toolkit (Partie I: la récolte des mots de passe)

L'objectif de cet article est de découvrir les immenses possibilités du Social Engineering Toolkit (appelé SET) disponible dans Backtrack5.

Le cas d'utilisation que nous avons choisi de couvrir consiste à créer un faux site web pour récupérer les noms d'utilisateur et les mots de passe des utilisateurs imprudents.

C'est SET qui prend en charge la création du faux site web et la récupération des identifiants de l'utilisateur.

En plus de SET, il est nécessaire de configurer un MITM (Man In The Middle) basé sur un spoofing DNS du nom de domaine cible. Ce spoofing DNS est permis par Ettercap.

Concrètement:

• La victime accède comme à l'accoutumée à Facebook
• Elle est redirigée vers le faux site web généré par SET.
• L'utilisateur s'authentifie.
• Son authentification échoue et SET récupère son nom d'utilisateur et son mot de passe
• La victime est redirigée vers la page de login officiel de Facebook
• Elle s’authentifie de nouveau, pensant avoir saisi un mauvais mot de passe lors de sa première tentative

Tous les détails de l’attaque dans la vidéo ci-dessous:

Cette attaque est particulièrement imparable si le MITM a pu être mis en place et si l'utilisateur n'est pas paranoïaque.

Une parade à l'attaque Man In The Middle (ou pas)!

Pour éviter une attaque de type MITM (Man In The Middle) dans une architecture orientée services, une solution possible est le CBT (Chain Binding Token de Microsoft) appelé aussi "Extended Protection for Authentication".

Cette solution, proposée par Microsoft, fait partie de WCF et apparaît avec le .NET Framework 3.5 et Windows 7.

WCF (Windows Communication Foundation) est un sous-système de communication de Windows Vista. Les applications WCF peuvent être développées en utilisant les différents langages de Microsoft .NET. WCF est l'un des composants majeurs du .NET Framework 3.0, qui est inclus dans Windows Vista et Windows Server 2008.

Le modèle de programmation WCF est une couche d'abstraction qui unifie et simplifie la mécanique d'intégration des services Web (entre autres choses).

Si vous souhaitez mieux comprendre en quoi consiste une attaque du type MITM, vous pouvez consulter l'article du blog suivant "L'attaque MITM démystifiée avec Backtrack 3".




Décrivons le scénario d'attaque suivant avec 3 participants: un client, un serveur et un attaquant.




L'attaquant fait croire au client qu'il accède au serveur alors qu'en fait le client accède à l'attaquant. Puis l'attaquant transmet la requète du client au serveur. Le serveur répond à l'attaquant avec une demande d'authentification HTTP sous la forme d'un header contenant un "WWW-Authenticate". L'attaquant ne dispose pas des informations d'authentification, il va alors transmettre le "WWW-Authenticate" au client. Le client envoie alors à l'attaquant (qu'il prend pour le vrai serveur) la réponse au "WWW-Authenticate" avec un header contenant un "Authentication" (qui est la réponse au "WWW-Authenticate" contenant les informations d'authentification). Puis l'attaquant se contente de transmettre le "Authentication" au serveur. L'attaquant a ainsi accès aux ressources sécurisées du client.





Généralement, quand un client s'authentifie auprès d'un serveur avec une authentification Kerberos ou NTLM en utilisant HTTPS, un canal SSL est établi en premier lieu afin de permettre à la phase d'authentification d'avoir lieu dans de bonnes conditions. Cependant il n'existe pas de lien entre la clef de session générée par SSL et la clef de session générée pendant l'authentification.


Ainsi, dans le scénario précédent, il y a deux canaux SSL distincts: un entre le client et l'attaquant et un entre l'attaquant et le serveur. Les "credentials" du client (généralement le nom d'utilisateur et le mot de passe) sont envoyés vers le serveur en premier lieu au travers du canal SSL entre le client et l'attaquant, puis dans un deuxième temps au travers du canal SSL entre l'attaquant et le serveur. Une fois que les "credentials" sont transmis au serveur, le serveur vérifie les "credentials" sans pouvoir détecter que le canal SSL au travers duquel les "credentials" ont été transmis est celui en provenance de l'attaquant et non pas celui en provenance du client.





La solution consiste à utiliser un canal SSL externe et un canal interne (celui du client authentifié) et à passer un CBT au serveur (Channel Binding Token). Le CBT est une propriété du canal SSL externe, et il est utilisé pour lier le canal SSL externe au canal interne (celui du client authentifié).





Dans le scénario précédent, le CBT du canal "client-attaquant" est combiné avec les informations d' "Authentication" transmises par le client au serveur en réponse au "WWW-Authenticate" (via l'attaquant). Un serveur capable de gérer ce CBT qui correspond au canal SSL "client-attaquant" le compare au CBT attaché au canal "attaquant-serveur". Le CBT est lié à la destination du canal, et donc le CBT "client-attaquant" ne correspond pas au CBT "attaquant-serveur". Le serveur peut ainsi détecter l'attaque MITM et refuser la requète d'authentification.



Le client ne nécessite aucune configuration particulière (à partir du moment où le CBT est implémenté). Une fois que la machine cliente à été mise à jour pour passer le CBT, elle le fait toujours. Si le serveur à lui aussi été mise à jour alors il peut être configuré pour vérifier ou ignorer le CBT. S'il n'a pas été mis à jour alors le serveur ignore toujours le CBT.

N'est-ce pas fantastique!

La vidéo ci-dessous va nous permettre au travers d'un exemple de comprendre comment configurer le CBT entre un client et un serveur.

Il nous reste maintenant à vérifier que cette nouvelle solution ne présente pas de failles. Mais ceci est une autre histoire!

Source: Microsoft MSDN http://msdn.microsoft.com/en-us/library/dd767318.aspx

L'attaque MITM démystifiée avec Backtrack 3

L’objectif de cet article est de décrire une des nombreuses possibilités de réaliser une attaque « MITM » i.e. Man In The Middle.

Cette attaque se base sur l’ARP poisoning.

Il y a plusieurs types d'attaques pour devenir "man in the middle", nous allons voir dans cet article des attaques basées sur le protocole ARP. Le protocole ARP est un protocole de niveau 3 utilisé pour traduire des adresses IP en adresses physiques de carte réseau ou adresse MAC. Quand un équipement essaie d'accéder à une ressource réseau, il va d'abord envoyer des requêtes vers les autres équipements pour connaître l'adresse MAC associée avec l'adresse IP qu'il veut atteindre. Cette équipement va garder l'association IP - MAC adresse dans son cache, le cache ARP, pour accélérer de nouvelles connections vers cette même adresse IP. L'attaque survient quand une machine demande aux autres de trouver l'adresse MAC associée à une adresse IP. Le pirate va répondre au demandeur avec des paquets indiquant que l'adresse IP est associée à sa propre MAC adresse. Par ce biais, il va court-circuiter la vraie réponse d'association IP - MAC venant d'autre hôte. Cette attaque est référencée en tant qu'usurpation ARP (ARP poisoning ou ARP spoofing). Elle n'est possible que si le pirate et les victimes sont à l'intérieur du même domaine de broadcast qui est défini au niveau d'un hôte par une adresse IP et un masque de sous-réseau, par exemple: 192.168.1.1 255.255.255.0

Dans le cas présent une machine (le pirate) usurpe l’adresse MAC d’une autre machine (la cible). Pour réaliser cette attaque nous allons utiliser la distribution « Bactrack 3 ».


Prenons le cas d’une attaque en entreprise. Le pirate (l’employé malveillant) lance sa machine Backtrack et la connecte à son réseau d’entreprise. Il ne lui reste alors plus qu’a s’immiscer entre le routeur et la machine « cible » en utilisant Ettercap.

Lorsque cette opération est terminée le trafic de la machine « cible » transite par la machine « pirate ».

Intéressons nous au trafic HTTPS. Dans ce cas le trafic transite également par la machine « pirate ».

Si la cible se connecte sur son site mail de Google en HTTPS, elle est prévenue par un message d’erreur que le certificat n’est pas entièrement fiable. Mais pour la plupart des utilisateurs non avertis, ce message d’erreur n’est pas pris en compte et pour la plupart des utilisateurs avertis mais pressés, le message n’est pas traité avec l’importance qui devrait lui être accordé.
La machine « pirate » peut donc ainsi obtenir le nom d’utilisateur et le mot de passe du mail Google de la « cible ».

Les applications ne se limitent pas aux comptes mail malheureusement.

Vous pouvez voir la video de cette attaque ICI.