Une tentative sur cinq pour obtenir un accès non autorisée à des comptes utilisateurs s’opère maintenant à travers des API plutôt que sur les interfaces de connexion elles-mêmes. Cette tendance, que révèle un rapport d’Akamai « Financial Services – Hostile takeover attemps », est encore plus marquée dans le secteur des services financiers où l’utilisation d’API est très répandue, en partie à cause des exigences réglementaires. Entre décembre 2017 et novembre 2019, Akamai a dénombré 85,4 milliards d’attaques par utilisation frauduleuse d’identifiants à l’encontre d’entreprises mondiales utilisant ses services. Sur ces attaques, 16,5 milliards - soit presque 20% - ciblaient des noms d’hôtes clairement identifiés comme des points de connexion d’API. Alors que dans le secteur financier, le pourcentage d’attaques ciblant des API a grimpé brutalement entre mai et septembre 2019 pour atteindre 75%. « La large adoption des API a permis aux criminels d’automatiser leurs attaques », expliquent le fournisseur dans son rapport. « C’est pourquoi le volume d’incidents de type bourrage d’identifiants a continué à progresser d’une année sur l’autre, et c'est pourquoi de telles attaques continuent à représenter un risque important et constant à travers tous les segments de marché ».

Le « credential stuffing » ou bourrage d’identifiants est un type d’attaque par force brute qui consiste à utiliser des combinaisons de listes de noms d’utilisateurs et de mots de passe volés pour accéder aux comptes. C’est devenu un problème majeur ces dernières années. C’est une conséquence du grand nombre d’intrusions dans des systèmes au cours de la dernière décennie qui ont résulté en des milliards d’identifiants rendus publics sur Internet ou vendus comme des produits sur des marchés clandestins. Les utilisateurs se servent souvent des mêmes mots de passe sur différents sites web. Les attaquants le savent et se servent des identifiants exposés lors des intrusions pour élaborer des combinaisons de listes. Celles-ci sont chargées dans des botnets et des outils automatisés qui sont utilisés pour inonder les sites web avec des requêtes de connexion pour arriver à trouver des accès. Toutefois, une fois l’accès obtenu, extraire l’information des services en balayant les pages client demande des efforts et de la personnalisation, alors qu’interroger une API et en extraire l’information est standardisé et bien adapté à l’automatisation. Après tout, le véritable rôle d’une API est de faciliter le dialogue entre les applications et de pouvoir échanger les données automatiquement.

L'open banking a favorisé le développement d'API

Si les API ont toujours existé au sein des systèmes d’exploitation et ailleurs, l’usage des API web s’est considérablement développé ces dix dernières années, en partie à cause de l’écosystème mobile, puisque les apps mobiles échangent avec les services de back-end à travers les API - mais également à cause de l’adoption des infrastructures cloud et les architectures orientées services où les applications monolithiques auto-suffisantes sont en train d’être remplacées par des microservices conteneurisés qui manipulent des fonctionnalités indépendantes et parlent avec les autres à travers des API.

L’innovation dans les technologies financières, souvent tirée par les fintechs, a également mis la pression sur les banques pour que leurs données clients et services soient disponibles via des API. En fait, la directive PSD2 (revised payment services directive) qui a pris effet dans l’Union européenne en septembre a été faite pour pousser le concept et les principes de l’open banking. PSD2 demande aux banques et autres institutions financières qui gèrent des comptes clients de permettre à des services tiers de vérifier la disponibilité des fonds, de réaliser des paiements ou d’accéder aux données du compte si le détenteur en donne l’autorisation. La façon la plus courante de se conformer à cette demande consiste à développer des API web et la plupart des banques ont commencé à mettre en œuvre de telles API bien avant la date limite de la directive.

Le manque de standard commun augmente le risque

Même s’il n’existe pas de telles exigences réglementaires dans les pays qui n’appartiennent pas à l’UE, le marché pousse les institutions financières dans la même direction car elles ont besoin d’innover et de rester en phase avec la concurrence. Les experts en sécurité ont depuis longtemps exprimé leurs préoccupations en soulignant que les erreurs de mise en œuvre sur les API bancaires et le manque de standard de développement commun pourraient augmenter le risque de fuites de données.

Les données gérées par les services financiers ont toujours beaucoup intéressé les cybercriminels qui peuvent les monétiser de différentes façons, ce qui fait des API bancaires une cible attractive. « Les criminels continuent à acheter et vendre des cartes bancaires, des identifiants financiers, des cartes cadeaux compromises et des comptes en ligne à un rythme rapide parce que la demande reste forte », indique les chercheurs d’Akamai. « Certains actifs compromis sont échangés contre de l’argent, tandis que d’autres sont échangés entre criminels ».

47% des attaques sont de type « local file inclusion »

En dehors des attaques contre les connexions API et du credential stuffing, d’autres types d’attaques sont menées pour récupérer des données dans ce secteur. Sur la période de 24 mois analysée, Akamai a observé 473 millions d’attaques par bourrages d’identifiants dans le secteur bancaire, mais également 662 millions d’attaques sur d’autres applications web. Dans les services financiers, les attaques les plus fréquentes ont été de type « local file inclusion » (LFI), dans 47% des cas. Viennent ensuite les injections SQL dans 36% des cas et le cross-site scripting (XSS) dans 7,7% des cas. Les autres attaques observées ont utilisé des injections PHP, des injections de commande, des inclusions de fichiers distants, des injections OGNL et des chargements de fichiers malveillants. Les attaques LFI ciblent des fichiers scripts écrits dans différents langages web, principalement PHP, mais aussi ASP, JSP et d’autres, et débouchent souvent sur la mise au jour d’informations sensibles.

Les chercheurs d’Akamai ont identifié des problèmes dans le développement d’API qui facilite la tâche aux attaquants. Par exemple, certaines API n’indiquent pas de limite pour les tentatives d’authentification ce qui permet aux criminels d’essayer des dizaines de milliers de mots de passe par minute. Réduire le nombre de requêtes d’authentification est une bonne pratique, mais cela ne peut pas suffire contre les attaques de type credential stuffing, parce les attaquants configurent leurs scripts pour réduire le rythme des requêtes afin d’éviter d’être bloqués.

Le zero trust pour lutter contre les intrusions

Un autre problème concerne les réponses d’erreur données par les API lors des tentatives de connexion échouées. Cela conduit souvent à livrer des informations sur l’existence d’un nom d’utilisateur sur le service et les criminels en tirent profit pour valider et trier leurs listes d’identifiants et rendre leurs prochaines attaques plus difficiles à détecter parce que le taux d’erreurs sera plus faible. « Cela ne concerne pas seulement les services financiers ; tout le monde est ciblé par les criminels qui utilisent des identifiants volés », rappellent les chercheurs d’Akamai. « L’un des moyens pour combattre ces assauts continus, c’est le zero trust. A mesure que l’adoption de ces technologies se développera, il deviendra plus difficile de se servir d’attaques passives, telles que le bourrage d’identifiants, pour pénétrer un réseau. De même, il sera plus difficile de passer par le phishing, ou les serveurs de commande et contrôle personnalisé puisque le DNS peut être bloqué à la source ».