Revizija WordPressa? Začnite s svojimi vtičniki

Povzetek

Večina varnostnih revizij WordPressa je narobe usmerjenih: poudarjajo posodobitve jedra in poročila skenerjev, medtem ko ranljivosti, ki dejansko bolijo, živijo v vtičnikih. Bela knjiga SANS je ugotovila, da več kot 96 % ranljivosti v ekosistemu izvira iz vtičnikov tretjih oseb, približno 43 % pa ne potrebuje avtentikacije. Ta članek vas popelje skozi revizijo, ki daje prednost vtičnikom, za majhno interno marketinško ekipo, ob uporabi zgodbe spletišča, ki je bilo vdrt, ker so vsi pregledovali napačno plast. Naučili se boste popisati in razvrstiti vsak vtičnik, preizkusiti neavtenticirane napadalne površine, ročno pregledati uporabnike in dnevnike ter prevesti ugotovitve v jezik tveganja, ki ga razume ne-tehnični šef. Rezultat je četrtletni ritual triaže namesto vaje s kljukico.

Večina varnostnih revizij WordPressa je gledališče. Popoldne porabite za posodabljanje jedra, spreminjanje skrbniškega gesla in zagon skenerja vtičnikov, ki ponosno poroča: "No critical issues." Medtem vtičnik, ki je sprejemal nalaganja datotek in je bil nazadnje posodobljen pred tremi leti, tiho čaka v vašem imeniku za nalaganja na nekoga, ki ni na seznamu gostov.

Številke to potrjujejo. Bela knjiga SANS o skeniranju vtičnikov WordPress je ugotovila, da več kot 96 % ranljivosti v ekosistemu WordPress izvira iz vtičnikov tretjih oseb, pri čemer teme predstavljajo 4 %, jedro pa manj kot 1 %. Približno 43 % teh napak je mogoče izkoristiti brez kakršne koli avtentikacije. Ko torej vaša revizija porabi večino energije za jedro, pregledujete drevesa, medtem ko se gozdni požar začne v sosednjem imeniku vtičnikov.

To ni poziv k paniki glede jedra. Ranljivosti jedra, kot so napake RCE wp2shell, ki so pred kratkim dobile javne izkoriščevalske kode, je treba zakrpati še isti dan, ko so objavljene. Vendar so dovolj redke, da si ne zaslužijo večine vaših revizijskih ur. Večina pripada vtičnikom in tam se začne pravi potek dela.

Predstavljajte si scenarij prej: nedeljsko jutro, vaše spletišče preusmerja na igralniško stran, šef pa po e-pošti piše: "Mislil sem, da imamo varnost." Varnost ste imeli – imeli ste revizijo s kljukico. Scenarij potem pa je sistem triaže, ki obravnava vtičnike kot napadalno površino, ki dejansko so, jih testira od zunaj in preverja stvari, ki jih skenerji ne vidijo.

Ste v majhni marketinški ekipi s spletiščem WordPress, ki deluje od leta 2017. Ima po meri izdelan vtičnik za registracijo dogodkov, ki ga je leta 2019 zgradil freelancer, vtičnik za kontaktni obrazec s poljem za nalaganje datotek in vtičnik za drsnike, ki je bil prodan in nima več javne strani za posodobitve. To ni nenavaden sklop. Tukaj se začne vaša revizija.

---

Popis vtičnikov je vaša varnostna politika

Popišite vsak vtičnik in temo. Zapišite različico, datum zadnje posodobitve, ali je ponudnik še aktiven in ali ga kdo dejansko uporablja. Nato vsakega razvrstite v kategorijo: vzdrževan in uporabljen, vzdrževan in neuporabljen, opuščen, a uporabljen, opuščen in neuporabljen. Neuporabljene takoj odstranite. Ignorirajte obrambo "stane le 50 $ na mesec" – neuporabljen vtičnik je obveznost, ne funkcija. Pri opuščenih, a uporabljenih se odločite: zamenjajte ga ali sprejmite tveganje in ga zapišite v register tveganj, ki ga je šef videl.

Vtičnik za registracijo dogodkov spada v kategorijo opuščen, a uporabljen. Sprejema plačila in pošilja potrditvena e-poštna sporočila, zamenjava pa je projekt, zato ga za zdaj obdržite. Vendar si zapišete: "to je najverjetnejši vir prihodnje kršitve", in ga dodate na vrh seznama za testiranje.

Napadalna površina	Delež znanih ranljivosti WordPressa	Prednost pri reviziji
Vtičniki tretjih oseb	Več kot 96 %	Najvišja — popis, skeniranje, testiranje, zamenjava
Teme	Približno 4 %	Srednja — le če so po meri ali zastarele
Jedro WordPressa	Manj kot 1 %	Nizka — redno zakrpati in iti naprej

Ko je SecurityWeek leta 2024 naštel več kot 8.000 novih ranljivosti WordPressa, je bila velika večina te vrste: težave z vtičniki, ne popravki jedra. Skener vam bo povedal o tistih, ki so bile razkrite in so dobile CVE. Ne bo vam povedal o kodi freelancerja po meri brez CVE, ker je nihče nikoli ni natančno pregledal. Ta ročni pregled je vaša naloga. Za podrobnejši potek preverjanj, specifičnih za vtičnike, si oglejte ta vodnik o reviziji vaših vtičnikov WordPress za ranljivosti.

---

Preizkusite kot neznanec: 43 %, ki ne potrebuje gesla

Vaš skener vam je že povedal, da ni nič narobe. Zdaj naredite tisto, česar ne zmore: preiščite spletišče od zunaj, brez prijave. Začnite z vsakim poljem za nalaganje datotek, vsakim obrazcem, ki obdeluje POST, vsako končno točko admin-ajax. Ali nalaganje dejansko preverja vsebino datoteke ali samo končnico? Kje pristanejo naložene datoteke in ali lahko spletni strežnik v tem imeniku izvaja PHP? 43 % napak v vtičnikih, ki ne zahtevajo avtentikacije, je običajno ravno na teh mestih: neavtenticiran shranjen XSS, poljubno nalaganje datotek in vbrizgavanje PHP objektov.

Vtičnik za kontaktni obrazec omogoča obiskovalcem, da priložijo življenjepis. Datoteko preimenuje z izvirnim imenom obiskovalca, zato naložite "resume.php" in shrani jo v mapo /uploads/contact/, ki je po zasnovi zapisovalna. Če strežnik v tem imeniku dovoljuje tudi izvajanje PHP, je napadalec pravkar dobil spletno lupino. Podjetje Fastly je dokumentiralo aktivno izkoriščanje neavtenticiranega shranjenega XSS v vtičnikih WordPress – to ni nišno tveganje s prosojnic. Vaš test je preprost: ustvarite datoteko z znano vsebino, jo naložite in preverite, ali se vrne z izvirnim imenom in vrsto. Nato poskusite naložiti datoteko .php. Če se vrne kot .php, ste pravkar našli izkoriščljivo luknjo.

Tu se podre tudi argument "ampak naš varnostni vtičnik ima WAF". WAF lahko blokira znani koristni tovor, vendar se pravila za normalizacijo poti, na katera se zanaša, pogosto razlikujejo od tega, kaj strežnik dejansko naredi. OWASP-ov vodnik za testiranje spletne varnosti je boljši referenčni vir kot katera koli nadzorna plošča: opisuje, kako metodično preizkusiti napake pri nalaganju datotek in shranjen XSS. In če odkrijete, da je vtičnik opuščen, je čas, da uporabite protokol za čiščenje: skrita nevarnost opuščenih vtičnikov WordPress pojasnjuje, zakaj je pustiti mrtev vtičnik na mestu slabše kot ga odstraniti in prilagoditi vaš potek dela.

---

Česar skener ne vidi: uporabniki, dnevniki in stara koda

Dinamični testi ujamejo tisto, kar je trenutno izpostavljeno. Ročni pregled ujame tisto, kar je že v notranjosti. Začnite z uporabniškimi računi: odprite seznam skrbnikov in poiščite račune, ki jih niste ustvarili. Skrbnik z imenom "support" s prostim e-poštnim naslovom in brez človeka za njim so vrata v hrbet, ne sodelavec. Preverite časovne žige datotek v wp-content/uploads za vse, kar je bilo nedavno spremenjeno in ni vaša vsebina. Preverite dnevnik dostopa do strežnika za zahteve, ki so videti kot botov ukaz curl in ne kot brskalnik človeka.

Vtičnik za dogodke ima nalaganje "fotografije govornika", ki shranjuje v uploads/event-headshots/. Med testom najdete datoteko, ki ni vaša – majhno PHP datoteko z naključno videti imenom. To je vaša spletna lupina. Tja je prišla skozi isto napako pri nalaganju, ki ste jo testirali pred dvema tednoma, in skener je zdaj še vedno ne bi "videl", ker ni ranljivost vtičnika; je dokaz zanjo. Ročni pregled jo najde, izbriše in preveri dnevnik za IP-naslov, ki jo je tja postavil. Invicti je opozoril, da vbrizgavanje PHP objektov v vtičnikih narašča in je pri black-box skeniranjih skoraj nevidno, ker se zlonamerni objekt materializira šele med izvajanjem. Edini način, da ga opazite, je branje kode za nevarne vzorce, kot je klic unserialize() na uporabniško vnesene podatke. Branje nekaj sto vrstic kode po meri je cenejše kot najem strokovnjaka za odziv na incident.

Tu doseže mejo tudi standardni nasvet, naj "samo namestite več varnostnih vtičnikov". Zlaganje treh varnostnih vtičnikov vam prinese prekrivajoča se pravila WAF, ki se med seboj blokirajo, poplavo podvojenih dnevniških e-poštnih sporočil in občasno napako "blokirani ste" pri lastni skrbniški prijavi. En aktiven varnostni vtičnik, dobro konfiguriran, je dovolj. Preberite o zakaj preveč varnostnih vtičnikov povzroči nasprotni učinek, preden na kup dodate še kaj.

---

Kako šefu povedati resnico brez sprožitve panike

Vašega šefa ne zanimajo ocene CVSS ali vbrizgavanje PHP objektov. Skrbi ga, da spletišče pade, trgovina ne sprejema naročil in IT proračun. Prevod je preprost: "Ta vtičnik ima znano neavtenticirano napako pri izvajanju oddaljene kode. Neznanec lahko izbriše vsebino našega spletišča ali namesti vrata v hrbet. Zamenjati ga moramo to četrtletje." Nato pokažite seznam prednostnih nalog: zamenjajte vtičnik za dogodke, onemogočite nalaganje datotek v kontaktnem obrazcu, dokler pravilno ne preverja vrst datotek, zavrtite vsa skrbniška pooblastila in načrtujte naslednji četrtletni pregled.

Imate tudi jezikovno prednost: CISA vzdržuje katalog znanih izkoriščenih ranljivosti, ki natančno pove, katere objavljene napake se dejansko aktivno izkoriščajo v naravi. Če se kateri od vaših vtičnikov pojavi tam, argument ni več teoretičen – znano izkoriščanje obstaja in čas teče. Če se ne, ga vseeno uporabite kot merilo, kaj pomeni "nujno". Sledenje CISA olajša prepričevanje netehničnega šefa, da to ni phishing e-poštno sporočilo; to je javna zbirka podatkov o tem, kaj napadalci počnejo prav zdaj. Ko se četrtletje konča, boste imeli potek dela za odpravo ranljivosti, ne enkratne vaje s kljukico. Potek dela za pretvorbo ranljivosti v cikel popravkov ohranja navado pri življenju.

Prej je bilo pokvarjeno spletišče, frenetično e-poštno sporočilo in čisto poročilo skenerja, ki je reklo, da ni nič narobe. Potem pa je četrtletni ritual: popis, razvrstitev, testiranje od zunaj, pregled uporabnikov in dnevnikov ter zapis odločitev, ki ste jih sprejeli, in tveganj, ki ste jih sprejeli. Skener postane zemljevid, kam pogledati, ne potrdilo o zdravju. Vtičniki postanejo seznam, ki ga poznate po imenu. In naslednjič, ko vas bo šef vprašal o reviziji, boste imeli odgovor, ki ne vključuje upanja na srečo.