Zadnji teden je bil za inženirje pester — za nami je nekaj neprespanih noči, glavni krivec pa je php2shell. Večina nas je pričakovala napade ravni CVE-2021-44228 (Log4Shell), CVE-2017-0144 (EternalBlue) ali CVE-2014-0160 (Heartbleed). A do tega (vsaj zaenkrat) ni prišlo.
Več virov sicer poroča o močno povečanem številu zaznanih poskusov izkoriščanja. Cloudflare navaja milijone poskusov, Amazon pa je prvi poskus prek svojega honeypota zaznal že 17. oktobra, štiri dni pred objavo popravkov. Kljub temu potrjenih uspešnih napadov trenutno ni: Sophos je v svojih podatkih videl le skeniranje in nekaj neuspešnih poskusov, SecurityWeek pa je še 23. oktobra poročal, da javno ni potrjen noben uspešen vdor.
Ta razkorak — veliko hrupa in poskusov, a nobenega potrjenega vdora — je iztočnica tega članka. Poglejmo, zakaj PHP2shell po mojem mnenju — vsaj v obliki masovnega, enostavnega napada — verjetno ne bo postal nov Log4Shell.
Katere nastavitve php2shell izkorišča
PHP2shell združuje dve ranljivosti v jedru PHP: CVE-2026-109618 in CVE-2026-109619. Obe sta ocenjeni z 9,2 po CVSS v4.0 in nista v aplikacijski kodi, ampak v izvajalnem okolju PHP.
Spodnja tabela povzema php.ini nastavitve, ki so relevantne za obe ranljivosti — njihove privzete vrednosti (torej stanje, če jih inženir ne spreminja) in vrednosti, ki jih priporočajo uradne ublažitve.
Tu je že prvi namig, zakaj masovno izkoriščanje ni tako preprosto: privzeta vrednost memory_limit je 128M, medtem ko večina javnih PoC-jev za zanesljivo sprožitev napake potrebuje bistveno nižjo mejo (npr. 8M). Razvijalci PHP sicer opozarjajo, da nobena od teh ublažitev ne blokira vseh napadov — edina trajna rešitev je nadgradnja.
Zakaj napad spodleti
Napad ni ena poteza, ampak veriga ovir. Napadalec mora premagati vse štiri; če katerokoli zgreši, se PHP sesuje — kar je DoS napad, ne pa izvajanje kode. Prav zato javni PoC-ji delujejo v labu (kjer so naslovi vnaprej znani), na realnih strežnikih pa ne.
Lab test: PoC v praksi
Da bi se sam prepričal, kako nevarna je ta ranljivost, sem v lab okolju postavil začasni strežnik z zgoraj navedenimi (privzetimi) nastavitvami in poskušal izvesti PoC. Med testom sem uporabil več različnih exploitov, ki so se te dni pojavili na GitHubu.
Rezultat: nobeden ni dosegel izvajanja kode. Kar sem videl, se ujema z opažanji drugih. SANS ISC je po pregledu objavljenih PoC-jev ugotovil, da je izdelava zanesljivega exploita »na en klik« precej težka, saj imajo objavljeni PoC-ji več predpogojev in si na nek način »pomagajo z goljufanjem«.
Pri Flare so analizirali pogovore na vodilnih podzemnih hekerskih forumih (Exploit.in, XSS, Dread) in povzeli konsenz napadalcev z zgovornim citatom: “PoC Yes. RCE No.”. Izkušeni akterji na forumih so javno objavljene skripte na GitHubu označili za neuporabne ponaredke (“AI slop” in “vibe-coded junk”), ki delujejo izključno v umetno prirejenih laboratorijskih kontejnerjih (kjer je memory_limit znižan na 8M, binarne datoteke pa statično definirane).
Več analiz javne PoC-je opisuje kot strojno generirano kodo slabe kakovosti. En razvijalec je preizkusil tri najbolj »zvezdane« GitHub repozitorije proti običajnemu PHP strežniku in nobeden ni dosegel izvajanja kode. To se ujema tudi z mojo izkušnjo.
Vloga umetne inteligence in zakaj napad v praksi odpove
Kako je do tega exploita sploh prišlo in zakaj je okoli njega toliko prahu? Ranljivosti te vrste (OOM bailout obdelava v PHP) so bile teoretično znane že več let (podobne težave so bile izpostavljene že leta 2004 in 2020), a so veljale za “pretežke za izkoriščanje”. Avgusta letos pa so raziskovalci pri podjetju Calif (in vzporedno ekipe pri OpenAI ter Wiz) pri pregledu izvorne kode PHP uporabili napredne jezikovne modele (LLM), ki so jim pomagali najti točne točke prekinitve in način, kako zaobiti post_max_size omejitev z gnezdenimi polji.
Kot pa v svoji kritični analizi izpostavlja Davi Ottenheimer (Flying Penguin), so tržne ekipe ponudnikov oblačnih in AI rešitev zgodbo o “AI-odkritem hrošču, ki ogroža 70 % interneta” napihnile prek vseh razumnih meja (t. i. High FUD).
V realnem svetu (zunaj sterilnega Docker kontejnerja) napadalec naleti na tri skoraj nepremostljive zidove, ki jih odlično opiše tudi varnostni raziskovalec Daniele Berardinelli:
-
Slepa ulica zaradi ASLR in PIE: Za RCE napadalec nujno potrebuje točen odmik (offset) funkcij znotraj knjižnice libphp.so (npr. razdaljo med zval_ptr_dtor in zend_call_function) ter bazni naslov PIE. Vsaka Linux distribucija (Debian, Ubuntu, RHEL, Alpine) in vsaka podverzija PHP ima drugačen binarni odtis. Brez predhodnega “memory leak” koraka je ugibanje naslova nemogoče – napačen naslov pa takoj ubije proces (SIGSEGV) in ponastavi stanje pomnilnika.
-
Loterijski sistem procesov: Na produkcijskem strežniku z več deset aktivnimi Apache ali PHP-FPM ter stalnim prometom uporabnikov napadalec nima zagotovila, da bo njegov drugi zahtevek pristal na istem kot prvi.
-
Arhitekturna razlika (mod_php vs. PHP-FPM): Medtem ko je pri starejšem Apache mod_php veriga lažje dosegljiva, sodobne postavitve večinoma temeljijo na PHP-FPM (za Nginxom ali Apachejem), kjer izkoriščanje zahteva še dodatno sodelovanje same aplikacijske logike.
Konkretno: Kevin Beaumont je opozoril, da HP System Management Homepage (nameščen na strežnikih HPE ProLiant), VM-ji požarnih zidov Palo Alto in Citrix NetScaler pošiljajo PHP z onemogočenim ASLR — kar izkoriščanje naredi bistveno laže. Take naprave težijo k identičnim gradnjam na vsaki enoti, redko so posodobljene in redko nadzorovane kot spletni strežniki. Zanje »PoC da, RCE ne« preprosto ne velja, zato jih je treba posodobiti prve oz. upravljalni vmesnik umakniti z interneta.
Vsi viri, na katere se opiram, so stari nekaj dni, Flare pa izrecno pričakuje, da bodo PoC-ji postali boljši »v urah ali dneh«. Zato velja previdnost pri — trditev, da masovno izkoriščanje ni izvedljivo, velja za trenutno dostopne javne exploite in tipične postavitve z ASLR, ne pa kot trajna napoved.
Zaključek
Po dobrih dveh dneh aktivne analize sem prišel do mnenja, da php2shell ne bo postal nov Log4Shell. Napad je preveč zapleten in preveč odvisen od poznavanja ciljnega okolja, da bi se dal masovno in zanesljivo avtomatizirati proti poljubnim strežnikom.
Kljub temu je treba CVE vzeti skrajno resno in sisteme čim prej posodobiti in zaščititi.
Viri
- SANS ISC — (Reliable)? php2shell exploitability
- Flare — PoC Yes, RCE No (analiza podzemnih forumov)
- Sansec — PHP2Shell RCE analiza
- flyingpenguin — Low Risk, High FUD of PHP2Shell
- berardinellidaniele.com — php2shell
- BleepingComputer — emergency patches
- SecurityWeek — first exploitation attempts
- The Register — AWS in Cloudflare
