samedi 14 novembre 2009

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

Partager avec...