Blogi

Auditeerid WordPressi? Alusta oma pluginatest

Lõpeta WordPressi tuuma auditeerimine ja hakka auditeerima oma pluginaid: praktiline, pluginakeskne turvaaudit väikestele meeskondadele.

Summary

Enamik WordPressi turvaaudite on tagurpidi: nad rõhutavad tuumauuendusi ja skannerite aruandeid, samal ajal kui haavatavused, mis tegelikult hammustavad, elavad pluginates. SANS-i valge raamat leidis, et üle 96% ökosüsteemi haavatavustest pärinevad kolmanda osapoole pluginatest ja umbes 43% neist ei vaja autentimist. See artikkel juhendab pluginakeskset auditi läbiviimist väikesele majasisesele turundusmeeskonnale, kasutades loo saidist, mis häkiti, sest kõik skaneerisid valet kihti. Sa õpid inventuurima ja klassifitseerima iga plugina, testima autentimata ründepindu, vaatama käsitsi üle kasutajad ja logid ning tõlkima leiud riskikeelde, mida mittetehniline juht mõistab. Tulemuseks on kvartaalne triaažirituaal, mitte linnukese harjutus.

Enamik WordPressi turvaaudite on teater. Sa veedad pärastlõuna tuuma uuendades, adminiparooli vahetades ja pluginaskannerit käivitades, mis uhkelt teatab: "Kriitilisi probleeme pole." Vahepeal istub plugin, mis võttis vastu failiüleslaadimisi ja mida viimati uuendati kolm aastat tagasi, vaikselt sinu uploads-kataloogis, oodates kedagi, kes pole külalistenimekirjas.

Arvud toetavad seda. SANS-i valge raamat WordPressi pluginate skaneerimise kohta leidis, et üle 96% WordPressi ökosüsteemi haavatavustest pärinevad kolmanda osapoole pluginatest, teemad 4% ja tuum alla 1%. Umbes 43% nendest vigadest on ärakasutatavad ilma igasuguse autentimiseta. Seega, kui su audit kulutab suurema osa energiast tuumale, vaatad sa puid, samal ajal kui kõrval asuvas pluginakataloogis süttib metsatulekahju.

See ei ole üleskutse paanikaks tuuma pärast. Tuumahaavatavused, nagu wp2shell RCE vead, millele hiljuti avalikud ärakasutused ilmusid, tuleks paikata samal päeval, kui need teatatakse. Kuid need on piisavalt haruldased, et nad ei vääri suuremat osa sinu auditi tundidest. Suurem osa kuulub pluginatesse ja seal algab tegelik töövoog.

Kujutle ette enne-stsenaariumit: pühapäeva hommikul suunab su sait kasiinolehele ja su ülemus saadab meili: "Ma arvasin, et meil on turvalisus." Sul oli turvalisus — sul oli linnukese audit. Pärast-stsenaarium on triaažisüsteem, mis kohtleb pluginaid ründepinnana, mis nad tegelikult on, testib neid väljastpoolt ja kontrollib asju, mida skannerid ei näe.

Sa oled väikeses turundusmeeskonnas, kellel on WordPressi sait, mis on töötanud alates 2017. aastast. Sellel on kohandatud sündmuste registreerimise plugin, mille vabakutseline ehitas 2019. aastal, kontaktvormi plugin faili üleslaadimise väljaga, ja slaidiseade-plugin, mis müüdi maha ja millel pole enam avalikku uuenduste lehte. See pole ebatavaline virn. See on koht, kust sinu audit algab.


Plugininventuur on sinu turvapoliitika

Võta inventuur kõigist pluginatest ja teemadest. Kirjuta üles versioon, viimase uuenduse kuupäev, kas müüja on veel elus ja kas keegi seda tegelikult kasutab. Seejärel klassi igaüks kategooriasse: hooldatud ja kasutusel, hooldatud ja kasutuseta, mahajäetud kuid kasutusel, mahajäetud ja kasutuseta. Eemalda kasutuseta kohe. Ignoreeri "see on ainult 50 dollarit kuus" kaitset — kasutamata plugin on kohustus, mitte funktsioon. Mahajäetud-kuid-kasutusel puhul otsusta: asenda see või aktsepteeri risk ja kirjuta see riskiregistrisse, mida su ülemus on näinud.

Sündmuste registreerimise plugin kuulub mahajäetud-kuid-kasutusel kategooriasse. See võtab vastu makseid ja saadab kinnitusmeile ning selle asendamine on projekt, nii et sa jätad selle praegu alles. Aga sa kirjutad märkuse, mis ütleb: "see on kõige tõenäolisem tulevase rikkumise allikas," ja lisad selle testinimekirja tippu.

RündepindWordPressi teadaolevate haavatavuste osakaalAuditi prioriteet
Kolmanda osapoole pluginadÜle 96%Kõrgeim — inventuur, skaneeri, testi, asenda
TeemadUmbes 4%Keskmine — ainult kui kohandatud või vananenud
WordPressi tuumAlla 1%Madal — hoia paigatud, liigu edasi

Kui SecurityWeek luges 2024. aastal üle 8000 uue WordPressi haavatavuse, oli valdav enamus seda tüüpi: pluginaprobleemid, mitte tuumapaigad. Skanner räägib sulle nendest, mis on avalikustatud ja saanud CVE. Ta ei räägi sulle kohandatud vabakutselise koodist ilma CVE-ta, sest keegi pole seda kunagi hoolikalt vaadanud. See käsitsi vaatamine on sinu töö. Sügavama pluginaspetsiifiliste kontrollide läbivaatamiseks vaata seda juhendit WordPressi pluginatest haavatavuste auditeerimiseks.


Testi seda nagu võõras: 43%, mis ei vaja parooli

Su skanner on sulle juba öelnud, et miski pole valesti. Nüüd tee seda, mida see ei suuda: uuri saiti väljastpoolt, ilma sisselogimiseta. Alusta iga failiüleslaadimise väljaga, iga vormiga, mis töötleb POST-päringut, iga admin-ajax lõpp-punktiga. Kas üleslaadimine kontrollib tegelikult faili sisu või ainult laiendit? Kuhu üleslaetud failid jõuavad ja kas veebiserver saab selles kataloogis PHP-d käivitada? Need 43% plugina vigadest, mis ei nõua autentimist, asuvad tavaliselt just nendes kohtades: autentimata salvestatud XSS, suvaline failiüleslaadimine ja PHP objekti süstimine.

Kontaktvormi plugin laseb külastajatel lisada CV. See nimetab faili ümber külastaja algse failinime järgi, nii et sa laed üles "resume.php" ja see salvestab selle /uploads/contact/ kausta, mis on disaini poolest kirjutatav. Kui server lubab ka selles kataloogis PHP-d käivitada, sai ründaja just veebikesta. Fastly on dokumenteerinud WordPressi pluginates aktiivset ärakasutamist autentimata salvestatud XSS-i puhul — see ei ole nišš-risk, mida näidatakse ainult slaidiesitlustes. Sinu test on lihtne: loo teadaoleva sisuga fail, laadi see üles ja vaata, kas see tuleb tagasi oma algse nime ja tüübiga. Seejärel proovi üles laadida .php-fail. Kui see tuleb tagasi .php-na, oled just leidnud ärakasutatava augu.

See on ka koht, kus "aga meie turvapluginil on WAF" argument ei pea paika. WAF suudab blokeerida teadaoleva payloadi, kuid tee-normaliseerimise reeglid, millele see toetub, lahknevad sageli sellest, mida server tegelikult teeb. OWASP Web Security Testing Guide on parem viide kui ükski juhtpaneel: see kirjeldab, kuidas testida failiüleslaadimise vigu ja salvestatud XSS-i metoodiliselt. Ja kui avastad, et plugin on mahajäetud, on aeg rakendada puhastusprotokoll: mahajäetud WordPressi pluginate varjatud oht selgitab, miks on surnud laienduse paigale jätmine halvem kui selle eemaldamine ja töövoo kohandamine.


Mida skanner ei näe: kasutajad, logid ja vana kood

Dünaamilised testid püüavad kinni selle, mis on praegu eksponeeritud. Käsitsi ülevaatus püüab selle, mis on juba sees. Alusta kasutajakontodest: ava admin-loend ja otsi kontosid, mida sa ei loonud. Admin nimega "support" tasuta meiliaadressiga ja ilma inimeseta taga on tagauks, mitte kolleeg. Kontrolli failide ajatempleid wp-content/uploads kaustas, et leida midagi hiljuti muudetud, mis pole sinu sisu. Kontrolli serveri juurdepääsulogi päringute jaoks, mis näevad välja nagu roboti curl-käsk, mitte inimese brauser.

Sündmuspluginil on "kõneleja foto" üleslaadimine, mis salvestab kausta uploads/event-headshots/. Testi käigus leiad faili, mis pole sinu oma — väikese PHP-faili juhusliku nimega. See on sinu veebikest. See sattus sinna sama üleslaadimisvea kaudu, mida sa testisid kaks nädalat tagasi, ja praeguseks ei näeks skanner seda ikka "näe", sest see pole plugina haavatavus; see on selle tõend. Käsitsi ülevaatus leiab selle, kustutab selle ja kontrollib logist IP-aadressi, mis selle sinna pani. Invicti on märkinud, et PHP objekti süstimine pluginates on tõusuteel ja see on peaaegu nähtamatu musta kasti skannimisele, sest pahatahtlik objekt materialiseerub ainult täitmise ajal. Ainus viis seda märgata on lugeda koodi ohtlike mustrite jaoks, nagu näiteks unserialize() kutsumine kasutaja sisendil. Paarisaja rea kohandatud plugina lugemine on odavam kui intsidentidele reageerimise retainer.

See on ka koht, kus standardne nõuanne "lihtsalt installi rohkem turvapluginaid" jõuab oma piirini. Kolme turvapluginat virna panemine annab sulle kattuvad WAF-i reeglid, mis blokeerivad üksteist, topeltlogi meilide tulva ja aeg-ajalt "sa oled blokeeritud" vea sinu enda admin-sisselogimisel. Üks aktiivne turvaplugin, hästi konfigureeritud, on piisav. Loe miks liiga palju turvapluginaid tagasilöögi annavad enne kui midagi muud hunnikusse lisate.


Oma ülemusele tõe rääkimine ilma paanikat tekitamata

Su ülemus ei hooli CVSS-skooridest ega PHP objekti süstimisest. Teda huvitab, kas sait on maas, kas pood ei võta tellimusi vastu ja IT-eelarve. Tõlge on lihtne: "Sellel pluginil on teadaolev autentimata kaugkoodi käivitamise viga. Võõras saab kustutada meie saidi sisu või installida tagaukse. Peame selle kvartalis välja vahetama." Seejärel näita prioriteetide nimekirja: asenda sündmusplugin, keela kontaktvormi failiüleslaadimine, kuni see nõuetekohaselt failitüüpe valideerib, vaheta kõik admini mandaadid ja planeeri järgmine kvartaliülevaatus.

Samuti on sul keeleeelis: CISA haldab teadaolevate ärakasutatud haavatavuste kataloogi, mis ütleb sulle täpselt, millised avalikustatud vead on praegu looduses aktiivselt kasutusel. Kui mõni su pluginatest seal esineb, pole argument enam teoreetiline — teadaolev ärakasutus on olemas ja sa oled ajapiirangu all. Kui nad ei esine, kasuta seda ikkagi standardina, mida "kiireloomuline" tähendab. CISA jälgimine muudab mittetehnilisele ülemusele veenmise lihtsamaks, et see pole andmepüügimeil; see on avalik andmebaas sellest, mida ründajad praegu teevad. Kui kvartal lõpeb, on sul parandustööde töövoog, mitte ühekordne linnukese harjutus. Töövoog haavatavuste muutmiseks paikamistsükliks hoiab harjumuse elus.


Enne oli katkine sait, meeletu meil ja puhas skanneri aruanne, mis ütles, et miski pole valesti. Pärast on kvartaalne rituaal: inventuur, klassifitseerimine, väljastpoolt testimine, kasutajate ja logide ülevaatus ning tehtud otsuste ja aktsepteeritud riskide kirjapanek. Skannerist saab kaart, kuhu vaadata, mitte tervisetõend. Pluginatest saab nimekiri, mida sa nimepidi tunned. Ja järgmine kord, kui su ülemus auditi kohta küsib, on sul vastus, mis ei nõua sõrmede ristamist.

Sources (5)