Biffer les URL comme moyen de prévention contre le phishing par e-mail?
Dans une grande organisation (par exemple, un personnel de la ville), s'appuyer sur le comportement humain pour prévenir les attaques de phishing n'est pas assez efficace. Bien que cela soit quelque peu gênant (la sécurité l'est généralement), je pense à une approche par laquelle le client de messagerie rédigerait toutes les URL d'un message. Non seulement les URL sont inactives, mais elles sont complètement éliminées. Par exemple, quelque chose comme ceci:
Cliquez ici pour voir notre nouveau rapport sur les taxes foncières:
[URL supprimée]
S'il y a vraiment un nouveau rapport, et si le membre du personnel de la ville veut vraiment le voir, il peut aller sur le site Web et retrouver le rapport. Si l'utilisateur accède au site Web via un gestionnaire de mots de passe ou un signet, il n'y a aucun moyen d'atteindre le faux site au lieu du site réel. (Une attaque de phishing impliquant un site que l'utilisateur n'est pas familier et n'a donc pas de connexion ne serait pas une attaque de phishing.)
Bien que toutes les attaques de phishing n'impliquent pas d'URL dans les e-mails, je suppose que 99% d'entre elles le font probablement.
J'apprécierais quelques commentaires pour savoir si vous pensez que cela serait efficace pour réduire les attaques de phishing. Je suis moins intéressé à savoir si l'absence d'URL présente un inconvénient, comme je le sais.
(Forcer le client de messagerie à fonctionner en mode texte supprime uniquement le lien; l'URL est toujours là.)
Tout d'abord, ce serait un cauchemar pour l'utilisabilité.
Deuxièmement, cela ne réglerait même pas le problème auquel il prétend. Bien qu'il puisse être efficace pour les messages de phishing conçus pour des clients "normaux", les attaques conçues pour suir de tels systèmes seraient probablement encore plus efficaces.
Les utilisateurs de ces réseaux seraient habitués à utiliser toutes sortes de manières alternatives de se référer aux URL. Supposons que je voulais créer un lien vers cette question et vous demander de voter pour ma réponse, car vous ne me permettez pas d'écrire https://security.stackexchange.com/questions/215871/redacting-urls-as-an -email-phishing-preventative Je pourrais dire:
- security.stackexchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative
- https://security.stack exchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative
- Passez à la sécurité SE question 215871
- légèrement 2ZoZiTS
- Lien envoyé à votre courrier personnel
- Veuillez appeler au 555-0123 afin que je puisse vous donner l'URL réelle
- Rechercher "Rédaction d'URL à titre de prévention contre le phishing par e-mail?" dans Google
- Voir la dernière question active
- hôtel tango tango papa sierra colon double slash sierra echo charlie uniforme romeo inde tango yankee dot sierra tango alpha charlie kilo echo xray charlie hôtel alpha novembre golf echo dot charlie oscar mike slash québec uniforme echo sierra tango inde oscar novembre sierra slash deux un cinq huit sept one slash romeo echo delta alpha charlie tango inde novembre golf dash uniforme romeo lima sierra dash alpha sierra dash alpha november dash echo mike alpha india lima dash papa hotel india sierra hotel india novembre novembre golf dash papa romeo echo victor echo novembre tango alpha tango india victor echo
- URL envoyée dans une pièce jointe
Notez que certains e-mails malveillants utilisent déjà des URL dans les pièces jointes pour [contourner] les filtres de courrier électronique. Vous pourriez penser "Je supprimerai également les URL des pièces jointes", mais cela causera des ravages lorsque les documents que vos utilisateurs sont expurgés seront silencieusement corrompus par le système de messagerie. Le formatage peut également se casser partout. Sans oublier que cet effort pourrait vous obliger à être en mesure de (correctement) reconnaître et modifier presque tous les formats de fichiers existants.
De plus, votre service juridique vous empêchera probablement complètement de modifier les factures (reçues sous forme de pièces jointes), quelle que soit l'innocence de la modification.
De plus, des choses comme les liens de récupération pour les mots de passe oubliés ne fonctionneraient pas du tout pour vos utilisateurs.
Mais à mon humble avis, le principal problème serait que les utilisateurs seraient "formés" pour faire toutes sortes de solutions de contournement étranges, une "URL cachée" qui les faisait passer par de tels cerceaux ne soulèverait aucun soupçon.
(Et comme noté par Joseph Sible , votre filtre antispam ne pourrait pas examiner les URLs obscurcies)
Quelques exemples:
- Demandez à l'utilisateur de rechercher "StackExchangeBank carte de crédit bloquée" sur Google. Ensuite, faites apparaître une page de phishing pour la StackExchangeBank en haut en utilisant des mots inhabituels ou même en achetant des publicités.
- Si vous m'appelez pour que je vous donne l'url qui serait autrement filtrée, je peux vous envoyer sur une page de phishing, en ajoutant une ingénierie sociale en direct pour la rendre plus crédible qu'un simple e-mail.
- Envoyez-les via un raccourcisseur d'URL. L'utilisateur n'aura aucune idée d'où il est envoyé
- La n-ième question de la liste changerait évidemment, donc elle ne garantirait pas à l'utilisateur d'arriver à la question "légitime" que vous avez posée, au lieu de voter sur une autre question "usurpant l'identité" de celle qu'il était censé atteindre.
Une approche beaucoup plus saine serait que vous changiez les URL pour passer par un de vos services de redirection. Certains filtres de sécurité de messagerie le font déjà. De cette façon, ils peuvent vérifier, lorsque l'utilisateur clique sur le lien s'il est répertorié sur une liste noire (où il se peut que ce ne soit pas le cas lorsque l'e-mail a été reçu) , et ainsi bloquer l'accès. Vous pourriez également lui faire afficher un grand avertissement effrayant qu'ils ne vont pas sur un site Web sûr, au moment où ils essaient d'accéder à un site non sur liste blanche (uniquement ceux auxquels ils ont des informations d'identification, soi-disant). Et pourtant, une telle approche serait quelque peu défectueuse car les utilisateurs auront en fait des informations d'identification sur plus de sites que ceux figurant sur la liste blanche du proxy pour ne pas afficher l'avertissement, et les sites légitimes décident souvent de publier leur contenu sur un nouveau domaine (ce qui ne n'apparaissent pas sur la liste blanche, évidemment). S'il y a trop de faux positifs, les utilisateurs finiront par y prêter peu d'attention, car il serait "normal" de les recevoir.
Ce n'est pas une bonne idée. Tout d'abord, "quelque peu gênant" est un énorme euphémisme. En outre, la règle d'utilisation d'AviD s'applique ici: au lieu des URL que les ordinateurs comprennent, vous aurez des instructions sur la façon de taper une URL, ce qui empêchera les scanners de messagerie de détecter que l'URL va vers un site de phishing.
En plus des humains capables de décrire les URL en anglais pour contourner le filtre, cela briserait toutes sortes de systèmes automatisés de vérification des e-mails, de vérification des comptes et de réinitialisation des mots de passe qui dépendent de votre capacité à recevoir une URL envoyée par e- mail afin de vérifier la propriété de l'adresse. Certains de ces systèmes fournissent un code qui peut être copié-collé dans un formulaire, mais beaucoup ne fournissent qu'une URL.
Vos utilisateurs dans le cadre de ce système ne pourraient pas ouvrir de nouveaux comptes sur divers sites Web et pourraient être verrouillés de leurs comptes existants dès que le fournisseur de services demande une vérification par e-mail, par exemple. connexion sur un nouvel appareil.
(Avertissement: je travaille sur l'une des meilleures solutions de sécurité des e-mails. Ce message est destiné à être indépendant du fournisseur.)
Au moins les deux principales passerelles de sécurité de messagerie d'entreprise offrent la possibilité de réécrire les URL via une couche de sécurité supplémentaire au moment où un utilisateur clique sur le lien. Il s'agit d'une approche plus sûre que la suppression complète du lien. Ces solutions intègrent des contrôles de sécurité supplémentaires ainsi que des rapports pour la correction dans le cas où l'un des liens cliqués finit par être malveillant, permettant à votre équipe infosec d'effectuer un contrôle des dommages.
Vous pouvez implémenter la version d'un pauvre de cela en configurant votre propre service RL Shortening , en réécrivant les liens de l'hameçonnage suspect (ou tout, bien que cela puisse ennuyer vos utilisateurs) et en vérifiant le mappage par rapport à RI DNSBLs soit lors de la redirection, soit périodiquement avec une tâche cron.
Comme réponse d'Ángel déclare, les réécritures ne fonctionnent que pour les URI que votre système peut reconnaître. Ce ne sera jamais complet, mais j'espère que cela correspond très étroitement à ce que les clients de messagerie de vos utilisateurs afficheront sous forme de liens cliquables.