Ma banque continue de saboter la sensibilisation anti-phishing
(moritz-mander.de)- La banque envoie des e-mails promotionnels d’événement ressemblant à des e-mails de phishing peu fiables
- Les liens et le domaine du site dans le message semblent sans rapport avec la banque, et la demande de saisie d’informations personnelles rend difficile de déterminer s’il s’agit de phishing
- Même après vérification, découvrir qu’il s’agit d’un événement officiel accroît la confusion et la méfiance
- Ce comportement sape l’objectif de la sensibilisation au phishing et expose fortement la banque à une responsabilité juridique
- Pour résoudre le problème, l’accent est mis sur l’usage de domaines fiables et sur une implémentation dans l’application
Préface
J’ai vécu une situation où ma banque sabote directement la sensibilisation anti-phishing. Un e-mail lié à un événement envoyé par la banque présentait des caractéristiques si suspectes qu’il était presque impossible de le distinguer d’une arnaque de phishing. Il demandait de saisir des informations personnelles sur un site qui n’utilisait pas le domaine officiel de la banque, et cela met en lumière les problèmes de pratiques de sécurité et de la réalité de la sensibilisation dans les banques et organismes publics, en Allemagne comme ailleurs.
Chapitre 1 : arrivée d’un e-mail suspect
- Réception d’un e-mail de la banque au sujet de « Wero-Win-Wochen » (événement avec lots)
- Le message incitait à participer en annonçant des gains pouvant aller jusqu’à 7 000 euros par semaine
- Sparkasse (réseau allemand de caisses d’épargne locales) et Wero (nouveau système européen de paiement numérique) étaient mentionnés dans le message
- Le lien dans l’e-mail menait vers « gewinnen-mit-wero.de », différent du domaine officiel de la banque
- Le contenu et le ton ressemblaient à un e-mail de phishing ordinaire ; seule l’adresse d’envoi était une adresse officielle de Sparkasse
- Il a fallu vérifier sur le site officiel de la banque si l’événement était réel
Qu’est-ce que Sparkasse ?
- Une caisse d’épargne locale opérant de manière indépendante selon les régions
- L’un des plus grands groupes de services financiers d’Europe
Qu’est-ce que Wero ?
- Un nouveau système de paiement numérique créé par l’European Payments Initiative (EPI)
- Développé pour unifier les systèmes de paiement locaux, avec au départ un focus sur les paiements P2P
- Comparable à PayPal, mais avec une structure répartie entre les banques
Chapitre 2 : aggravation de la situation – un site web suspect
- Le design et la structure du site d’inscription à l’événement accessible via le lien de l’e-mail ressemblent fortement à ceux d’un site de phishing
- Aucune mention d’une agence Sparkasse ni distinction entre les banques, ce qui ignore leur indépendance respective
- Le domaine lui-même n’a aucun lien avec le domaine officiel de la banque et utilise une dénomination générique que n’importe qui peut enregistrer
- Le certificat SSL utilise aussi le gratuit Let’s Encrypt, ce qui réduit la confiance
- Le contexte et la justification de l’événement sont peu expliqués ; seul « l’opportunité de recevoir de l’argent » est mise en avant
- Pour participer, il est demandé de saisir des informations personnelles et financières comme le nom, la date de naissance, l’IBAN et l’adresse e-mail
- Cela va à l’encontre de la tendance habituelle des événements financiers numériques modernes, généralement conçus pour une participation uniquement dans l’application
Cela conduit l’institution financière à rendre délibérément inutile la sensibilisation des utilisateurs à la sécurité.
Le problème de la baisse d’efficacité de la sensibilisation à la sécurité
- Si même de vraies banques utilisent des méthodes semblables aux e-mails/sites de phishing, les utilisateurs finissent par ne plus faire confiance à la formation de détection du phishing elle-même
- L’idée que « cela ressemble à du spam, mais c’est peut-être quand même légitime » se propage
- Par le passé, cette banque a déjà envoyé des SMS officiels contenant des formulations et des domaines suspects (par exemple un lien vers paperless.io)
- Même le centre d’assistance ne comprend pas pourquoi cela peut ressembler à du spam
Chapitre 3 : quelle solution ?
- La solution la plus sûre consiste à implémenter directement la procédure de participation dans l’application
- Si cela est inévitable, il faut utiliser le domaine officiel (par exemple
sparkasse.de) ou un sous-domaine de chaque agence afin de préserver la fiabilité - Le gouvernement allemand a également renforcé la confiance dans ses services dans un cas similaire en adoptant la politique de marque numérique gov.de
Chapitre 4 : quand la négligence peut devenir un problème juridique
- Les décisions de justice récentes imposant aux banques d’indemniser des victimes de phishing sont en augmentation
- Dans l’évaluation de la « négligence » en cas de fuite d’informations personnelles, les tribunaux concluent à la responsabilité de la banque lorsqu’aucune faute de l’utilisateur n’est établie
- Si une attaque de phishing était menée avec une structure d’e-mail/site comme celle-ci, il serait difficile pour la banque de prouver que la victime n’a pas été suffisamment prudente
- Le niveau de ressemblance entre les véritables e-mails/sites officiels de la banque et le phishing accroît le risque juridique
Conclusion
- Si la sécurité technique progresse, la sécurité de l’expérience utilisateur (USABLE SECURITY) présente encore de sérieuses failles
- De tels cas sapent la confiance dans la sensibilisation anti-phishing elle-même et nuisent à la fois à la charge juridique des banques et à l’ensemble du secteur financier
- Le problème est un problème structurel de système qu’il est difficile de résoudre par de simples retours individuels
- Il faut prendre encore plus au sérieux le fait que ce type de problème survienne même dans l’un des plus grands groupes financiers d’Europe
- La leçon finale pourrait se résumer ainsi : « Ne sabotez pas la sensibilisation à la sécurité. Faites au moins un peu attention. »
2 commentaires
On dirait que ce sentiment de déjà-vu n’est pas une illusion 🤣
Avis Hacker News
Ma banque utilise un système de détection de fraude qui m’appelle lorsqu’une activité suspecte est détectée sur mon compte, puis me demande de rappeler un numéro précis ; le problème, c’est qu’elle me donne un numéro de rappel différent à chaque fois. Si je cherche ce numéro en ligne, je n’obtiens qu’un seul résultat : la page officielle du système de détection de fraude, qui dit de ne faire confiance à aucun appel téléphonique (ce conseil est pertinent, mais il signifie ironiquement qu’il faut aussi ignorer leurs propres contacts légitimes).
La seule fois où j’ai vu le système antifraude se déclencher sur ma carte, j’ai reçu un SMS de la banque disant : « Votre carte a été bloquée pour utilisation suspecte, veuillez appeler le numéro suivant ». Ce numéro aussi était un numéro non répertorié attribué de façon aléatoire. La seule raison pour laquelle je ne l’ai pas ignoré, c’est que je venais justement d’effectuer un paiement sur un nouveau site web. J’ai donc appelé directement mon agence locale pour vérifier que c’était réel, et on m’a confirmé que oui. J’ai failli me lancer dans une tirade sur à quel point cette procédure est nulle.
On dirait qu’il n’y a personne chargé de l’ensemble du parcours UX dans la banque. La mienne fonctionne aussi de façon bizarre : par exemple, chaque fois que je fais un virement à ma femme, on me fait confirmer plusieurs questions « pour éviter la fraude », puis une fois que j’y ai répondu, un message apparaît encore pour dire en substance : « Comme vous faites souvent ce virement, nous ne vous demanderons pas de code 2FA ni d’authentification supplémentaire ». Ce genre d’UX absurde vient probablement du fait qu’aucune personne ni équipe ne supervise le flux dans son ensemble.
Les banques ne respectent même pas leurs propres règles. Une fois, la banque m’a appelé au sujet d’un changement d’assurance que j’avais demandé un mois plus tôt, et on m’a demandé de m’authentifier avec mon dongle de sécurité. Avec ce genre de pratiques, il n’y a rien d’étonnant à ce que les gens se fassent arnaquer.
La banque où je travaille envoie des SMS pour demander : « Avez-vous émis un chèque de $x ? » afin de vérifier s’il y a une anomalie. Le problème, c’est que l’arnaque au chèque la plus courante est le « check washing », où le montant reste identique mais le bénéficiaire est falsifié. Dans ce cas, la transaction paraît légitime tant que le montant correspond, mais il n’y a aucun moyen de vérifier à qui l’argent a réellement été versé.
Même quand j’appelle le numéro général de la banque, que j’attends longtemps et que j’arrive enfin à parler à un conseiller, on me dit qu’ils ne reconnaissent pas ce numéro, alors que c’est bien le bon. C’est encore plus pénible avec une banque que je n’utilise pas : si j’appelle le numéro affiché sur son site, je tombe directement sur un système de réponse automatique, et sans numéro de compte il est impossible d’aller plus loin ; je dois donc trouver un autre numéro pour pouvoir parler à quelqu’un.
Ma banque (USAA) a déjà mis en place des choses que j’avais suggérées. Mais récemment, j’ai reçu un e-mail en apparence légitime sur mon adresse e-mail unique, sauf que le domaine n’était pas celui qu’ils utilisent d’habitude (ce qui était d’autant plus suspect que je venais justement d’effectuer une démarche). J’ai immédiatement appelé la banque et parlé à quelqu’un du service fraude ; j’ai expliqué le problème en disant soit que leur système interne avait été compromis, soit qu’ils habituent insidieusement leurs clients au phishing, et j’ai demandé qu’un ticket soit créé. La personne m’a assuré que ce domaine n’appartenait pas à USAA et qu’ils n’utilisaient que usaa.com, puis a verrouillé mon compte sans autre forme d’explication. J’ai finalement dû rappeler pour le faire déverrouiller, et on m’a dit qu’un ticket avait bien été créé. Il faudra voir la suite.
Les pratiques techniques et marketing des banques en matière d’expérience utilisateur sont catastrophiques. Tous les formulaires de connexion des banques indiennes que j’ai utilisés sont
Interdiction de dépasser 15 caractères ?! Ma banque exige exactement 6 chiffres. Pas des lettres, obligatoirement des chiffres. Impossible d’utiliser un gestionnaire de mots de passe, impossible de copier-coller, il faut cliquer à la souris sur les cases numériques. À force d’obsession pour la « sécurité », leur second facteur est passé d’un token physique à une app, puis finalement à du SMS. Et ce n’est pas une petite banque de quartier : c’est l’une des plus grandes banques de France.
Il y a quelques semaines, une capture d’écran d’une banque publique indienne dont l’application bloquait l’utilisateur simplement parce qu’il avait installé Firefox a circulé sur Reddit et a déclenché une polémique. Les banques et les sites gouvernementaux sont extrêmement hostiles aux utilisateurs ; autrefois, je pensais que cette approche visait à protéger les personnes peu à l’aise avec la technologie, mais je pense désormais que c’est surtout une excuse pour éviter d’adopter des frameworks à la fois sûrs et pratiques.
Certaines applications de banques publiques indiennes refusent même de se lancer si l’on n’accorde pas des permissions prétendument indispensables comme l’accès à la caméra ou à tout le système de fichiers. En revanche, je n’ai jamais reçu de spam du type décrit par l’OP de la part de ma banque. Cela dit, dans l’opinion publique, on entend souvent dire que des employés subalternes revendent régulièrement des informations de compte à des escrocs.
Ma banque m’oblige à changer de mot de passe tous les 180 jours, n’autorise que des mots de passe de 6 à 11 caractères et impose une liste précise de caractères autorisés. Du coup, quand j’essaie de me connecter, on me force encore à le modifier, et les mots de passe générés automatiquement par Firefox ne respectent pas les règles de la banque ; je me retrouve donc à devoir générer moi-même un mot de passe aléatoire dans le terminal qui satisfasse leurs contraintes.
Je ne vois pas vraiment en quoi utiliser un hash de mot de passe côté client pose problème.
C’est encore pire lors d’un achat immobilier. Il y a énormément d’entités différentes, chacune avec son propre domaine, etc. J’ai aussi déjà dû faire confiance à un domaine suspect dans le cadre d’un rappel de dispositif médical. Ce problème pourrait être résolu simplement en publiant sur le site principal une liste des domaines partenaires de confiance. Mon protocole de sécurité personnel consiste à chercher les coordonnées de l’établissement financier sur un site en .gov, puis à appeler le service client via le domaine trouvé pour demander quels sont les véritables domaines de confiance. Les conseillers me prenaient souvent pour quelqu’un de bizarre. Un jour, l’un d’eux m’a même dit : « Si LinkedIn indique que cette personne travaille chez <Bank Name>, alors vous saurez qu’elle est légitime. »
Quand on m’a dit « si LinkedIn indique que <Bank Name> est son employeur, vous pouvez lui faire confiance », j’ai répondu : « Donnez-moi deux minutes et je peux mettre la même chose sur mon propre profil ; vous me confierez vos données personnelles dans ce cas ? »
J’ai aussi eu une expérience d’achat immobilier qui n’avait rien de compliqué. J’étais passé par un courtier pour mon prêt hypothécaire et je n’avais affaire qu’à une seule personne en direct.
Les personnes naïves qui ont le pouvoir de décider ne perçoivent pas correctement ce type de risque, jusqu’à ce qu’elles-mêmes ou quelqu’un de leur entourage soient victimes d’une arnaque ou d’un problème juridique. Aux États-Unis aussi, avant 2012, beaucoup d’entreprises étaient dirigées par ce genre de profils, mais avec la diffusion rapide du hacking white hat/black hat, ces problèmes ont été réglés relativement vite.
J’ai travaillé autrefois dans une société financière où la culture de la sécurité informatique était très solide. Après son rachat, toutes sortes de demandes ont commencé à arriver par e-mail depuis des prestataires externes au nom de dirigeants du siège. Or, selon notre politique de sécurité d’origine, il était interdit de traiter ce type de messages ; sur Slack, tout le monde s’est donc mis d’accord pour dire que, même si ces e-mails étaient authentiques, il fallait systématiquement les signaler comme phishing conformément à la politique. C’était de la non-coopération sans malveillance, mais en réalité c’était la bonne pratique. Ensuite, un dirigeant du siège a commencé à envoyer des messages préalables du genre : « Vous allez recevoir ce type d’e-mail, merci de réagir ainsi. » Alors entre collègues, on a recommencé la même discussion : « Et comment sait-on que cet e-mail d’avertissement est lui-même authentique ? » À la fin, tout le monde s’est lassé et a fini par accepter les pratiques de sécurité plus laxistes du siège.
Dans ce type d’organisation, je pense qu’il existe une structure sociale qui empêche les personnes compétentes et capables de prendre les bonnes décisions d’accéder à des postes où elles auraient réellement le pouvoir de décider. Pour élaborer de bonnes politiques, il faut souvent dire « non » à beaucoup de monde, et dans ce processus, le plus difficile est justement de ne pas contrarier les personnes qui ont le pouvoir de nomination.
Il y a sur le papier tout un cortège de CISO, EVP, SVP, directeurs sécurité et autres postes élevés, et pourtant je ne comprends toujours pas pourquoi on prend des décisions aussi aberrantes. Dans ces cas-là, il est difficile de distinguer l’incompétence de la malveillance. Parler de « naïveté » ressemble presque à une excuse pour des comportements qui méprisent les clients. Investir dans la sécurité coûte de l’argent, ne pas investir coûte aussi cher, mais pour l’instant il semble que la perte liée au départ des utilisateurs reste inférieure au coût de faire les choses correctement et de manière sûre ; c’est sans doute pour cela que ces pratiques perdurent. En fin de compte, c’est une triste réalité pour tout le monde.
Ma banque m’appelait souvent au hasard pour du marketing, et avant même de m’exposer son offre, me demandait ma date de naissance et le nom de jeune fille de ma mère. Quand je leur retournais la question en disant : « Commencez d’abord par prouver que vous êtes bien ma banque », ils semblaient toujours déstabilisés.
Quand quelqu’un m’appelle d’un numéro inconnu pour me demander de confirmer mes informations personnelles, je réponds toujours : « Je ne sais pas qui vous êtes, donc je ne peux pas vous donner d’informations personnelles. » En général, la moitié raccroche simplement ; l’autre moitié enchaîne directement sur son argumentaire commercial.
Je vis exactement la même chose très souvent dans le médical. Le secrétariat d’un spécialiste m’appelle et la première chose qu’on me demande est ma date de naissance ; quand je refuse, la personne est très surprise. Pour moi aussi, si c’est eux qui appellent, c’est à eux de commencer par prouver leur identité.
Ma banque a fini par comprendre cela et a désormais mis en place un système où l’application permet de vérifier que le conseiller est bien en train de faire de la prospection commerciale et d’identifier exactement de quel employé il s’agit.
Si l’idée du « sous-domaine enregistré » est apparue comme solution, c’est parce que quelqu’un à l’IT savait que déléguer des droits à coups de sous-domaines était risqué et l’a refusé. Du coup, d’autres services de l’entreprise, comme le marketing, contournent le problème en enregistrant leurs propres domaines séparément. Je me demande comment des entreprises comme Google gèrent ça. Le détournement d’un sous-domaine de google.com serait une cible extrêmement alléchante, et pourtant Google utilise lui aussi assez souvent des sous-domaines. Voir à ce sujet ce gist.
En pratique, ça ne remonte souvent même pas jusqu’à l’IT. Le marketing est structurellement séparé de l’IT et n’a pas envie de passer par lui. L’IT travaille avec un système de tickets inefficace et lent, et a souvent des avis inutiles à donner, donc le marketing considère cela comme une corvée. Les promotions marketing sont donc confiées à des services SaaS ou à des prestataires externes, qui n’ont eux-mêmes aucun lien avec l’IT de l’entreprise. Les responsables marketing ne savent même pas ce qu’est un sous-domaine ; ils travaillent via recherche Google ou clic sur des liens, point final. Personne ne regarde le texte des URL, donc personne ne perçoit pourquoi un sous-domaine serait important. Quand on observe les usages réels d’Internet, la formation traditionnelle anti-phishing est sans effet : « lire attentivement le domaine » est moins réaliste que « faire une recherche Google puis cliquer sur le premier résultat » comme pratique de défense contre le phishing.
Google n’est pas moins exaspérant sur ce point. Ses e-mails d’information ont un format qui peut facilement être pris pour du phishing, et ils annoncent des choses en utilisant toutes sortes de domaines bizarres en plus de google.com, comme goo.gl ou foobar.google. L’époque où l’on faisait confiance naïvement à ce genre de choses est révolue depuis longtemps.
Pour moi, le point clé est dans le chapitre 4. Si une banque envoie à ses clients des e-mails qui ressemblent à du phishing, cela devrait constituer une faute grave engageant sa responsabilité juridique.
C’est un exemple très concret de la loi de Conway à l’œuvre. Le service marketing a sa propre IT, séparée de celle qui gère le site central. Résultat : ils ne peuvent pas développer ensemble sur le même domaine web, et lancent donc des sites distincts, avec des expériences distinctes.
Dans l’entreprise où travaille un ami, le CISO envoie une newsletter sécurité à tous les employés, mais elle part d’un domaine externe au lieu du domaine interne, et les liens pointent aussi vers une plateforme d’hébergement externe plutôt que vers un site maison, ce qui lui donne toujours l’apparence d’un e-mail de phishing. Quand il y a en plus un concours avec des cadeaux, cela semble encore plus faux (vu la réputation de l’entreprise, de tels lots généreux paraissent invraisemblables).