/fdata%2F4266034%2Favatar-blog-1212474526-tmpphpFMIwYn.jpeg){kind=avatar}
Le deuxième article de cette série de retour aux fondamentaux de la sécurité va traiter encore des mots de passe mais cette fois lorsqu'ils circulent en clair sur les réseaux.
Le scenario est simple: un intrus "sniffe" le trafic réseau et repère des mots de passe en clair. Ceux-ci permettent alors l'accès à l'applicatif en se faisant passer pour l'utilisateur légitime. Il y donc deux conditions à réunir: être capable d'intercepter des flux réseau et que les crédentités circulent en clair.
Nous allons couvrir les deux aspects. Pour réaliser une interception de flux réseau, il suffit d'un logiciel capable de "Man in the middle". Ce type de logiciel génère une double usurpation en utilisant les propriétés des paquets IP: Chaque paquet renseigne la MAC Address (l'adresse physique de la carte réseau) et l'adresse IP (l'adresse logique assignée à chaque noeud du réseau). Chaque paquet renseigne ainsi une paire d'adresses MAC, celle de l'emetteur et celle du destinataire; De même pour les adresses IP. C'est cette combinaison d'adresses qui permet l'acheminement des paquets entre les clients et les serveurs:
Un logiciel capable de faire ces interceptions comme Cain & Abel link va substituer l'adresse MAC de la source avec la sienne de manière à tromper le destinataire, puis va inverser la manoeuvre au moment de la réponse pour tromper l'émetteur. Cette opération de substitution s'appelle l'ARP poisoning.
L'attaque va donc intercepter les flux réseau. Il suffit d'être physiquement connecté au réseau et de disposer d'un logiciel approprié.
(source OWASP)
Les paquets transitent alors vers l'ordinateur de l'attaquant. Si un login-mot de passe en clair se présente celui-ci est donc connu par l'attaquant (les colonnes U et P masquées correspondent à User et Password):
Quels sont donc les protocoles qui véhiculent des mots de passe en clair sur le réseau ?
Tout d'abord tout site qui a un système d'authentification en HTTP correspond à ces possibilités d'attaque. De même pour les messageries POP3 et IMAP, ainsi que le tranfert de fichiers en FTP et l'émulation de terminal en TELNET.
SMB correpond à un protocole chiffré mais pas assez pour résister à une attaque de décodage simple.
Que faut-il donc faire pour remédier à ce problème ? Tout d'abord il faut repérer les protocoles en clair sur le réseau en étudiant les flux. Si on repère des flux en clair on va regarder quel type d'application web, de messagerie, de transfert de fichiers ou d'administration utilise ce protocole.
Pour les applications web il suffira de passer en HTTPS au niveau de la page d'authentification (plus quelques autres mesures de sécurité que nous verrons dans un prochain article)
Pour les applications de transfert de fichiers il suffit de changer pour un serveur FTPS ou bien d'utiliser HTTPS comme pour un serveur web.
Pour POP3 et IMAP, il faudra utiliser leur correspondant chiffré à savoir POP3S et IMAPS. A noter que Exchange n'est pas concerné par ce problème puisqu'il s'appuie sur l'authentification de Windows server au niveau de l'Active Directory. Le problème des messageries est essentiellement celui des messageries fournies par Internet, notamment à travers les fournisseurs d'accès, qu'on y accède par le web (webmail) ou bien par un client Outlook (POP3 et IMAP).
Pour TELNET il sera avantageusement remplacé par SSH. A chaque fois il suffit donc de repérer les protocoles en clair et les remplacer par l'équivalent chiffré, rendant l'interception sans objet.
Pour celà il faudra probablement acquerir un certificat "wild card" permettant d'utiliser le même certificat sur plusieurs serveurs du même domaine et ainsi d'éviter l'usurpation de certificat par l'intrus.
Cette usurpation se caractérise par un "warning" au niveau du navigateur par exemple de l'utilisateur en indiquant que le certificat est invalide:
Mais en réalité qui s'en soucie ?! La plupart des utilisateurs vont valider l'exception pensant à un problème technique...
En réalité, ils vont décoder le flux avec l'attaquant lui donnant ainsi de nouveau les mots de passe en clair...
Comment se prémunir alors de ces faux certificats, malgré les utilisateurs ? Il faut empêcher au niveau du navigateur la possibilité de passer outre le message d'erreur et d'autre part d'utiliser des certificats qui soient valides aussi bien en termes de nom de serveur (d'où l'intérêt des certificats wild card), de date et de non-revocation. Pour celà on utilisera de préférence des certificats de sociétés connues au lieu d'utiliser des certificats auto-générés.
Il existe une offre officielle en France garantie par des "étoiles": Certinomis, Keynectis, CertEurope par exemple.
Nous voilà en train de sécuriser notre deuxième point de "retour aux fondamentaux de la sécurité", en supprimant tous les mots de passe réseau qui circulent en clair.
Mais, nous n'avons parlé que de l'hypothèse des réseaux filaires et donc d'un visiteur qui serait physiquement connecté à notre réseau par une prise ethernet... Mais le "Man in the Middle" est-il possible également en wifi ou dans les lieux publics ? C'est ce que nous étudierons dans un prochain article sur les fondamentaux de la sécurité des réseaux sans fil...
