Zeroday in Magento en Adobe Commerce wordt actief misbruikt, patch ontbreekt

StyleSmuggler, een ongepatchte kwetsbaarheid in Magento en Adobe Commerce, wordt sinds 4 september actief misbruikt om zonder inloggen code uit te voeren op webshopservers, meldt het Utrechtse beveiligingsbedrijf Sansec.

Daarmee verschuift voor elke Nederlandse webshop op dit platform de gebruikelijke volgorde. Er is geen patch om te installeren, geen CVE-nummer om te volgen, en bijwerken heeft niet geholpen: het eerste slachtoffer draaide 2.4.6-p15 met de juli- en augustusupdates van Adobe en een schone security:patch-status. De enige knoppen die vandaag bestaan zitten bij jou of bij je hostingpartij, en dat zijn er twee: GraphQL dichtzetten, en je server nalopen op de achterdeur.

Bijgewerkt zijn helpt hier niet

Sansec reproduceerde de volledige aanvalsketen zonder inloggegevens op schone installaties van Magento Open Source 2.4.7, 2.4.8 en 2.4.9 en stelt dat alle huidige versies geraakt zijn. Sessies verplaatsen naar Redis of naar de database stopt de aanval niet. Een webshophouder zag een poging stranden op de sessieopslag en acht seconden later een tweede poging slagen, die in plaats daarvan een bestand gebruikte dat via Magento's custom options was geupload. Beide kwamen van dezelfde aanvaller.

Het Almelose Disrex Group, dat twee getroffen winkels host en afhandelde, laat zien hoe weinig de gebruikelijke verdediging uithaalde. Winkel A draaide 2.4.8 en was klant van Sansec Shield, met de module geinstalleerd, ingeschakeld en gelicentieerd toen hij op 4 september om 23.10 UTC werd geraakt. Dat was uren voordat Sansec de eerste blokkeerregels voor dit lek uitrolde, om 07.15 UTC de volgende ochtend. Beide winkels vielen in dat gat van ruwweg acht uur tussen de eerste aanval en het eerste verweer. Patchstatus deed er niet toe, zegt Disrex, en dat is volgens het bedrijf precies het deel dat webshophouders moeten horen.

Hoe de aanval werkt

Het gaat in twee stappen. Eerst schrijft de aanvaller PHP-code weg in een bestand dat Magento zelf aanmaakt, bijvoorbeeld een foutrapport in var/report/ of een regel in var/log/system.log. Daarna laat hij Magento die code uitvoeren door de standaardmail "Payment Transaction Failed Reminder" te laten opmaken. De code draait tijdens het renderen van dat bericht, dus niemand hoeft de mail te openen, en de aanval slaagt ook als het versturen mislukt.

Lukt dat, dan start er een klein Rust-programma als achtergrondproces dat zich voordoet als een kernel-thread. Het hernoemt zichzelf ook: op 6 september naar fc-cache, op 7 september naar chronyd, waarbij het baken versie 2.1.5 meldt. Dat baken gaat als NTP-verkeer over UDP-poort 123 naar buiten en komt daarmee langs de meeste uitgaande filters. Sansec zag op 7 september ook een tweede, ongerelateerde aanvaller die via hetzelfde lek een PHP-webshell in de cache met productafbeeldingen legt. Alleen het proces stoppen is dus niet genoeg.

Wat je vandaag kunt doen

GraphQL tijdelijk blokkeren is de enige echte rem zolang Adobe niets levert. Draai je een headless storefront of een PWA, dan heb je GraphQL nodig en valt die optie af. Bij een klassieke Luma- of Hyva-winkel zonder koppelingen die de API gebruiken is het endpoint /graphql dichtzetten op webserver- of firewallniveau veilig, aldus het Nederlandse Magento-bureau Vendic.

En je moet zelf gaan zoeken. De implant zit buiten de webroot, in de thuismap van de Linux-gebruiker onder ~/.local/share/.gvfsd/ of ~/.cache/fontconfig/, dus een schone Magento-map betekent nog geen schone server, schrijft Disrex in zijn incidentverslag. De drie snelste checks:

crontab -l | grep -i gvfsd
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'
grep -ril 'x_trace_' var/report/ var/log/

• Processen. Een echte kernel-thread draait als root en gebruikt geen geheugen. Een proces met vierkante haken op de site-gebruiker met echt geheugengebruik is de implant.
• Cron. Kijk ook in het spoolbestand zelf, want de regel wordt daar rechtstreeks in geschreven en verschijnt niet in het systeemlog.
• Vergiftigde logs. Zoek in var/report/ en in var/log/system.log. Disrex zag de markering X_TRACE_ binnen een dag al van vorm veranderen, dus zoek op het patroon en niet op de letterlijke tekst.
• Webshell. find pub/media -name '*.php' vangt de tweede aanvaller.
• Gratis alarmbel. Staat je webgebruiker in /etc/cron.deny, dan mislukt de persistence en laat elke poging een regel crontab command not allowed achter in je auth-log.
• De mail zelf. Een onverwachte "Payment Transaction Failed Reminder" met onopgeloste {{var ...}}-tags, een klantadres op een .invalid-domein en een totaal van nul euro. Bij Disrex was dat de allereerste aanwijzing.

Verder helpt het om proc_open toe te voegen aan disable_functions in PHP en /tmp, /var/tmp en /dev/shm met noexec te mounten. Vind je iets, bewaar dan eerst bewijs, haal de cronregel weg voordat je het proces stopt (het herstelt zichzelf binnen een seconde), herstart de server niet en draai geen composer install.

De patchstatus, met een tijdstempel

Adobe publiceerde tot nu toe geen advisory, geen CVE en geen workaround, en de eigen bulletinindex voor Adobe Commerce staat sinds de update van 11 augustus stil. Bij zijn laatste bijwerking op 7 september om 13.29 UTC noteert Sansec dat Adobe Enterprise Support die dag bevestigde aan een patch te werken, zonder datum te noemen. De eerstvolgende geplande beveiligingsrelease staat op 8 september. Of dit lek daarin zit, is onbekend. Adobe brengt beveiligingsupdates normaal uit op de tweede dinsdag van de maand, dus die release valt toevallig samen met deze week, en dat maakt hem nog geen zekerheid.

Waar dit heen wijst

Sansec documenteerde eerder SessionReaper en PolyShell in Magento op dezelfde manier: een lek zonder inloggen, een golf van overgenomen winkels, een patch die achteraan komt. Wat StyleSmuggler daaraan toevoegt, is dat beide gebruikelijke verdedigingen deze keer te laat waren. Winkel A was bijgewerkt en draaide een blokkerende module, en werd toch geraakt in het gat tussen de eerste aanval en de eerste regel die hem kon tegenhouden.

Bij een actief misbruikt lek luidt het advies normaal gesproken patchen. Toen een RCE-lek in Langflow maanden na de beschikbare fix in versie 1.9.0 nog werd misbruikt, was traagheid het probleem. Hier bestaat de fix niet, en verschuift het zwaartepunt van patchen naar detecteren. De vraag voor een webshop op Magento is deze week niet of je bij bent, maar of je zou merken dat er iets op je server draait dat er niet hoort.