Chyby v PHP postavili svet na nohy: Všetko na čom ste roky pracovali, môže byť fuč, varuje expert

Manažér kybernetickej bezpečnosti Mišura vysvetľuje:

• aká závažná je chyba s hodnotení 9,2 z 10,

• či vie útočník kradnúť aj prihlasovanie údaje a meniť obsah webu,

• ktorých verzií PHP sa riziko dotýka, a ktoré sú opravené,

• čo najhoršie sa môže stať e-shopom,

• prečo s opravami nečakať,

• prečo sú štátne weby atraktívny cieľ pre útočníkov.

1. Národný bezpečnostný úrad vydal v súvislosti so zraniteľnosťami PHP naliehavé bezpečnostné upozornenie. Vydáva NBÚ takéto upozornenia bežne, alebo jeho naliehavosť naznačuje, že ide o mimoriadne závažnú hrozbu?

Upozornenia na zraniteľnosti vydávajú NBÚ a SK-CERT pravidelne. Je to ich každodenná práca. Toto však bežné upozornenie nebolo. Úrad vyzval prevádzkovateľov, aby sa pripravovali ešte predtým, ako vôbec vyšli opravy, a aby si naplánovali aj izoláciu alebo odstavenie systémov, ktoré nestihnú aktualizovať.

Takýto tón volí štát len pri hrozbách najvyššej kategórie. Z posledných rokov si podobnú mieru naliehavosti pamätám len pri Log4Shell v roku 2021. Rovnako dôrazne reagovali aj partneri v zahraničí: americká CISA aj britské NCSC vyzvali na okamžité nasadenie bezpečnostných opráv. Keď sa takto zhodnú národné autority vo viacerých krajinách, nie je to preventívna opatrnosť, ale reálne riziko.

2. Aké veľké riziko predstavujú odhalené zraniteľnosti? Čo všetko by útočník mohol získať, ak by ich úspešne zneužil?

Ide o vzdialené spustenie kódu bez overenia totožnosti, odborne označované ako RCE (Remote Code Execution). To je najhorší typ zraniteľnosti, aký môže webový server mať. Obe chyby majú hodnotenie 9,2 z 10 podľa medzinárodnej stupnice CVSS. Útočník nepotrebuje heslo, účet ani pomoc zvnútra. Stačí mu poslať na server špeciálne pripravenú požiadavku.

Technicky ide o chyby v správe pamäte samotného interpretera PHP. Jedna súvisí so spracovaním situácie, keď skriptu dôjde pamäť, druhá s tým, že údaje z jednej požiadavky môžu „prežiť“ do ďalšej. Pre bežného človeka je podstatné toto: kto chybu zneužije, získa kontrolu nad serverom s právami webovej aplikácie. Vie čítať databázu, kradnúť prihlasovacie údaje a kľúče, meniť obsah stránky, podstrčiť návštevníkom škodlivý kód a zo servera sa pokúsiť dostať ďalej do vnútornej siete organizácie.

3. PHP používa veľké množstvo webových stránok, odhadom asi 6,3 milióna stránok vo svete a asi 140-tisíc na Slovensku. Týka sa riziko každej stránky postavenej na PHP, alebo len webov využívajúcich konkrétne verzie?

Tu je odpoveď nepríjemná: prakticky každej. Podľa výskumníkov sa zraniteľný kód objavuje už v PHP 5.4 z roku 2012, teda viac ako desať rokov vývoja až po aktuálne PHP 8. CISA uvádza, že sa chyby týkajú všetkých inštalácií PHP, ktoré obsluhujú webové požiadavky. Nezáleží na tom, či ide o WordPress, e-shop alebo aplikáciu napísanú na mieru: chyba je v samotnom interpreteri PHP, nie v konkrétnom systéme nad ním.

Opravené sú verzie 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Najväčšiu obavu mám zo starých, už nepodporovaných verzií, ktorých na Slovensku v praxi vidím veľa. Pre verzie 7.4 až 8.1 vydal tím PHP len minimálne opravy zdrojového kódu, pre PHP 7.3 a staršie oprava nevyjde vôbec. NBÚ to pomenoval presne: chýbajúca oprava je dôvod, aby takýto systém prestal byť prístupný z internetu, nie dôvod nechať ho tak.

4. Ako môže prevádzkovateľ zistiť, či je jeho web zraniteľný a či sa ho bezpečnostné upozornenie týka?

Prvým krokom je inventarizácia. Prevádzkovateľ musí vedieť, kde všade PHP beží, a to nielen na hlavnom webe. Často sa zabúda na administračné rozhrania, testovacie prostredia, kontajnery či zariadenia a softvér tretích strán, ktoré PHP obsahujú bez toho, aby to bolo na prvý pohľad vidieť. Nemôžete chrániť to, o čom neviete.

Druhým krokom je overiť verziu PHP na serveri. Ak ide o starú, už nepodporovanú radu alebo je verzia nižšia ako opravená verzia v tej istej rade (napríklad 8.4.26 oproti 8.4.27), systém treba považovať za zraniteľný, pokiaľ dodávateľ alebo linuxová distribúcia výslovne nepotvrdia, že opravu doplnili. Upozorňujem na častý omyl: aktualizácia WordPressu, pluginu alebo frameworku nestačí. Opraviť treba samotný interpreter PHP a potom reštartovať všetky bežiace PHP procesy, inak na serveri ďalej beží starý, zraniteľný kód.

Ak web spravuje externá firma alebo hostingový poskytovateľ, odporúčam si od nich ešte dnes vyžiadať písomné potvrdenie, že opravu nasadili. Zodpovednosť za bezpečnosť služby zostáva na prevádzkovateľovi, nie na dodávateľovi.

5. Niektoré weby boli v stredu dočasne nedostupné vrátane webu Úradu vlády alebo ZSSK. Čo hrozí štátu, respektíve štátnym webom, ktoré fungujú v PHP a nevypli sa po upozornení?

Treba rozlíšiť dve situácie. Ak štátny web nebol vypnutý, pretože ho správcovia stihli rýchlo opraviť alebo nasadiť dočasné ochranné opatrenia, je to v poriadku. Vypnutie nie je cieľ. Cieľom je, aby systém nebol zraniteľný.

Problém sú weby, ktoré neboli ani vypnuté, ani opravené. Štátne systémy sú pre útočníkov atraktívny cieľ. Môžu cez ne získať osobné údaje občanov, zneužiť dôveryhodnú štátnu doménu na šírenie podvodov alebo sa cez webový server dostať hlbšie do infraštruktúry úradu. Netreba zabúdať ani na reputačný rozmer. Napadnutá stránka ministerstva je presne ten typ výsledku, o ktorý útočníci stoja.

6. Dokonca bol vypnutý aj Centrálny register zmlúv, web ministerstva vnútra. Neprehnal to štát s reakciou? Bola takáto reakcia primeraná závažnosti hrozby, alebo bolo možné riziko zvládnuť aj bez vypínania stránok?

Z môjho pohľadu to štát neprehnal. Ide o jednoduché zváženie rizika. Hodina či dve nedostupnosti bežného webu sú len nepríjemnosť. Kompromitovaný server, únik údajov a následné vyšetrovanie znamenajú týždne práce, náklady a stratu dôvery. Aj pri Centrálnom registri zmlúv, kde má výpadok právne dôsledky, pretože povinne zverejňované zmluvy nadobúdajú účinnosť až po zverejnení, je dočasné vypnutie menšie zlo. Pri chybách s kritickým hodnotením, ktorých technický popis koloval verejne ešte pred vydaním opráv, je dočasné odstavenie racionálne a zodpovedné rozhodnutie.

Áno, riziko sa dalo zvládnuť aj bez vypínania, ale len tam, kde mali správcovia presný prehľad o svojich systémoch a možnosť bezpečne aktualizovať v priebehu hodín alebo aspoň dočasne zmierniť riziko. To, že niektoré inštitúcie radšej siahli po vypnutí, než aby nechali bežať systém bez istoty, že je opravený, považujem za prejav zodpovedného riadenia rizík. A to je presne to, čo zákon o kybernetickej bezpečnosti od organizácií vyžaduje. Ten istý zákon však vyžaduje aj to, aby organizácie mali o svojich systémoch prehľad a vedeli ich rýchlo aktualizovať. Cieľom preto nie je vypínať, ale byť pripravený tak, aby to nebolo treba.

7. NBÚ napísal, že toto nie je situácia typu „opravíme neskôr tento týždeň“. „Buďte pripravení patchovať ešte dnes.“ Čo by sa mohlo stať tej stránke, keby ju opravili o týždeň?

S vysokou pravdepodobnosťou by bola napadnutá. Útočníci dnes nehľadajú ciele ručne. Automatizované nástroje nepretržite skenujú celý internet a zraniteľné servery nájdu v priebehu hodín, nie dní.

Ukázal to aj vývoj týchto konkrétnych chýb. Amazon zachytil prvý pokus o zneužitie na svojich návnadových serveroch už 17. októbra, štyri dni pred zverejnením. V deň vydania opráv viaceré bezpečnostné firmy hlásili pokusy o zneužitie oboch zraniteľností od rôznych útočníkov. Týždeň je v takejto situácii večnosť. A ešte jedna dôležitá vec: ak útočník na server medzitým prenikol, samotná oprava nestačí. Mohol tam zanechať zadné vrátka, ktoré fungujú aj po aktualizácii. Preto odporúčam po oprave preveriť aj to, či k prieniku nedošlo.

8. Predstavme si, že zraniteľný e-shop zostane v prevádzke bez opravy. Aký je najhorší realistický scenár? Môže útočník získať údaje zákazníkov, dostať sa k objednávkam alebo prevziať kontrolu nad serverom?

Áno, všetko z toho. Výskumníci potvrdili, že útok funguje bez prihlásenia aj proti konkrétnym verziám bežných systémov ako WordPress, Drupal, Joomla či e-shopová platforma Magento. Najhorší realistický scenár je úplné prevzatie servera. Útočník najprv získa práva webovej aplikácie, a ak si ich dokáže rozšíriť, ovládne celý server. Už s právami aplikácie však získa prístup k databáze zákazníkov: mená, adresy, telefónne čísla, e-maily, históriu objednávok a často aj heslá, ak nie sú správne chránené.

Veľmi častým scenárom pri e-shopoch je podvrhnutie platobného formulára. Zákazník si nič nevšimne, nakúpi ako vždy, ale údaje z jeho platobnej karty získa útočník. Môže tiež meniť objednávky, presmerovať platby na iný účet alebo server zašifrovať a žiadať výkupné.

Pre majiteľa e-shopu to znamená povinnosť hlásiť únik osobných údajov podľa GDPR, pri vysokom riziku aj informovať dotknutých zákazníkov, riešiť reklamácie a možné pokuty. Najväčšou škodou však býva strata dôvery, ktorú malý obchod buduje roky a môže o ňu prísť za jeden víkend.

9. Očakávate, že sa takéto niečo ešte zopakuje, že AI odhalí ďalšie a ďalšie chyby? Ak áno, kde?

Áno, a bude sa to diať čoraz častejšie. Na tomto prípade je podstatné, že výskumné tímy, ktoré chyby odhalili, pri práci využili umelú inteligenciu. Zraniteľný kód bol pritom v PHP viac ako desať rokov a PHP patrí k najpreverovanejším technológiám na svete. AI nezmenila to, že chyby existovali. Zmenila to, ako rýchlo ich dokážeme nájsť a pochopiť, ako sa dajú zneužiť.

Ďalšie nálezy očakávam najmä v rozšírených open source komponentoch, na ktorých stojí internet: webové servery, databázy, knižnice na spracovanie obrázkov a dokumentov, šifrovanie či obsahové systémy. Osobitne citlivou oblasťou sú priemyselné a zdravotnícke systémy, kde sa aktualizácie nasadzujú roky, nie dni.

Rovnaký nástroj však majú k dispozícii aj útočníci. Čas medzi zverejnením chyby a jej zneužitím sa skracuje z týždňov na hodiny. Rozhodovať preto nebude, kto má najdrahšie bezpečnostné technológie, ale kto má prehľad o svojich systémoch a overený proces, ako ich rýchlo a bezpečne aktualizovať. Nečakať na ďalšie varovanie. Nečakať na incident.