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

Transcription

1 Analyse de la sécurité des serveurs courriel du Canada Projet présenté dans le cadre des Bourses d'excellence ASIQ Présenté par : Marc-André GIRARD [email protected] Félix HAMEL [email protected] Francis SANTERRE [email protected] Sous la supervision de : François GAGNON (enseignant) [email protected] Département de l informatique Techniques de l informatique Cégep de Sainte-Foy Hiver 2013

2 Sommaire 1. Introduction à la problématique Le courriel Évolution de la messagerie Utilisation Inscritption en ligne Méthodes d authentifications CLEAR PLAIN APOP/CRAM SSL/TLS Résultats Inventaire des serveurs courriel au Canada Support pour les connexions sécurisées La validité des certificats Mécanismes d authentification supportés Sommaire Description de l outil Présentation Structure de l outil Travaux futures Analyse en profondeur des serveurs courriel Scan mensuel automatique pour faire le suivi de l évolution Volet Application web Conclusion Bibliographie... 25

3 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.

4 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 s 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 s 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 s 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 s 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é 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 , 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 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

5 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 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 s 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é 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

6 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.

7 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 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]

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 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:

9 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 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

10 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 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 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 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é 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.

11 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 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 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 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.

12 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.

13 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 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.

14 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 CLEAR User Password 2 APOP 7776 NTLM 3364 STLS 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 serveurs supportent la commande USER, qui fait partie du 5 Notez qu un serveur peut supporter plus d un mécanisme d authentification.

15 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é 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.

16 5.2. Structure de l outil 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 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

17 avec le serveur, soit lorsqu il a besoin d une nouvelle tâche ou soit lorsqu il a terminé la tâche qui lui a été assignée. Pour que la connexion soit autorisée, le client doit fournir son nom et son nom d organisation (tous deux modifiables dans le fichier de configuration du client). Si l une et/ou l autre information est invalide, la connexion est tout simplement refusée. Dans le cas contraire, le serveur va générer une identité propre au client et lui envoyer. Ce même identifiant est conservé dans le gestionnaire des clients du serveur (voir section ).

18 - Donner une tâche à un client : Lorsqu un client est prêt à recevoir une tâche, ce dernier va demander au serveur de lui en fournir une. Pour ce faire, le client doit transmettre son identifiant au serveur afin que celui-ci puisse l identifier. Dès que c est fait, le serveur va demander à son générateur de tâche de lui fournir la prochaine tâche. Si le générateur génère une tâche avec succès, celle-ci va être transmise au client. Dans le cas où il ne resterait plus de tâches, le serveur considère le processus comme terminée et dit au client qu il peut se fermer. - Exécuter la tâche : Après que le client ai reçu sa tâche, celui-ci va l exécuter. Une tâche peut être d obtenir les informations de connexion de plusieurs serveurs de courriel, déterminer si un port est ouvert sur une machine ou bien valider le certificat SSL qu un serveur utilise pour sécuriser la connexion, si ce dernier supporte ce mode de connexion.

19 - Recevoir les résultats d une tâche d un client : Lorsque le client a terminé sa tâche, ce dernier doit envoyer les résultats au serveur. Pour ce faire, le client doit envoyer son identifiant de connexion au serveur. Le serveur prend cet identifiant et va vérifier avec son gestionnaire des clients si celui-ci est bel et bien présent dans sa liste de client actif. Si c est le cas, le serveur va accepter la connexion du client et reçoit les résultats de la tâche. Dans le cas où le temps d attente maximale pour un client et une tâche est atteint, le client se voit refuser la connexion et doit obtenir un nouvel identifiant puisque celui-ci est considéré comme étant inactif Le gestionnaire de tâches Le rôle principal du gestionnaire de tâches est de faire le pont entre les clients et les tâches à exécutée (ou en cours d exécution). Ainsi, ce gestionnaire a la responsabilité de valider qu une tâche donnée à un client n ait pas dépassé un certain délai d exécution. Le mécanisme de timeout permet de gérer les cas où un client serait fermé dans le milieu d une tâche. On veut s assurer que cette tâche sera réassignée à un autre client pour qu elle soit éventuellement complétée Le gestionnaire des clients Le rôle du gestionnaire des clients et de répertorier tous les clients actifs sur le serveur. Ainsi, il est facile de pouvoir valider qu un identifiant que le serveur reçoit soit valide et appartient bien à un client actif sur ce dernier. L utilisation de ce gestionnaire des clients

20 permet également de faciliter le processeur de «timeout» puisqu un identifiant peut être invalidé et ainsi, faire en sorte que ce même client doit demander un nouvel identifiant au serveur pour continuer à demander des tâches au serveur Le client Le client est la deuxième partie qui compose notre outil. Le client est une partie importante dans notre projet parce que celui-ci permet de se connecter au serveur et d exécuter les tâches qui sont données par le serveur. Afin de pouvoir se connecter au serveur, le client doit fournir un nom représentant l organisation que celui-ci représente ainsi qu un nom pour le client lui-même (identifier quel ordinateur de l organisation exécute le client en question). Après que le serveur ai analysé ces données, si ces 2 informations sont valides, il va générer un identifiant unique pour ce client et ensuite lui transmettre. C est avec cette information reçue du serveur que le client va pouvoir se connecter à lui et pouvoir recevoir des tâches et lui transmettre les résultats par la suite Le noyau du client Le noyau est la partie principale qui compose le client. Pour résumer, la fonction principale de cette composante de l outil est d aller demander des tâches au serveur, de les exécuter et ensuite, lorsque celles-ci ont été complétées, retourner au serveur les résultats L exécution des tâches Lorsque le client est prêt à exécuter une tâche, il va tenter d obtenir une tâche auprès du serveur. Ayant reçu une tâche serveur, il va l exécuter et ensuite envoyer les résultats au serveur.

21 Une tâche se compose de deux éléments : l action à exécuter et la liste des serveurs courriels sur qui le client actuel doit exécuter l action. Pour l action à exécuter, nous avons une structure simple permettant au serveur de spécifier l action précise et aux clients d exécuter cette action sans se soucier de sa nature particulière. Les clients ne manipulent qu une classe abstraite «Task», pour entre autre l exécuter. Le serveur de son côté créé des instances de différentes tâches spécifiques (Ex. «WhoisInfoFetcher», «SSLCertificateFetcher»). Pour la liste des serveurs courriels, notre serveur envoi à ses clients un «générateur d IP». Celui-ci fournira au client la liste des serveurs sur qui exécuter l action. Nous avons développé trois types de générateurs d IP : Serveur unique, contient simplement une IP [pour certaines tâches particulières]. Serveurs multiples spécifiques, contient une collection de plusieurs IP [flexible, mais coûteux en échange client/serveur pour une liste contenant beaucoup d IP]. Serveurs multiples génériques, contient une expression algébrique (Ex X.4) permettant de générer plusieurs IP [un peu moins flexible, mais peu coûteux en échange client/serveur] Retour des résultats Une fois sa tâche terminée, le client va acheminer au serveur un fichier texte contenant le résultat de la tâche (Ex. l information Whois ou encore la liste des commandes supportées par le serveur courriel).

22 Analyse des résultats Une fois la collecte d information terminée, nous avons un module d analyse qui permet d interpréter le contenu des fichiers résultats (selon la tâche effectuée) et d en extraire les données pertinente. Les données sont alors insérées dans une base de données qui contient les requêtes permettant une analyse statistique rapide des résultats (ex. : nombre de serveurs courriel offrant une connexion sécurisée vs non-sécurisé ou encore ratio certificats valides/invalides). 6. Travaux futures Voici quelques idées concernant les prochaines tâches ou améliorations que nous aimerions apporter à notre application Analyse en profondeur des serveurs courriel L une des améliorations que nous pourrions apporter comporte à récolter plus d information des serveurs mails et analyser plus en profondeur certaines parties de l information que nous avons déjà Pourquoi le certificat n est pas valide Il serait important de déterminer automatiquement les raisons qui font qu un certificat n est pas valide. On pourrait identifier les informations dans le certificat et peut-être effectuer la chaîne de vérification pour s assurer que le certificat est valide. Par exemple, nous devrions être en mesure de déterminer les cas où le certificat est self-signed Est-ce que les suites de chiffrement supportées par le serveur sont toutes sécuritaires Une autre possibilité serait de définir une méthode pour identifier les chiffrements non sécuritaires. Nous pourrions garder une liste qui définit les chiffrements qui sont considérés comme périmés et comparer cette liste à celle que le serveur propose. Cela permettrait de vérifier si les configurations du serveur permettent aux utilisateurs d utiliser des moyens qui ne sont plus adéquat Est-ce que les serveurs sont vulnérables aux attaques bien connues. Il serait possible de regrouper d autres sources d informations ou outils déjà disponible pour vérifier si les serveurs sont susceptibles d être vulnérable à des attaques. Nous pourrions par exemple ajouter une tâche qui utilise un autre outil de scan existant, récupérer leur rapport et ajouter cette analyse à nos données.

23 6.2. Scan mensuel automatique pour faire le suivi de l évolution L un des points important de l application serait de récolter des données avec régularité pour avoir un meilleur portrait se la situation. Il serait possible d avoir un serveur et des clients dédiés qui récolteraient les données et les entreposeraient. Nous pourrions donc ajouter un volet temporel à nos analyses. Un scan mensuel permettrait aussi de rendre nos données plus consistantes avec la situation réelle. Ainsi, certains serveurs qui ne se retrouveraient pas dans un scan pourraient se retrouver dans le suivant Volet Application web Suivi des scans mensuels Dans l éventualité où nous pouvons exécuter des scans mensuellement, nous pourrions afficher et gérer les scans par une interface web. Cela permettrait d automatiser toute la procédure des scans. Nous pourrions aussi rendre le tout accessible à distance pour faciliter la gestion du serveur de l application. De plus, le volet web permettrait de rendre notre application et nos résultats plus visibles et ainsi sensibiliser peut-être quelques entreprises aux rôles cruciales de la sécurité Rendre accessible le produit aux entreprises Il serait important, si l on veut que les entreprises améliorent leur sécurité, de fournir notre application, ou une partie des fonctionnalités, pour qu elles puissent scanner leurs propres serveurs. Nous pourrions conjuguer le volet web en rendant disponible sur notre site la possibilité de scanner son propre domaine. Nous pourrions aussi rendre une application disponible qui permet de rouler certaines tâches sur les serveurs à l interne et produire un rapport à la fin. Il faut prendre certaines précautions pour ne pas avoir des abus qui seraient reliés à une mauvaise utilisation de l application.

24 7. Conclusion Nos résultats révèlent une situation peu enviable par rapport à la sécurité des serveurs courriel au Canada. D un côté, très peu de serveurs obligent leurs usagers à se connecter en mode SSL, laissant ainsi la possibilité d utiliser une connexion non-sécurisée. D un autre côté, parmi les serveurs permettant l établissement d une connexion sécurisée SSL, la majorité n utilisent pas un certificat valide ce qui ouvre la porte à des attaques possibles. Il semble donc y avoir un réel besoin au niveau de la sécurité des serveurs courriel. D une part, des outils d analyse sont utiles afin d avoir une bonne compréhension de la situation et même de suivre son évolution. D autre part, il semble pertinent d être en mesure de faire des recommandations précises (voir fournir des marches à suivre détaillées) afin de régler les faiblesses de sécurités identifiées. Bien que notre outil (et l analyse qu il permet de faire) soit intéressant car il nous permet d obtenir une vue d ensemble sur la situation, de l information plus détaillée est nécessaire pour être en mesure d émettre des recommandations précises. Par exemple, il faut pouvoir connaître la cause exacte de l invalidité d un certificat afin d aider à régler le problème. Finalement, l information recueillie indique une situation problématique au niveau de la configuration de plusieurs serveurs courriel. Par contre, la situation réelle pourrait être légèrement moins dramatique que nos résultats l indiquent si les logiciels clients des utilisateurs s avèrent tous configurés proprement (c est à dire pour utiliser seulement les mécanismes d authentifications sécuritaires). Des statistiques sur l utilisation réelle des mécanismes d authentifications non-sécurisés seraient très intéressantes. Par contre, ces statistiques demandent l analyse de l établissement des connexions par les logiciels clients. Cette analyse est très difficile car elle demande la collaboration de plusieurs organisations ayant beaucoup d usagers (Ex. Universités, Fournisseurs d accès internet) qui eux doivent respecter plusieurs règles par rapport à la confidentialité de l information de leurs usagers.

25 8. Bibliographie [1] CORBATO, F. J., SALTZER, J. H., & CLINGEN, C. T. (1972). Multics. New-York: ACM. [2] Leiner, B. M. (2009). A brief History of the Internet. ACM SIGCOMM. [3] Sluizer, S., & Postel, J. B. (1981, Mai 1). RFC Mail Transfer Protocol. Retrieved Avril 1, 2013, from IETF TOOLS: [4] Reynolds, J. K. (1984, Octobre 1). RFC Post Office Protocol. Retrieved Avril 1, 2013, from IETF Tools: tools.ietf.org/html/rfc918 [5] Radicati, S. (2012). Market, Palo Alto: THE RADICATI GROUP, INC. [6] Wiki. (2013, Mars 12). Population mondiale. Retrieved Avril 1, 2013, from Wikipedia: [7] Would you like free Wi-Fi with that? (2011, Mai 18). Retrieved Avril 1, 2013, from McDonalds: _You_Like_Free_Wi_Fi_With_That.html [8] Base64, processus de codage - [9] POP3 APOP - [10] Cryptographie asymétrique - [11] Qu est-ce qu un certificat X [12] Définition du protocole NTLM - [13] Processus d authentification - [14] Wikipedia STARTTLS - [15] (2009) Crying wolf : An empirical study of SSL Warning effectiveness Joshua Sunshine, Serge Egelman, Hazim Almuhimedi, Neha Atri, and Lorrie Faith Cranor Proceedings of Usenix Security 2009, P