Uzņēmuma mājaslapas uzturētājam nekavējoties jāpārbauda PHP vide un jāievieš drošības labojumi. CERT.LV 21. oktobra plkst. 23.00 paziņojumā min aptuveni 6000 potenciāli ietekmētu Latvijas resursu un automatizētus uzbrukumu mēģinājumus. Tajā brīdī nebija ziņu par sekmīgiem uzbrukumiem; šis skaitlis neapzīmē uzlauztas vietnes.
Kāda ir problēma un kurus uzņēmumus tā skar?
Tehniskais brīdinājums attiecas uz CVE-2026-109618 un CVE-2026-109619 ar CVSS vērtējumu 9,2. Tās noteiktos apstākļos ļauj bez autentifikācijas izpildīt kodu serverī. Jāpārbauda PHP darbinātas mājaslapas, interneta veikali un klientu portāli, arī tie, kuru uzturēšana nodota ārpakalpojumā.
Viena problēma ir saistīta ar atmiņas izsīkuma apstrādi; otra — ar nederīga iekšējā stāvokļa saglabāšanos starp pieprasījumiem. Apache mod_php gadījumā demonstrēts uzbrukums pirms lietotnes koda izpildes. Arī PHP-FPM nav uzskatāms par drošu izņēmumu; konkrētā izmantojamība atkarīga no konfigurācijas un lietotnes.
Kuras PHP versijas satur labojumus?
PHP izstrādātāji publicējuši 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Jāuzstāda savai videi atbilstošs labojums. PHP 8.1 un vecākiem zariem nav regulārā projekta atbalsta; atsevišķi piegādātāji nodrošina pārnestus labojumus. Tādēļ vecāks redzamais versijas numurs jāpārbauda kopā ar piegādātāja drošības paziņojumu.
Pieci jautājumi mājaslapas uzturētājam
Redakcijas praktiskais kontrolsaraksts palīdz pārvērst vispārīgu atbildi “viss ir kārtībā” pārbaudāmā darba rezultātā:
- Kuras mūsu sistēmas ir pārbaudītas? Uzskaitiet galveno mājaslapu, veikalu, apakšdomēnus un klientu portālu. Vienas vietnes pārbaude neaizstāj pārējo uzskaiti.
- Kas pierāda abu CVE novēršanu? Lūdziet PHP pakotnes versiju, piegādātāja labojuma atsauci un ieviešanas laiku. Ar atbildi, ka atjaunināti tikai CMS spraudņi, nepietiek.
- Vai labojums darbojas visā apkalpojošajā vidē? Prasiet apstiprinājumu par tīmekļa pieprasījumus apstrādājošajiem procesiem un visiem serveriem. Vienas komandrindas pārbaudes rezultāts var neatspoguļot visu izvietojumu.
- Vai pēc izmaiņām vietne darbojas? Pārbaudiet pieteikšanos, kontaktformu, pasūtījuma izveidi un failu augšupielādi, ja tā paredzēta. Fiksējiet testētāju un laiku.
- Kas pārbauda iespējamā incidenta pazīmes? Vienojieties, kurš izvērtē aizdomīgus notikumus un kam ziņo. Nenoteikta atbildība starp programmētāju un hostingu nedrīkst atstāt šo darbu neizdarītu.
Kāpēc ar atjaunināšanu vien nepietiek incidenta pārbaudei?
Amazon drošības komanda ziņo par 17. oktobrī savos mānekļserveros novērotu izmantošanas mēģinājumu. Tas pamato vajadzību pārbaudīt arī agrāku periodu. Uzturētājam jāizvērtē žurnāli, negaidītas failu izmaiņas un procesu darbība; labojums pats par sevi neapstiprina, ka iepriekš nekas nav noticis.
Uzņēmuma vadītājs var prasīt īsu noslēguma ierakstu: pārbaudītās sistēmas, ieviestais labojums, atbildīgais, pārbaudes rezultāts un atlikušais darbs. Šāds ieraksts palīdz arī nākamajā drošības brīdinājumā, jo nav no jauna jāmeklē katras sistēmas īpašnieks.
Ko darīt, ja vecā sistēma neatbalsta atjauninājumu?
Jāvienojas par pagaidu piekļuves ierobežošanu un konkrētu labošanas vai migrācijas termiņu. Konfigurācijas maiņa un filtrēšana nav pilnīgs labojuma aizvietotājs. Svarīga ir gan aizsardzība, gan uzņēmuma plāns pasūtījumu un klientu pieprasījumu apkalpošanai ierobežojuma laikā.
Ārpakalpojumu izvērtēšanai var apskatīt biznesa sludinājumus, savukārt administratīvajām vajadzībām — pakalpojumus uzņēmumiem. Konkrēta IT uzturētāja kompetence un darbu apjoms jāpārbauda atsevišķi.
Komentāri
Vēl nav neviena komentāra. Jūsu komentārs varētu būt pirmais!
Pievienot komentāru