Risques bancaires ouverts

Les vagues de la tempête numérique couvrent de plus en plus de secteurs de l'économie, formant une nouvelle réalité. L'industrie financière n'a pas fait exception: les pays, l'un après l'autre, développent et mettent en œuvre une approche révolutionnaire du travail des établissements de crédit - le concept d'open banking ou d'Open Banking.

Open Banking est une interface logicielle unifiée avec les systèmes d'information bancaire. Il peut être utilisé par les développeurs d'applications financières, les sociétés de technologies financières, pour fournir aux clients des services financiers de nouvelle génération.

L'interaction avec les banques via une interface ouverte n'est pas seulement une opportunité, mais aussi un risque. Dans cet article, nous examinerons les risques et menaces qui découlent de la mise en œuvre de l'Open Banking et discuterons des options possibles de protection contre eux.

À propos des sociétés fintech

Malgré la volonté des banques de créer des produits financiers innovants, il leur est difficile de rivaliser à cet égard avec les sociétés fintech qui ne sont pas liées par les exigences du régulateur et du règlement intérieur. Et la concurrence entre les banques et le désir d'attirer des clients vers le service lui-même imposent des restrictions naturelles à la création de services qui intègrent les services de plusieurs établissements de crédit.

Les sociétés Fintech se comparent favorablement aux banques conservatrices. Ils peuvent se permettre d'attirer des clients de différentes banques, introduire rapidement de nouveaux produits non standard, en utilisant tous les avantages de l'indépendance vis-à-vis du régulateur.

La nature dynamique des sociétés financières et technologiques est dans une certaine mesure une conséquence de leurs caractéristiques organisationnelles. Une analyse des fournisseurs de technologies financières par Trend Micro en préparation de l'étude « Ready or Not for PSD2: The Risks of Open Banking » a montré que la plupart de ces entreprises:

• avoir un petit nombre d'employés;
• ressources financières limitées;
• utiliser activement l'infrastructure cloud pour le travail;
• appliquer la virtualisation et la conteneurisation des services;
• Utiliser des SDK tiers pour raccourcir le cycle de développement et se concentrer sur l'innovation;
• raccourcissez le cycle de test pour économiser du temps et de l'argent. Ce n'est pas surprenant. Cette approche est pratiquée dans le but de réduire les coûts, même par des géants comme Microsoft, qui a abandonné les testeurs à plein temps au profit des participants au programme Windows Insider.

Le revers de ces fonctionnalités est une vulnérabilité beaucoup plus importante par rapport aux banques. Avec le nombre croissant de pays introduisant l'Open Banking, le paysage des menaces se diversifie, les cybercriminels ayant à leur disposition de nouvelles cibles d'attaques. Parlons-en plus en détail.

Objectifs des attaques Open Banking

API publiques bancaires

L'API ouverte, mise en œuvre dans les banques européennes conformément à la PSD2 - la «Directive révisée sur les services de paiement» - n'est qu'un élément d'un grand processus. La mise en œuvre de telles interfaces de programmation a lieu dans de nombreux pays. Quelque part, ces travaux sont une initiative pour unir des entreprises privées et des banques. Par exemple, le développement de l'API Durable Data aux États-Unis est soutenu par l'association à but non lucratif FDX , une filiale du Financial Services Information Analysis Center (FS-ISAC) . D'autres gouvernements préfèrent avoir le contrôle total du processus, comme le Mexique, qui a adopté la loi Fintech , ou l'Australie, dans lequel l'accès des fintech aux interfaces de programmation bancaire n'est qu'une partie d'un large pool d'événements appelé Consumer Data Right .


La croissance des avalanches d'API financières introduites dans le monde. Source: Trend Micro

Une augmentation du nombre d'API de banque publique entraînera inévitablement une augmentation des tentatives d'utilisation à des fins lucratives. Pourquoi casser la protection de la banque s'il existe une interface à travers laquelle vous pouvez civiliser pour vous connecter à un système automatisé et vous transférer quelques millions?

Une étude de Trend Micro a révélé un nombre important de banques qui divulguent des informations confidentielles - mots de passe à usage unique, jetons d'accès, e-mails, IMEI et données de transaction dans l'API et les URL de sites Web.

Bien que l'utilisation de SSL protège contre l'interception du trafic, la transmission de ces informations dans l'URL est dangereuse car ces paramètres:

• Peut apparaître dans les journaux du serveur Web;
• Sera affiché dans l'URL du navigateur;
• Apparaissent dans l'historique de navigation du navigateur;
• Ils seront visibles par tout appareil qui effectue l'interception SSL, par exemple, un équipement de surveillance réseau avec un certificat de confiance.

Données confidentielles dans les URL des API bancaires. Source: Trend Micro

Dans certains navigateurs, l'historique de navigation est partagé entre plusieurs appareils, tels qu'un ordinateur portable, un smartphone et une tablette. L'affichage d'informations sensibles dans une URL risque d'affaiblir l'efficacité de l'authentification multifacteur, permettant aux pirates d'attaquer les appareils les moins sécurisés pour voler ces informations.


Exemple concret: une fintech européenne comptant des millions de clients a publié une documentation API indiquant que les adresses e-mail, les mots de passe, les mots de passe et les identifiants clients sont envoyés dans les URL API.
Source: Trend Micro

Une autre méthode d'utilisation malveillante des API publiques est les attaques DoS / DDoS. Tout pirate intéressé peut essayer les essais et les erreurs pour trouver une combinaison de paramètres qui entraînera une défaillance du service.

Applications mobiles

Outre les attaques traditionnelles contre les applications mobiles utilisant des superpositions et d'autres options familières, l'utilisation de SDK tiers comporte également un danger supplémentaire.

Il y a des cas où des fonctions malveillantes y ont été introduites qui ont abonné un utilisateur d'un programme utilisant cette bibliothèque à des SMS ou des services payants premium, comme E xpensiveWall, qui a été intégré à la bibliothèque gtk , ou DrainerBot, qui a été introduit dans le SDK Tapcore et a montré des vidéos invisibles pour les tromper. .

Dans certains cas, les applications initialement sûres et utiles sont devenues soudainement malveillantes, comme CamScanner - Phone PDF Creator, qui a soudainement obtenu une bibliothèque avec des fonctionnalités de cheval de Troie .

De toute évidence, la fonctionnalité cachée des programmes de travail avec les données financières peut entraîner les conséquences les plus désagréables.

Et même si les applications Open Banking sont limitées dans le droit aux paiements pour le compte des clients, les attaquants pourront toujours les utiliser à des fins lucratives. Les données sur les transactions terminées sont également un bien précieux. Des informations sur le moment et le lieu des achats vous permettent de vous faire une idée des mouvements quotidiens des utilisateurs, de leurs habitudes, de leurs intérêts et de leur situation financière.

Les rapports de bogues constituent une autre cible pour attaquer les applications mobiles. Si l'application se bloque, des informations sur l'état de l'appareil et les circonstances à l'origine de l'erreur sont envoyées au serveur du développeur. De plus, les informations transmises peuvent également contenir des informations confidentielles:



Rapport de bogue. Source: Trend Micro

Si un attaquant compromet le développeur de logiciels pour les rapports d'erreur, il aura accès à ces informations.

Infrastructure des entreprises Fintech

L'utilisation d'une infrastructure cloud pour la mise en œuvre de projets fintech est un moyen raisonnable d'économiser l'entreprise du coût d'acquisition de serveurs «iron» et d'assurer leur bon fonctionnement. Cependant, dans ce cas, un autre participant est ajouté à l'entreprise, à la banque, au client et à l'organisation fintech - le fournisseur de services cloud.

Les pirates peuvent organiser une attaque sur la chaîne d'approvisionnement en infiltrant le réseau du fournisseur de cloud. Une telle attaque affectera plusieurs sociétés de technologies financières qui disposent de ressources dans ce cloud. Son danger est que ni les clients, ni les banques, ni les sociétés fintech elles-mêmes ne seront informées du compromis, car l'attaque se produira hors de leur portée.

Les utilisateurs

Les attaques contre les utilisateurs sont en premier lieu en termes d'efficacité et de pertinence. Elles sont beaucoup plus simples et moins coûteuses à mettre en œuvre que les cyberattaques "techniques".

Au cours de leur travail avec les utilisateurs, les banques ont réussi à s'assurer que les e-mails de phishing de masse tels que «Vos informations d'identification pour SuperCredit Bank sont obsolètes. Cliquez ici pour réinitialiser le mot de passe "a perdu son efficacité. Les utilisateurs en sont devenus plus méfiants.

Lorsque vous travaillez avec une application fintech, cette expérience est déjà inapplicable. Par conséquent, la lettre «Nous sommes une société fintech MegaTech, un fournisseur de services à SuperCredit Bank. Veuillez cliquer ici pour mettre à jour les détails de votre compte. »Cela semble complètement sûr. Les utilisateurs ne se rendent pas compte que le mot de passe du compte du fournisseur de technologies financières est aussi important que le mot de passe de la banque Internet. Et le plus triste, c'est que les banques ne seront pas informées du compromis de l'utilisateur.

Un moyen plus difficile d'attaquer les utilisateurs consiste à utiliser de fausses applications fintech, qui s'affichent dans le premier Play Market ou App Store, puis volent des informations d'identification, des informations financières et de l'argent.

Comment protéger l'Open Banking

Une lutte efficace contre les fraudeurs fournit un ensemble de mesures, et la banque ouverte ne fait pas exception. Nous énumérons les moyens de protéger les clients des technologies financières contre les menaces.

Authentification multifacteur

Il s'agit d'une exigence obligatoire de la directive PSD2 et des réglementations similaires liées à l'Open Banking. Selon Microsoft, l' utilisation de l'authentification multifacteur bloque 99,9% des tentatives de piratage de comptes.


Trois baleines du MAE - connaissances, possession, biométrie. Source: WSO2

En plus du MFA, PSD2 ajoute le concept de liaison dynamique - l'utilisation d'un code d'authentification qui dépend du montant et du destinataire. Toute modification de ces paramètres invalidera ce code.

API sécurisée

À ce titre, Open Banking propose d'utiliser l' API Financial-grade (FAPI) , une interface logicielle basée sur OAuth 2.0. FAPI, qui est développé par la Fondation OpenID et l'organisation britannique pour la mise en œuvre de l'open banking.

FAPI est une version plus sécurisée du protocole OAuth 2.0, qui permet à des tiers d'accéder à un fournisseur de services sans fournir les informations d'identification de l'utilisateur. Au lieu d'un mot de passe, un tiers reçoit un jeton pour accéder aux données de l'utilisateur après avoir obtenu son consentement explicite. L'utilisateur contrôle les droits d'accès de tiers à l'aide d'un jeton, par exemple, un accès temporaire et un accès en lecture seule. Il peut retirer le token à tout moment, et en cas de vol, un changement de mot de passe n'est pas nécessaire, car le mot de passe n'a été communiqué à personne.


Interaction avec FAPI. Source: Trend Micro

Les développeurs FAPI ont ajouté des modules de sécurité à OAuth 2.0. Parmi ces modules, il convient de noter:

• mTLS (Mutual TLS) est un protocole d'authentification mutuelle similaire à HTTPS, mais ici non seulement le serveur confirme son authenticité au client, mais aussi le client au serveur. En d'autres termes, pour réaliser une transaction, une application fintech doit non seulement vérifier l'authenticité du serveur, mais également confirmer son authenticité auprès du serveur.
• OAuth 2.0 Token Binding (OAUTB) - liaison des jetons d'accès et / ou des codes d'autorisation à une connexion TLS. Si un attaquant vole un code d'autorisation, il ne pourra pas l'utiliser dans une autre connexion TLS. Malheureusement, le token token n'est actuellement pris en charge que sur Microsoft Edge.
• Déclarations client Signature Web JSON (Assertions client JWS) - établit que seul un client spécifique peut utiliser le jeton d'accès sur le serveur d'autorisation bancaire.
• Code Exchange Verification Key (PKCE) - aide à empêcher les attaquants d'utiliser un jeton d'accès client. Pour ce faire, l'application envoie un code de vérification supplémentaire au serveur d'authentification pour confirmer que le client souhaite utiliser ce jeton d'accès.

Actuellement, le FAPI a identifié des problèmes de sécurité qui doivent être résolus.

Infrastructure et sécurité des terminaux

La protection de l'infrastructure des sociétés fintech est un facteur important pour combler les échappatoires des pirates. Les points de terminaison , les systèmes cloud et les mécanismes de développement doivent être protégés , ainsi que la surveillance de bout en bout de l'ensemble de l'infrastructure .

Nous avons parlé de la sécurité des points finaux dans la publication Quand les murs ne suffisent pas. Comment protéger les terminaux . "

Conclusion

Toute nouvelle technologie nécessite non seulement la prise en compte des perspectives, mais également une analyse minutieuse des risques qu'elle présente. Il est particulièrement important de considérer les dangers dans le cas où une nouvelle approche serait introduite dans le domaine auquel l'attention la plus étroite des cybercriminels a traditionnellement été dirigée.

L'Open Banking change déjà le paysage des relations financières. Au cours des prochaines années, ces changements peuvent changer notre vie et révolutionner la façon dont nous gérons notre argent. Pour que ces changements soient positifs, il est extrêmement important que les sociétés de technologies financières, les banques et les autres participants au processus non seulement prennent en compte les menaces identifiées, mais également affinent rapidement les API et les normes pour éliminer les problèmes de sécurité.