Auditujete WordPress? Začněte svými pluginy

Shrnutí

Většina bezpečnostních auditů WordPressu je zpátečnická: zdůrazňují aktualizace jádra a reporty skenerů, zatímco zranitelnosti, které skutečně bolí, žijí v pluginech. Bílá kniha SANS zjistila, že více než 96 % zranitelností ekosystému pochází z pluginů třetích stran a zhruba 43 % nevyžaduje žádnou autentizaci. Tento článek provede auditem zaměřeným na pluginy pro malý interní marketingový tým, a to na příběhu webu, který byl napaden, protože všichni skenovali špatnou vrstvu. Naučíte se inventarizovat a klasifikovat každý plugin, testovat neautentizované útočné plochy, ručně kontrolovat uživatele a logy a převádět zjištění do jazyka rizik, kterému rozumí netechnický šéf. Výsledkem je čtvrtletní triážní rituál místo cvičení se zaškrtávacími políčky.

Většina bezpečnostních auditů WordPressu je divadlo. Strávíte odpoledne aktualizací jádra, změnou hesla administrátora a spuštěním skeneru pluginů, který hrdě hlásí „Žádné kritické problémy.“ Mezitím plugin, který přijímal nahrávání souborů a byl naposledy aktualizován před třemi lety, tiše sedí ve vašem adresáři uploads a čeká na někoho, kdo není na seznamu hostů.

Čísla to potvrzují. Bílá kniha SANS o skenování pluginů WordPressu zjistila, že více než 96 % zranitelností v ekosystému WordPressu pochází z pluginů třetích stran, přičemž témata tvoří 4 % a jádro méně než 1 %. Zhruba 43 % těchto chyb lze zneužít bez jakékoli autentizace. Takže když váš audit věnuje většinu energie jádru, zkoumáte stromy, zatímco vedle v adresáři pluginů začíná lesní požár.

Toto není výzva k panice ohledně jádra. Zranitelnosti jádra, jako jsou chyby wp2shell RCE, které se nedávno dočkaly veřejných exploitů, by měly být opraveny v den, kdy jsou oznámeny. Jsou ale dost vzácné na to, aby si nezasloužily většinu vašich auditorských hodin. Většina patří pluginům, a tam začíná skutečný pracovní postup.

Představte si scénář před: nedělní ráno, váš web přesměruje na kasino stránku a váš šéf napíše: „Myslel jsem, že máme zabezpečení.“ Zabezpečení jste měli – měli jste audit se zaškrtávacími políčky. Scénář po je triážní systém, který zachází s pluginy jako s útočnou plochou, kterou skutečně jsou, testuje je zvenčí a kontroluje věci, které skenery nevidí.

Jste na malém marketingovém týmu s webem WordPress, který běží od roku 2017. Má vlastní plugin pro registraci událostí, který freelancer postavil v roce 2019, plugin kontaktního formuláře s polem pro nahrávání souborů a plugin posuvníku, který byl prodán a už nemá veřejnou stránku s aktualizacemi. Toto není neobvyklý stack. Tady váš audit začíná.

---

Inventář pluginů je vaše bezpečnostní politika

Proveďte inventuru každého pluginu a tématu. Zapište si verzi, datum poslední aktualizace, zda je dodavatel stále aktivní a zda jej skutečně někdo používá. Poté každý zařaďte do kategorie: udržovaný a používaný, udržovaný a nepoužívaný, opuštěný ale používaný, opuštěný a nepoužívaný. Nepoužívané okamžitě odeberte. Ignorujte obranu „stojí to jen 50 $ měsíčně“ – nepoužívaný plugin je závazek, ne funkce. U opuštěných, ale používaných se rozhodněte: nahradit jej, nebo přijmout riziko a zapsat ho do registru rizik, který váš šéf viděl.

Plugin pro registraci událostí spadá do kategorie opuštěný, ale používaný. Přijímá platby a odesílá potvrzovací e-maily a jeho nahrazení je projekt, takže ho zatím ponecháte. Ale napíšete si poznámku: „toto je nejpravděpodobnější zdroj budoucího průniku,“ a přidáte ho na začátek seznamu testů.

Útočná plocha	Podíl známých zranitelností WordPressu	Priorita auditu
Pluginy třetích stran	Přes 96 %	Nejvyšší – inventura, skenování, testování, nahrazení
Témata	Asi 4 %	Střední – pouze pokud jsou vlastní nebo zastaralé
Jádro WordPressu	Méně než 1 %	Nízká – udržujte opravené, jděte dál

Když SecurityWeek napočítal v roce 2024 více než 8 000 nových zranitelností WordPressu, naprostá většina byla tohoto typu: problémy s pluginy, ne záplaty jádra. Skener vám řekne o těch, které byly zveřejněny a dostaly CVE. Neřekne vám o vlastním kódu freelancera bez CVE, protože se na něj nikdy nikdo pořádně nepodíval. Tento ruční pohled je vaší prací. Pro podrobnější procházku kontrolami specifickými pro pluginy se podívejte na tohoto průvodce auditem zranitelností vašich pluginů WordPress.

---

Testujte to jako cizinec: 43 %, které nepotřebují heslo

Váš skener vám už řekl, že není nic špatně. Teď udělejte to, co neumí: prozkoumejte web zvenčí, bez přihlášení. Začněte s každým polem pro nahrávání souborů, každým formulářem, který zpracovává POST, každým admin-ajax endpointem. Kontroluje upload skutečně obsah souboru, nebo jen příponu? Kam nahrané soubory dopadnou a může webový server v tomto adresáři spouštět PHP? Těch 43 % chyb pluginů, které nevyžadují autentizaci, obvykle sedí přesně na těchto místech: neautentizované uložené XSS, libovolné nahrávání souborů a injektáž PHP objektů.

Plugin kontaktního formuláře umožňuje návštěvníkům přiložit životopis. Přejmenuje soubor pomocí původního názvu návštěvníka, takže nahrajete „resume.php“ a ono ho uloží do složky /uploads/contact/, která je záměrně zapisovatelná. Pokud server v tomto adresáři také umožňuje spouštět PHP, útočník právě získal webshell. Fastly zdokumentoval aktivní zneužívání neautentizovaného uloženého XSS v pluginech WordPress – toto není riziko z okrajové prezentace. Váš test je jednoduchý: vytvořte soubor se známým obsahem, nahrajte ho a zjistěte, zda se vrátí s původním názvem a typem. Pak zkuste nahrát soubor .php. Pokud se vrátí jako .php, právě jste našli zneužitelnou díru.

Tady se také rozpadá argument „ale náš bezpečnostní plugin má WAF“. WAF může zablokovat známý payload, ale pravidla normalizace cest, na která se spoléhá, se často rozcházejí s tím, co server skutečně dělá. OWASP Web Security Testing Guide je lepší reference než jakýkoli dashboard: popisuje, jak metodicky testovat chyby nahrávání souborů a uložené XSS. A pokud zjistíte, že je plugin opuštěný, je čas použít protokol čištění: skryté nebezpečí opuštěných pluginů WordPress vysvětluje, proč je ponechání mrtvého rozšíření na místě horší než jeho odstranění a přizpůsobení pracovního postupu.

---

Co skener nevidí: uživatelé, logy a starý kód

Dynamické testy zachytí to, co je právě odhaleno. Ruční kontrola zachytí to, co už je uvnitř. Začněte uživatelskými účty: otevřete seznam administrátorů a hledejte účty, které jste nevytvořili. Administrátor jménem „support“ s adresou z bezplatné e-mailové služby a bez lidského zázemí je zadní vrátka, ne kolega. Zkontrolujte časová razítka souborů v wp-content/uploads na cokoli nedávno upraveného, co není váš obsah. Zkontrolujte přístupový log serveru na požadavky, které vypadají jako botův příkaz curl spíše než prohlížeč člověka.

Plugin událostí má nahrávání „fotografie řečníka“, které ukládá do uploads/event-headshots/. Během testu najdete soubor, který není váš – malý PHP soubor s náhodně vypadajícím názvem. To je váš webshell. Dostal se tam stejnou chybou nahrávání, kterou jste testovali před dvěma týdny, a skener by to stále „neviděl“, protože to není zranitelnost pluginu; je to důkaz jedné. Ruční kontrola ho najde, smaže a zkontroluje log pro IP adresu, která ho tam umístila. Invicti poznamenal, že injektáž PHP objektů v pluginech roste a je téměř neviditelná pro black-box skenování, protože škodlivý objekt se zhmotní pouze během provádění. Jediný způsob, jak to odhalit, je číst kód na nebezpečné vzory, jako je volání unserialize() na uživatelský vstup. Přečtení pár set řádků vlastního pluginu je levnější než placení zadržovacího poplatku za reakci na incident.

Tady také naráží na svůj limit standardní rada „prostě nainstalujte více bezpečnostních pluginů“. Naskládání tří bezpečnostních pluginů vám dá překrývající se pravidla WAF, která se vzájemně blokují, proud duplicitních e-mailů z logů a občasnou chybu „jste zablokováni“ při vlastním přihlášení do administrace. Jeden aktivní bezpečnostní plugin, dobře nakonfigurovaný, stačí. Přečtěte si o tom, proč příliš mnoho bezpečnostních pluginů selhává, než něco přidáte na hromadu.

---

Řekněte šéfovi pravdu, aniž byste vyvolali paniku

Váš šéf se nestará o skóre CVSS nebo injektáž PHP objektů. Zajímá ho, že web spadne, obchod nepřijímá objednávky a IT rozpočet. Překlad je jednoduchý: „Tento plugin má známou neautentizovanou chybu umožňující vzdálené spuštění kódu. Cizí člověk může smazat obsah našeho webu nebo nainstalovat zadní vrátka. Musíme ho v tomto čtvrtletí nahradit.“ Pak ukažte seznam priorit: nahraďte plugin pro události, zakažte nahrávání souborů v kontaktním formuláři, dokud nebude správně ověřovat typy souborů, otočte všechna přihlašovací pověření administrátorů a naplánujte další čtvrtletní přezkum.

Máte také jazykovou výhodu: CISA udržuje katalog Known Exploited Vulnerabilities, který vám přesně řekne, které zveřejněné chyby se aktivně zneužívají v praxi. Pokud se tam objeví některý z vašich pluginů, argument už není teoretický – existuje známý exploit a vy jste v časovém tlaku. Pokud ne, použijte to stejně jako standard pro to, co znamená „naléhavé“. Sledování CISA usnadňuje přesvědčit netechnického šéfa, že to není phishingový e-mail; je to veřejná databáze toho, co útočníci právě dělají. Když čtvrtletí skončí, budete mít nápravný pracovní postup, ne jednorázové cvičení se zaškrtávacími políčky. Pracovní postup pro přeměnu zranitelností na cyklus záplat udržuje návyk naživu.

---

Předtím to byl rozbitý web, zoufalý e-mail a čistá zpráva skeneru, která říkala, že nic není špatně. Poté je to čtvrtletní rituál: inventura, klasifikace, testování zvenčí, kontrola uživatelů a logů a zapsání rozhodnutí, která jste udělali, a rizik, která jste přijali. Skener se stane mapou toho, kam se dívat, ne certifikátem zdraví. Pluginy se stanou seznamem, který znáte jménem. A až se vás příště šéf zeptá na audit, budete mít odpověď, která nezahrnuje držení palců.