E-prekybos skimerių slaptoji evoliucija: kaip WebRTC apeina skaitmeninį griovį

Šokiruojantis „PolyShell“ išnaudojimų greitis

Savaitę po 2026 m. kovo 19 d. stulbinantys 56,7 % visų pažeidžiamų „Magento“ ir „Adobe Commerce“ parduotuvių buvo kompromituoti vienos išnaudojimo grandinės. Ši statistika reikalauja griežtos, analitinės sisteminių trūkumų, leidusių tokiai greitai ir plačiai paplisti infekcijai, apžvalgos. Mes matome ne tik standartinį kenkėjiškos programinės įrangos protrūkį; mes stebime sudėtingo atakos vektoriaus atsiradimą, kuris paverčia teisėtus saityno protokolus ginklais, kad tradiciniai saugumo perimetrai taptų nebeaktualūs.

Užkulisiuose šios skaitmeninės epidemijos katalizatorius yra pažeidžiamumas, žinomas kaip „PolyShell“. Šis trūkumas veikia „Magento Open Source“ ir „Adobe Commerce“, suteikdamas neautorizuotiems užpuolikams galimybę įkelti savavališkus vykdomuosius failus per REST API. Pasiekę kodo vykdymą, užpuolikai nesustoja ties serverio valdymu. Jie įdiegia itin specializuotą mokėjimų skimerį, kuris reprezentuoja reikšmingą šuolį slaptojo sekimo technologijose.

Veidrodžio sudaužymas: kaip WebRTC apeina CSP

Daugelį metų saugumo profesionalai pasikliovė turinio saugumo politika (angl. Content Security Policy, CSP) kaip tvirta gynyba nuo scenarijų vykdymo tarp svetainių (XSS) ir duomenų nutekinimo. Pagal sumanymą, gerai sukonfigūruota CSP nurodo naršyklei, kuriais domenais tiksliai pasitikėti. Jei kenkėjiškas skriptas bando išsiųsti pavogtus kredito kortelių duomenis į neautorizuotą serverį per standartinę HTTP užklausą, naršyklė ją blokuoja.

Tačiau „PolyShell“ skimeris naudoja subtilų apėjimą: WebRTC („Web Real-Time Communication“) duomenų kanalus. Iš pradžių sukurti mažos delsos tiesioginiam ryšiui tarp vartotojų (peer-to-peer) — pavyzdžiui, vaizdo skambučiams ar dalijimuisi failais — WebRTC leidžia duomenims tekėti tiesiogiai tarp klientų arba į STUN/TURN serverį.

Praktikoje daugelis CSP įgyvendinimų nėra pakankamai detalūs, kad atsižvelgtų į WebRTC. Nors saugumo komanda gali griežtai stebėti connect-src tradiciniams API iškvietimams, decentralizuota WebRTC prigimtis dažnai lieka nepastebėta. Skimeris naudoja šiuos duomenų kanalus savo kenkėjiškam kroviniui įkelti ir jautriai mokėjimo informacijai nutekinti. Žiūrint iš rizikos perspektyvos, tai paverčia teisėtą funkciją skaitmeniniu Trojos arkliu, leidžiančiu pavogtiems duomenims apeiti tradicinio tinklo filtravimo „pilis ir griovius“.

„PolyShell“ atakos anatomija

Atakos paviršiaus įvertinimas atskleidžia daugiapakopį procesą, kuris yra toks pat efektyvus, kaip ir kenkėjiškas. Ataka prasideda nuo REST API išnaudojimo — kritiškai svarbaus šiuolaikinės e-prekybos komponento, kuris dažnai paliekamas atviras dėl sąveikos poreikio. Kadangi pažeidžiamumas leidžia atlikti neautorizuotus įkėlimus, patekimo barjeras yra pavojingai žemas.

Kai užpuolikas įsitvirtina, jis įterpia skriptą į atsiskaitymo puslapį. Įdomu tai, kad šis skriptas nesielgia kaip skimeriai prieš penkerius metus. Prisimenu, kaip tyriau ankstyvuosius „MageCart“ incidentus, kai kenkėjiška programa tiesiog siųsdavo GET užklausą su „base64“ koduotais duomenimis URL adresu. Tai buvo triukšminga ir lengvai pastebima serverio žurnaluose. Priešingai, „PolyShell“ skimeris yra beveik nematomas. Naudojant WebRTC, srautas atrodo kaip standartinis tiesioginio ryšio pasisveikinimas (handshake), todėl teismo ekspertizė tampa košmaru incidentų tyrėjams, kurie ieško tik įtartinų HTTP POST užklausų.

Kodėl vien pleistrų neužtenka

Saugumo pataisų (pleistrų) diegimas dažnai lyginamas su skylių kamšymu laivo korpuse, ir nors tai būtina, tai retai kada yra išsamus sprendimas pats savaime. Nepaisant to, kad pataisos yra prieinamos, „PolyShell“ plitimo greitis — kai masiniame skenavime dalyvauja daugiau nei 50 IP adresų — rodo, kad daugelis organizacijų nespėja su grėsmių kaita.

Architektūriniu lygmeniu problema slypi prigimtiniame pasitikėjime, kurį suteikiame trečiųjų šalių skriptams ir integruotoms naršyklės funkcijoms. Kai parduotuvė kompromituojama, duomenų saugumo pažeidimas veikia kaip naftos išsiliejimas; žala aplinkai ir reputacijai plinta toli už pradinio poveikio taško. Galutiniam vartotojui patirtis yra skaidri ir atrodo saugi, tačiau jų jautriausi finansiniai duomenys yra nukreipiami per šifruotą, decentralizuotą kanalą tiesiai į grėsmės sukėlėjo rankas.

Proaktyvūs veiksmai: gynybinės priemonės

Norėdamos sukurti atsparesnę gynybą nuo šios naujos kartos skimerių, organizacijos turi žvelgti toliau nei standartinės konfigūracijos. Proaktyvi saugumo pozicija reikalauja daugialypio požiūrio į duomenų vientisumą ir privatumą.

1. REST API prieigos auditas: Įsitikinkite, kad jūsų „Magento“ ar „Adobe Commerce“ REST API nėra pasiekiamas viešajame internete, nebent tai absoliučiai būtina. Įdiekite griežtus IP baltuosius sąrašus arba stiprius autentifikavimo sluoksnius.
2. Sustiprinkite CSP direktyvas: Jūsų turinio saugumo politika turi būti atnaujinta, kad apimtų WebRTC. Tiksliau, peržiūrėkite connect-src direktyvą ir apsvarstykite galimybę naudoti media-src arba specifinius su WebRTC susijusius apribojimus, jei jūsų platforma juos palaiko.
3. Vientisumo stebėjimas: Naudokite failų vientisumo stebėjimą (FIM), kad aptiktumėte neautorizuotus e-prekybos kodo pakeitimus. Kadangi skimeris turi būti įterptas į vartotojo sąsają (frontend), bet koks atsiskaitymo logikos pakeitimas turėtų sukelti neatidėliotiną įspėjimą.
4. Elgsenos analizė: Ieškokite neįprasto WebRTC srauto, kylančio iš jūsų atsiskaitymo puslapių. Pagal šią struktūrą bet koks P2P ryšys, inicijuotas iš puslapio, kuriame turėtų būti tik apdorojami mokėjimai, yra didžiulė „raudona vėliava“.

Galiausiai, „PolyShell“ incidentas primena, kad tinklo perimetras yra pasenusi sąvoka sudėtingų kliento pusės atakų amžiuje. Kiekvieną naršyklės funkciją privalome vertinti kaip potencialų duomenų nutekinimo kelią.

Veiksmai, kurių reikia imtis

Jei naudojate „Magento Open Source“ arba „Adobe Commerce“, jūsų neatidėliotinas prioritetas yra patikrinti savo pataisų lygį dėl „PolyShell“ pažeidžiamumo. Užkimšę skylę, atlikite savo atsiskaitymo skriptų teismo ekspertizės auditą, kad įsitikintumėte, jog šiuo metu nėra aktyvių WebRTC pagrindu veikiančių skimerių. Nelaukite pranešimo iš savo mokėjimų apdorojimo paslaugų teikėjo; šios atakos greitis rodo, kad kol apie ją išgirsite, duomenys jau gali būti parduoti tamsiajame žiniatinklyje (dark web).

Šaltiniai:

• Sansec Threat Intelligence Report on WebRTC Skimmers.
• Adobe Security Bulletin for Magento and Adobe Commerce.
• WebRTC Protocol Specifications and Security Guidelines.