A támadók egy új, még be nem foltozott sebezhetőséget használnak ki a Magento Open Source és az Adobe Commerce rendszerekben, amellyel bejelentkezés nélkül futtathatnak kártékony kódot a webáruház szerverén – közölte a holland e-kereskedelmi biztonsági cég, a Sansec a szeptember 5-én kiadott közleményében.

A hibát felfedező Sansec StyleSmuggler néven említi a sebezhetőséget, és azt írja, hogy a támadások szeptember 4-én indultak. „A Sansec azért hozza ezt nyilvánosságra ilyen korán, mert a webáruházakat éppen most törik fel” – fogalmazott a cég.

Szeptember 6-ig az Adobe nem adott ki közleményt, CVE-azonosítót, javítócsomagot vagy kerülőmegoldást, és az Adobe Commerce security bulletin index sem tartalmaz semmit az augusztus 11-i frissítés után.

Egy sikeres támadás távoli kódfuttatást biztosít a támadónak a webáruház szerverén, és egy tartós hátsó ajtót telepít. A Sansec szerint az összes jelenlegi verzió érintett, beleértve a 2.4.9-et is, és sikerült reprodukálniuk a teljes, bejelentkezés nélküli támadási láncot tiszta Magento Open Source 2.4.7, 2.4.8 és 2.4.9 telepítéseken.

Az első ismert áldozat 2.4.6-p15-öt futtatott, rajta az Adobe 2026. júliusi és augusztusi biztonsági frissítéseivel. Ez az adott kiadási ághoz elérhető legfrissebb javítási szint, amelyet az Adobe augusztusi közleménye 2.4.6-2026-aug néven jelöl.

A Sansec eddig nem közölt reprodukciót Adobe Commerce vagy Adobe Commerce on Cloud rendszeren, és az Adobe sem erősítette meg, pontosan mely verziók érintettek. A Sansec azt sem árulta el, hány webáruházat törtek fel.

A kutatók átmeneti javaslata azoknak a webáruházaknak, amelyek nem használják a Sansec Shield termékét, hogy kapcsolják ki a GraphQL-t, amíg az Adobe ki nem ad egy ideiglenes javítást.

A Magento hostinggal és fejlesztéssel foglalkozó Disrex Group, amely két feltört áruház incidenskezelésében vett részt, arra hívja fel a figyelmet, hogy a headless és a progressive web app alapú kirakatok igénylik a GraphQL-t, míg a legtöbb klasszikus és Hyvä kirakat nem.

A Sansec szerint az Adobe következő tervezett biztonsági kiadása szeptember 8-án várható, de egyelőre nem tudni, hogy ez tartalmazza-e ennek a hibának a javítását.

A Disrex megállapításai a Sansectől független bizonyítékot jelentenek a sebezhetőség aktív kihasználására. A cég a szeptember 5-én közzétett incident-response tárolóban azt írja, hogy két olyan áruház incidensét kezelte, amelyeket szeptember 5-én törtek fel, egy harmadikat pedig megtámadtak, de nem sikerült feltörni. Webszerver-szabályaikat az egyik feltört áruházon rögzített támadó forgalom alapján állították össze.

Az érintett áruház a Magento 2.4.7-p2 verziót futtatta, olyan biztonsági szinttel, amelyet az Adobe verziótörténete 2024 augusztusára datál. Ez nyolc szinttel marad el a jelenlegi 2.4.7-p10-től. A Disrex által Store A néven említett áruház Sansec Shield előfizető volt, és 2024. szeptember 4-én 23:10 UTC-kor érte támadás, néhány órával azelőtt, hogy a Sansec első blokkoló szabályai életbe léptek volna.

A tároló maga is figyelmeztet. „Ezt a tárolót AI segítségével írtuk, egy élő incidens közben, néhány óra alatt” – áll a README-ben. Hozzáteszik, hogy nem vizsgálták felül, az Apache-szabályokat soha nem futtatták éles Apache szerveren, és a legtöbb takarító parancsot csak leírták, de nem hajtották végre.

A Sansec indikátorai szerint az implantátum egy háttérfolyamatként fut, [kworker/u:8:0] név alatt álcázva magát. Ez a név egy Linux kernel szálhoz tartozik. A bináris nem a web root alá kerül, hanem a site felhasználójának saját könyvtárába, a ~/.local/share/.gvfsd/gvfsd-user alá, és egy cron bejegyzés ötpercenként újraindítja.

A Disrex leírása szerint a bináris egy lecsupaszított, statikusan linkelt Rust program, nagyjából 1,9 MB méretű, x86-64 és arm64 architektúrára fordítva. A cron bejegyzést közvetlenül a /var/spool/cron/crontabs/ alatti spool fájlba írja, ezért a rendszer napló nem mutat crontab-cserét.

Az egyik áruházban ugyanaz a sor 1728-szor szerepelt, és az implantátum a törlés után egy másodpercen belül újra beírta.

A két áruház egyikén az implantátum egyáltalán nem létesített kifelé irányuló kapcsolatot. Ehelyett 28 kapcsolatot tartott fenn az áruház saját Redis példányához a 6379-es porton. A Disrex szerint ebből olvasta a Magento session tárolóját, és a két, egyenként 200 MB feletti forgalomrögzítés közül egyikben sem volt egyetlen csomag sem sem a letöltési szerver, sem a Sansec által megadott vezérlőszerver felé, miközben az implantátum aktív volt.

A Sansec közölte, hogy azoknál a Shield ügyfeleknél, akiket még a szabályok életbe lépése előtt támadtak meg, nincs arra utaló jel, hogy a hátsó ajtót ténylegesen használták volna. Azt javasolják, hogy mindenhol, ahol az érintett folyamatot azonosították, cseréljék le a Magento hitelesítő adatokat.

A támadás két lépésben működik a Sansec leírása szerint. Először PHP kódot ültet egy olyan fájlba, amelyet maga a Magento hoz létre, például egy hibajelentés generálásakor. Ezután ráveszi a Magentót, hogy futtassa ezt a fájlt, mégpedig a platform „Payment Transaction Failed Reminder” (Sikertelen fizetési tranzakció emlékeztető) szabványos e-mailjének kiváltásával. A kód akkor fut le, amikor a Magento az üzenetet összeállítja, így senkinek sem kell megnyitnia, és a támadás akkor is sikeres lehet, ha az e-mail kézbesítése meghiúsul.

A Sansec egyelőre nem tette közzé a teljes exploit láncot, és azt ígéri, hogy egy későbbi frissítésben részletesen bemutatja majd a láncot, a droppert és az implantátumot.

Disrex a támadási láncot bemutató, a saját szabályaival együtt közzétett részletes elemzésében úgy értelmezte a folyamatot, hogy a befecskendezett szövegben lévő egyik direktíva a Magento saját osztályainak sorozatát indítja el, egészen addig a kódig, amelyet eredetileg kizárólag a parancssori dependency-injection fordító kiszolgálására írtak.

A kód végül egy olyan fájl elérési útját illeszti be, amelyet a támadó választott ki: azt a logfájlt, amelyet az imént mérgeztek meg. A lefutó PHP dropper egymás után hat PHP függvénnyel próbál új folyamatot indítani, majd letölti és elindítja az implantátumot. Disrex három fájlt nevez meg a setup/src/Magento/Setup/Module/Di/Code/ könyvtár alatt, mint ahol a lánc véget ér. A Sansec ezt az értelmezést nem erősítette meg, és Disrex sem tette közzé az összeállított kérést.

Az első fázis szempontjából két hely számít. A Sansec által közzétett ellenőrzés a var/report/ könyvtárban keresi az X_TRACE_ jelölőt. Disrex szerint viszont mindkét általa vizsgált fertőzés a var/log/system.log fájlon keresztül történt, és így ez a vizsgálat nem találta volna meg őket, ezért mindkét könyvtárat át kell nézni.

A jelölő már változott is: Disrex szeptember 5-én reggel még X-TRACE- formájú trigger fejlécet látott, amelyet tíz hexadecimális karakter követett, délutánra viszont ugyanez a fejléc már a TRACE szó nélkül jelent meg. Érdemes tehát a minta alakjára keresni, nem a pontos szövegre.

Disrex szerint a system.log fájlban, közvetlenül az include után megjelenő TypeError, amely az array_merge() hívásnál egész szám típusú argumentumra panaszkodik, annak a jele, hogy az exploit sikerrel járt. Létezik azonban egy rejtőzködőbb változat is, amely üres tömböt ad vissza, és semmit sem hagy a logban.

A futó folyamat azonosításához Disrex azt mondta, hogy a valódi kernel szál root tulajdonában van, és nincs foglalt rezidens memóriája, ezért ha zárójelbe tett névvel fut egy folyamat a weboldalt futtató felhasználó alatt, és tényleges memóriát használ, az már az implantátum. Az implantátum a parancssort is erre a zárójeles sztringre állítja be, így ha valaki a processz comm mezője alapján ír ellenőrzést, az nem fog találatot adni.

Disrex azt is megfigyelte, hogy az egyik áruházban a memóriában futó bináris eltért a lemezen lévő fájltól, ezért azt javasolja, hogy ne csak a fájlt, hanem a futó folyamatot is hash-eljék a /proc/<pid>/exe útvonalon keresztül. A Sansec szerint gyanúra ad okot, ha hirtelen megnő a „Payment Transaction Failed Reminder” tárgyú e-mailek száma, bár a valódi, visszautasított fizetések is ugyanezt az értesítést generálják.

A Sansec és Disrex indikátorlistája alapján az alábbi jelekre érdemes figyelni:

• Folyamat: [kworker/u:8:0], amelyet nem root felhasználó birtokol
• Fájl: ~/.local/share/.gvfsd/gvfsd-user
• Fájl: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
• Fájl: /tmp/.gvfsd_<8hex>.lock
• Fájl: /tmp/.kw_<random><random>
• Cron: /5 * exec <home>/.local/share/.gvfsd/gvfsd-user, ennek egy változata pedig a /tmp/.kw_ útvonalra mutat
• SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (a Sansec mintája)

SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (Disrex mindkét áruházában a lemezen lévő bináris)

SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (az egyik Disrex-áruházban a memóriában futó bináris)

Domain: 247.cdnflare[.]xyz (a kártevő letöltési kiszolgálója)

IP: 99.84.67[.]186:443 (command-and-control WebSocketen és TLS-en keresztül, a Sansec szerint)

IP: 88.216.72[.]181 (támadói forrás IP, a Sansec szerint)

IP: 5.181.86[.]133 (támadói forrás IP, tömeges küldéshez, a Disrex szerint)

A Sansec az eComscan szkennert javasolja az implantátum felderítésére, és közölte, hogy az 1.9.7-es verzió a Shield ügyfeleknél le is állítja a folyamatot.

Disrex egy áruház esetében ennek az ellenkezőjéről számolt be: az eComscan úgy futott, hogy engedélyezve voltak a háttérfolyamat- és az ütemezett feladat-ellenőrzések, miközben az implantátum aktív volt, 1728 cron sorral, mégis tisztának minősítette az áruházat. Disrex nem árulta el, melyik eComscan verzió futott, és mikor.

Jelenleg nincs telepíthető gyártói javítás. Amíg az Adobe nem ad ki javítócsomagot, addig a Sansec ideiglenes GraphQL-lezárása, a Disrex, a ProxiBlue és a Graycore által közzétett három nem hivatalos védekezés, valamint két, a hibától független szerverbeállítás jöhet szóba.

Disrex nginx és Apache szabályokat tett közzé, amelyek blokkolják azokat a kéréseket, amelyek URL-lekérdezésben (query stringben) hordozzák a kihasználáshoz használt paramétereket. Egy éles áruházon végzett saját tesztje azonban megmutatta a korlátokat: ugyanazok a paraméterek, ha POST törzsben érkeztek, eljutottak a PHP-ig, ahogy JSON törzsben is, mert nginx és Apache csak a query stringet vizsgálja – írta Disrex. Úgy fogalmazott, hogy ezek a szabályok a jelenlegi kampányt állítják meg, nem magát a sebezhetőséget.

Disrex fő védelmi megoldása egy ellenőrzést ad három metódushoz a Magento dependency-injection kód-szkennereiben, és megakadályozza, hogy parancssoron kívül fussanak. A kézi módosítást minden composer install visszavonja, ezért Disrex composer-patches source patch formájában is kiadta, amely telepítéskor újra alkalmazza a módosítást, és elmondása szerint változtatás nélkül működik 2.4.6-tól 2.4.9-ig.

A három fájl egyike, a ClassesScanner.php legalább egy harmadik féltől származó modul, a mageplaza/module-admin-permissions esetében HTTP-n keresztül is meghívódik, és a védelem beépítése tönkreteszi a modul adminisztrációs felületét. Disrex ezért azt tanácsolja, hogy a rendszergazdák előbb keressenek rá a vendor könyvtárban, mielőtt hozzányúlnak.

A védelmet tesztkörnyezetben próbálták ki, nem egy futó áruházban, és Disrex szerint önmagában nem jelent teljes javítást. Egy GitHub felhasználó, ProxiBlue szeptember 5-én közzétette ugyanezt a védelmet, valamint három nem hivatalos javítócsomagot. Sem a Sansec, sem az Adobe nem erősítette meg, hogy valóban ezek a szkennerek jelentik a támadási lánc végpontját.

A Graycore, LLC szeptember 5-én egy Magento modult tett közzé a GitHub és a Packagist oldalán. A Graycore szerint a jelenlegi kód a támadási lánc három pontján erősíti meg a védelmet: az e-mail sablonok block direktívája elutasítja a backend blokkokat, a rácssor URL-generátor ellenőrzi az osztályt, mielőtt felépíti, és a Web API fatális hibajelentéseiben a PHP nyitó tagek használhatatlanná válnak.

A cikk írásakor a Packagisten elérhető verzió egy korábbi kiadás volt, amelynek egyetlen védelmi megoldása egy PayPal GraphQL resolverre irányult, ezt azóta eltávolították. A README-ben az áll, hogy „Ez megerősítés, nem javítás”, és figyelmeztet, hogy a sebezhetőség más útvonalai továbbra is nyitva maradnak, és lehet, hogy az áruházat már feltörték.

Disrex szerint két szerverbeállítás egyáltalán nem függ a támadási lánc ismeretétől. Két boltja közül az egyiknél a dropper által használt hat PHP függvény közül az első négy le volt tiltva; a proc_open nem, és a dropper ezt használta az implant elindítására, miközben az open_basedir nem korlátozta érdemben a gyermekfolyamatot.

Disrex szerint a legfontosabb védelem, hogy a PHP disable_functions listájához hozzáadják a proc_open-t, és a /tmp, /var/tmp, valamint a /dev/shm könyvtárakat noexec opcióval csatolják fel, hogy a letöltött bináris ne tudjon lefutni. Ezeket a rétegeket minden tárolóban szereplő szabály elé helyezi.

Ha az áruházat már megfertőzték, Disrex takarítási útmutatója meghatározza a sorrendet: először a bizonyítékokat kell megőrizni, a cron bejegyzést el kell távolítani, mielőtt kilövik a folyamatot, mert a folyamat visszaállítja; nem szabad újraindítani a gépet, mert lehet, hogy a /proc alatt lévő példány az egyetlen megmaradt bináris; és nem szabad composer install parancsot futtatni „takarítás” céljából, mert felülírja az időbélyegeket, amelyek megmutatják, mihez nyúltak hozzá.

Ezután azt javasolja, hogy ürítsék a munkamenet-tárolót, mivel az implant olvasta azt, majd forgassák meg az app/etc/env.php fájlban lévő crypt/key értéket, továbbá minden admin jelszót, minden fizetési szolgáltató API-kulcsát és az összes egyéb, abban a fájlban szereplő integrációs hitelesítési adatot.

A Nexcess és a Liquid Web tárhelyszolgáltatók szeptember 5-én azonos tartalmú incidensértesítést tettek közzé, amelyekben azt írták, hogy felülvizsgálják szerverkörnyezetüket, és megelőző intézkedéseket vezetnek be.

Egyikük sem állítja, hogy bizonyítottan feltörték volna bármelyik ügyfelüket, vagy hogy saját maguk reprodukálták volna a hibát. Disrex két boltja összesen 26 különböző forráscímet rögzített, ezek közül kettő tömegesen küldött kéréseket hoszting-infrastruktúráról, a többi pedig lakossági proxy pool volt, amelyek egyenként kettő és hat közötti kérést küldtek. Disrex szerint ha csak a Sansec közleményében szereplő egyetlen támadói címet tiltották volna, az a forgalom kevesebb mint egynegyedét állította volna meg. A támadók kilétét eddig senki sem nevezte meg.