StyleSmuggler napadi pogađaju Magento i Adobe Commerce prodavnice
Sansec je 5. septembra upozorio da se nova neispravljena ranjivost, nazvana StyleSmuggler, aktivno koristi protiv Magento Open Source i Adobe Commerce prodavnica. Napad ne zahteva prijavu, omogućava izvršavanje koda na serverskoj strani i postavlja trajni pristup napadača. Sansec je kompletan lanac bez autentikacije ponovio na čistim Magento Open Source instalacijama 2.4.7, 2.4.8 i 2.4.9, dok je prvi zabeleženi slučaj koristio 2.4.6-p15 sa julskim i avgustovskim bezbednosnim ažuriranjima.
Do 6. septembra Adobe nije objavio CVE oznaku, savet, zakrpu niti zvanično privremeno rešenje. Sansec nije objavio potpunu reprodukciju za Adobe Commerce i Adobe Commerce on Cloud, pa proizvođač još nije potvrdio tačan obuhvat izdanja. Prema navodima Sanseca, napadi su počeli 4. septembra, a broj kompromitovanih prodavnica nije saopšten.
Kako se izvršava napad
Prema opisu Sanseca, napadač najpre upisuje PHP kod u datoteku koju Magento sam generiše, na primer prilikom kreiranja izveštaja o grešci. Zatim aktivira standardni Magento imejl „Payment Transaction Failed Reminder“, pri čemu se zlonamerni kod izvršava tokom prikaza poruke. Nije potrebno da korisnik otvori poruku, a napad može uspeti i kada isporuka imejla ne uspe.
Disrex Group je prijavio dva kompromitovana i jedan neuspešan pokušaj napada 5. septembra. Njihova analiza opisuje binarni implant koji se predstavlja kao Linux nit [kworker/u:8:0], čuva se van web korena, pod korisničkim direktorijumom sajta, i ponovo pokreće cron zadatkom svakih pet minuta. U jednom slučaju cron stavka je bila ponovljena 1.728 puta, a implant ju je vraćao gotovo odmah nakon uklanjanja.
Indikatori i ograničenja provere
Sansec preporučuje pretragu direktorijuma var/report za oznakom X_TRACE_, ali Disrex navodi da su njihove dve infekcije koristile var/log/system.log. Zaglavlja su se menjala tokom dana, pa provera ne bi trebalo da zavisi samo od jedne doslovne oznake. Disrex takođe navodi da TypeError poruka iz array_merge() posle uključivanja datoteke može biti trag uspešne eksploatacije, ali da tiša varijanta može ostaviti bez zapisa.
Za proveru procesa bitno je razlikovati stvarnu kernel nit od imitacije: autentična nit je u vlasništvu root korisnika i nema rezidentnu memoriju. Braketirani naziv procesa pod korisnikom sajta, uz stvarnu potrošnju memorije, zahteva istragu. Disrex preporučuje proveru binarnog fajla i izvršne slike iz /proc/<pid>/exe, jer je na jednoj prodavnici aktivni proces bio drugačije verzije od fajla na disku.
Privremene mere dok nema zakrpe
Sansec preporučuje privremeno isključivanje GraphQL-a za prodavnice koje ne koriste njegov Shield proizvod. To može uticati na headless i PWA izloge, dok klasični i Hyvä izlozi uglavnom ne zavise od GraphQL-a. Mrežna pravila koja blokiraju poznate parametre u URL upitu mogu usporiti trenutnu kampanju, ali Disrex upozorava da POST i JSON telo zahteva mogu proći do PHP-a.
Nezvanične izmene Magento koda i moduli drugih autora opisuju se kao dodatno očvršćavanje, a ne kao potpuna ispravka. Njihovo uvođenje zahteva proveru kompatibilnosti sa postojećim modulima i kontrolisano testiranje. Kao širi sloj zaštite, Disrex predlaže onemogućavanje funkcije proc_open i montiranje /tmp, /var/tmp i /dev/shm sa opcijom noexec, uz napomenu da takve mere treba proceniti u odnosu na radno opterećenje prodavnice.
Postupak u slučaju sumnje na kompromitaciju
Kada se pronađu indikatori, Disrex savetuje da se najpre sačuvaju dokazi, zatim ukloni cron stavka pre gašenja procesa, jer je implant može obnoviti. Ne preporučuje se restart servera ako kopija iz /proc predstavlja jedini preostali trag binarnog fajla, niti pokretanje composer install pre očuvanja vremenskih oznaka izmenjenih datoteka. Pošto je implant mogao da čita Magento sesije iz Redis-a, preporučeni koraci obuhvataju brisanje sesija i rotaciju Magento naloga, ključa crypt/key, API ključeva platnih provajdera i drugih kredencijala iz app/etc/env.php.
Rizik je posebno važan u kontekstu napadi na e-trgovinske platforme posle zakrpe gde su napadi na e-trgovinske platforme usledili ubrzo po objavi bezbednosnih informacija. Dok Adobe ne objavi zvaničnu zakrpu, poslovni prioritet je proveriti izloženost GraphQL-a, nadgledati indikatore kompromitacije i unapred pripremiti postupak za očuvanje dokaza, oporavak sesija i rotaciju pristupa.