En dépit des difficultés économiques de cette période, l’e-commerce est en hausse de 25% depuis le début de mars1. Mais la fraude a également augmenté. Selon Malwarebytes, le clonage de cartes de crédit en ligne a augmenté de 26% pour le seul mois de mars.2
Dans notre billet de blog d’avril, «La revue de presse sécurité des experts Splunk», j’ai mentionné un article au sujet du piratage d’un site d’e-commerce impliquant un «cloneur virtuel» (merci à Matthew Joseff de m’avoir envoyé le lien). L’auteur de l’article conclut son analyse en invitant les clients à se protéger à l’aide de dispositifs de détection et de prévention des malwares installés côté client (par le consommateur, donc). Je n’ai rien contre cette approche, mais les solutions AV/AM ne protègent pas toutes contre ce type d’attaques, et le site d’e-commerce doit assumer son devoir de protéger ses systèmes et les données de ses clients. Nous allons donc passer en revue trois approches permettant aux sites d’e-commerce de détecter ces attaques et de protéger leurs clients contre le vol de données.
Résumé rapide des événements rapportés par Malwarebytes :
- Les malfaiteurs ont eu accès aux fichiers du site web ciblé (probablement à cause d’une version obsolète du logiciel d’e-commerce Magento).
- La page d’accueil a été altérée par l’ajout de code JavaScript dissimulé afin de charger une image PNG invisible.
- Cette image PNG comprenait du code JavaScript malveillant.
- Le fournisseur de traitement des paiements utilisé par le site est Cybersource, et les utilisateurs sont redirigés vers la page de paiement Cybersource légitime pour fournir leurs informations de carte de crédit.
- Le JavaScript du fichier PNG créait une iframe qui se superposait à la page de paiement (sur l’iframe de paiement Cybersource existant).
- La page de paiement malveillante était chargée à partir de «deskofhelp[.]com» (enregistrée avec une adresse e-mail Yandex[.]ru)
- Les utilisateurs saisissaient leurs données de carte de crédit dans l’iframe malveillant, recevaient un message d’expiration de session et étaient redirigés vers le véritable iframe de paiement de Cybersource.
- Les malfaiteurs récoltaient ainsi des informations de paiement complètes :
– Nom et prénom
– Adresse de facturation
– Numéro de téléphone
– Numéro de carte de crédit
– Date d’expiration de la carte de crédit
– Cryptogramme de la carte de crédit.
Il faut souligner que l’iframe malveillant n’est affiché que sur le navigateur de l’utilisateur, à partir d’un site distant, et que rien dans les logs web du site marchand ne peut indiquer directement que le navigateur d’un client a émis une requête vers ce site distant.
Examinons trois approches permettant de détecter cette attaque avec Splunk, en gardant à l’esprit que la détection des anomalies est un mécanisme fondamental dans la détection des fraudes.
1. Supervision des OS
Les logs d’OS constituent un bon point de départ. La modification, l’ajout et la suppression de fichiers sont faciles à consigner avec la plupart des OS. Des solutions natives, open-source ou payantes peuvent être utilisées pour superviser les modifications. Les cibles à forte valeur, comme les serveurs en contact avec le public, doivent faire l’objet de cette supervision. Elle aurait ainsi permis de détecter l’ajout d’un fichier PNG malveillant au système, ainsi que les modifications apportées au fichier de la page d’accueil. Les deux événements auraient dû alerter les équipes de sécurité, de DevOps ou de gestion de contenu, car ils étaient tous deux inattendus.
Splunk propose des extensions techniques (TA) disponibles gratuitement sur Splunkbase pour faciliter la supervision et le signalement de ces événements, et de nombreux articles de blogs tiers et de Splunk abordent le thème du contrôle des systèmes de fichiers dans Windows et Linux.
2. Métriques du site web
Les métriques du site web offrent une autre zone de détection. Le temps de paiement et le taux d’abandons de panier doivent être connus. C’est généralement une préoccupation de premier plan pour les équipes de marketing et de fiabilité des sites. Dans un cas, le client a mis deux fois plus de temps que d’habitude pour finaliser son processus de paiement, et dans un autre il a abandonné après le message d’expiration. Quoi qu’il en soit, les indicateurs de ces deux types d’événements auraient dû enregistrer une forte hausse. On trouve sur Splunkbase une application pour les métriques du site web (website metric app) qui peut fournir des détails de qualité, mais certains de ces indicateurs sont faciles à calculer à partir de simples recherches.
Par exemple, les logs d’accès Apache offrent des moyens supplémentaires de détecter une activité suspecte. On peut facilement déduire la durée du paiement si l’on connaît la page précédente et la page suivante, et que l’on calcule la différence entre les deux accès. Comme je n’ai pas de véritables données de traitement des paiements, j’ai pris la liberté d’utiliser quelques données d’exemple. En calculant le temps séparant l’affichage du panier et l’envoi des informations sur la page de paiement, je peux calculer le temps qui sépare les deux événements principaux et afficher une moyenne horaire:
index="web-site" sourcetype="access_combined_wcookie" | transaction JSESSIONID startswith="GET /viewCart" endswith="POST /checkout" | timechart span=1h avg(duration)
Mes données montrent une moyenne de 5,5secondes environ pour mon processus de paiement ou «checkout process». Le délai de paiement d’un véritable site d’e-commerce peut être de 30secondes ou plus, mais la page d’erreur fictive et le deuxième processus de paiement vont nécessairement augmenter le temps de paiement moyen.
On peut en outre utiliser certaines fonctions mathématiques sympathiques de Splunk pour extraire les transactions qui ont duré plus de « durée moyenne du paiement + 2 x écart-type » en calculant l’écart-type des 100 transactions précédentes et en l’ajoutant (une ou plusieurs fois) au temps de transaction moyen, pour ensuite comparer le résultat au temps de transaction réel :
index="web-site" sourcetype="access_combined_wcookie" | transaction JSESSIONID startswith="GET /viewCart" endswith="POST /checkout" | table _time, duration, JSESSIONID
| streamstats window=100 avg("duration") as avg stdev("duration") as stdev
| eval upperBound=(avg+stdev*2)
| eval isOutlier=if(’duration’ > upperBound, 1, 0)
| table "_time", "JSESSIONID", "duration", "upperBound", "isOutlier"
| sort - isOutlier
Et en quelques clics sur l’interface, on peut en faire une recherche récurrente (toutes les quelques minutes) afin d’émettre une alerte en cas de détection d’une valeur anormale. Splunk prend en charge un large éventail de méthodes d’alerte : e-mail, scripts, webhook, etc.
De plus, la page d’erreur fictive doit avoir un impact sur l’expérience client et entraîner une hausse des abandons de panier. On obtient le nombre d’abandons en soustrayant le nombre d’achats réussis du nombre total d’accès au panier. Voici un moyen d’afficher ces données, mais il en existe bien d’autres selon la structure de vos logs :
index="web-site" sourcetype="access_combined_wcookie" "GET /viewCart"
| timechart span=1h dc(JSESSIONID) AS Cart
| appendcols
[search index="web-site" sourcetype="access_combined_wcookie" "POST /checkout"
| timechart span=1h dc(JSESSIONID) AS Purchased]
| eval Abandoned=Cart-Purchased
| table _time, Cart, Purchased, Abandoned
Le décompte des accès aux ressources constitue une autre métrique courante et permet aux équipes marketing et à d’autres de déterminer si les pages sont difficiles à trouver, sans intérêt ou si les images doivent être mises en cache en cas d’accès fréquent. Le fichier PNG malveillant aurait dû apparaître spontanément et alerter quelqu’un en raison de son taux d’accès élevé. Même si le fichier était dissimulé sur la page, la requête HTTP était nécessairement consignée.
Voici une simple recherche effectuée sur des données d’exemple issues d’un log d’accès Apache, consignant l’historique des accès aux ressources web ; remarquez le pic d’accès au fichier member.php :
index=botsv2 sourcetype="access_combined" | timechart span=1d count by file limit=20 usenull=false useother=false
3. Supervision du site web
Enfin, la troisième méthode qui aurait pu permettre de détecter la faille est celle de la supervision automatisée du site web. La supervision scriptée d’un site web, qui vise à vérifier que tout fonctionne de bout en bout, est une tactique courante utilisée depuis des années pour garantir la fiabilité des sites. Lorsque des ressources tierces (fournisseurs de processus de paiement) sont intégrés à un site, il est essentiel de s’assurer que tout fonctionne et que ces fournisseurs externes respectent les SLA. Selenium web driver est une solution open-source qui permet de réaliser des tests scriptés sur l’intégralité d’une transaction sur un site d’e-commerce. Certains événements importants auraient dû apparaître dans les informations de ce système de supervision client et les logs de proxy d’entreprise :
- Le message d’expiration de session, bien que fictif, aurait dû générer un événement, car c’est une page imprévue (les expirations légitimes devraient également déclencher une alerte).
- Le hash de la page de paiement falsifiée ou de la fausse page d’expiration de session n’aurait pas été identique au hash de la page attendue.
- Les requêtes DNS du client (capturées chez le client ou sur le réseau) auraient signalé un domaine et une requête DNS inconnus (deskofhelp[dot]com)
- Les malfaiteurs n’ont pas traduit leur iframe malveillant sur les sites dans d’autres langues que l’anglais. Tester les sites ES ou FR aurait renvoyé une page de paiement en anglais : une fois encore, un résultat inattendu qui devrait générer une alerte
.
Ces solutions de détection ne sont pas nouvelles, et elles ont déjà été abordées dans des billets de blog sur la supervision des sites web et la détection des nouveaux domaines.
Suite au billet de blog « Détection des nouveaux domaines » déjà évoqué, cette détection a d'ailleurs été ajoutée à l’application Splunk Security Essentials. Vous pouvez trouver cette requête en cherchant « new domain ».
Certains d’entre vous ont sans doute remarqué qu’une partie des techniques et des références que j’ai données ont déjà quelques années. Cela met en évidence que les attaques n’ont pas besoin d’être innovantes ou sophistiquées pour être efficaces, et que certaines méthodes de supervision traditionnelles et éprouvées sont encore performantes.
Les différentes techniques de détection présentées ci-dessus ne sont pas toutes liées à la sécurité. Les opérations IT, le marketing et les opérations anti-fraude utilisent régulièrement Splunk. Il aurait suffi qu’une seule de ces équipes utilise Splunk pour détecter la faille bien plus tôt qu’elle ne l’a été. Imaginez si toutes les équipes utilisaient Splunk Enterprise et collaboraient avec des données partagées.
Merci à James Brodsky pour son aide dans l’élaboration de ces scénarios de détection.
1. https://www.digitalcommerce360.com/2020/04/01/us-ecommerce-sales-rise-25-since-beginning-of-march/
2. https://blog.malwarebytes.com/cybercrime/2020/04/online-credit-card-skimming-increases-by-26-in-march/
*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.
