Kort samengevat: detectie van digitale skimmers in de checkout
- Monitoring waarschuwt te laat: De meeste client-side beveiligingstools beweren digitale skimmers te vangen, maar ze inspecteren scripts pas nadat de browser ze al heeft geladen, wat betekent dat de melding precies op het moment binnenkomt dat de kaartgegevens van de gebruiker de pagina al verlaten.
- cside blokkeert vóór rendering: De first-party JavaScript-agent van cside observeert het runtimegedrag van elk third-party script in de browser, DOM-lees-acties, netwerkcalls, mutaties, en blokkeert skimmergedrag voordat de kwaadaardige payload het nep-kaartformulier kan renderen, zonder sampling en met autonome blokkering erbovenop.
- Waar de aansprakelijkheid ligt: Voordat PCI DSS 4.0-auditors gaan vragen over third-party scripts op je betaalpagina's, bepaal of monitoring-only tools die pas na uitvoering waarschuwen de aansprakelijkheid daadwerkelijk weghalen bij je merchant account.
Weinig tijd? Bekijk cside's in-browser blokkering van Magecart en skimmers. Dit dekt alles hieronder in één deployment.
Onlangs lazen we over een nieuwe, grootschalige cyberaanvalscampagne die honderden webwinkels trof door kwetsbaarheden in scripts en plug-ins van derden te misbruiken.
Dit is een perfect voorbeeld van een 'digitale skimmer'.
Digitale skimmers zijn stukjes code die kwaadaardig worden geïnjecteerd in legitieme websites. Ze zijn gericht op persoonlijke gegevens en creditcardinformatie.
Dit probleem neemt toe en is een van de redenen waarom cside is opgericht. cside kan deze kwaadaardige code detecteren en voorkomen dat deze gebruikers op websites treft.
Deze code wordt geladen aan de client-side (de browser) van de gebruiker, in plaats van op de server van de website. Dat maakt het bijzonder moeilijk te detecteren, omdat de meeste websites geen tool zoals cside hebben om de client-side ervaring van hun gebruikers te beschermen.
De meeste van onze concurrenten controleren deze code nadat deze al in de browser van de gebruiker is geladen, waarmee ze de aanval niet voorkomen, maar simpelweg de betrokken website waarschuwen. Wij laden alle scripts eerst in een proxy en serveren ze pas aan de gebruiker nadat ze als veilig zijn beoordeeld. Waar mogelijk optimaliseren we scripts ook, zodat ze sneller worden geleverd dan via een Content Delivery Network (CDN), waardoor latentieproblemen worden vermeden. Sterker nog, vaak verhogen we hiermee de leveringssnelheid van deze scripts.
Wat er bij deze aanval gebeurde
Deze aanval werd bekendgemaakt door MalwareBytes en was tot nu toe de meest recente in een reeks aanvallen op e-commercesites die gebruikmaken van Magento.
We hebben hier destijds niet over bericht, omdat geen van onze gebruikers momenteel Magento gebruikt.
In ander nieuws merkten we onlangs dat Malwarebytes(.)fr was ingericht als een domeinverkooppagina, met een IP-logger. Die stuurde de gegevens vervolgens door naar een Discord-webhook. Deze werd snel verwijderd of verbannen van Discord. Lees hier waarom verlopen domeinen een groot probleem kunnen zijn en vaak worden gebruikt bij dit soort aanvallen.
Hier is bewijs van die webhook:
Terug naar het verhaal.
Een web supply chain-aanval zoals deze gebeurt doordat aanvallers Magento (of een plug-in in Magento) compromitteren en op afstand simpelweg één regel JavaScript invoegen. Bij de meeste van deze aanvallen, en ook bij deze meest recente, passen de aanvallers een legitiem script aan om zo lang mogelijk onopgemerkt te blijven.
De code is ook geobfusceerd om het nog moeilijker te maken om precies te begrijpen wat er wordt uitgevoerd. Dit is een legitieme manier om code te beschermen, en bedrijven gebruiken dit voortdurend om hun code te beveiligen tegen kopiëren of manipulatie.
Vanaf dat punt is de aanval vrij eenvoudig. De code laadt een functie die informatie ophaalt van de betreffende site, die wordt ingevoerd en verzonden in allerlei formulieren. Het domein in de kwaadaardige code ontvangt deze informatie vervolgens, en de aanvallers hebben nu die gegevens.
Bij deze aanval richtten ze zich op creditcardinformatie van nietsvermoedende mensen die online aankopen deden. Die mensen kunnen daar zelf weinig aan doen, maar de websites waarop de aanval plaatsvindt zijn aansprakelijk en ontvangen vaak boetes van PCI DSS en soms ook rechtszaken.
In dit geval werd de betaalstroom tijdens het afrekenen onderbroken. Er werd een nep-betaalmethodenframe ingevoegd en mensen vulden dit formulier in plaats van het echte formulier in. Dit werd gedaan via een eenvoudige image-tag die in één enkele JavaScript-regel was verwerkt.
Dit ziet er dan zo uit: {domain}.{shop|online)/img/
Kwaadaardige domeinen die tot nu toe bij deze aanvallen zijn aangetroffen:
- codcraft(.)shop
- codemingle(.)shop
- datawiz(.)shop
- deslgnpro(.)shop
- happywave(.)shop
- luckipath(.)shop
- pixelsmith(.)shop
- salesguru(.)online
- statlstic(.)shop
- statmaster(.)shop
- trendset(.)website
- vodog(.)shop
- artvislon(.)shop
- statistall(.)com
- analytlx(.)shop
Dit is wederom een aanval die aantoont waarom bedrijven de client-side ervaring van hun gebruikers moeten beveiligen. Als deze sites een tool zoals cside hadden geïnstalleerd, zouden hun gebruikers beschermd zijn geweest.
Regelgeving is hier
Vanaf maart 2025 verplicht PCI DSS 4.0 websites met online afrekenpagina's om scripts van derden op hun betaalpagina's te monitoren.
Wij pleiten ervoor deze scripts te monitoren én te beveiligen, om volledig veilig te zijn. We schreven hier over het risico van het alleen beveiligen van betaalpagina's en niet van de gehele website. Aanvallers passen zich eenvoudig en snel aan, en aanvallen zullen naar verwachting toch blijven plaatsvinden.
Weet dat door cside te gebruiken, uw gehele website beschermd is.
Je kunt gratis aan de slag en binnen enkele minuten beveiligd zijn.
