WordPress-audit? Kezdj a bővítményeiddel

Összefoglaló

A legtöbb WordPress biztonsági audit fordítva működik: a mag frissítésére és a scanner-jelentésekre helyezi a hangsúlyt, miközben a valódi veszélyt jelentő sebezhetőségek a bővítményekben élnek. Egy SANS fehér könyv megállapította, hogy az ökoszisztéma sebezhetőségeinek több mint 96%-a harmadik féltől származó bővítményekből ered, és körülbelül 43%-ukhoz nem szükséges hitelesítés. Ez a cikk egy bővítmény-központú auditot mutat be egy kis belső marketingcsapat számára, egy olyan webhely történetén keresztül, amelyet azért törtek fel, mert mindenki a rossz réteget vizsgálta. Megtanulod, hogyan leltározd és osztályozd az összes bővítményt, teszteld a hitelesítés nélküli támadási felületeket, nézd át manuálisan a felhasználókat és naplókat, és fordítsd le az eredményeket olyan kockázati nyelvre, amit a nem technikai főnököd is megért. Az eredmény egy negyedéves triázsritmus lesz a pipaellenőrzés helyett.

A legtöbb WordPress biztonsági audit színház. Egy délutánt töltesz a mag frissítésével, az admin jelszó megváltoztatásával, és lefuttatsz egy bővítmény-szkennert, amely büszkén jelenti: „Nincsenek kritikus problémák.” Közben a bővítmény, amely fájlfeltöltést fogadott el, és utoljára három éve frissítették, csendben ül a feltöltési mappádban, és arra vár, hogy valaki, aki nincs a vendéglistán, rátaláljon.

A számok ezt támasztják alá. A WordPress bővítmények szkenneléséről szóló SANS fehér könyv megállapította, hogy a WordPress ökoszisztémában található sebezhetőségek több mint 96%-a harmadik féltől származó bővítményekből ered, a témák 4%-ot, a mag pedig kevesebb mint 1%-ot tesz ki. E hibák körülbelül 43%-a hitelesítés nélkül is kihasználható. Tehát ha az auditod az energiája nagy részét a magra fordítja, a fákat vizsgálod, miközben a szomszédos bővítménykönyvtárban erdőtűz keletkezik.

Ez nem felhívás a pánikra a mag miatt. A mag sebezhetőségeit, mint a nemrég nyilvános exploitot kapott wp2shell RCE hibákat, a bejelentésük napján javítani kell. De elég ritkák ahhoz, hogy ne érdemeljék ki az auditálási óráid nagy részét. A nagy rész a bővítményeké, és itt kezdődik az igazi munkafolyamat.

Képzeld el az előtti állapotot: vasárnap reggel a webhelyed egy kaszinóoldalra irányít át, és a főnököd e-mailt ír: „Azt hittem, van biztonságunk.” Volt biztonságod — volt egy pipaellenőrzésed. Az utáni állapot egy triázsrendszer, amely a bővítményeket valódi támadási felületként kezeli, kívülről teszteli őket, és ellenőrzi azokat a dolgokat, amelyeket a szkennerek nem látnak.

Egy kis marketingcsapatban dolgozol egy WordPress webhellyel, amely 2017 óta fut. Van rajta egy egyedi eseményregisztrációs bővítmény, amit egy szabadúszó épített 2019-ben, egy kapcsolati űrlap bővítmény fájlfeltöltési mezővel, és egy slider bővítmény, amit eladtak, és már nincs nyilvános frissítési oldala. Ez nem szokatlan stack. Itt kezdődik az audited.

---

A bővítményleltár a biztonsági politikád

Vedd leltárba az összes bővítményt és témát. Írd le a verziót, az utolsó frissítés dátumát, hogy a szállító még él-e, és hogy valójában használja-e valaki. Ezután sorold be mindet egy kategóriába: karbantartott és használt, karbantartott és használaton kívüli, elhagyott, de használt, elhagyott és használaton kívüli. Azonnal távolítsd el a használaton kívülieket. Ne hallgass a „csak havi 50 dollár” kifogásra — a használaton kívüli bővítmény teher, nem funkció. Az elhagyott, de használtaknál döntsd el: cseréld le, vagy vállald a kockázatot, és írd be egy kockázati nyilvántartásba, amit a főnököd is látott.

Az eseményregisztrációs bővítmény az elhagyott, de használt kategóriába esik. Fizetéseket fogad és visszaigazoló e-maileket küld, a cseréje pedig projekt, ezért egyelőre megtartod. De írsz egy megjegyzést, hogy „ez a jövőbeli biztonsági incidens legvalószínűbb forrása”, és felveszed a tesztlista tetejére.

Támadási felület	A WordPress ismert sebezhetőségeinek aránya	Audit prioritás
Harmadik féltől származó bővítmények	Több mint 96%	Legmagasabb — leltár, szkennelés, tesztelés, csere
Témák	Körülbelül 4%	Közepes — csak ha egyedi vagy elavult
WordPress mag	Kevesebb mint 1%	Alacsony — tartsd frissítve, lépj tovább

Amikor a SecurityWeek 2024-ben több mint 8000 új WordPress-sebezhetőséget számolt össze, a túlnyomó többség ilyen típusú volt: bővítményproblémák, nem mag-javítások. A szkenner megmondja azokat, amelyeket nyilvánosságra hoztak és CVE-számot kaptak. Azt viszont nem mondja meg, hogy mi van az egyedi, szabadúszó kódban CVE nélkül, mert még soha senki nem nézte meg alaposan. Ez a manuális ellenőrzés a te feladatod. Ha részletesebben szeretnéd átlátni a bővítmény-specifikus ellenőrzéseket, nézd meg ezt az útmutatót: WordPress-bővítmények biztonsági auditálása.

---

Teszteld kívülállóként: a 43%, amelyhez nem kell jelszó

A szkenner már közölte, hogy semmi baj. Most tedd meg, amire ő nem képes: fürkészd a webhelyet kívülről, bejelentkezés nélkül. Kezdd minden fájlfeltöltési mezővel, minden űrlappal, amely POST kérést dolgoz fel, minden admin-ajax végponttal. A feltöltés tényleg ellenőrzi a fájl tartalmát, vagy csak a kiterjesztést? Hová kerülnek a feltöltött fájlok, és a webszerver végre tudja-e hajtani a PHP-t abban a könyvtárban? A bővítményhibák azon 43%-a, amelyekhez nem szükséges hitelesítés, általában pont ezeken a helyeken van: hitelesítés nélküli, tárolt XSS, tetszőleges fájlfeltöltés és PHP-objektuminjektálás.

A kapcsolati űrlap bővítmény lehetővé teszi a látogatók számára, hogy önéletrajzot csatoljanak. A fájlt a látogató eredeti fájlnevével nevezi át, így feltöltöd a „resume.php”-t, és egy /uploads/contact/ mappába menti, amely tervezésből írható. Ha a szerver ebben a könyvtárban is engedélyezi a PHP futtatását, a támadó éppen kapott egy webshellet. A Fastly dokumentálta a hitelesítés nélküli, tárolt XSS aktív kihasználását WordPress-bővítményekben — ez nem egy niche, diasorban bemutatott kockázat. A teszted egyszerű: hozz létre egy fájlt ismert tartalommal, töltsd fel, és nézd meg, hogy az eredeti nevével és típusával tér-e vissza. Ezután próbálj feltölteni egy .php fájlt. Ha .php-ként jön vissza, akkor éppen találtál egy kihasználható rést.

Itt dől meg a „de a biztonsági bővítményünknek van WAF-ja” érv is. A WAF képes blokkolni egy ismert payloadot, de az általa használt útvonal-normalizációs szabályok gyakran eltérnek attól, amit a szerver valójában csinál. Az OWASP Web Security Testing Guide jobb referencia, mint bármelyik műszerfal: módszeresen írja le, hogyan kell tesztelni a fájlfeltöltési hibákat és a tárolt XSS-t. És ha rájössz, hogy a bővítmény elhagyott, itt az ideje a tisztítási protokoll alkalmazásának: az elhagyott WordPress-bővítmények rejtett veszélye elmagyarázza, miért rosszabb egy halott bővítményt a helyén hagyni, mint eltávolítani és hozzáigazítani a munkafolyamatodat.

---

Amit a szkenner nem lát: felhasználók, naplók és régi kód

A dinamikus tesztek azt kapják el, ami éppen látható. A manuális átvizsgálás azt, ami már bent van. Kezdd a felhasználói fiókokkal: nyisd meg az admin listát, és keresd azokat a fiókokat, amelyeket nem te hoztál létre. Egy „support” nevű admin, ingyenes levelezési címmel és mögötte ember nélkül, hátsó ajtó, nem kolléga. Ellenőrizd a fájlok időbélyegeit a wp-content/uploads mappában, ha találsz valamit, ami nem a te tartalmad, de nemrég módosították. Nézd meg a szerver hozzáférési naplóját olyan kérésekért, amelyek inkább egy bot curl parancsára hasonlítanak, mint egy ember böngészőjére.

Az eseménybővítménynek van egy „előadó fotó” feltöltése, amely a uploads/event-headshots/ mappába ment. A teszt során találsz egy fájlt, ami nem a tiéd — egy kis PHP-fájlt, véletlenszerűnek tűnő névvel. Ez a te webshelled. Ugyanazon a feltöltési hibán keresztül került oda, amit két hete teszteltél, és mostanra egy szkenner sem „látná”, mert nem bővítmény-sebezhetőség; hanem annak bizonyítéka. A manuális átvizsgálás megtalálja, törli, és megkeresi a naplóban az IP-címet, amely oda helyezte. Az Invicti megjegyezte, hogy a PHP-objektuminjektálás a bővítményekben növekszik, és szinte láthatatlan a feketedobozos szkennelések számára, mert a rosszindulatú objektum csak végrehajtáskor materializálódik. Az egyetlen módja, hogy észrevedd, ha veszélyes minták után kutatva olvasod a kódot, például ha az unserialize() függvényt felhasználói bemeneten hívják meg. Néhány száz soros egyedi bővítmény elolvasása olcsóbb, mint incidens-elhárítási megtartó díjat fizetni.

Itt ér véget a „csak telepíts több biztonsági bővítményt” szokásos tanács is. Három biztonsági bővítmény egymásra pakolása átfedő WAF-szabályokat eredményez, amelyek blokkolják egymást, rengeteg duplikált napló e-mailt, és időnként egy „ki vagy tiltva” hibát a saját admin bejelentkezésednél. Egy aktív, jól beállított biztonsági bővítmény elég. Olvass arról, miért sül el visszafelé a túl sok biztonsági bővítmény, mielőtt még többet adnál a halomhoz.

---

Hogyan mondd el a főnöködnek az igazságot pánik keltése nélkül

A főnöködét nem érdeklik a CVSS-pontszámok vagy a PHP-objektuminjektálás. Őt az érdekli, hogy a webhely ne menjen le, a bolt fogadja a rendeléseket, és a IT-költségvetés rendben legyen. A fordítás egyszerű: „Ennek a bővítménynek ismert, hitelesítés nélküli távoli kódfuttatási hibája van. Egy idegen törölheti a webhely tartalmát vagy hátsó ajtót telepíthet. Ebben a negyedévben le kell cserélnünk.” Ezután mutasd meg a prioritási listát: cseréld le az eseménybővítményt, tiltsd le a kapcsolati űrlap fájlfeltöltését, amíg megfelelően nem ellenőrzi a fájltípusokat, cseréld le az összes admin hitelesítő adatot, és ütemezd a következő negyedéves felülvizsgálatot.

Van egy nyelvi előnyöd is: a CISA vezeti a Known Exploited Vulnerabilities katalógust, amely pontosan megmondja, mely publikált hibákat használják ki aktívan a vadonban. Ha a bővítményeid bármelyike szerepel ott, az érv már nem elméleti — létezik ismert exploit, és az óra ketyeg. Ha nem szerepelnek, akkor is használd viszonyítási pontként arra, mit jelent a „sürgős”. A CISA nyomon követése megkönnyíti, hogy meggyőzz egy nem technikai főnököt arról, hogy ez nem phishing e-mail; ez egy nyilvános adatbázis arról, hogy a támadók éppen mit csinálnak. Amikor a negyedév véget ér, lesz egy javítási munkafolyamatod, nem egy egyszeri pipaellenőrzés. Egy munkafolyamat a sebezhetőségek javítási ciklussá alakítására életben tartja a szokást.

---

Az előtte egy törött webhely volt, egy pánikolt e-mail és egy tiszta szkennerjelentés, ami azt mondta, hogy semmi baj. Az utána egy negyedéves rituálé: leltár, osztályozás, kívülről tesztelés, felhasználók és naplók átvizsgálása, és a meghozott döntések, valamint a vállalt kockázatok lejegyzése. A szkenner térkép lesz arról, hogy hová nézz, nem pedig egészségügyi bizonyítvány. A bővítmények olyan listává válnak, amelyet név szerint ismersz. És ha legközelebb a főnököd az auditról kérdez, lesz egy válaszod, ami nem abból áll, hogy keresztbe teszed az ujjaidat.