Banking Fraud: Protéger les données bancaires avec la sécurité des applications

Il y a quelques semaines, IBM Trusteer a signalé une campagne de fraude massive contre les banques qui a entraîné des pertes de plusieurs millions de dollars. D’une part, les attaquants ont réussi à voler les identifiants de nombreux utilisateurs finaux. D’autre part, ils ont réussi à contourner le concept de gestion de la fraude des banques afin d’automatiser des millions de petites transactions qui peuvent passer inaperçues dans toutes les infrastructures d’analyse des risques et de sécurité et potentiellement passer inaperçues par l’utilisateur.

La première étape a apparemment été effectuée à l’aide d’une sorte d’attaque d’ingénierie sociale qui a installé des logiciels malveillants sur l’appareil de l’utilisateur. Dans la deuxième étape, cependant, les attaquants ont utilisé des émulateurs pour « tromper » les systèmes de gestion de la fraude des différentes banques. On peut en conclure que le système de gestion de la fraude n’a pas fait son travail correctement dans ce cas. Car cela consiste précisément à se prémunir contre des situations dans lesquelles les utilisateurs ont été trompés.

Identifier le point faible

Un système anti-femme devrait effectivement détecter les situations dans lesquelles un compte utilisateur a été utilisé sur un appareil autre que celui de l’utilisateur légitime. A typique de gestion de la fraude est lorsque le système remarque que l’utilisateur utilise un iPhone alors qu’il se connecte normalement à partir d’un appareil Samsung. Pour que les pirates réussissent à déjouer la solution anti-fraude, ils ont utilisé des émulateurs. Cela donne l’impression que l’appareil de l’utilisateur est utilisé, bien qu’en réalité ce n’était pas le cas.

Comme les chercheurs n’ont pas fourni suffisamment de détails, il n’est pas possible de déterminer clairement comment cela fonctionne. Corn on peut supposer que l’attaquant

  • a réussi d’une manière ou d’une autre à introduire des logiciels malveillants dans l’appareil de l’utilisateur (par exemple via une escroquerie par hameçonnage).
  • utilisé ce malware pour voler les informations de connexion et de périphérique et accéder aux SMS.
  • ont mis en place un schéma automatique avec les informations capturées qui
    a) a permis la création d’un émulateur qui (aux yeux du système anti-fraude) ressemble exactement à l’appareil d’un utilisateur.
    b) s’est connecté à l’application bancaire avec les données de connexion volées. L’appareil ressemblant à celui de l’utilisateur, le système anti-fraude n’a pas réagi.
    c) a permis l’exécution d’une petite transaction qui n’éveille pas de suspicion dans le système de la banque (et susceptible de passer inaperçue pour l’utilisateur).
    d) A pu répéter ces étapes des millions de fois en quelques jours, volant effectivement des millions de dollars.

Il y a plusieurs choses qui auraient pu être faites différemment dans ce scénario. Nous voulons nous concentrer principalement sur la façon dont les attaquants ont réussi à « falsifier » l’appareil ; ou, en d’autres termes, la force du mécanisme d’identification de l’appareil. Pour répondre à cette question, il est logique de se mettre à la place de l’attaquant.

L’étape pertinente pour « forger » l’appareil de l’utilisateur final consiste à collecter les informations correctes sur l’appareil à utiliser ultérieurement. La chose la plus importante que l’attaquant doit savoir est quelles informations le système de gestion de la fraude utilise pour identifier un appareil. En fin de compte, ce sont les informations que les pirates – avec l’aide du malware – doivent extraire de l’appareil final afin de pouvoir les falsifier.

Très probablement, le système de gestion de la fraude utilise de nombreuses valeurs différentes pour l’identification de l’appareil : certaines d’entre elles sont évidentes, d’autres moins. Parmi les valeurs évidentes figurent des éléments tels que le fabricant de l’appareil, le modèle de l’appareil, la version du système d’exploitation, l’ID Android (pour les appareils Android) ou l’IDFV (pour les appareils iOS). Cependant, ceux-ci ne sont pas si pertinents que n’importe quel système d’identification de périphérique les utiliserait.

La véritable force du système d’identification des appareils réside dans les identificateurs d’appareils moins évidents, en particulier le nombre d’entre eux utilisés et la qualité de leur protection. Ici, ce n’est pas si important quel paramètre est utilisé, mais combien il est difficile pour un attaquant de savoir qu’il est utilisé. En fin de compte, l’objectif de l’attaquant est d’écrire un logiciel malveillant qui collecte les paramètres – et c’est exactement ce qu’il faut empêcher.

Profiter de la faiblesse

La question est donc : comment un attaquant pourrait-il savoir quels ID d’appareil sont utilisés ?

  • L’approche la plus simple serait probablement d’espionner les informations transmises de l’application au backend à l’aide d’une attaque MITM. En analysant le trafic, l’attaquant obtiendrait une bonne compréhension des identifiants utilisés.
  • Une autre option serait de lire le code source de l’application pour trouver les routines qui collectent ces informations et les envoyer aux systèmes backend. Puisque l’attaquant n’a probablement pas le code source, l’alternative sera le fichier binaire décompilé. Ce n’est pas aussi utile que le code source, mais l’analyse statique peut en extraire beaucoup d’informations.
  • La dernière option et la plus difficile à la disposition du pirate informatique serait l’analyse dynamique. Des exemples en sont le débogage de l’application pendant son exécution et l’utilisation d’un framework d’accrochage comme Frida.

Cependant, toutes ces options ne doivent pas être remplies : l’attaquant n’a qu’à réussir avec l’une d’entre elles pour mener à bien l’attaque entière. Les solutions qui empêchent un seul des scénarios rendent la vie difficile à l’attaquant, mais ne l’empêchent pas de réussir.

Protégez correctement les applications

Avec tout cela à l’esprit, on peut dire qu’un concept d’identification d’appareil solide devrait :

  1. Utilisez beaucoup d’identifiants d’appareils non évidents. Plus il y a d’identifiants d’appareils, mieux c’est.
  2. Protection contre les attaques MITM. L’écoute du trafic réseau fournit beaucoup d’informations. Par conséquent, une bonne protection est indispensable à ce stade.
  3. Déguisez les parties sensibles du fichier binaire. Dans le cas des applications mobiles, les attaquants ont toujours accès au programme binaire. Par conséquent, un obscurcissement adéquat pour empêcher l’analyse statique est essentiel.
  4. Prévention de l’analyse dynamique. Si l’analyse statique ne suffit pas, les attaquants auront recours à l’analyse dynamique : débogage, instrumentation, modification de l’application, etc. Cela signifie que la protection contre les débogueurs, les frameworks de hooking et l’injection de code, entre autres, est également importante.

Dans une perspective plus large, on peut conclure qu’une protection adéquate des terminaux est indispensable pour les solutions de prévention de la fraude basées sur l’identification des appareils des utilisateurs finaux. Dans le cas contraire, les attaquants pourront alimenter des « fausses » données qui contournent les mécanismes de protection mis en œuvre dans le backend.