Analyse de la sécurité des serveurs courriel du Canada

Analyse de la sécurité des serveurs courriel du Canada Projet présenté dans le cadre des Bourses d'excellence ASIQ 2012-2013 Présenté par : Marc-André GIRARD marcandr.girard@gmail.com Félix HAMEL felixhamel@me.com Francis SANTERRE francis.santerre@gmail.com Sous la supervision de : François GAGNON (enseignant) francois.gagnon1@cegep-ste-foy.qc.ca Département de l informatique Techniques de l informatique Cégep de Sainte-Foy Hiver 2013

Sommaire 1. Introduction à la problématique... 3 2. Le courriel... 4 2.1. Évolution de la messagerie... 4 2.2. Utilisation... 4 2.3. Inscritption en ligne... 4 3. Méthodes d authentifications... 5 3.1. CLEAR... 7 3.2. PLAIN... 7 3.3. APOP/CRAM... 8 3.4. SSL/TLS... 9 4. Résultats... 10 4.1. Inventaire des serveurs courriel au Canada... 10 4.2. Support pour les connexions sécurisées... 11 4.3. La validité des certificats... 13 4.4. Mécanismes d authentification supportés... 14 4.5. Sommaire... 15 5. Description de l outil... 15 5.1. Présentation... 15 5.2. Structure de l outil... 16 6. Travaux futures... 22 6.1. Analyse en profondeur des serveurs courriel... 22 6.2. Scan mensuel automatique pour faire le suivi de l évolution... 23 6.3. Volet Application web... 23 7. Conclusion... 24 8. Bibliographie... 25

1. Introduction à la problématique Le courrier électronique est un service omniprésent, la majorité des gens possèdent plusieurs comptes courriel : personnel, travail, etc. Pratiquement tous les clients courriels : Thunderbird, Outlook, etc, permettent à leur usager de se connecter à un serveur courriel de façon non sécuritaire, en utilisant un protocole désuet ou utiliser un mode qui n est plus garanti sécuritaire. Il revient donc à l usager de bien configurer son programme et connaitre ce qui est sécuritaire. Cependant, il est rare que l usager possède la connaissance nécessaire pour comprendre comment sécuriser son logiciel et connaître quel protocole est sécuritaire. Du côté des serveurs courriels, nous savons que certains acceptent encore des requêtes de connexion non-sécurisées. Ces pratiques, telle que la transmission du nom d usager et mot de passe en clair sur le réseau, ne sont pas désirable et compromettent la sécurité des comptes courriel. Le problème est grandement amplifié par le fait que plusieurs compagnies forcent les usagers à réutiliser le même mot de passe pour différentes tâches (courriel, intranet, connexion sur le poste de travail et sur le réseau). De plus, l usager lui-même va réutiliser des mots de passes pour d autres comptes et tâches quotidienne. Notre projet vise donc à étudier la sécurité des serveurs courriel au Canada. L application que nous avons développée permet d effectuer plusieurs tâches, et ainsi amasser de l information sur plusieurs aspects. Pour commencer, nous avons identifié les serveurs courriels offrant la possibilité de s authentifier en mode non-sécuritaire, c est-à-dire que l authentification peut être interceptée. Par la suite, nous avons étudié la qualité de la configuration des serveurs courriel offrant un mode d authentification sécurisé avec un certificat TLS/SSL. En particulier, nous avons recherché à savoir si certains serveurs, et surtout combien, utilisent des certificats invalides, des clés d encryptions trop faibles, ou des algorithmes de chiffrement désuets.

2. Le courriel 2.1. Évolution de la messagerie Le service de courrier électronique, bien que couramment utilisé de nos jours, à bien évolué depuis ces débuts. Certains font remonter la naissance des emails aux premiers systèmes d exploitation qui pouvaient être utilisés par plusieurs utilisateurs en même temps. Comme par exemple, celui développé par le MIT, le CTSS créer en 1965[1]. CTSS, Compatible Time-Sharing System, permettait de laisser des fichiers dans l un des dossiers communs en ayant comme titre le destinataire du message que l on voulait transmettre. C était une forme bien primitive de ce qu allait devenir le courrier électronique. C est le développement du réseau ARPANET qui va lancer le courrier électronique vers les protocoles et la forme tel qu on le connait aujourd hui. Le changement qu amène ARPANET est celui de la distance que parcourra le fichier. En effet, le système de courrier électronique n est plus seulement limité à une seule machine accessible par plusieurs utilisateurs, mais bien un envoi qui transige entre différents hôtes. C est en 1972 que la première application qui pouvait envoyer et recevoir des emails a été développée par Ray Tomlinson. Les concepteurs qui travaillaient sur ARPANET cherchaient un moyen rapide et efficace de coordonner leurs actions, leur solution : le courriel [2]. C est en 1981 que le service de courrier électronique va être défini avec la spécification RFC-780 qui défini le protocole SMTP [3]. Ce protocole est utilisé pour transférer les emails entre les différents serveurs. Par la suite, les protocoles POP et IMAP seront défini en 1984 et 1986 respectivement, pour s occuper de la partie cliente du service, c est-àdire récupérer les emails sur le serveur SMTP [4]. Les protocoles ayant été défini et standardiser, l évolution du courriel évoluera vers une utilisation standard. Par la suite, les différents protocoles ont connues des versions qui visaient à améliorer, soit l efficacité, le fonctionnement ou la sécurité. 2.2. Utilisation L utilisation du service de courrier électronique est devenu une pratique courante, tant dans les entreprises que chez le public. Dans le monde, il existe un peu plus de 2.2 milliards d utilisateurs [5] pour le service d email, ce qui représente environ le tiers de la population mondiale actuelle. [6] 2.3. Inscritption en ligne De nos jours, il existe plusieurs sites internet proposant des services qui lors de l inscription vont demander une adresse email pour y lier au compte. Les utilisateurs qui vont créer ses comptes sur les différentes applications vont souvent utiliser la même adresse courriel. Google offre aussi aux sites tiers un service d authentification à partir

des informations du compte, qui est normalement à la base un compte courriel, ce qui permet de s authentifier au site tierce avec son compte Google. Ces éléments engendrent une centralisation des accès des différents et fait du compte de courriel un élément critique de la sécurité. Si le mot de passe de l adresse courriel est compromis pour une raison, un pirate cybernétique peut débloquer d autres comptes dont il ne connaît pas le mot de passe. 2.3.1. Travail Le courriel est aussi une partie importante du travail quotidien. Il transige environ 89 milliards de courriel produit par les différentes compagnies du monde entier [5]. Cela représente plus de la moitié des quelques 145 milliards de courriels qui sont échangés dans le monde. De plus, la tendance de l utilisation des emails devrait augmenter d ici 2016 pour atteindre un total de 192 milliards de courriels par jour. Il est clair que le service de courrier électronique fait partie courante de la vie d un employé. 2.3.2. Lieux Avec la monté du marché du téléphone mobile, des portables, tablettes et autres dispositifs mobiles, il est maintenant rendu accessible et facile de lire ses courriers. Plusieurs restaurants tel que McDonald, fournissent même des bornes WI-FI gratuites [7] pour leurs usagers. Ce genre d initiatives étend la zone d accès et modifie les habitudes de l usager. Désormais, tous les usagers ont accès à leur compte courriel du travail et personnel en tout temps. Du côté des applications mobiles, plusieurs applications de courriels sont développées pour toutes les plates-formes. L usager peut donc accéder à ses courriels à partir d un appareil dont la sécurité d utilisation reste à prouver. 3. Méthodes d authentifications Plusieurs protocoles sont à notre disposition pour interagir avec un serveur de courriels. Les principaux utilisés de nos jours sont POP3, IMAP, et STMP. POP3 : permets à un utilisateur de consulter ses courriels dans un logiciel tiers aussi appelé client. Le désavantage avec ce protocole est qu il supprime le courriel du serveur une fois que celui-ci a été consulté dans le client. IMAP : même principe que le protocole POP3, il permet de consulter ses courriels dans un logiciel tiers, mais cette fois, sans le supprimer du serveur. Cela est beaucoup plus pratique lorsque nous souhaitons consulter nos courriels de plusieurs endroits comme au bureau, à la maison, chez un ami, etc., sans avoir à nous les transférer ou à trainer de sauvegardes. SMTP : ce protocole permet à un utilisateur d envoyer des courriels de son client vers un serveur ou d un serveur vers un autre. Chacun de ces protocoles offre plusieurs méthodes d authentifications et les 5 principales sont expliquées en détail ci-dessous. Bien que certaines méthodes soient plus sécuritaires que d autres, ce n est pas tous les serveurs qui les supportent. En effet, cela dépend de la

configuration initiale du serveur et, malheureusement, celle-ci est trop souvent problématique. Les administrateurs système laissent beaucoup trop de méthodes non sécuritaires à la disposition des utilisateurs. Comme la majorité des utilisateurs font confiance à leur client pour consulter leur courriel, ceux-ci ne prennent pas le temps de voir quelle méthode a été utilisée. Or, il est là le réel problème, car ceux-ci ont une confiance aveugle en leur logiciel ce qui est tout à fait normal, car ils ne connaissent pas tous le principe d une méthode d authentification et ils ne devraient pas avoir à le savoir. C est au fournisseur du service de courriels à mettre les bonnes configurations en place pour forcer tous ses utilisateurs à utiliser des méthodes sécuritaires. L explication des méthodes sert donc à montrer la différence entre chacune d entre elles afin de justifier ou non leurs utilisations.

3.1. CLEAR Cette méthode et la plus simple et la moins sécuritaire. Elle envoie directement les identifiants de l utilisateur au serveur courriel pour valider s ils sont bons ou non. Le processus est très simple, il se fait en 3 étapes distinctes. 1. Le client envoie la commande USER suivie du nom d utilisateur pour savoir s il existe ou non. 2. Si l utilisateur existe, celui-ci répond +OK. 3. Une fois la réponse reçue, le client envoie la commande PASS suivie du mot de passe de l utilisateur pour l authentifier sur le serveur. Un des plus gros problèmes avec les clients est qu ils utilisent, pour la plupart, cette méthode par défaut. Ainsi, lorsqu un utilisateur tente de s authentifier, il suffit de faire un audit du réseau pour voir des paquets passer avec ces informations à l intérieur. Il devient très facile pour un utilisateur malveillant de prendre ces données pour les utiliser sur d autres sites Internet, lire les courriels, consulter les comptes bancaires, etc. 3.2. PLAIN La méthode plain ressemble beaucoup à la méthode clear, cependant les informations qui sont envoyées au serveur sont encodées en base64. Le processus d encodage est très simple et Wikipédia a une définition qui le résume très bien : «Ce processus de codage consiste à coder chaque groupe de 24 bits successifs de données par une chaîne de 4 caractères simples. On procède de gauche à droite, en concaténant 3 octets pour créer un seul groupement de 24 bits (8 bits par octet). Ils sont alors séparés en 4 nombres de seulement 6 bits (qui en binaire ne permettent que 64 combinaisons). Chacune des 4 valeurs est enfin représentée (codée) par un caractère simple et prédéfini de l'alphabet retenu. (Table ci-dessous.) Ainsi 3 octets quelconques sont remplacés par 4 caractères simples, choisis pour être compatibles avec tous les systèmes existants.» [8]

Aussi, contrairement à clear, toutes les informations de l utilisateur sont envoyées en même temps. La chaine de caractères qui est encodée a la structure suivante : authid\0userid\0pswd. AUTHID : numéro d authentification de l utilisateur. Ce numéro est peu utilisé et est, pour la majorité des requêtes, laissé vide. USERID : identifiant de l utilisateur. PSWD : mot de passe. Un exemple de chaine encodée : YXV0aGlkXDB1c2VyaWRcMHBzd2Q=. Bien que celle-ci semble être complexe, elle ne l est pas. Effectivement, l algorithme pour décoder les messages en base64 est accessible à tous. Des outils sont disponibles en ligne 1 pour le faire, il suffit de copier/coller le message et de demander à avoir l original. Un usager malveillant peut donc intercepter cette information sur le réseau et l utiliser pour s authentifier ou tout simplement pour connaitre le nom d utilisateur et le mot de passe. Ce qui est intéressant ici est qu il suffit d avoir la chaîne de caractère encodée pour s authentifier («replay attack»); même si la chaîne était chiffrée, un attaqueur on pourrait la réutiliser pour s authentifier. 3.3. APOP/CRAM APOP est une méthode d authentification utilisant le chiffrement (ne pas confondre avec l encodage) de données pour pallier aux problèmes des deux précédents protocoles qui permettaient à un usager malveillant d intercepter le nom d utilisateur et le mot de passe avec un simple audit des paquets sur un réseau. Son fonctionnement est un peu plus complexe. Tout d abord, le client fait une demande d authentification de type «challengeresponse» au serveur. Ensuite, de son côté, le serveur génère une chaine de caractère que l on nomme «challenge». Celle-ci est constituée d un numéro de processus (process-id), du temps actuel (timestamp) et de son nom d hôte (hostname). Le résultat est le suivant : processid.timestamp@hostname. Le «challenge» est encodé en base64 et envoyé au client. Ce qui intéressant avec le «challenge» est qu il est différent à chaque demande d authentification. Cela force le client à produire une réponse différente à chaque fois (la réponse dépend du «challenge»). Ceci ajoute donc un niveau de sécurité, car on ne peut rejouer une réponse précédente capturée du client. Une fois l information reçue, le client décode le base64 pour ajouter, à la suite du «challenge», son mot de passe (aussi appelé le ShareSecret). Au final, la réponse ressemble à ceci : <process-id.timestamp@hostname>sharesecret. 1 Par exemple: http://www.base64decode.org/

Finalement, le client chiffre cette chaine de caractère en MD5 2 (chiffrement unidirectionnel). Le serveur recevra le tout de son côté et essayera de générer la même chaine de caractère (appelée hash), car comme il détient le mot de passe de l utilisateur (et le challenge évidement), il peut lui aussi recréer le hash et ainsi le comparer avec celui du client. Si les deux résultats ne sont pas identiques, l utilisateur a probablement entré un mauvais mot de passe et l accès lui est automatiquement refusé. Ce qui est intéressant dans cette méthode est que l information échangée avec le serveur est cryptée et l utilisateur malveillant ne peut pas y avoir accès, ou presque [9]. Effectivement, bien qu elle soit cryptée, cela n empêche pas à un individu d utiliser des outils pour casser le mot de passe; c est-à-dire d essayer une multitude de combinaisons pour reproduire le même hash. Il suffit d intercepter le «challenge» et la «response». Un problème majeur de ce mécanisme d authentification est la possibilité d une attaque «man-in-the-middle» ou le client parlera à un serveur malicieux. Ce serveur pourra alors utiliser le client pour générer la réponse au «challenge» qui lui est demandé par le serveur réel. Le serveur malicieux parviendra alors à s authentifier au serveur réel avec la réponse produite par le client. 3.4. SSL/TLS TLS (transport layer security) est une version plus à jour et plus sécuritaire de son «ancêtre» SSL (secure socket layer). Cette méthode d authentification utilise la cryptographie asymétrique et symétrique [10]. ASYMÉTRIQUE : Concept de clé privée, clé publique. La clé publique chiffre le message qui sera déchiffré par la clé privée. SYMÉTRIQUE : Une seule clé à connaitre pour pouvoir chiffrer et déchiffrer des messages. La toute première étape consiste à établir une connexion sécurisée (appelé handshake) entre le client et le serveur. Une fois ce procédé terminé, le client demandera le certificat X.509 du serveur. Le certificat contient, entre autre, la clé publique du serveur. Après avoir validé l authenticité du certificat reçu, le client pourra générer une clé symétrique et la transmettre au serveur (encrypté avec la clé publique de ce dernier). Les deux parties partageront alors un secret qu ils utiliseront pour chiffrer de façon symétrique leurs échanges. Même si une personne réussirait à faire un audit du réseau et à obtenir toutes les données, comme il n a pas la clé privée du serveur pour déchiffrer les données, cela ne lui sert à rien. Un problème peut survenir dans la phase de vérification de l authenticité du certificat qui est faite au niveau du client. Si un serveur malveillant parvient à tromper le client (en lui faisant accepter un faux certificat), il parviendra alors à voler les informations 2 D autres méthodes de chiffrement sont parfois utilisées, mais généralement c est celle-ci qui est utilisée

personnelles de l usager. Ce type d attaques semble bien plus difficile, mais de mauvaises configurations sur le serveur rendent parfois la tâche trop facile aux attaquants. 3.4.1. NTLM NTLM est un protocole qui a été implanté dans de nombreux services de Microsoft et qui est supporté par le NTLM Security Support Provider (NTLMSSP) [12]. Son fonctionnement est similaire à celui d APOP, car c est de type «challenge-response». Trois étapes sont nécessaires pour l authentification [13] : 1. Envoi du nom d utilisateur au serveur 2. Réception de la clé de chiffrage de 16-bits (générée aléatoirement par le serveur) 3. Envoi du mot de passe crypté avec la clé précédemment reçue. Au final, le serveur déchiffre le mot de passe et essaie d authentifier l utilisateur. 3.4.2. STLS STLS (aussi écrit STARTTLS) est une extension du protocole PLAIN qui offre la possibilité de passer d une session non-sécurisée (port 110) vers une connexion sécurisée (TLS ou SSL) tout en restant sur le même port [14]. 4. Résultats L outil que nous avons développé et l expérimentation réalisée dans le cadre de ce projet nous ont permis d obtenir plusieurs résultats relatifs à la sécurité des serveurs courriel au Canada. 4.1. Inventaire des serveurs courriel au Canada Dans un premier temps, nous avons dressé la liste des serveurs courriel au Canada. Éventuellement, le projet pourrait s étendre au-delà du Canada pour inclure tous les serveurs courriel à travers le monde. Mais l ampleur du projet nécessitait certaines restrictions pour s assurer de la réalisation complète à l intérieur d une année scolaire. Nous avons donc répertorié 100621 serveurs courriel au Canada. Nous croyons que cette liste est incomplète pour plusieurs raisons, en particulier : Nous sommes partis avec une liste des plages d adresses IPs (sous-réseau) qui sont associés au Canada. Une telle liste n est pas complètement statique et il n est pas clair que nous disposions des données les plus à jour à ce sujet. Certaines organisations ont mis en place des mécanismes rendant difficile la découverte des serveurs courriel.

Nous avons regardé seulement les ports 110 (POP) et 995 (POP + SSL). Certains serveurs pourraient offrir uniquement le service IMAP, ou encore sur des ports non-standards. Nous croyons aussi que notre liste de 100621 serveurs courriel contient possiblement des serveurs que l on ne devrait pas considérer car : Ils ne sont pas forcément situés au Canada. Ils ne représentent pas de véritables serveurs courriel, par exemple dans le cas d un «honeypot». Malgré tout, nous somme confiant que nos données représentent la majorité des serveurs courriel du Canada. 4.2. Support pour les connexions sécurisées Une des premières caractéristiques que nous avons étudiez concernant la sécurité des serveurs courriel est leur capacité de supporter les connexions sécurisées à l aide d un certificat de type SSL (ou TLS). Les certificats SSL représentent la norme pour sécuriser l authentification des clients à un service distant (ex. courriel, application web). Un service ne supportant pas le mode d authentification par certificat SSL n est pas considéré comme étant sécuritaire car on peut souvent obtenir le mot de passe d un usager simplement en capturant le trafic réseau lors de son authentification avec le serveur. En absence d un certificat SSL valide, on peut faire une attaque de type «manin-the-middle» pour forcer l usager à s authentifier à un faux serveur et ainsi lui voler son identité. Sur la totalité des serveurs courriels identifiés dans ce projet, nous les avons classés en trois groupes : Ceux qui supportent seulement les connexions sécurisées par SSL/TLS. C est à dire les serveurs acceptant les connexions sur le port 995 (POP SSL), mais pas sur le port 110 (POP). Ceux qui supportent à la fois les connexions sécurisées SSL/TLS et celles nonsécurisées. C est à dire les serveurs acceptant les connexions sur le port 995 et sur le port 110. Ceux qui ne supportent que les connexions non-sécurisées. C est à dire les serveurs acceptant les connexions sur le port 110 mais pas 3 995. Parmi les trois groupes, les serveurs supportant seulement les connexions sécurisées par SSL sont de loin préférables au niveau de la sécurité. Ceux supportant à la fois les connexions sécurisées et les connexions non-sécurisées offrent la possibilité aux usagers de se connecter de manière sécuritaire (ce qui est bien), mais ils leurs offrent aussi la 3 Il reste possible que certains serveurs acceptent les connexions POP SSL sur un autre port que 995 (le standard), mais ceci est probablement très rare.

possibilité de se connecter de manière non-sécuritaire. Dans ce cas, il revient aux usagers de s assurer que leur configuration est sécuritaire, ce qui n est pas à la portée de tous. Finalement, ceux supportant seulement les connexions non-sécurisées (aucun support direct pour SSL) obligent les usagers à s authentifier d une manière risquée. Cette dernière configuration est donc non désirable. La Figure 1 illustre la répartition des serveurs courriels dans les trois groupes mentionnés ci-dessus. Il est évident que la situation est loin d être idéale avec seulement 4% des serveurs configurés pour le meilleur niveau de sécurité. La grande majorité des serveurs (près de 70%) supportent à la fois un mode sécurisé et non-sécurisé. Finalement, environ 27% des serveurs ne supportent que le mode de connexion non-sécurisé. 27% 4% Supportent seulement les connexions sécurisées (SSL/TLS) Supportent à la fois les connexions sécurisées et non-sécurisées 69% Supportent seulement les connexions non-sécurisées Figure 1 Répartition des serveurs par types de connexions supportées Une précision doit être apportée sur ces chiffres. Lorsqu un serveur accepte les connexions sur le port 110 (donc en mode non-sécurisé) il peut supporter différentes commandes à ce niveau. Il est possible qu il ne supporte aucune commande d authentification (voir section 3) ou encore seulement la commande STLS qui demande le début d une connexion chiffrée SSL sans utiliser un port différent. Ces serveurs ne seraient donc pas si problématiques. Par contre, même si un serveur ne supporte pas un mécanisme d authentification non-sécuritaire sur son port 110 (Ex. Plain) il est possible que le logiciel client tente de se connecter de cette façon et envoie donc l information de l usager (nom d utilisateur et mot de passe) de façon non-sécuritaire sur le réseau. De plus, et c est possiblement le problème le plus important, dès que le logiciel client tente d établir une connexion sur le port 110 (même si c est pour ensuite passer en mode sécurisé avec STLS), l établissement de la connexion (le TCP Handshake) est susceptible à une attaque de type «man-in-the-middle». Le support des connexions sur le port 110 reste donc problématique.

4.3. La validité des certificats La seconde partie de notre analyse consiste à vérifier, pour tous les serveurs courriel offrant un mode de connexion sécurisé (SSL sur le port 995), si le certificat SSL utilisé par le serveur est bien valide. Lors d une connexion sécurisée par certificat, le client doit valider le certificat reçu du serveur avant d utiliser la clé publique contenue dans le certificat pour envoyer un message chiffré au client (voir la section 3.4). En théorie, si le certificat est invalide, le client devrait abandonner la connexion car le certificat pourrait provenir d un serveur malicieux qui fait une tentative de «man-in-the-middle». Mais en pratique, les logiciel clients (Ex. : clients courriels, navigateurs web) offrent souvent la possibilité aux usagers de continuer la connexion malgré le certificat invalide dans le but de ne pas nuire à la fonctionnalité/convivialité. Encore pire, une étude a démontrée [15] que les utilisateurs sont maintenant tellement habituer de faire face à des certificats invalides qu ils ont développé le réflexe d accepter les certificats invalides sans se poser de questions. Un certificat invalide facilite une attaque «man-in-the-middle» où un serveur malicieux peut se faire passer pour le serveur réel en montrant un certificat invalide 4. Un certificat peut être invalide pour plusieurs raisons. En voici quelques exemples : Le certificat est expiré. La compagnie offrant le service a oublié de renouveler son certificat lorsqu il est venu à échéance. Le certificat est associé à une URL différente de celui visité par le client. Le certificat est auto-signé («self-signed»). La compagnie offrant le serveur n a pas acheté le certificat, elle en a simplement créé un. Le certificat a été révoqué. Peut-être que sa clé privée avait été volé. Actuellement, notre analyse ne nous permet pas de déterminer la raison d invalidité d un certificat. Nous avons simplement recueilli les statistiques concernant le nombre de serveurs courriel possédant un certificat valide vs ceux possédant un certificat invalide. La Figure 2 montre la répartition des 73137 serveurs courriel offrant la possibilité de se connecter en mode SSL (sur le port 995) selon la validité de leur certificat. On constate encore une fois une situation problématique : 81% des serveurs courriel offrent SSL ont un certificat invalide. 4 Le certificat du serveur réel étant invalide lui aussi, l utilisateur ne verra pas de différence dans son utilisation du service.

19% Certificat Valide Certificat Invalide 81% Figure 2 Validité des certificats recueillis 4.4. Mécanismes d authentification supportés Les serveurs acceptant des connexions non-sécurisées sur le port 110 peuvent supporter 1 ou plusieurs mécanismes d authentification (voir section 3). À ce niveau, tous les mécanismes sont jugés non-sécuritaires. Les pires sont CLEAR (User/Password), et PLAIN où le mot de passe peut-être obtenu simplement à partir du trafic réseau. APOP et NTLM offrent un certain niveau de sécurité qui requiert une attaque par force brute ou «man-in-the-middle» pour attaquer l utilisateur. STLS requiert une attaque «man-inthe-middle» pour briser la sécurité. Tableau 1 Mécanismes d'authentification supportés Mécanisme d authentification Nombre de serveurs courriel (sur 97018) PLAIN 39363 CLEAR User 90597 Password 2 APOP 7776 NTLM 3364 STLS 74820 Le Tableau 1 indique le nombre de serveurs supportant chaque mécanisme d authentification 5. Environ 40% supportent le mode PLAIN qui est totalement nonsécuritaire. Plus de 90000 serveurs supportent la commande USER, qui fait partie du 5 Notez qu un serveur peut supporter plus d un mécanisme d authentification.

mode CLEAR qui est non-sécuritaire. Par contre, seulement 2 supportent la commande PASSWORD de ce même mode. Il n est pas clair à ce point si le support de la commande USER est suffisant pour causer un trou de sécurité 6. 4.5. Sommaire Voici un sommaire de nos résultats : Très peu de serveurs courriel (4%) obligent une connexion de type sécurisée avec certificat SSL. Les autres sont rendent leurs utilisateurs potentiellement vulnérables à une attaque. Parmi les serveurs courriel offrant une connexion SSL, seulement 20% possèdent un certificat valide. Les autres rendent leurs utilisateurs vulnérables à un «manin-the-middle». Plusieurs serveurs courriel supportent encore des mécanismes d authentification triviaux comme PLAIN. 5. Description de l outil 5.1. Présentation Dans un contexte où nous voulions obtenir les données de plusieurs serveurs courriel à travers le monde, il nous fallait de l aide afin de rendre ce processus plus simple et surtout, plus efficace en termes de temps et de productivité. Nous avons alors décidé de développer notre propre outil dans le but d automatiser le processus et par la même occasion, de rendre cette collecte d information beaucoup plus intéressante autant sur le plan de son développement que sur l approfondissement du fonctionnement des serveurs courriel et des protocoles utilisés. Ainsi, nous avons créé ce qu il est possible d appeler un automatiseur de tâches, plus spécifiquement un logiciel permettant de définir une action précise à exécuter 7 sur plusieurs IPs et de la distribuer à plusieurs clients dans le but d accélérer le processus de recherche. En suivant cette idée, nous avons mis sur pied notre outil qui se divise en 2 parties, soit le module serveur et le module client. 6 Autre qu un «man-in-the-middle» 7 Par exemple, obtenir le certificat SSL.

5.2. Structure de l outil 5.2.1. Le serveur Cette partie de l outil est en soi le cerveau de l opération de collecte d information. Sans lui, les clients ne sauraient quoi faire ni quoi aller chercher comme information. De cette manière, tout ce qui est joint à la tâche de recherche d information est centralisé ici, de même pour la gestion de différentes tâches et clients. Afin de simplifier sa structure, nous avons divisé le serveur en quelques modules que voici. 5.2.1.1. Le noyau du serveur Cette partie du serveur est ce qui se trouve au centre de l opération de collecte de données. Elle sert principalement de pont entre le client et les gestionnaires du serveur, soit le gestionnaire des tâches et celui des clients. Les principales fonctionnalités de cette partie sont : - Valider une demande d autorisation de connexion au serveur par un client : Lorsqu un client veut se connecter au serveur, il doit l interroger afin de lui demander d accepter sa demande d autorisation de connexion. Si cette demande est valide et acceptée, le serveur lui donne un identifiant propre à ce client lui permettant par après de s identifier à chaque fois qu il a besoin de communiquer