Une nouvelle technique d'attaque : le "In-Session Phishing"

Le 29 décembre dernier la société Trusteer a publié un avis de sécurité concernant une nouvelle technique d'attaque. Celle-ci peut être réalisée contre la plupart des implémentations des moteurs JavaScript présentes dans les principaux navigateurs (Internet Explorer, Firefox, Safari, Chrome, etc.). Un bug de conception dans le moteur JavaScript permet à des personnes malveillantes de voler les informations de sessions (cookies, credentials, etc.), et peut être exploité pour abuser de services tels que ceux offerts par des banques en ligne (cf. veille média du 14/01/2009), de jeux en ligne, de réseaux sociaux ou encore de contourner des applications requérant une authentification. Ce nouveau type d'attaque est désormais appelé le « In-Session Phishing » ou « Phishing en cours de session ». Certains experts avancent que cette nouvelle technique signe la fin du « Phishing par email ». Pourquoi ?

"Phishing" versus "In-Session Phishing"

L'attaque par "Phishing" est désormais un grand classique du genre, tel que nous le connaissons aujourd'hui. Un email est envoyé à des victimes, les incitant par des moyens divers et variés à cliquer sur le lien malveillant inclus dans ce dernier. Le taux de réussite de cette attaque repose essentiellement sur le niveau de persuasion du contenu du mail et sur la crédulité de la victime. Ces facteurs sont difficilement mesurables par les pirates et de telles attaques nécessitent parfois des techniques complémentaires de "social engineering" et de connaissance des victimes pour réussir. De plus les liens malveillants utilisés sont désormais "bien" détectés par les mécanismes anti-phishing inclus dans les navigateurs, et la sensibilisation et la méfiance des utilisateurs rendent difficile le succès de ce Phishing traditionnel.

L'attaque "In-session Phishing" quant à elle, ne nécessite plus d'envoi d'emails incitant une victime à cliquer sur un lien malveillant. Les pirates n'ont plus à recopier les sites cibles (bancaires par exemple) et à les héberger chez des fournisseurs complaisants ou peu scrupuleux. Cette nouvelle technique ne nécessite qu'une navigation simultanée (navigation par onglet) sur un site bancaire et sur un site susceptible d'héberger du code malveillant.

Scenario d'une attaque "In-session Phishing"

Une attaque "In-session Phishing" peut se produire lorsque la victime est connectée (avec authentification) à une application de banque en ligne par exemple et qu'elle visite simultanément dans un autre onglet du navigateur, un site web compromis hébergeant du code malveillant, sans toutefois clore la session au site bancaire. Soudain, au cour de la navigation, un popup indiquant que la session a expiré demande à l'utilisateur de ressaisir son identifiant et son mot de passe de connexion au site bancaire. D'autres prétextes autres que l'expiration d'une session peuvent être utilisés, tels que répondre à une enquête de satisfaction ou encore participer à un jeu promotionnel.

Puisque l'utilisateur s'est déjà connecté et qu'il a probablement déjà effectué certaines opérations, il y a de fortes chances qu'il ne soupçonne pas que le popup puisse être frauduleux et qu'il ressaisisse les informations demandées pour ne pas perdre la session en cours.

Plusieurs conditions sont nécessaires pour que l'attaque réussisse :

• Un site web quelconque doit avoir été compromis (c'est lui qui servira à lancer l'attaque) et être visité par l'internaute.

•  Le code malveillant injecté dans ce site web compromis doit pouvoir identifier sur quels sites web navigue l'internaute et s’il est connecté sur l'un des sites cibles (banque en ligne, etc.).

•  Le site web pour lequel le pirate cherche à obtenir les identifiants de connexion d'une victime potentielle doit utiliser une fonction spécifique de JavaScript.

Bien que ces conditions soient requises, elles sont aisément remplies sur Internet.

En effet la première condition est "facilement" remplie puisqu'il existe des milliers de sites web susceptibles d'être compromis sur Internet (forum, etc.). La seconde également puisque les codes injectés peuvent être techniquement évolués et être en mesure de détecter les sites cibles visités. Enfin la troisième l'est aussi puisque les sites de banque en ligne, de financement en ligne, de jeux en ligne, voire également certaines applications nécessitant une authentification susceptible d'être prisée par un pirate, utilisent la fonction Javascript vulnérable.

Le code injecté dans le site compromis ne modifie pas l'apparence de ce dernier il est donc difficile de le détecter. Par contre le code malveillant doit être en mesure de détecter les sites de banques en lignes (par exemple) auxquels une victime serait susceptible d'être connectée. Ensuite il doit être en mesure de fournir un popup qui semble provenir du site de banque en ligne et qui incite la victime à fournir ses identifiants.

Le bug !

Le plus difficile pour l'attaquant est de produire un code malveillant qui puisse déterminer si sa victime est connectée ou non au site pour lequel il souhaite récupérer les identifiants de connexion. Une vulnérabilité dans l'implémentation de JavaScript, récemment découverte par la société Trusteer, permet à l'aide d'une fonction particulière de JavaScript, de déterminer si la victime est connectée à son site de banque en ligne par exemple. L'appel à la dite fonction laisse en mémoire une "empreinte" temporaire caractérisant la connexion de l'internaute au site cible. L'exploitation de cette empreinte permet au code malveillant de savoir si l'utilisateur est connecté et de lui envoyer un popup le cas échéant. Si l'internaute se laisse piéger, c'est lui qui fournit ses identifiants au popup (c'est-à-dire au code malveillant) en pensant les fournir au site sur lequel il se croit déconnecté.

Comment se protéger de ce type d'attaque ?

Les deux premières recommandations que l'on puisse faire sont des bonnes pratiques. La première consiste simplement à penser à se déconnecter dès que l'on n'a plus besoin d'accéder à un site en ligne (banque, finance, jeux, etc.) et ne pas attendre que la session expire. La seconde consiste à être extrêmement vigilant lors de toute apparition de fenêtre popup lors d'une session web alors qu'aucun lien n'a été cliqué. En effet, les fenêtres d'expiration n'apparaissent que lors d'un clic sur un lien d'un site sur lequel on est connecté, ou lors d'un rafraichissement d'une page déjà visitée, mais rarement lors d'une inactivité vis-à-vis de la session.

Enfin une autre recommandation consiste à utiliser un programme tel que NoScript (cf. l’article du Cert-IST intitulé « NoScript, l'extension sécurité incontournable de Firefox »), bien que celui-ci ne soit valable que pour Firefox. La fonction première de NoScript étant de bloquer le code JavaScript, il est fort probable qu'un site vulnérable et exploité par une telle attaque soit bloqué du fait de l'outil (exception faite si l'utilisateur a sciemment autorisé le JavaScript sur le site vulnérable).

Pour plus d'information :

Avis de sécurité Trusteer : In Session Phishing Attacks