Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Une nouvelle technique pour le vol de données personnelles : Le "in-session phishing" ou les "pop-ups vicieuses"

Une nouvelle technique pour le vol de données personnelles : Le "in-session phishing" ou les "pop-ups vicieuses"
2009-01-172013-02-11bonnes pratiquesfr
Les attaques de hameçonnage (phishing) utilisent généralement le mail comme vecteur d'attaque : L'attaquant envoie des messages usurpant l'identité et le look&feel d'une banque ou autre organisme afin d"inciter les personnes peu soupçonneuses à cliquer sur un lien ; ce dans le but de...
Publié le 17 Janvier 2009 par Jean-François Audenard dans bonnes pratiques

Les attaques de hameçonnage (phishing) utilisent généralement le mail comme vecteur d'attaque : L'attaquant envoie des messages usurpant l'identité et le look&feel d'une banque ou autre organisme afin d"inciter les personnes peu soupçonneuses à cliquer sur un lien ; ce dans le but de collecter des informations personnelles de connexion.

L'une des variantes, connue sous le terme de "spear-phishing" se base sur le même principe de fonctionnement (envoi d'un mail avec un lien) mais vise une population de personnes plus ciblée ; donc avec potentiellement plus de victimes à la clef...

La créativité et l'adaptabilité aidant, une nouvelle technique baptisée "in-session phishing" vient d'être identifiée par des experts en sécurité de la société Trusteer. Au vu des informations à ma disposition, celle-ci serait d'une efficacité redoutable... Son principal défaut est quelle repose sur un ensemble de facteurs que l'attaquant ne maitrise pas totalement. Elle n'en reste pas moins des plus pernicieuse.

Je vous propose d'en découvrir les principales caractéristiques.

Vu d’un utilisateur lambda, une attaque de "in-session phishing" se matérialise sous la forme d’une fenêtre "pop-up" apparaissant lors de la consultation d’un site de banque en ligne. Cette pop-up l’invitant bien entendu à saisir des identifiants de connexion (login/passord) pour X ou Y bonnes raisons plus vraisemblables les unes que les autres.

Une personne même un peu soupçonneuse tombe aisément dans le panneau... redoutable...

Comment cela est-il possible ? Quels sont les principes de fonctionnement d’une telle attaque ? Quel comportement adopter pour s’en protéger ?

Cette attaque de "in-session phishing" s’appuie sur trois grands "fondamentaux"

  1. L’utilisateur accède simultanément à deux sites Internet, le 1er son site bancaire et un autre site.
  2. Il est possible pour un script Javascript d’une fenêtre/onglet d’identifier si un site donné est accédé simultanément dans un autre onglet.
  3. L’autre site que celui de la banque (disons pour simplifier un forum de discussion) permet l’injection de code JavaScript (Faille de Cross-Site Scripting ou XSS par exemple).

Un attaquant va monter une attaque de "in-session phishing" selon le scénario suivant :

  • Il injecte du code malicieux dans le forum de discussion. Ce code "surveille" si le site de certaines banques est simultanément accédé sur un autre onglet du navigateur.
  • Si c’est le cas, le script ou code malicieux fait apparaitre une fenêtre pop-up indiquant à l’utilisateur que sa session va bientôt expirer (par exemple) et qu’il lui faut ressaisir son login et mot de passe.
  • .... et hop, c’est dans la poche : Voici vos identifiants de connexion sont désormais connus par un sombre groupe de personnes malintentionnées.

Comment se protéger de ce type d’attaques ?

  • Ne consultez pas simultanément votre compte bancaire et d’autres sites.
  • Restez en alerte : Les fenêtres pop-up ne sont plus légion depuis pas mal de temps... bloquez-les, même pour vos sites de confiance.

Quelques liens pour en savoir sur le "in-session attack"

[1] Trusteer, Research, Attacks techniques, In-Session Phishing (PDF)


[2] CircleID, Phishers Using New Web-Based Technique ‘In-Session Phishing’ to Steal User Data, Researcher Warn, January 16, 2009


[3] DarkReading, New Phishing Attack Targets Online Banking Sessions With Phony Popups, January 13, 2009

5 Commentaires

  • 20 Janvier 2009
    2009-01-20
    par
    Florent
    Il me semblait justement que chrome utilisait des processus différents par onglet...
    Dans mes vieux stocks j'ai bien une attaque même pas en javascript qui permet de connaître l'historique du navigateur.
    C'est simplement en css avec détection des liens utilisés : http://ha.ckers.org/weird/CSS-history.cgi
    Après il faut en plus que le site victime ait une faille XSS pour faire croire que c'est lui qui ouvre une pop-up... Ce n'est pas non plus une super bidouille qui permet à du javascript de s'exécuter un autre onglet...
    Bref le seul truc nouveau c'est la détection plus efficace des sites ouverts en simultanée... Mais reposant sur javascript.

    En gros c'est pour rendre moins suspect l'attaque. Car du XSS on sait faire et on sait même faire du CSRF dans certaines autres situations (dans certains cas changer le mot de passe de l'utilisateur...).
  • 19 Janvier 2009
    2009-01-20
    par
    Vince
    Malgré la faible portée d'une telle annonce dans la "sphère médiatique grand public" (ce qui est regrettable), on ne peut que conseiller aux utilisateurs non avertis les quelques règles de base suivantes:
    - utiliser des outils de blocage de popups
    - utiliser des outils de blocage de fishing
    - nettoyer toutes traces de surf à la fermeture de son navigateur (cookies, fichiers temporaires, historique ...)
    - lancer une session "propre" et unique lorsque l'on se connecte sur un site sensible comme sa banque
    - utiliser (si il est disponible) le mode de connexion "privée" de son navigateur (IE8, FFX3.1)
  • 19 Janvier 2009
    2009-01-20
    par
    Vince
    Amit Klein (Trusteer's chief technology officer) prétend avoir trouvé un moyen de savoir si l'utilisateur est connecté ou non sur un site web, en utilisant une fonction Javascript particulière.
    Cependant, Amit Klein ne souhaite pas divulguer le nom de cette fonction afin de ne pas donner lieu à la sortie d'"exploits", mais il est en contact avec les dévelopeurs de navigateurs web afin que ces derniers soient rapidement patchés.
  • 19 Janvier 2009
    2009-01-20
    par
    Effectivement, si un onglet/page d'un navigateur n'a aucune visibilité sur la page accédée sur un autre onglet ou page, alors cette attaque se retrouve quasiment contrée car dans un tel contexte, l'attaquant est obligé de travailler en aveugle.
  • 18 Janvier 2009
    2009-01-20
    par
    Eric
    Si les navigateurs fournissent un patch pour bien assurer l'étanchéité entre onglets, le pb de ne pose plus... Dans le doc il est fait référence à une fonction javascript commune à tous les navigateurs... Mais pas plus d'infos...

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage