 de comment faire parfaitement faire une email. Tu peux être en même temps dans le même temps. Nous avons notre prochain Speaker, Andrew, qui est un chercheur en sécurité, et il va nous parler de la contrôlation de nos emails et des stratégies qui vont nous permettre cela. Merci de l'applaudir. Bonjour, je m'appelle Andrew, et je travaille pour la sécurité en Latvia. La sécurité elle est en. Ce qu'on fait principalement, c'est d'essayer de rendre les gens conscients des bonnes pratiques. Donc on n'est pas les seuls. Des organisations gouvernementales dans d'autres pays font la même chose. Cependant, pour être honnête, nos avancées actuellement sont plutôt pas mal. Si on regarde par exemple ici l'usage au niveau mondial d'une technologie particulière, des marques, sur la gauche. Donc on peut voir que... Dans les deux groupes qu'on peut voir ici, il y en a deux tiers qui n'ont même pas configuré des marques. Si il y a quelque chose à retenir de ce tool, c'est bien qu'il s'agirait de commencer à utiliser au moins cette technologie. Donc une explication pour ce faible taux d'adoption à l'heure actuelle, c'est qu'à l'heure actuelle, il y a beaucoup de technologies concurrentes. J'ai essayé de réduire ça autant que possible dans le contenu de ma présentation, mais comme vous pouvez le voir, je parle quand même de au moins 3 choses différentes. Il y a un problème dans le fait qu'il y a trop de bassoir, trop de technologie. On sait pas lesquelles il est utilisé, à quel moment. Et je pense que maintenant on commence à trouver une façon de résoudre tous ces problèmes. En particulier les tests d'intrusion. Donc quand un test d'intrusion a été fait, que ces résultats ont été publiés, ça devient impossible de dépasser la question de est-ce qu'on utilise plutôt la technologie A ou la technologie B. On peut commencer à parler des problèmes intéressants, c'est-à-dire est-ce que c'est possible de commencer à spouffer des e-mails venant de votre entreprise. Donc c'est ce pourquoi mon audience principale ici ça va être les gens qui font des tests d'intrusion. Mais bon, d'autres gens ici peuvent être intéressés, par exemple les 6 à 9. Même si vous avez déjà des connaissances, ce sujet bien sûr, cette présentation va pouvoir peut-être vous permettre d'approcher les choses selon une perspective un peu différente. Et donc des fois il y a des choses qui sont pas assez faciles à comprendre. Donc par exemple SMTP comment ça fonctionne, comment on va pouvoir effectuer du spoofing sur tout ce qui est mail. Et du coup ça va être intéressant aussi pour des gens qui débutent un peu dans le milieu. Donc l'envergure de la menace. Donc c'est vraiment un sujet très large. Moi je vais m'attacher seulement à la partie qui concerne comment spouffer des mails, comment réussir à spouffer des mails. Dans les tests de sécurité parfois il y a des choses qui, enfin le spoofing il peut se faire via phishing ou super phishing. Mais une approche qui est vraiment efficace c'est via le social engineering pour autant que je sache. Et ça ça nous permet de montrer aux clients quels sont les risques effectifs en fait. Mais si dans un rapport de pentest on parle seulement de social engineering les personnes qui lisent le rapport les managers ils vont se dire que le meilleur moyen d'aller contre ça c'est à être de sensibiliser les gens. Mais il faut aller plus loin que ça à l'heure actuelle on peut pas s'attendre à ce qu'on demande aux utilisateurs de vérifier les haideurs présent dans les mails par exemple. Avant qu'on passe aux aspects techniques il y a un petit secret qui pourrait aider les gens qui ne travaillent pas dans l'industrie du mail à comprendre tout ça. Donc pour les administrateurs qui gèrent des serveurs mails historiquement ce qui leur importe le plus c'est la disponibilité de leur service et leur fiabilité beaucoup plus que leur sécurité. Par exemple si vous gérez les mails dans une entreprise et que les clients arrêtent de pouvoir recevoir des mails le management va probablement assez rapidement vous demander sympathiquement de corriger tout ça. Mais c'est pas forcément de votre faute ça se pourrait que le problème soit pas de votre côté. Un autre exemple si certains de vos employés ne peuvent pas recevoir leurs mails assez rapidement par exemple pour faire un recette de password, une vérification un token d'authentification ou ils ne peuvent pas se loguer sur un système important alors il va falloir résoudre ça rapidement. Mais si le système est vulnérable à certains problèmes de sécurité il n'y a pas d'utilisateur ou le management qui va le remarquer. Alors du coup maintenant on peut commencer par la partie technique donc je vais commencer par une petite introduction au protocole SMTP SMTP c'est le protocole qui souhaitant toute la communication par email. Donc ça c'est facile à suivre donc vous voyez si le flux de données se passe on va avoir un mail à une autre personne par exemple Alice on va avoir un mail à Bob et il travaille pour de différentes compagnies et donc il utilise différentes domaines donc ce qui se passe c'est que les deux ont utilisé des clear email par exemple Thunderbird Alice envoie un email par ce protocole SMTP et elle l'envoie à son serveur d'email donc ça c'est un serveur d'email sortant en général les organisations ont deux types un serveur email, un pour les mail entrants et un pour mail sortant donc c'est important pour les tests d'intrusion d'y penser en tant que de systèmes différents même si c'est une seule machine parce que la configuration peut être différente entre les mail sortants et les mail entrants Alors donc là le serveur d'Alice essaye d'envoyer un mail au serveur de Bob donc le serveur essaye de trouver automatiquement quel est le bon serveur à qui a envoyé l'email et donc ça c'est fait dans cette boîte bleue donc c'est les enregistrements DNS de type MX et donc ça c'est maintenu par l'organisation de Bob donc l'organisation de Bob s'il veut recevoir des emails elle définit ce type d'enregistrement DNS et on lui envoie des emails qui dit en gros merci de l'utiliser ce serveur pour nous envoyer des emails donc le serveur sortant d'Alice connaît l'adresse du serveur entrant de Bob lui envoie et ensuite Bob reçoit son email et donc la partie qu'on va essayer de casser en tant que testeur d'intrusion c'est cette partie entre le serveur sortant et le serveur entrant donc maintenant si on prend l'inverse on aurait l'impression que c'est juste l'inversion des flèches mais si on est du point de vue du testeur d'intrusion donc en fait si notre client est de l'organisation d'Alice dans le deuxième exemple quand on envoie un mail de Bob à Alice une partie de cette transaction va passer par les serveurs d'Alice alors que si on va dans l'autre sens c'est pas le cas bon c'est un peu confusant mais bon vous verrez bien plus tard donc voilà un autre exemple qui a l'air similaire mais pas tout à fait donc donc Alice communique avec son collègue qui est dans la même organisation et là encore il va y avoir de manière logique un serveur entrant mais les deux appartiennent à notre client donc ce qu'il faudra réfléchir c'est parmi ces trois scénarios lequel est le plus facile à casser et ensuite on doit regarder à ce qui est vraiment envoyé quand un email est envoyé donc c'est le protocole SMTP c'est vraiment un protocole assez sympa c'est juste du texte du texte simple il est assez facile de jouer avec parce que vous avez juste à ouvrir une connexion un bon serveur et d'essayer d'écrire le commande à la main donc vous pouvez vous amuser à trifouiller essayer différentes choses et vous voyez en temps réel ce qui se passe donc sur la partie droite vous voyez deux parties définies par SMTP donc d'abord l'enveloppe SMTP qui dit Hello qui spécifie un émetteur un récepteur par exemple Alice et Bob et ensuite la deuxième partie commence par data et c'est le conclu le message donc si on regarde un peu plus en détails en temps tard si vous voulez regarder les détails c'est un peu important donc le message le contenu SMTP est constitué lui-même de deux parties les en tête et le corps donc si vous n'êtes pas familier avec les e-mails bon aussi je pense que tout le monde ici dans le public connaît HTTP donc c'est un peu la même chose donc il y a une partie et vous remarquez qu'il y a les adresses d'Alice et Bob deux fois donc Alice est sur la deuxième ligne et le from et ensuite Alice est encore dans le header from et la même chose pour Bob alors pourquoi alors en fait ça vient de la façon dont on voit l'email alors une personne assez normale qui utilise l'email on les imagine comme cette chose à gauche qui est une sorte de carte postale et donc sur une carte postale il y a quelqu'un qui l'a signé l'émetteur et puis il y a un récepteur et puis voilà il y a un message c'est comme ça qu'on apprend et ensuite pour les administrateurs e-mail ça ressemble plutôt à l'image à droite donc il y a une enveloppe et à l'intérieur il y a une carte postale donc il y a deux adresses dans ce scénario d'abord l'expéditeur et destinateur sur l'enveloppe et ensuite le bureau de poste par exemple et à l'intérieur de l'enveloppe il y a un autre message le message interne qui est destiné que au destinateur donc en fait on pourrait mettre toute l'enveloppe dans une autre enveloppe ça a l'air un peu idiot mais en fait l'e-mail le permet de faire ça et dans les documents standards il y a tout un tas d'exemples où on voit pourquoi ce sera nécessaire et pourquoi c'est possible mais c'est effectivement assez perturbable d'habitude on spécifie la même adresse deux fois mais quand on fait un test d'intrusion ce qu'on doit se demander c'est est-ce que c'est vraiment toujours vrai est-ce que c'est pas juste un peu pieux et en fait le standard ne dit absolument pas qu'on doit mettre deux fois la même adresse aussi bien pour le destinateur que pour l'expéditeur sur l'enveloppe et sur le message donc vous pourriez mettre des choses différentes alors en fait il y a beaucoup plus d'entête que ce que j'ai montré alors ce que j'ai mis c'est les entêtes que tout le monde connait parce qu'en général c'est ce qu'on voit on voit la date, le sujet, l'expéditeur et le destinateur qui en général vous même il peut y en avoir plus et une autre question c'est si on a bon par accident pour une autre raison spécifier des adresses différentes entre l'enveloppe et le message laquelle le destinateur va suivre et en fait c'est celle qui est dans le message qui est destiné le destinateur si on regarde dans le standard il y a un peu plus de haideur et en fait il y en a 3 qui sont sémantiquement très proches donc dans le standard explique quand est-ce qu'on l'utilise chacune ce qui est drôle c'est que le from par exemple il devrait pas y avoir plus d'une adresse mais en fait l'heideur peut contenir plusieurs adresses j'ai jamais reçu d'emails avec un from avec plusieurs personnes mais c'est possible alors ce qui est important dans ce standard c'est la compatibilité ascendante et c'est pour ça qu'on doit avoir au maximum un seul de ces heideurs etc en fait vous pouvez envoyer des emails avec plusieurs fois le même en tête ou alors sans aucun sender et en fait en pratique c'est incorrect mais ça va marcher quand même et la plupart des clients vont faire de leur mieux pour parser quand même des messages même le plus malformé possible donc c'est mieux de faire comme si tout allait marcher en général et pour les tests d'intrusion ça veut dire qu'en fait on peut jouer avec ça parce qu'il y a différentes implementations et puis par exemple savoir exactement lequel des deux heideurs sera choisie c'est totalement dépendant de les implementations comme il y en a vraiment beaucoup dans la nature et qui sont fait de différentes façons en tant que testeur d'intrusion vous pouvez essayer différentes choses donc maintenant qu'on a vu ces bases on va passer à comment on va vraiment essayer de spouffer des emails donc si on revient à ce schéma qu'on a déjà vu exemple Alice envoie un mail à Bob donc on a Chuck une tierce partie donc par exemple l'appel testeur on a le droit de faire ça on va essayer de spouffer un mail de Alice à Bob donc l'idée c'est qu'on va envoyer un mail à Bob et il faut que ce mail il est l'air d'avoir été envoyé par Alice donc par exemple un problème qu'on a eu en Létonie c'est celui des fake news donc tout ça ça va être utilisé contre des entités gouvernementales ou des des éléments faux ont été envoyés soi-disant par des entités gouvernementales à des gens donc vous pouvez évidemment imaginer que c'est pas une bonne chose donc ce qui est intéressant ici c'est que même si Chuck défectue une attaque donc selon votre perspective contre attaque ou quoi de Bob il faut que le mail est l'air de venir de Alice donc maintenant il y a un deuxième type d'attaque si on envoie maintenant dans l'autre sens un mail de Bob Alice alors dans ce cas donc on est à nouveau de Chuck donc là le mail va passer sur les systèmes d'Alice donc ce qui est intéressant maintenant c'est donc quelle mesure c'est facile à protéger dans ce second exemple on a l'impression que effectivement le mail passe par les systèmes d'Alice donc on pourrait se dire que Alice a plus de moyens de se protéger ou de faire quelque chose contre ça dans notre cas même si en fait nous c'est la personne qu'on essaie de protéger c'est Alice pour nous ça va être plus facile de protéger la personne qui reçoit le mail soit disant d'une Alice donc maintenant dans le cas de mail envoyé au sein d'une même organisation donc si on a un mail qui arrive vers le serveur en train de Alice théoriquement dans cet exemple ça va être le cas le plus facile où on se rend compte qu'il se passe quelque chose d'anormal parce que le serveur en train devra avoir toutes les informations nécessaires mais en pratique des fois et en fait assez souvent il va y avoir une white list précise au sein de l'organisation d'Alice et du coup il y a certaines vérifications qui vont pas être effectuées en fait d'ailleurs il y a cet exemple donc on a vu ça au cours des dernières années pas spécialement spécificales à l'étonym mais ça semble-t-il donc on a ce mail qui est faux et qui parle de choses liées à des ransomware donc où dans le mail on essaie de vous faire chanter et on vous dit d'essayer d'envoyer du bitcoin sur telle ou telle adresse ou wallet donc quelque chose qui se fait assez souvent pour vous montrer qu'on a accès mais c'est d'envoyer un mail depuis votre adresse pour la plupart des gens ça fonctionne ils y croient puisqu'ils ont reçu un mail depuis eux-mêmes mais comme vous allez le voir c'est assez facile en fait de spouffer des mails parce que les protections adéquates n'ont pas été mises en place donc j'espère que personne ici ne se fait avoir de telles arnaques mais c'est possible que vous ayez des amis des collègues de la famille qui est reçu de telle mail et qui se soit fait avoir si c'est le cas vous devriez peut-être leur suggérer de contacter leurs fournisseurs de mail et de leur demander de mettre en oeuvre les protections adéquates maintenant regardons une conversation smtp spouffée on est dans un exemple similaire au précédent mais maintenant on est choc donc on envoie un mail à Bob en prétendant être Alice en quoi on est dans un cas différent du précédent donc c'est la même conversation concernant le le protocole smtp en lui-même il n'y a pas de production si on est ce gars là qui envoie des faux ransomware on peut envoyer ça telle qu'elle et ça va fonctionner dans beaucoup de cas mais bien sûr les gens qui cherchent les serveurs de mail ils les admettent mail savent enfin son cours en tout ça il y a eu beaucoup de tentatives d'ajouter des protections donc en ajoutant par exemple des filtres des choses comme ça mais pas seulement mais certaines de ces protections en fait cassent le standard, l'RFC mais l'RFC c'est pas un texte sacré donc bon en fait un problème c'est qu'il n'y a pas assez d'informations donc si on revient ici si on est Bob et qu'on essaie de protéger nos systèmes donc on est le système admin dans l'organisation de Bob donc on essaie d'ajouter quelques règles qu'est-ce qu'on peut vraiment faire donc un exemple c'est de faire ce qu'on appelle un callback smtp donc quand on va recevoir un mail d'Alice on va vérifier est-ce que sa adresse mail existe vraiment parce qu'en fait beaucoup de spammer ce qu'ils vont faire c'est qu'ils vont essayer d'envoyer des mails qui viennent d'adresses qui en fait n'existent pas qui ont l'air de venir d'adresse qui en fait n'existent pas le callback smtp en fait ça veut dire que lorsqu'on va recevoir un mail qui a l'air de venir d'une adresse on va essayer de se connecter à l'adresse qui semble avoir envoyé le mail et du coup si le serveur qu'on a contacté dit ok ce mail existe ok très bien et si ça n'a pas l'air d'exister alors on arrête la conversation donc une autre façon de vérifier est-ce c'est en utilisant le Hello donc normalement ce Hello il indique le serveur qui a envoyé le mail doit être envoyé le mail donc ce que beaucoup de serveurs vont faire c'est qu'ils vont essayer de vérifier d'une part que cet osname il pointe vers la bonne vers la bonne d'adresse IP par la même et ensuite ils vont essayer de faire une requête en reverse dns sur cet adresse IP pour vérifier que cet adresse IP correspond bien à ce osname en tant que pentester on est conscient de ça parce que si on n'est pas conscient on va essayer de faire tourner quelque chose et ça va juste pas fonctionner mais en fait ces mécanismes sont en réalité assez faciles à passer et ils offrent que des protections limitées donc comme on l'a vu SMTP en tant que telle ne fournit pas de protection alors quel âge au protocole on peut essayer d'utiliser alors un de ces protocoles c'est SPF alors qu'est-ce qu'il fait il essaye d'être le miroir du système des MX donc le MX c'est ce que le serveur d'Alice va utiliser pour automatiquement trouver le serveur qu'il faut contacter pour envoyer des emails à Bob SPF c'est entre guillemets l'inverse donc c'est ce qu'il va être utilisé sur le serveur de Bob donc dans l'autre sens il va requêter le SPF pour savoir de quel serveur sortant on s'attend à trouver les mails d'Alice et donc un champ qui est testé c'est le champ Sender Enveloppe alors voici une syntaxe SPF c'est pas mal alors c'est assez facile à comprendre même si vous comprenez pas la syntaxe donc c'est l'adresse IP du serveur sortant donc c'est facile à comprendre c'est qu'il y en a un seul donc si on reçoit un message de cet adresse IP c'est bon on peut l'accepter et sinon on le jette dans la norme on peut spécifier non seulement des adresses IP mais on peut aussi spécifier des noms de DNS donc pour les administrateurs les testeurs d'intrusion voilà c'est un peu plus simple et ensuite il y a ces qualificateurs c'est quelque chose qu'on doit mettre devant les méthodes donc par exemple si il n'y a aucun qualificateur de qu'une sorte donc c'est le comportement par défaut c'est à dire que tout ce qui est listé dans le record de SPF doit être accepté et en fait il y a d'autres options qu'on peut utiliser donc par exemple fail le moins donc par exemple assez souvent on utilise moins all donc ça ça veut dire que si on match celui-là jeter l'e-mail parce que c'est pas bon et donc il y a aussi soft fail donc ça c'est plutôt pour les périodes de test quand on commence à implémenter le SPF le problème c'est qu'en fait on peut facilement oublier d'ajouter des saveurs SMTP dans la liste et puis donc du coup si on est pas sûr ou qu'on pense qu'on a oublié alors on en met un seul et dans ce cas là donc en fait si on commence à mettre en place le SPF plutôt que de mettre fail qui est un peu trop fort donc vous pouvez utiliser celui-là soft fail donc voilà il y a d'autres exemples un petit peu plus compliqués donc par exemple include donc au lieu de l'utiliser votre propre politique parce que par exemple vous utilisez un tier comme google alors dans ce cas-là vous incluez un autre record alors ensuite on peut regarder un petit peu l'utilisation de SPF si on regarde la quantité de domaines qui ont défini une politique c'est plutôt pas mal par exemple si on regarde les domaines les plus populaires c'est 70% mais en fait la majorité sont plutôt mal configurées parce qu'ils vont utiliser plutôt l'option soft fail et ce que ça fait en pratique c'est rien du tout puisque même si a soft fail en fait on peut usurper votre email et puis du côté destinateur on va le voir quand même donc bon le pourcentage est maintenant qu'il y a quelque chose qui est important pour les pentesters c'est de comprendre qu'est-ce qu'on va faire maintenant qu'on peut spouffer donc ça veut pas dire que pour nous c'est terminé donc on a des règles etc et typiquement on va mettre à la fin maintenant ce till all si on a des mails qui viennent d'adresses enfin qui ont l'air d'être spouffés on va d'abord juste rien faire on va pas les droper quelque chose à remarquer ici c'est que pour il y a certains systèmes qui n'utilisent pas cette classification binaire enfin ça passe ou ça ne passe pas et par exemple dans le cas de soft fail on va pouvoir avoir quelque chose ou si le mail match on va pas juste le droper on va ajouter quelque chose quelque chose d'autre qui include donc c'est pratique quand on utilise enfin quand on fait appel à des détails c'est parti mais en fait pour certaines people c'est pas ce à quoi, enfin ce à quoi on s'attendrait en fait le nom n'a pas été choisi forcément de manière adéquate en fait c'est pas comprendre comme une macro en fait l'idée c'est pas qu'on devrait copier tout ce qui est à l'intérieur en fait en cas d'échec ça va pas juste droper le message ça va remonter d'un niveau et ça va essayer de continuer donc une erreur qui est commune c'est que par exemple si on oublie d'ajouter ce moins all alors même si la règle a le moins all alors ça ne va pas fonctionner parce qu'en fait un moins all dans include ça n'a pas la même sémantique qu'un moins all au niveau plus haut donc on pourrait se dire ça va marcher parce que par exemple j'ai mail il a ce qu'il faut mais en fait non ça marche pas exactement comme ça souvent on voit c'est ce genre d'enregistrement SPF qui contiennent beaucoup de choses donc il y a tout il y a zp il y a un mx il y a un ptr mais du coup en fait souvent les administrateurs ne savent pas exactement comment ça fonctionne ce qu'il faudrait mettre dans les enregistrements donc la plupart du temps la plupart des organisations à part si elles sont petites elles vont avoir plusieurs serveurs donc plusieurs zp et pour la plupart elle va pas y avoir de raison de mettre de mx dans les enregistrements SPF un autre cas c'est que les administrateurs comprennent ce qu'il se passe mais par contre l'architecture est un petit peu assez complexe ce qui est en genre de la complexité ensuite un autre défaut c'est que la granularité est pas extrêmement bien fait dans beaucoup de cas une adresse zp elle est pas liée seulement à un serveur mail par exemple elle pourrait correspondre à un serveur mail et un serveur web ou à une base de données donc en tant que pen testeur on pourrait s'intéresser à un autre service exposé parce que souvent sur les serveurs mail il y a pas grand chose sur un service web on a beaucoup plus de chance d'avoir quelque chose une vulnérabilité donc un exemple du hosting partagé qui est quelque chose de très commun donc dans ce cas on a l'adresse zp d'un serveur smtp donc ce serveur il est peut-être seulement utilisé pour envoyer des mails mais le serveur il fonctionne pas que pour vous il peut être utilisé par d'autres personnes donc un attaquant peut utiliser un service quelconque par exemple il n'y a même pas besoin d'attaquer quoi que ce soit il suffit de devenir un autre client et de se dégoyer pour avoir la même épis un autre défaut c'est vérifier le mauvais identifier il y a au moins 2 identifiers donc celui dans l'enveloppe, celui qui est à l'extérieur et ensuite ceux qui sont à l'intérieur donc par exemple dans le header from donc généralement spf lui vérifie seulement celui qui est dans l'enveloppe, celui qui est à l'extérieur mais les utilisateurs qui vont vraiment recevoir le mail ils vont pas avoir celui de l'enveloppe ils vont recevoir celui qui est à l'intérieur par exemple celui qui est dans le header from donc ce comportement-là il est fixé par exemple par des marques mais dans la plupart des cas lorsqu'il y a utilisation de spf il n'y a pas une utilisation parallèle de des marques donc ça veut dire que pour un attaquant la seule chose qu'on a à faire pour passer spf c'est de mettre le sender sur l'enveloppe à quelque chose d'autre qui va permettre de passer le filtre spf mais à l'intérieur ensuite on va pouvoir utiliser n'importe quoi par exemple une adresse mail qui a l'air de matcher celle de l'organisation cible alors ensuite du coup il y a une autre technologie qui est censée corriger ça parce que comme vous avez vu tout à l'heure spf c'est pas assez alors Dekim ah désolé donc c'est domain keys identify mail donc Dekim alors qu'est ce que ça fait en fait il fait de la cryptographie parce qu'il est quand même sympa alors c'est difficile à casser pour les attaquants etc le fait c'est qu'il signe chaque email sortant qui passe par les serveurs sortants donc tous les emails qui sortent obtiennent une signature vérifiée cryptographiquement donc alors c'est assez compliqué de comprendre parce que c'est pas censé être lui par des humains c'est censé être traité par des ordinateurs mais donc ce qui est important c'est que en fait toute la partie jaune c'est la signature cryptographique et la partie verte c'est l'identifiant de domaines et la partie rouge c'est j'oublie comment ça s'appelle et donc l'idée c'est que vous pourriez avoir plusieurs clés pour votre organisation donc par exemple vous pourriez envoyer des mails depuis le serveur d'origine et puis aussi le serveur de backup par google pour certaines campagnes de marketing et donc chacun de ces domaines peut changer ce paramètre donc le destinateur doit faire une requête DNS dessus et dans ce cas là il obtiendra la clé publique et il utilise la clé publique pour vérifier la signature donc ça a l'air assez sympa alors le problème c'est quoi alors déjà comment on l'utilise en prenant la cryptographie avec les publics c'est assez simple à comprendre donc l'expéditeur génère une clé publique il publie avec les publics dans le DNS et utilise la clé publique pour signer les messages dans le serveur sortant et donc le destinateur il requête la clé publique dans le DNS il vérifie la signature de l'expéditeur et il vérifie la signature alors quel est le problème alors le problème c'est que il peut y avoir plusieurs sélecteurs parce que quand vous fais de la configuration d'équipe vous pouvez choisir le retour de sélecteur que vous voulez et le destinateur ne peut pas savoir lequel de ces descripteurs d'équipe on aurait dû utiliser donc bon modifier une signature d'équipe c'est évidemment difficile mais ce qui est assez facile à faire c'est de l'enlever parce que dans ce cas le destinateur n'a aucune idée qu'il aurait dû en avoir parce que pour vérifier la signature il faut connaître l'identification de domaines en verre le sélecteur etc qui sont dans le header donc ça c'est un problème assez énorme ça veut dire que on ne peut pas usurper d'équipe lui-même mais on peut juste enlever du message envoyer le message sans d'équipe et puis dans ce cas là ça va marcher alors un autre problème c'est ce sélecteur de domaines pourquoi on a besoin en fait parce qu'il y a le champ envelope sender la bonne pratique ce serait que ce serait égal à from et que ce soit aussi égal au sélecteur de domaines et le problème c'est que en fait c'est pas mentionné en l'irfc que ça doit être le cas donc ce qui se passe exactement c'est que parfois ça passe comme ça donc par exemple si vous regardez à droite donc il y a le vrai domaines donc ça c'est celui de Google Apps Google Suite et par défaut Google Suite va signer tous les emails sortant et si vous ne faites pas votre propre configuration il va le le signer avec leur domaine interne qui est GAPS SMTP et bon on voit juste que ça a signé par d'équipe mais d'une manière qui permet pas de monter à l'origine alors qu'est-ce que le destinataire doit faire est-ce qu'il faut rejeter le message l'ignorer bon alors évidemment la politique la plus correcte c'est pas de l'ignorer peut-être qu'on s'y rigole un peu un valide alors donc la partie intéressante c'est une modification de d'équipement j'aurais pas trop le temps mais l'idée c'est que de temps en temps on peut modifier d'équipement donc la partie la plus simple c'est de modifier les headers parce que comme d'équipement se met dans les headers il va pas signer tous les headers c'est un peu la félapoule donc en fait on peut spécifier plus de headers que ceux qui doivent être signés donc pour l'attaquant le plus facile c'est d'ajouter un header et même s'il est rfc que j'ai dit avant on dit que certains headers donc subject problem etc d'avoir une seule copie en fait on peut en ajouter d'autres par exemple plusieurs from et donc ce qui se passe c'est assez intéressant parce que dès qu'il me match et dès qu'il me va signer le premier en tête en partant du bas mais en fait le client email en général il va afficher à l'utilisateur le premier en tête en partant du haut de l'autre côté alors l'attaquant du coup peut usurper ces deux rendres en ajoutant d'autres en haut alors ce problème est mentionné dans la rfc d'équipement et ils ont mis une protection mais pas implémenté en pratique donc modifier le corps du message c'est vraiment plus difficile à faire parce que naïvement on devrait le faire par cryptographie et bon ce que vous voulez pas faire et en fait on peut le faire d'une autre manière c'est avec un autre paramètre qui s'appelle la longueur du corps du message par exemple quand on fait de la signature ça veut dire que quand on fait de la signature on regarde pas tout le corps du message mais juste une partie en général c'est pas très utile mais donc les logiciels d'email ils vont pas faire ça et si ils le font ils vont commencer à être vulnérable cette modification du corps du message par exemple pour rajouter un type MIM à la fin on a fiché un autre maintenant la troisième technologie qui s'appelle démarque évidemment il y a un nom plus long également dans ce nom il y a deux mots clés le reporting et le respect et la conformance donc le problème dans ce cas c'est qu'on a besoin de dire à l'autre partie ce qui doit se passer par exemple une fois par jour et en fait un attaquant pour utiliser ça pour essayer de comprendre quel type de configuration vous utilisez mais l'autre partie la conformance c'est très utile d'abord d'équipe a ce problème majeur que si on enlève juste des haideurs le destinateur n'a pas de moyen de savoir qu'on utilisait d'équipe qu'on utilisait d'équipe démarque règle ce problème parce que ça veut dire qu'au moins l'un de SPF ou d'équipe devrait passer ça modifie la sémantique pour SPF parce que ça veut dire que si on a SPF et démarque alors les vérifications adéquates devraient être effectuées alors que si on utilise SPF seul on va pouvoir modifier des haideurs et le destinateur ne le saura pas donc la syntaxe c'est minimal à nouveau donc elle est facile à comprendre donc tout ce qu'on a à faire c'est créer un seul enregistrement si on n'a pas SPF mais qu'on a démarque donc ce que ça veut dire c'est que le domaine ne devrait pas envoyer de mail du tout parce que pour qu'un destinateur considère un mail valide il faudrait que l'espèce lide aussi donc s'il n'y en a pas il ne peut pas être considéré comme valide c'est donc ici c'est ce qu'il faut faire donc on a d'autres tags qui sont disponibles donc qui peuvent être bien plus long mais pour les pentaster c'est pas très très utile donc à nouveau on a 3 policies possible donc non, quarantine quarantaine ou reject donc ça veut dire que si un message devrait être rejeté alors il va en spam et reject ça veut dire qu'il sera rejeté donc sur les diagrammes on voit que même si démarque est la meilleure de ces 3 technologies en réalité c'est pas très utilisé donc ça veut dire qu'on peut spouffer la plupart des server mail alors comment on peut contourner cette protection alors qu'est ce qui se passe si quelqu'un a implémenté des marques donc je veux dire que l'attaquant peut vraiment rien faire mais en fait non par exemple supposons que quelqu'un a implémenté dès qu'il me démarque mais pas spf donc ça c'est assez pratique c'est parce que dès qu'il met assez puissant et démarque obligé à l'utiliser mais ça c'est en théorie parce que pour protéger vos propres e-mails donc côté destinataire il faut valider l'entête et le corps mais en fait par exemple Microsoft Exchange je le fais pas et par défaut il n'a aucune fonctionnalité pour parser des Kim donc il faudrait quand même activer le spf et donc ça c'est bien pour le testeur d'intrusion parce que si spf et des marques seuls sont activés c'est bien mais en fait comme on a vu il n'y a pas assez de granularité en général c'est mal configuré en fait dans des marques on dit juste que soit spf soit des Kim doivent être utilisés mais il n'y a aucun moyen de spécifier que les deux doivent être utilisés obligatoirement vraiment d'avoir les trois et spf dedans c'est le maillon faible alors juste une minute pour le récapitulatif il me reste plus beaucoup de temps désolé alors parce qu'il est vraiment important de test le système il faut étudier tous les deux scénarios pas juste donc par exemple si vous testez Alice l'organisation d'Alice il faut pas juste se concentrer sur les emails envoyés mais il faut aussi tester l'autre sens parce que ici vous voyez que c'est facile d'implementer spf et des marques parce que il faut juste une configuration dns mais le tester le valider proprement en fait c'est plus compliqué parce que pour le premier il faut qu'il y ait du support logiciel et ce qui peut se passer en pratique c'est qu'il y a plein d'organisations qui auront démarqué spf et qui ne l'ont pas correctement validé bon alors désolé j'ai pas de temps pour ça donc bon voilà on va s'arrêter là merci Andrew pour ce talk merci Andrew pour ce talk et oui effectivement on a le temps pour quelques questions donc je vois quelqu'un au micro 2 bonjour merci beaucoup est ce que vous connaissez de bons outils pour monitorer tout ce qui se passe en termes de démarque c'est vraiment une bonne question comme j'ai dit on préconise vraiment de l'activer mais à ma connaissance tous les outils disponibles sur internet collect des données qu'ils utilisent pour d'autres pour d'autres besoins et en fait c'est pas une très bonne idée pour la vie privée donc il faut faire un truc soi-même ou autre chose ok micro 1 s'il vous plaît merci pour la présentation donc je me considère comme ce que vous avez décrit comme un admin mail des fois j'ai besoin de raccourcir des enregistrements SPF et ce que j'ai tendance à faire c'est d'enlever la partie ptr mais vous dîtes qu'elle est utile donc comment vous faites pour raccourcir vos SPF et particulièrement pour le ptr ça dépend vraiment de votre besoin parce que bon selon parfois la régulation impose un long SPF et il n'y a vraiment aucun moyen de le contourner donc dans ce cas-là vous avez utilisé une cloude mais comme j'ai dit tout à l'heure c'est pas une macro donc c'est pas expandé et bon du coup là ce que je suggérer c'est de de revoir est-ce que c'est est-ce qu'on a vraiment besoin de tous ces enregistrements parce que avant que vous soyez google en fait vous n'avez pas besoin de ce très très long SPF là c'est probablement une erreur pour beaucoup d'organisation donc à propos de l'enregistrement ptr j'ai cru comprendre que c'était pas dans le standard si c'est dans le standard c'est dans le cas d'utilisation je pense pas que ce soit enlevé automatiquement alors micro 6 derrière merci pour votre présentation c'est un serveur mail accepte l'enregistrement d'équipe SPF démarque etc mais par exemple google pour beaucoup d'organisation il est classé en spam et la boîte de réception n'est pas affichée alors est-ce que vous avez une solution à ce problème contre google donc j'ai des choses à dire ce sujet c'est que google sont vraiment très script donc et ça ça vient du fait même qu'il y ait beaucoup de cas où les SPF sont mal configurés et google va pas accepter votre mail s'il n'a pas d'aspect dans mon travail je préfère que google fasse ce que je fais google a les outils nécessaires et vous avez besoin de traiter ce problème au cas par cas même si vous avez ce déquim, ce démarque installé ils sont pas configurés correctement ou alors ils sont configurés correctement mais il y a quelques erreurs alors une question de l'internet alors quand on essaye de vérifier une adresse comment gérer les erreurs de type noreplay vous pouvez répéter s'il vous plaît alors quand on essaye de vérifier une adresse comment gérer les adresses de type noreplay si j'ai bien compris c'était à propos du editor noreplay qui n'existe pas comment gérer des mail en noreplay je vais essayer de expliquer ça selon ma compréhension ce qui arrive souvent c'est que le mail va être envoyé depuis une adresse inexistante le fait qu'il y ait une adresse en noreplay c'est pas le problème en soi le problème c'est qu'il y a pas de telle adresse en fait en fait j'ai pas vraiment de réponse pour ça parce que si on s'en tient à l'RFC on devrait quand même l'accepter en pratique beaucoup de systèmes mail le drop c'est mail et il va pas être possible d'envoyer de mail depuis ces adresses donc si c'est votre situation crée l'adresse en question si dans le cas contraire vous recevez un mail de telles adresses il faut vraiment que vous vérifiez essayer de contacter l'organisation et qu'est ce qui se passe si on drop c'est mail mais selon l'RFC vous devriez la recevoir et les traiter alors micro 4 alors merci pour cette présentation est ce que vous connaissez tout courant d'efforts pour résoudre le problème des gros serveurs d'email parce que dans beaucoup de cas vous pouvez juste pas aller contacter en fait ils savent pas exactement comment faire ça fait partie de ce qu'on essaie de faire si vous avez ce problème ou une grande compagnie et concerné essayer de la contacter ou essayer de passer par l'organisation gouvernementale qui va gérer ça par exemple pour les Tony si quelque chose n'est pas parfaitement sécurisé ça veut pas dire que c'est mauvais il pourrait y avoir des cas d'usage au business ou en fait c'est utile dans le cas d'Amazon si ils ont testé et si ils ont testé des convécutions très strictes ils ont pu voir que dans ce cas là il y aurait des mails qui passeraient juste pas en termes de business puisque on va pas pouvoir se permettre de poser des problèmes en termes de business OK on attend la fin de ce talk si vous avez des questions supplémentaires adressez-les directement au speaker