Efficacité des images de sécurité
Les images de sécurité telles que celles présentées lors de la connexion aux banques offrent-elles des avantages tangibles en matière de sécurité, ou sont-elles principalement du théâtre?
D'après ce que je comprends, si quelqu'un hameçonne vos utilisateurs, il est également trivial pour eux de mandater les demandes de vos utilisateurs vers votre site Web authentique et de récupérer l'image de sécurité avec les informations d'identification que l'utilisateur fournit avant de recevoir l'image (par exemple, le nom d'utilisateur). Si tel est le cas, les images de sécurité semblent ne fournir aucune sécurité supplémentaire et peuvent en fait être nuisibles si elles aident à convaincre les utilisateurs qu'un site Web malveillant est légitime.
Suis-je en train de manquer quelque chose?
Grande question! En l'occurrence, je peux présenter des données expérimentales sur cette question - et les données sont fascinantes. (J'ai remarqué que certaines des réponses contiennent des spéculations des premiers principes sur le niveau de sécurité qu'offrent ces images de sécurité. Cependant, les données s'avèrent avoir des surprises pour nous tous!)
Méthodologie expérimentale. Les "images de sécurité" ont été évaluées dans une étude d'utilisateurs, menée auprès d'utilisateurs ordinaires qui ont été invités à effectuer des opérations bancaires en ligne dans le laboratoire. À leur insu, certains d'entre eux ont été "attaqués" de manière contrôlée, pour voir s'ils se comportaient en toute sécurité ou non et si les images de sécurité étaient utiles ou non.
Les chercheurs ont évalué deux attaques:
Attaque MITM: les chercheurs ont simulé une attaque d'homme au milieu qui supprime SSL. La seule indication visible de l'attaque est l'absence d'un indicateur HTTPS (pas de HTTPS dans la barre d'adresse, pas d'icône de verrouillage, etc.).
Attaque d'image de sécurité: les chercheurs ont simulé une attaque de phishing. Dans cette attaque, il semble que les utilisateurs interagissent avec le vrai site bancaire, sauf que l'image de sécurité est manquante. À sa place, l'attaque place le texte suivant:
Avis de maintenance de SiteKey: Bank of America met actuellement à jour notre fonctionnalité primée SiteKey. Veuillez contacter le service client si votre SiteKey ne réapparaît pas dans les prochaines 24 heures.
Je trouve que c'est une attaque brillante. Plutôt que d'essayer de comprendre quelle image de sécurité afficher à l'utilisateur, ne montrez aucune image de sécurité du tout et essayez simplement de persuader l'utilisateur qu'il est OK qu'il n'y ait pas d'image de sécurité. N'essayez pas de vaincre le système de sécurité là où il est le plus fort; juste contourner la chose entière en sapant sa fondation.
Quoi qu'il en soit, les chercheurs ont ensuite observé comment les utilisateurs se comportaient lorsqu'ils étaient attaqués de cette manière (à leur insu).
Résultats expérimentaux. Les résultats? Les attaques ont été incroyablement réussies.
Aucun utilisateur n'a évité l'attaque MITM; chacun qui a été exposé à l'attaque du MITM est tombé pour lui. (Personne n'a remarqué qu'ils étaient attaqués.)
97% des personnes exposées à l'attaque d'image de sécurité sont tombées dans le piège. Seulement 3% (2 participants sur 60) se sont comportés en toute sécurité et ont refusé de se connecter lorsqu'ils ont été touchés par cette attaque.
Conclusions. Permettez-moi de tirer quelques leçons de cette expérience.
Tout d'abord, les images de sécurité sont inefficaces. Ils sont facilement vaincus par des techniques d'attaque très simples.
Deuxièmement, lors de l'évaluation des mécanismes de sécurité efficaces, nos intuitions ne sont pas fiables. Même les professionnels de la sécurité experts peuvent tirer des conclusions erronées. Par exemple, regardez ce fil, où certaines personnes ont estimé que les images de sécurité ajoutent une certaine sécurité car elles obligent l'attaquant à travailler plus dur et à mettre en œuvre une attaque MITM. De cette expérience, nous pouvons voir que cet argument ne tient pas la route. En effet, une attaque très simple (cloner le site Web et remplacer l'image de sécurité par un avis indiquant que la fonction d'image de sécurité est actuellement hors service pour maintenance) est extrêmement efficace en pratique.
Ainsi, lorsque la sécurité d'un système dépend du comportement des utilisateurs, il est important de mener des expériences rigoureuses pour évaluer le comportement réel des utilisateurs ordinaires dans la vie réelle. Nos intuitions et nos analyses "des premiers principes" ne remplacent pas les données.
Troisièmement, les utilisateurs ordinaires ne se comportent pas comme les gens de sécurité souhaitent parfois. Parfois, nous parlons d'un protocole comme "l'utilisateur fera telle ou telle chose, alors le serveur fera telle ou telle chose, et si l'utilisateur détecte une déviation, l'utilisateur saura qu'il est attaqué". Mais ce n'est pas ce que pensent les utilisateurs. Les utilisateurs n'ont pas l'état d'esprit suspect que les gens de la sécurité ont, et la sécurité n'est pas au premier plan de leur esprit. Si quelque chose ne va pas, un expert en sécurité peut soupçonner qu'elle est attaquée - mais ce n'est généralement pas la première réaction d'un utilisateur ordinaire. Les utilisateurs ordinaires sont tellement habitués au fait que les sites Web sont floconneux que leur première réaction, en voyant quelque chose d'étrange ou d'inhabituel, est souvent de le hausser et de supposer que l'Internet (ou le site Web) ne fonctionne pas tout à fait correctement au moment. Donc, si votre mécanisme de sécurité compte sur les utilisateurs pour devenir suspects si certains indices sont absents, c'est probablement pour des raisons précaires.
Quatrièmement, il n'est pas réaliste de s'attendre à ce que les utilisateurs remarquent l'absence d'indicateur de sécurité, comme une icône de verrouillage SSL. Je suis sûr que nous avons tous joué "Simon Says" quand j'étais enfant. Le plaisir du jeu est tout à fait que - même lorsque vous savez faire attention - il est facile de passer outre à l'absence du signal "Simon Says". Pensez maintenant à une icône SSL. La recherche de l'icône SSL n'est pas la tâche principale de l'utilisateur lorsqu'il effectue des opérations bancaires en ligne; au lieu de cela, les utilisateurs veulent généralement simplement payer leurs factures et faire la corvée afin de pouvoir passer à quelque chose de plus utile. Combien il est plus facile de ne pas remarquer son absence, dans ces circonstances!
Soit dit en passant, vous vous demandez peut-être comment le secteur bancaire a réagi à ces conclusions. Après tout, ils soulignent leur fonctionnalité d'images de sécurité (sous différents noms marketing) aux utilisateurs; Alors, comment ont-ils réagi à la découverte que la fonction d'image de sécurité est pratiquement inutile dans la pratique? Réponse: ils ne l'ont pas fait. Ils utilisent toujours des images de sécurité. Et si vous leur posez des questions sur leur réponse, une réponse typique a été quelque chose de la forme "eh bien, nos utilisateurs aiment et apprécient vraiment les images de sécurité". Cela vous dit quelque chose: cela vous dit que les images de sécurité sont en grande partie une forme de théâtre de sécurité. Ils existent pour que les utilisateurs se sentent bien dans le processus, plus que pour se protéger réellement contre les attaques graves.
Références. Pour plus de détails sur l'expérience résumée ci-dessus, lisez le document de recherche suivant:
- Les nouveaux indicateurs de sécurité de l'empereur . Stuart E. Schechter, Rachna Dhamija, Andy Ozment et Ian Fischer. Sécurité et confidentialité IEEE 2007. (modifier: lien mis à jour )
Je ne considère pas leur sécurité particulièrement élevée; mais ils sont plus qu'un simple théâtre de sécurité. Ils peuvent potentiellement rendre le travail de l'attaquant plus difficile et le travail d'un expert en sécurité judiciaire pour détecter les anomalies.
Disons qu'il n'y a pas d'image/phrase de sécurité ou équivalent. Ensuite, un attaquant man-in-the-middle peut construire une fausse version du site Web pour capturer les informations d'identification des utilisateurs sans méfiance sans qu'aucun drapeau rouge n'apparaisse. (En supposant qu'ils peuvent faire remarquer à l'utilisateur le manque de https dans leur banque ou avoir installé un certificat fradualent dans le navigateur Web de l'utilisateur).
Analysons maintenant le schéma utilisé par ma banque (ING), où chaque fois que je m'inscris à partir d'un nouveau navigateur, je tape d'abord mon nom d'utilisateur, la banque répond "Hi jim bob", veuillez répondre à deux questions de sécurité (aléatoires) liste d'environ 5) car vous n'avez jamais utilisé cet ordinateur auparavant. Ces questions sont une entropie quelque peu faible, mais il faudrait tout de même me connaître ainsi que mes antécédents familiaux pour être correct; ou envoyer ces questions par proxy à mon ordinateur. Ensuite, il me montre mon image de sécurité et demande mon mot de passe.
Alors maintenant, l'homme au milieu de l'attaque doit être actif (puis un faux serveur qui attend toujours que les utilisateurs donnent des informations d'identification qui imitent parfaitement un faux site). Tout d'abord, je pense peut-être qu'il est suspect que je doive saisir à nouveau mes questions de sécurité lorsque cela provient de mon ordinateur normal. Maintenant, le MitM doit interroger la banque réelle pendant l'attaque pour trouver d'abord les deux questions aléatoires récupérées pour mon compte, me les renvoyer sans faire de bruit et enregistrer mes réponses, puis renvoyer mes réponses à la vraie banque via leur connexion https à saisir l'image de sécurité.
Ensuite, l'attaquant doit saisir l'URL de l'image de sécurité ou la télécharger lui-même, puis la télécharger sur son serveur Web intermédiaire pour que je puisse la télécharger à partir d'eux. Cela pourrait être suspect si disons qu'ils venaient de récupérer l'URL de l'image de sécurité, de sorte qu'une autre IP a visualisé l'image de sécurité puis avait établi une connexion https à leur site Web pour tout le reste. Ou si les attaquants l'ont téléchargée et affichée à nouveau, maintenant l'adresse IP des attaquants a été exposée et ils peuvent être en mesure d'obtenir le blocage/arrêt de cette adresse IP contrôlée par malveillance.
Pourrait-il être contourné, certainement oui. Mais ce n'est pas seulement un théâtre de sécurité et pourrait être une partie utile de la défense en profondeur avec https. Plus j'y pense, plus je pense que c'est le principal argument de vente. Je ne remarquerai peut-être pas si ma banque n'était pas https si je suis pressé. Si vous êtes invité à saisir à nouveau mes questions de sécurité; Je peux faire une pause et vérifier que c'est https avec l'URL de la banque réelle (pas http ou quelque chose de similaire).
Si tel est le cas, les images de sécurité semblent ne fournir aucune sécurité supplémentaire,
Au lieu de tirer une copie statique de la page de connexion, les hameçonneurs doivent maintenant créer une page capable d'interagir avec le site Web d'origine.
Une hypothèse extrême est qu'ils sont extrêmement stupides et récupèrent les images personnalisées avec leur propre IP, ou une IP qui peut leur être liée.
Une hypothèse de stupidité moins extrême consiste à récupérer de nombreuses images personnalisées avec une ou plusieurs adresses IP différentes, ce qui pourrait éveiller les soupçons pour les adresses IP du FAI pas connu pour utiliser le NAT à grande échelle.
Mais les mêmes problèmes "IP d'origine" existent avec un phishing de type simple, avec la paire login/mot de passe ordinaire: la seule valeur de ces données collectées est qu'elles peuvent être utilisées pour se connecter sur le site d'origine. Les hameçonneurs ont toujours besoin d'un pool d'adresses IP "belles" s'ils ne veulent pas éveiller les soupçons (ce qu'est une adresse "belle" dépend sur la page Web et son public).
Pour le phishing bancaire, l'argent doit être transféré par "mules" vers des comptes intermédiaires . Les pêcheurs ont besoin non seulement d'adresses IP (un botnet peut les fournir), mais également de comptes bancaires intermédiaires. Les vraies personnes doivent fournir ces comptes.
Le phishing à grande échelle nécessite certainement une bonne planification, et procédures de sécurité strictes, car tôt ou tard, l'opération de pêche va être découverte et étudiée. Et quand c'est le cas, les personnes en charge de l'hameçonnage se soucient certainement de leur vie privée (introuvable).
Je ne connais pas les détails exacts de ces opérations, mais je ne pense pas que l'ajout de "télécharger l'image de sécurité" aura un effet dissuasif.
et peut en fait, être nuisible s'il aide à convaincre les utilisateurs qu'un site Web malveillant est légitime.
Oui en effet.
L'utilisateur moyen susceptible d'être victime de phishing est incapable de faire l'évaluation de sécurité appropriée du schéma. Presque tous ces utilisateurs surestimeront les avantages de la sécurité.
Et les utilisateurs vérifient-ils même l'image de sécurité?
C'est une tentative courageuse pour résoudre le problème de la confiance. SSL est idéal pour les ordinateurs pour établir la confiance, mais il n'a pas de sens pour les gens. Si vous pouvez penser à un meilleur moyen pour un site de prouver à un utilisateur non technique qu'il est ce qu'il semble être, je serais très intéressé d'en entendre parler.
Comme d'autres l'ont dit, ils placent un autre obstacle devant les hameçonneurs.
Mais par rapport à un site de phishing autonome, cela signifie que le véritable fournisseur de services a potentiellement une certaine visibilité sur l'activité; voir beaucoup de demandes pour différents utilisateurs à partir de la même adresse, suivies d'aucune autre interaction ou d'une interaction automatisée, devrait être assez visible.