Per vieną bendrą skriptą įsilaužėliai taikėsi į mokėjimo korteles: rizika interneto parduotuvėms

Sekite TechNaujienos Google

Interneto parduotuvėms kyla naujas priminimas, kad mokėjimo duomenys gali būti pavogti net neįsilaužus tiesiogiai į pačią parduotuvę. Saugumo tyrėjai pranešė apie kompromituotą bendrą analizės skriptą, kurį naudojo su „Convertr“ siejama platforma. Užpuolikai bandė pasinaudoti lankytojo atsiskaitymo metu veikiančiu kodu ir perimti mokėjimo kortelių informaciją.

Spalio 27–28 d. paskelbtame pranešime pateikiamos pagrindinės incidento detalės. Spalio 27 d. apie ataką rašė „BleepingComputer“. Pagrindinis metodas priskiriamas vadinamajam „web skimming“ arba „Magecart“ tipo atakoms: nusikaltėliai pakeičia į svetainę įkeliamą JavaScript failą, todėl piktybinis kodas gali veikti ten, kur pirkėjas tikisi saugaus atsiskaitymo. Tokie incidentai dažnai neprasideda nuo apsaugos spragos pačiame mokėjimo paslaugų teikėjuje.

Elektroninės prekybos svetainė įprastai įkelia ne tik savo kodą, bet ir analizės, reklamos, klientų aptarnavimo ar rinkodaros įskiepius. Vienas bendras išorinis failas gali būti naudojamas dešimtyse ar šimtuose skirtingų svetainių. Jei užpuolikas įgyja teisę jį pakeisti, nepageidaujamas kodas atsiranda iš karto daugelyje puslapių. Tai vadinama tiekimo grandinės ataka.

Prekybininkai dažnai daug investuoja į mokėjimų teikėjo sertifikatus, tačiau pamiršta, kad naršyklėje kartu veikia ir kitų tiekėjų skriptai. Jei atsiskaitymo puslapio kodą gali papildyti išorinė reklamos ar analitikos sistema, užpuolikui atsiveria galimybė apeiti dalį apsaugos mechanizmų neįsilaužus į pačios parduotuvės serverį. Dėl to techninis saugumo auditas turi apimti tai, kas realiai vykdoma pirkėjo naršyklėje, o ne vien serverio konfigūraciją. Tai aktualu net modernioms internetinėms parduotuvėms, kurios naudoja patikimus mokėjimo partnerius.

Naujausi straipsniai

4 min. skaitymo • prieš 11 minučių

Britanijos policijos duomenis saugantys tiekėjai buvo atakuoti ne kartą – auditas atskleidė pavojingą spragą

4 min. skaitymo • prieš 31 minutė

Danijoje įsilaužta į universitetą: 525 tūkst. žmonių duomenys atsidūrė pavojuje, teko keisti įėjimo kodus

4 min. skaitymo • prieš 51 minutė

„Apple“ skubiai taiso senesnius „iPhone“: spraga jau naudota tikslinėse atakose – patikrinkite atnaujinimus

Visi naujausi straipsniai →

Šios atakos dažnai vadinamos tiekimo grandinės pažeidimais, nes pažeistas vienas bendras komponentas gali tapti rizika daugeliui nesusijusių svetainių. Užsakovas neturėtų manyti, kad išorinis analitikos skriptas savaime yra mažos rizikos vien todėl, kad jis neskirtas mokėjimui. Svarbu, kokias teises naršyklėje jis turi ir kokius duomenis gali pasiekti. Net jei techninis skriptas įdėtas tik statistikai, jo vykdymas tame pačiame puslapyje gali turėti platesnes pasekmes. Todėl reikalingas aiškus žemėlapis: kuris tiekėjas, kuriame puslapyje ir kokiu tikslu gali vykdyti kodą.

Verslo savininkui svarbus ir pasirengimas incidentui. Jei atsiranda įtarimas, jog atsiskaitymo puslapis buvo kompromituotas, reikia išsaugoti tyrimui reikalingus žurnalus, nustatyti pažeisto kodo veikimo laikotarpį, įvertinti klientų duomenų riziką ir bendradarbiauti su mokėjimų partneriu. Negalima vien pašalinti matomo skripto ir paskelbti, kad incidentas baigtas – reikia patikrinti, ar užpuolikas neturi kitų prieigos būdų. Lietuvoje tokie atvejai gali turėti ir asmens duomenų apsaugos prievolių, priklausomai nuo to, kokia informacija galėjo būti paveikta.

Kaip atsiranda grėsmė ir ką ji reiškia

Tokio užkrato ypatybė – parduotuvė gali atrodyti visiškai įprastai. Krepšelis veikia, apmokėjimo mygtukas matomas, o pirkėjas nebūtinai pastebi papildomą duomenų kopijavimą naršyklėje. Dėl to vien vizualinis puslapio patikrinimas nėra patikima kontrolė. Tikrinami faktiniai tinklo prašymai, įkeliami skriptai ir netikėti jų pakeitimai.

Ši istorija svarbi ir Lietuvos elektroninėms parduotuvėms, kurios dažnai naudoja išorines rinkodaros bei analitikos sistemas. Kol kas viešai nepatvirtinta, kad nukentėjo konkreti Lietuvos parduotuvė, todėl būtų neteisinga vardyti atsitiktinius vietinius prekės ženklus. Tačiau tiekimo grandinės rizika universali: kodas veikia kliento naršyklėje nepriklausomai nuo to, kur registruota parduotuvė.

Šis atvejis taip pat parodo skirtumą tarp internetinės parduotuvės serverio saugumo ir atsiskaitymo puslapio saugumo pirkėjo įrenginyje. Net jei serveris tvarkingai atnaujintas, iš trečiosios šalies įkeliamas kodas gali būti pakeistas be parduotuvės administratoriaus žinios. Todėl svarbu stebėti kritinių puslapių turinį ir palaikyti technines ribas, kurios neleis bet kuriam išoriniam skriptui skaityti jautrių formos laukų. Kibernetinis saugumas šioje vietoje susijęs ir su verslo sprendimais: kiekvienas naujas reklamos įskiepis suteikia rinkodaros galimybių, bet gali padidinti riziką. Sprendimą dėl jo įdiegimo turėtų priimti ne tik rinkodaros, bet ir už saugumą atsakingi darbuotojai.

Ką turi žinoti Lietuvos naudotojai ir įmonės

Administratorių veiksmai turėtų apimti išorinių scenarijų inventorizaciją, turinio saugumo politikos nustatymus, įkeliamų failų vientisumo kontrolę ir mokėjimo puslapio elgesio stebėseną. Ypač svarbu atskirti tuos scenarijus, kuriems tikrai reikia veikti atsiskaitymo metu, nuo rinkodaros įskiepių, kurių ten gali ir nebūti. Toks ribojimas mažina potencialų atakos paviršių.

Pirkėjams patarimas paprastesnis: verta įjungti banko pranešimus apie operacijas, naudoti papildomą mokėjimų patvirtinimą ir nedelsiant pranešti bankui apie neatpažintus nurašymus. Tai negali savaime užkirsti kelio pažeistam skriptui, bet padeda greičiau pastebėti galimą žalą. Įmonėms išvada griežtesnė: kiekvienas trečiosios šalies kodas atsiskaitymo lange yra saugumo sprendimas, ne vien rinkodaros pasirinkimas. Plačiau apie susijusias technologijų saugumo problemas rašėme ankstesniame „TechNaujienos.lt“ straipsnyje.