Faire face aux attaques de surplus : adopter une sécurité intégrée pour protéger l'expérience mobile

Frederik Mennes, août 14, 2018

La croissance de la technologie mobile et l'importance accrue de la cybersécurité ont dominé les cycles de l'information au cours de la dernière année. Dans le même temps, l'une des plus grandes menaces que nous voyons contre les attaques mobiles sont les attaques de superposement - combinant l'ingénierie sociale avec les faiblesses inhérentes de sécurité trouvées dans les applications mobiles, ces attaques profitent des utilisateurs pour les inciter à partager des données sensibles.

Dans le passé, ces attaques ont été seulement repéré en Russie, mais nous avons vu les premiers exemples en Europe, tels que le malware Android MazarBot, et les États-Unis, et il ya probablement plus.

Alors, comment cela fonctionne-t-il? Que peut-on faire à ce sujet? Que peuvent faire les organisations et les institutions financières pour se prémunir contre ces attaques malveillantes?

Comprendre la menace et ce que cela signifie pour les applications bancaires mobiles

Dans la majorité des cas, les logiciels malveillants de superpose ment aux logiciels malveillants prennent la forme d'un cheval de Troie, et est téléchargé comme une application soi-disant légitime à partir d'un site Web légitime ou App Store. Il peut également être installé par téléchargements drive-by, ce qui signifie qu'un utilisateur n'aurait besoin que d'être sur une certaine page Web pour être compromis.

Comme expliqué sur Infosecurity Magazine, le malware est dormant sur les appareils infectés, en attendant qu'un utilisateur ouvre une application bancaire. Une fois que cela se produit, le malware pousse l'application légitime à l'arrière-plan, quelque chose que la plupart des applications ne serait pas détecter comme inhabituel par eux-mêmes. En d'autres termes, l'application ne saurait pas qu'elle a été poussée à l'arrière-plan et continuerait à fonctionner normalement, en acceptant les entrées des utilisateurs, même si un humain ne pouvait pas fonctionner l'application.

Simultanément, le malware crée une fenêtre qui imite l'apparence et la sensation de l'application qui a été affectée. Ainsi, à toutes fins utiles, l'utilisateur supposerait qu'ils étaient encore en interaction avec leur application bancaire mobile.

Parce que l'utilisateur n'est pas le plus sage, ils vont procéder à entrer des données sensibles tout en utilisant l'application bancaire comme d'habitude. Comme mentionné dans Infosecurity Magazine, cela pourrait être n'importe quoi à partir de mots de passe, codes, et les détails financiers. Ces informations sont ensuite volées par le malware, et pour aggraver les choses, les données sont modifiées de sorte que l'utilisateur envoie sans le savoir des transactions aux criminels derrière le malware.

Missing élément de média.

Traverser les frontières géographiques: BankBot

Un exemple récent de ce malware cheval de Troie est BankBot. Alors que des échantillons plus anciens de BankBot visaient principalement des institutions financières russes, en avril 2017, la société néerlandaise Securify est tombée sur un nouvel échantillon de logiciels malveillants, montrant que BankBot ciblait également les banques européennes et américaines.

De nouvelles itérations ont ciblé au moins 420 banques dans des pays comme l'Allemagne, la France, l'Autriche, les Pays-Bas, la Turquie et les États-Unis. BankBot, d'abord déguisé en application de prévisions météorologiques, puis en différentes applications vidéo, peut être téléchargé à partir de Google Play et incite les utilisateurs à renoncer à des noms d'utilisateur, mots de passe, codes pin, détails de carte, ainsi que l'interception de messages texte SMS.

Cela signifie qu'il peut intercepter le message texte envoyé par les applications bancaires pour autoriser les paiements. Malheureusement pour l'utilisateur, ce n'est que lorsque leurs soldes commencent à baisser, ou les transactions sont redirigées vers des comptes criminels, qu'ils réalisent que quelque chose ne va pas.

Prendre des responsabilités : développeurs ou fournisseurs ?

Alors, qui est responsable de la protection contre les attaques de la reïe mobile? Est-ce le développeur de l'application ou le fournisseur d'applications? Idéalement, ils devraient travailler ensemble, ce qui ferait en sorte que si les cybercriminels exploitent une faiblesse spécifique sur une application, il ne suffit pas de compromettre l'utilisateur.

L'application bancaire elle-même devrait avoir la sécurité intégrée dans qui détecte quand l'application a été poussée à l'arrière-plan et empêche l'utilisateur pour entrer tous les détails qui pourraient être sensibles. Cependant, les logiciels malveillants évoluent, il ya donc toujours le potentiel pour les faiblesses de la plate-forme inconnue à exploiter, qui est l'endroit où l'effort conjoint des développeurs et des fournisseurs devient d'autant plus important.

La solution : RASP et 2FA

La meilleure approche est la protection sophistiquée runtime Application Self-Protection qui intègre la sécurité multi-couches directement dans les applications mobiles. Ainsi, au lieu d'avoir seulement une couche de sécurité à percer, les pirates auraient besoin de compromettre de nombreuses couches qui sont difficiles à passer pour commencer.

RASP prend également en compte le comportement ainsi que les codes spécifiques, ce qui signifie qu'il a une plus grande capacité à prévenir les attaques de surpondérité. Cependant, pour être vraiment efficace, la solution RASP choisie ne devrait pas fournir une protection contre des échantillons de logiciels malveillants spécifiques (par exemple la dernière version du malware BankBot), mais plutôt contre plusieurs familles de logiciels malveillants, tels que BankBot, svpeng et Marcher. De nombreuses familles de logiciels malveillants utilisent des techniques similaires pour créer des surposes afin que les solutions génériques RASP fourniront plus qu'une protection adéquate.

Si cela est ensuite combiné avec l'authentification à deux facteurs, même si un pirate obtient des informations utilisateur, ils ne seront d'aucune utilité s'ils ont alors besoin d'un deuxième élément d'information. Cela pourrait être n'importe quoi d'un code unique, la possession d'un dispositif physique, l'authentification biométrique, et donc un.

De toute évidence, la technologie pour prévenir les attaques de surclassement existe déjà, mais la question de savoir qui prendra la responsabilité de s'assurer que tout fonctionne ensemble reste. Il y a tellement à gagner à intégrer la sécurité des applications, l'authentification à deux facteurs et toute autre solution qui assure la confiance et la tranquillité d'esprit des utilisateurs. Surtout pour les institutions financières qui ont le devoir de protéger les données et les actifs des clients. Lorsque vous considérez les grandes longueurs de ces organisations vont pour faire des assurances que leurs applications sont vraiment sûrs, ne devrait pas ces applications être aussi sûr qu'ils disent qu'ils sont?

Cet article, rédigé par Frederik Mennes, Senior Manager Market - Security Strategy, OneSpan Security Competence Center, a été publié pour la première fois dans InfoSecurity Magazine.

Frederik dirige le Security Competence Center de OneSpan, où il est responsable des aspects de sécurité des produits et de l'infrastructure de OneSpan. Il possède une connaissance approfondie des technologies d'authentification, de gestion des identités, de réglementation et de sécurité pour les applications cloud et mobiles.