Balta lapa un 854 kaitīgi faili: uzlauztas WordPress vietnes anatomija

Jūlija sākumā kāda Latvijas uzņēmuma mājaslapa pārstāja atvērties. Servera kļūdas nebija — atbilde nāca ar kodu 200, tikai pilnīgi tukša. Kad administrators atvēra vadības paneli, tas strādāja kā parasti, un tas radīja mānīgu sajūtu, ka vaina ir kaut kur sīkumā. Patiesībā inficēts bija viss koplietošanas hostinga konts: vairāki desmiti domēnu, kas klusām ražoja mēstuļu lapas Google indeksam.

itn rīcībā ir pilns šī incidenta izmeklēšanas pārskats. Vietnes īpašnieks atļāva stāstu publicēt bez nosaukuma, un tas ir tā vērts — shēma, pēc kuras uzbrucēji strādāja, Latvijas koplietošanas hostingos atkārtojas atkal un atkal. Lūk, kā tā izskatās no iekšpuses.

Balta lapa, kas nav kļūda

Tīrā WordPress instalācijā fails index.php sver ap 400 baitiem. Šajā vietnē tas svēra 41 kilobaitu, un faila sākumā stāvēja viena gara rinda:

eval(gzinflate(base64_decode("Fx3HrpzaFkX/5b...")))

Tas ir klasisks paņēmiens, kā paslēpt kodu no acīm un no vienkāršiem meklētājiem: īstā programma glabājas saspiestā un pārkodētā veidā un atarhivējas tikai izpildes brīdī. Kad kāda šī koda daļa uz konkrētā servera neizpildās, PHP apstājas ar fatālu kļūdu. Publiskajā serverī kļūdu paziņojumi ir izslēgti, tāpēc apmeklētājs saņem tukšu, baltu lapu.

Baltā lapa uzbrucējam pat traucē — tā piesaista uzmanību. Bet vadības panelis publiskās daļas index.php neizmanto, tāpēc tas turpināja strādāt un maskēja problēmas mērogu.

Ko uzbrucēji īsti gribēja

Datu zādzība šeit nebija mērķis. Inficētās vietnes tika izmantotas kā platforma meklētājprogrammu mēstulēm — nozarē tās sauc par durvju lapām (doorway). Pazīmes no pārskata:

• fails robots.txt norādīja uz 70 viltus vietnes kartēm (sitemap384.xml un līdzīgām), kādas WordPress pats nekad neveido;
• katra karte saturēja tūkstošiem adrešu formā ?c=47504141494, aiz kurām ģenerējās lapas par viltotām precēm, medikamentiem un azartspēlēm;
• domēna saknē bija iemests svešs Google verifikācijas fails — uzbrucējs bija pieslēdzis vietni savam Search Console kontam, lai ērti sekotu, kā viņa mēstules indeksējas.

Triks balstās maskēšanā (cloaking): Google robotam ļaunatūra pasniedz mēstuļu lapas, bet dzīvam apmeklētājam — tukšumu vai novirzīšanu. Vecas vietnes reputācija meklētājā ir vērtīga manta, un tieši to šeit zaga. Google šādu praksi tieši aizliedz, un ilgtermiņā inficētā vietne pati izkrīt no rezultātiem.

Kā viņi tika iekšā

Pārskats nosauc trīs tipiskos ceļus, un šajā gadījumā strādāja vismaz pēdējais. Pirmais — nozagtas vai vājas cPanel, FTP vai WordPress paroles. Otrais — novecojis spraudnis; kontā bija arī failu pārvaldnieks, paplašinājumu tips, kam vēsturē ir bijuši caurumi ar failu augšupielādi bez atļaujas. Trešais ceļš ir koplietošanas hostinga specifika: visas konta vietnes darbojas zem viena sistēmas lietotāja, tāpēc pietiek ielauzties vienā, lai skripts izmētātu slēptās piekļuves failus pa visām pārējām mapēm.

Tieši tāpēc ļaunatūra bija atrodama gandrīz katrā konta domēnā — arī tajos, kam ar sākotnējo caurumu nebija nekāda sakara.

Kāpēc problēma “atgriezās pati”

Vietne šovasar bija labota jau agrāk, un pēc kāda laika baltā lapa parādījās atkal. Pārskats šo mīklu atrisina īsi:

Salabota vietne pēc kāda laika atkal parādīja balto lapu, un radās sajūta, ka problēma atgriežas pati no sevis. Patiesais iemesls bija serverī palikušās tīmekļa čaulas, kas atjaunoja injekciju.

Tīmekļa čaula (web shell) ir mazs PHP fails, kas ļauj uzbrucējam izpildīt komandas serverī bez pieteikšanās. Šeit tās slēpās zem nevainīgiem nosaukumiem — saiga.php, ammika.php, ah77.php, vesela sauja failu ar galotni default.php — arī WordPress sistēmas mapēs, kur svešus failus neviens nemeklē. Kamēr kaut viena čaula paliek, tīrīt redzamo index.php ir bezjēdzīgi: injekcija atgriežas dažu dienu laikā.

Tīrīšana septiņos soļos

Novēršanas gaita no pārskata ir laba pamācība ikvienam, kam pieder WordPress vietne:

1. Diagnostika: servera atbildes salīdzināšana ar failu faktisko stāvokli. Tukšais 200, uzpūstais index.php un viltus kartes apstiprināja diagnozi.
2. Inficētā index.php aizstāšana ar tīru oriģinālu un robots.txt atjaunošana — vietne atkal rādīja saturu.
3. Svešo PHP failu, mēstuļu mapju (pages, system, codex) un uzbrucēja verifikācijas faila izņemšana no vietnes.
4. Visa konta tīrīšana caur termināli — kaitīgos failus atpazina pēc nosaukumu paraugiem un koda parauga saturā. Karantīnā nonāca vairāk nekā 854 faili.
5. Viltus pozitīvo pārbaude: daži atzīmētie faili izrādījās normālas WooCommerce un Contact Form 7 sastāvdaļas, un tos atgrieza vietā. Svarīga detaļa — aizdomīgos failus nevis dzēsa, bet pārvietoja uz karantīnas mapi, lai kļūdu varētu atsaukt.
6. Divkārša pārbaude: atkārtota meklēšana pēc koda paraugiem un hostinga servera līmeņa pretvīruss, kas redz arī parastam lietotājam nepieejamās mapes. Abas — tīras.
7. Visu paroļu maiņa: cPanel, FTP, WordPress administratori. Bez šī soļa viss iepriekšējais ir uz laiku.

Ko no tā paturēt

Pārskata ieteikumi nav nekas eksotisks, un tieši tāpēc tos ir viegli atlikt “uz vēlāk”:

• atjaunināt WordPress, spraudņus un tēmas — lielākā daļa ielaušanos notiek caur sen izlabotiem caurumiem;
• izmest neizmantotos spraudņus, pirmām kārtām failu pārvaldniekus;
• garas, unikālas paroles un divpakāpju autentifikācija administratoriem;
• dublējumkopijas ārpus servera — inficētā serverī arī kopijas var būt inficētas;
• ja vienā hostinga kontā dzīvo daudz vietņu, apsvērt to sadalīšanu: viena konta modelī viena cauruma cena ir visas vietnes.

Baltā lapa šajā stāstā izrādījās veiksme. Ja injicētais kods būtu uzrakstīts kārtīgāk, vietne izskatītos vesela vēl mēnešiem — un visu šo laiku strādātu svešam biznesam.

Avoti

• Drošības incidenta pārskats, 2026. gada jūlijs — redakcijas rīcībā; publicēts ar vietnes īpašnieka piekrišanu, bez identificējošas informācijas.
• Google Search Central: Spam policies — durvju lapu un maskēšanas oficiālā definīcija un sekas.
• WordPress.org: Hardening WordPress — oficiālais vietnes nostiprināšanas ceļvedis.
• Sucuri: Website Malware Removal Guide — soli pa solim par inficētu vietņu tīrīšanu.