Kā atklāt un izanalizēt interneta veikala kompromitēšanu

Dažreiz interneta veikala uzlaušana neizskatās pēc klasiskas vietnes sabojāšanas. Veikals var atvērties, katalogs var darboties, daļa pasūtījumu var tikt noformēta, bet pati problēma izpaužas tikai vienā vietā — piemēram, grozā, apmaksas posmā vai neatbilstībā starp veikto maksājumu un pasūtījumu vēsturi.

Tieši šāds scenārijs ir īpaši bīstams. Tas ne vienmēr uzreiz ļauj saprast, ka runa nav par moduļa kļūdu vai nejaušu integrācijas problēmu, bet gan par secīgu kompromitēšanu ar vairākiem posmiem: iekļūšana sistēmā, nostiprināšanās, slēpta maksājumu plūsmas aizstāšana un mēģinājums gūt peļņu.

Zemāk — praktisks šāda incidenta atklāšanas piemērs, skarto failu loks un testu kopums, kas palīdz noteikt infekciju un apstiprināt, ka uzlaušanas aktīvā fāze patiešām ir apturēta.

Kā incidents attīstījās

Pēc iekšējās izmaiņu hronoloģijas kļuva skaidrs, ka uzbrukums attīstījās pakāpeniski, nevis vienā brīdī.

Sākumā tika skarts vietnes katalogs. Tas bija agrīnais kompromitēšanas posms, kad failu struktūrā parādījās izmaiņas, kas neatbilda ierastajai veikala darbībai. Aptuveni pēc divām nedēļām sekoja nākamais uzbrucēju solis: tika izveidoti vai nostiprināti papildu piekļuves punkti — backdoor faili un palīgfaili, kas ļāva atkārtoti atgriezties sistēmā un turpināt iejaukšanos arī pēc daļējas tīrīšanas.

Pēc tam iestājās relatīvs klusuma periods. No malas varēja šķist, ka viss aprobežojās ar lokālām izmaiņām, taču patiesībā tas bija tikai sagatavošanās posms.

Apmēram pēc diviem mēnešiem notika pirmais acīmredzamais biznesa incidents: tika kompromitēta one-page checkout lapa. Grozā parādījās saite uz ārēju karšu maksājumu procesoru. Šai saitei nebija nekāda sakara ar veikala standarta maksājumu shēmu, un tā novirzīja lietotāju uz svešu apmaksas maršrutu. Šajā posmā aizstāšana tika pamanīta un noņemta, kas ļāva uz laiku apturēt pirmo krāpniecības scenāriju.

Tomēr izmeklēšana parādīja, ka tas nebija incidents beidzies, bet tikai viens no epizodēm. Aptuveni pēc trim nedēļām pēc svešās saites noņemšanas sekoja nākamais uzbrukuma posms — jau maksājumu moduļa līmenī. Rezultātā Google Pay un Apple Pay maksājumi sāka tikt novirzīti nevis pa standarta shēmu, bet gan uzbrucēju virzienā. Vienlaikus pirkumi netika fiksēti veikala vēsturē: sistēmā neradās normāli pasūtījumi, neveidojās sagaidāmie maksājumu ieraksti, un administratoram tas varēja izskatīties kā noslēpumaina pasūtījumu pazušana.

Kādas pazīmes atklāja problēmu

Šādos incidentos reti ir viens ideāls indikators. Parasti aina veidojas no vairākiem satraucošiem signāliem:

• checkout lapā parādās lieka saite vai negaidīts apmaksas maršruts;
• klients pabeidz apmaksu, bet pasūtījums neparādās veikala vēsturē;
• mainās faili, kurus neviens no administratoriem nav rediģējis;
• sistēmā paliek servisa piekļuves punkti, kas der atkārtotai iekļūšanai;
• izmaiņu laika intervāli ir izstiepti nedēļās, kas liecina par atkārtotu uzbrucēja atgriešanos;
• daļa mainīto failu izskatās gandrīz normāli, bet ir pārveidoti aizdomīgā laikā;
• ir plaisa starp apmaksas loģiku frontendā un to, kas patiesībā tiek reģistrēts pasūtījumu sistēmā.

Kādi faili tika skarti vai prasīja atsevišķu pārbaudi

Izmeklēšanā ir svarīgi godīgi nošķirt divas grupas: faili, kas tiešām tika mainīti aizdomīgā laikā un nonāca galvenajā pārbaudes lokā, un standarta sistēmas faili, kas paši par sevi nenozīmē uzlaušanu, bet obligāti tiek analizēti kā iespējamie ieejas punkti.

1. Aizdomīgi mainīti vai skarti faili

Incidenta ietvaros uzmanību piesaistīja šādi failu tipi:

• lietotnes konfigurācijas fails ar pieslēguma parametriem un atslēgām;
• maksājumu moduļa kontrolieris;
• groza AJAX kontrolieris;
• atsauksmju, abonēšanas un wish-list moduļu kontrolieri;
• atsevišķi faili vietnes saknē;
• servisa PHP faili, kas parādījās vai tika mainīti netipiskā laikā.

Tipisks saraksts ar to, kas šādā izmeklēšanā parasti nonāk uzmanības lokā:

• app/config/parameters.php
• modules/.../controllers/front/payment.php
• modules/.../controllers/front/ajax.php
• modules/.../controllers/front/verification.php
• modules/.../controllers/front/lists.php
• modules/.../controllers/front/PostComment.php
• faili saknē, piemēram, phpinfo.php.

2. Potenciāli bīstami standarta ieejas punkti, kas tika obligāti pārbaudīti

Papildus vienmēr tiek analizēti faili, caur kuriem uzbrucējs var atvieglot sev piekļuvi, datu augšupielādi vai lejupielādi:

• failu pārvaldnieks administrācijas daļā;
• servisa failu augšupielādes apstrādātājs;
• backup failu lejupielādes apstrādātājs;
• veci administratīvie skripti;
• upload maršruti;
• jebkādi novecojuši palīgi darbam ar failiem.

Tipiskā gadījumā tas izskatās šādi:

• admin.../filemanager/upload.php
• admin.../backup.php
• dažādi veci ajax.php, drawer.php, get-file-admin.php;
• servisa upload/download apstrādātāji;
• saknes phpinfo.php.

3. Katalogi, kuros meklēja nostiprināšanās pēdas

Atsevišķi tika pārbaudīti:

• config/
• controllers/
• override/
• classes/
• modules/
• administrācijas katalogs;
• vietnes sakne;
• attēlu katalogi, meklējot nestandarta index.php;
• vietas, kur varēja parādīties slēpti augšupielādētāji vai mini backdoor faili.

Kāpēc nedrīkst uzskatīt par aizdomīgu jebkuru atrasto eval, base64_decode vai move_uploaded_file

Viena no biežākajām kļūdām izmeklēšanā ir pasludināt par ļaunprātīgu jebkuru failu, kurā sastopamas biedējošas funkcijas. Tas ir nepareizi.

Daudzās CMS un moduļos pilnīgi leģitīmi sastopami:

• move_uploaded_file() — attēlu un failu augšupielādes formās;
• base64_decode() — API, PDF bibliotēkās, kriptogrāfijā, logotipos, webhook risinājumos;
• php://input — API, webhook un AJAX apstrādātājos;
• gzuncompress() — PDF un grafikas bibliotēkās;
• eval() — vecākā CMS kodolā, autoload mehānismos un moduļu loģikā.

Tāpēc bīstama nav pati funkcija, bet gan tās konteksts:

• fails nesen mainīts bez saprotama iemesla;
• tas atrodas netipiskā vietā;
• tas neatbilst oficiālajai versijai;
• tas pievieno ārēju URL;
• tas aizstāj payment flow;
• tas veido slēptu piekļuves kanālu;
• tas nav saistīts ar vietnes biznesa loģiku.

Testu kopums, kas palīdz atklāt infekciju

Zemāk ir praktisks pārbaužu saraksts, ko ir lietderīgi veikt, ja ir aizdomas par interneta veikala kompromitēšanu.

1. Nesen mainīto PHP failu meklēšana

Pirmais tests — atrast visus PHP failus, kas mainīti aizdomīgajā periodā, izslēdzot kešu, vendor, upload un media direktorijas. Tas ļauj ātri sašaurināt pārbaudi līdz patiešām skartajiem failiem.

Ko skatīties:

• izmaiņu datumu;
• faila īpašnieku;
• netipiskus izmaiņu logus;
• masveida izmaiņas vairākos failos vienā un tajā pašā laikā.

2. Mainīto failu sintakses pārbaude

Katru aizdomīgo PHP failu ir vērts pārbaudīt ar php -l.

Tas tieši neatklāj uzlaušanu, bet dod svarīgu informāciju:

• vai fails ir izpildāms vai bojāts;
• vai tā ir nejauša bojāšana vai rūpīgi ievietots kods;
• vai uzbrucējs centās atstāt darbināmu failu.

3. Bīstamu funkciju meklēšana kodā

Nākamais tests — meklēšana pēc šādiem šabloniem:

• eval(
• assert(
• base64_decode(
• gzinflate(
• gzuncompress(
• str_rot13
• shell_exec
• system(
• passthru
• proc_open
• popen
• php://input
• file_put_contents
• move_uploaded_file
• aizdomīgi include un require.

Tas nav galīgais spriedums, bet filtrs manuālai analīzei.

4. Failu pārbaude vietnes saknē

Jebkuri PHP faili vietnes saknē pelna atsevišķu uzmanību, īpaši, ja tie ir:

• phpinfo.php;
• testa augšupielādētāji;
• veci atkļūdošanas skripti;
• pagaidu migrācijas faili;
• vienreiz lietotas servisa lapas.

Pat ja šāds fails ir nekaitīgs, tas paplašina uzbrukuma virsmu.

5. Administrācijas failu pārvaldnieku un backup skriptu pārbaude

Ja administrācijas daļā ir failu pārvaldnieks, failu augšupielāde, rezerves kopiju lejupielāde vai novecojuši apkalpošanas skripti, tie jāizlasa atsevišķi. Tieši šādi punkti bieži kļūst par ērtu rīku gan sākotnējai iekļūšanai, gan atkārtotai nostiprināšanai.

6. PHP koda meklēšana neparedzētos failos

Atsevišķi jāmeklē ne tikai .php, bet arī jebkuri faili, kas satur <?php:

• .txt
• .ico
• .jpg
• .phtml
• .phar
• pagaidu faili;
• faili bez paplašinājuma.

Šis tests palīdz atrast maskētus failus.

7. Attēlu katalogu un iekšējo index.php pārbaude

Liels skaits index.php attēlu katalogos pats par sevi vēl var būt norma, taču svarīgi pārbaudīt:

• vai tie sakrīt ar tipisko saturu;
• vai tie neatšķiras pēc izmēra;
• vai tie nesatur lieku kodu;
• vai tie nav parādījušies viļņveidīgi aizdomīgos datumos.

8. Salīdzināšana ar tīru CMS un moduļu versiju

Ļoti svarīgs tests — salīdzināt mainītos failus ar oficiālajiem oriģināliem:

• CMS kodolu;
• maksājumu moduli;
• grozu;
• checkout moduli;
• trešo pušu integrācijām.

Tieši tā visbiežāk tiek atrasta slēpta saites ievietošana, redirect aizstāšana, webhook loģikas nomaiņa vai ārēja URL ieviešana.

9. Maksājumu plūsmas manuāla pārbaude

Nepietiek tikai lasīt kodu, jāpārbauda arī biznesa loģika:

• kas notiek pēc apmaksas pogas nospiešanas;
• uz kurieni ved saite;
• kādi URL tiek izsaukti;
• vai sistēmā parādās pasūtījums;
• vai mainās groza statuss;
• vai tiek izveidots maksājuma ieraksts;
• kas notiek Google Pay, Apple Pay un card payment gadījumā.

Ja nauda aiziet, bet pasūtījums neparādās, tas ir viens no spēcīgākajiem kompromitēšanas indikatoriem.

10. Web servera un PHP logu pārbaude

Jāskatās:

• access.log
• error.log
• php-fpm logs
• maksājumu moduļu logi;
• webhook logi.

Jāmeklē:

• negaidīti POST pieprasījumi;
• pieprasījumi uz nestandarta kontrolieriem;
• upload un ajax apstrādātāju izsaukumi;
• anomālas pārejas uz ārējiem URL;
• pieprasījumi uz slēptiem servisa maršrutiem.

11. Tiesību un failu īpašnieku pārbaude

Svarīgi pārliecināties, ka:

• faili pieder paredzētajam lietotājam;
• web katalogos nav pēkšņu root īpašumā esošu failu;
• tiesības nav pārāk plašas;
• upload katalogi bez vajadzības nav izpildāmi.

12. Atkārtotu izmaiņu parādīšanās pārbaude

Ļoti svarīgs tests pēc tīrīšanas ir novērošana. Ja pēc ļaunprātīgā koda noņemšanas pēc dažām dienām vai nedēļām atkal parādās izmaiņas citos failos, tas nozīmē, ka sākotnējais ļaunprātīgais kods nav pilnībā noņemts, ir palicis backdoor vai kompromitācija notiek caur paneli, moduli vai nozagtiem piekļuves datiem.

Kas šādās izmeklēšanās ir īpaši svarīgi

Galvenā kļūda ir apstāties pie pirmā atrastā simptoma.

Ja jūs atradāt un izdzēsāt ļaunprātīgu saiti grozā, tas vēl nenozīmē, ka problēma ir atrisināta. Aprakstītajā gadījumā tieši tā arī notika: sākumā tika atrasta un noņemta saite uz ārēju karšu maksājumu procesoru, bet pēc trim nedēļām izrādījās, ka uzbrucējs piekļuvi bija saglabājis un jau bija iejaucies maksājumu modulī dziļāk. Rezultātā Google Pay un Apple Pay sāka darboties uzbrucēja interesēs, bet pirkumi netika fiksēti veikala vēsturē.

Praktiskie secinājumi

Pēc izmeklēšanas var izdarīt vairākus svarīgus secinājumus.

1. Interneta veikala uzlaušana bieži attīstās viļņveidīgi. Sākumā notiek sagatavošanās un nostiprināšanās, pēc tam pauze, bet vēlāk biznesa uzbrukums maksājumiem.
2. Ja cieš checkout, nepietiek pārbaudīt tikai groza veidnes. Obligāti jāanalizē maksājumu kontrolieri, redirect loģika, webhook un pasūtījumu vēsture.
3. Nedrīkst aprobežoties ar viena ļaunprātīga faila meklēšanu. Jāskatās visa notikumu ķēde, izmaiņu intervāli un anomāliju atkārtošanās.
4. Servisa faili, piemēram, phpinfo.php, filemanager, backup skripti un upload apstrādātāji, strauji palielina risku. Tos vajadzētu vai nu dzēst, vai stingri ierobežot.
5. Labākais veids, kā pārliecināties, ka uzbrukuma aktīvā fāze ir apturēta, ir pilns pārbaužu cikls. Faili, logi, tiesības, maksājumu plūsma, salīdzināšana ar oriģināliem un novērošana pēc tīrīšanas ir jāuztver kā vienots process.

Noslēgums

Šis incidents parādīja tipisku, bet ļoti bīstamu shēmu: sākumā failu struktūras kompromitēšana, pēc tam nostiprināšanās caur backdoor failiem, tad checkout lapas uzvedības aizstāšana un vēlāk — iejaukšanās pašā maksājumu modulī.

No ārpuses tas var izskatīties kā dīvaina groza kļūda vai problēmas ar pasūtījumu fiksēšanu. Praksē tā var būt labi laikā izstiepta uzbrukuma shēma, kurā uzbrucējs vispirms iegūst piekļuvi, pēc tam to saglabā un vēlāk sāk novirzīt naudu, aizstājot maksājumu plūsmu.

Tāpēc jebkurš gadījums, kad grozā parādās lieka saite, pircējs apmaksā pasūtījumu, bet ieraksts sistēmā neparādās, maksājumu moduļa kods mainās bez saskaņotiem darbiem un starp incidentiem ir vairāku nedēļu intervāli, ir jāuzskata par pilnvērtīgu kompromitēšanu, kamēr nav pierādīts pretējais.

🛡️ Nepieciešama veikala pārbaude pēc uzlaušanas?

SOLLER.LV palīdzēs veikt tehnisko auditu, pārbaudīt checkout un maksājumu moduļus, atrast nostiprināšanās pēdas, salīdzināt failus ar oriģināliem un novērtēt, vai kompromitēšanas aktīvā fāze ir apturēta.