Industrie Mag - Le journal de l'industrie.

Dans ce contexte, dans le secteur de la grande distribution, une fraude de grande envergure a été découverte mettant en avant une nouvelle fois l’inventivité sans limites des cyber-escrocs.

Une fraude mystérieuse ?

Lors d’un audit réalisé sur les plateformes de paiement d’un acteur de la grande distribution, une problématique de fraude à grande échelle a été détectée à l’issue de l’inventaire annuel des stocks. L’enquête interne a montré, après visualisation des enregistrements des caméras de vidéosurveillance des salles de stock de marchandises et auditions du personnel, que le « vol » ne pouvait pas s’expliquer par ce biais. Ainsi, la thèse d’une fraude informatique a été envisagée. L’investigation a alors été portée sur les systèmes d’encaissement et l’écosystème connexe.

L’échec de la réponse à incident

Tout d’abord, une investigation manuelle a été effectuée au niveau des journaux d’évènements des équipements réseau, des postes de vente, ainsi que des TPE (Terminaux de Paiement électronique) des magasins impactés par la fraude. Cette enquête a été rapidement limitée par la configuration trop faible des systèmes, un manque de détails dans les journaux d’événements et un temps de rétention trop faible de ces derniers.

À la recherche de scénarios réalisables

En l’absence d’une piste concrète, le problème a dû être pris à l’envers : il a alors été mis en œuvre des scénarii réalisables dans l’environnement donné en se rendant par exemple en magasin de manière incognito afin de rentrer dans le personnage. Ce premier contact a permis de constater tout d’abord la présence de deux types de postes de vente différents : des SCO (Self Check Out) et des postes de vente classiques gérés par un opérateur de caisse. Pour permettre le paiement électronique, des TPE sont présents et connectés à un réseau IP par Ethernet. Les caisses SCO auraient-elles été utilisées par les fraudeurs ? Elles permettent une marge de manœuvre beaucoup plus importante dans la manipulation des appareils d’encaissement. Deuxième constat : des prises Ethernet sont présentes un peu partout dans le magasin. Elles permettent certainement de joindre les systèmes d’encaissement. Réunis, ces deux éléments constitueront le premier vecteur d’attaque à tester : la communication entre la caisse et le TPE. En temps normal, lorsque l’on veut régler une transaction en CB, l’opérateur de caisse insère manuellement le montant de la transaction, puis vérifie son succès grâce au ticket émis. Toutefois, afin de réduire le temps de transaction, de plus en plus de revendeurs automatisent ces deux actions en faisant communiquer directement le poste de vente avec le terminal de paiement. Mais ce processus récent est-il sécurisé ? Et si on arrivait à tromper la caisse en lui faisant croire que les paiements ont eu lieu avec succès ?

Place à l’action

Une connexion d’un dispositif Wifi à l’une des prises Ethernet du magasin a alors été réalisée. De cette manière, il est possible d’interagir à distance sur le réseau de ce dernier. Il n’est pas impossible que les fraudeurs se soient introduits par ce biais à travers une malveillance interne. Une attaque d’interception réseau couramment utilisée est alors lancée (attaque ARP poisonning). Les communications entre le poste de vente et le TPE sont désormais captées. Une fois cette étape validée, une phase de rétro-ingénierie du protocole de communication est effectuée. L’objectif était alors de savoir si les fraudeurs auraient pu modifier la réponse du TPE. Un mécanisme de signature des messages a-t-il été implémenté ? Après une recherche « offline » dans le contenu des messages, il apparait qu’un tel mécanisme n’a pas été considéré, ce qui aurait permis à d’autres personnes de modifier les messages ! Reste encore à savoir quoi modifier. Il a alors fallu rechercher les informations permettant à la caisse de comprendre qu’une transaction s’est bien passée. Une autre analyse « offline » des différences de réponse du TPE a lieu, ce qui a permis d’isoler les comportements « succès » et « échec ».

Une question de traçabilité

Bien que le scénario ait été validé techniquement, une question restait en suspens. En effet, la caisse ayant validé le panier contrairement au serveur de paiement, une « différence de caisse » aurait dû être mise en avant à court terme, celle-ci ayant bien été remontée lors des analyses techniques. Comment est-il possible qu’aucune différence significative n’ait pu être enregistrée ? Comment les fraudeurs ont-ils procédé ? Ont-ils attaqué les serveurs ou les postes de caisse ? Ainsi, pour gagner du temps, une analyse des flux réseau des caisses est effectuée. En répétant l’exercice effectué avec le TPE, les échanges réseau sont captés. Une connexion à une base Oracle est faite lors de la finalisation d’une vente. Dans un premier temps, il a simplement été tenté de ne pas renvoyer les requêtes vers la base de données pour qu’aucune information sur la vente ne soit enregistrée.

Mais la caisse, elle, attendait des réponses particulières. Une retro-ingénierie des requêtes/réponses de la base de données est faite et, en quelques heures, il a été possible d’émuler parfaitement les réponses pour que l’opération soit transparente. Ce nouveau développement a été agrégé à l’outil qui servira à valider le scénario. Ce n’est que quelques jours plus tard qu’il a été identifié qu’aucun problème de différences de caisse n’a été enregistré, malgré une transaction frauduleuse d’un montant de 100 euros.

Une seconde phase d’analyse des journaux d’événements

En ayant décrit le mode opératoire pas à pas, il est désormais possible de refaire une analyse des journaux d’événements. Ces derniers ont été extraits sur l’intégralité des caisses, des bases SGBD, et des TPE, représentant ainsi plusieurs Giga-octets de données. Les journaux sont ensuite placés sur une infrastructure dédiée et des règles telles qu’elles avaient été décrites sont créées. Des caisses « suspectes » ont alors été identifiées. Des ventes par cartes bleues étaient, en effet, validées par ces dernières, malgré le fait que les TPE enregistraient un échec de transaction. Sur les journaux des bases de données, on recherche l’absence de référence de l’identifiant unique de la vente (générée par la caisse). Après quelques heures d’implémentation et de fonctionnement, plus d’une centaine de transactions ont été remontées sur les dernières semaines. Les transactions, de plusieurs centaines d’euros chacune, portaient principalement sur des produits plutôt onéreux. Grâce à ces informations précises sur l’heure et la caisse fraudée, le visionnage des enregistrements des caméras de vidéosurveillance a été fructueux : certains fraudeurs ont été identifiés, ce qui a permis de remonter le réseau criminel à l’origine de cette fraude inédite.

http://www.nes.fr/