Pirmiausia rūšiuokite, tada lopykite: praktinis „WordPress“ saugumo auditas

Santrauka

Šiame straipsnyje paaiškinama, kodėl beatodairiškas „WordPress“ papildinių lopymas yra kontrproduktyvus saugumo įprotis, ir siūlomas tikslingesnis, pirmiausia rūšiuojantis audito metodas. Jame pabrėžiama, kad maždaug 43% papildinių pažeidžiamumų gali būti išnaudojami be autentifikacijos, todėl jie nusipelno pirmenybės. Kontrolinis sąrašas apima pažeidžiamumų rūšiavimą, papildinių inventoriaus apkarpymą, nuskaitymo rezultatų vertinimą su sveiku skepticizmu, vartotojų teisių auditą, žiniatinklio apvalkalų (webshell) ir žurnalų anomalijų tikrinimą bei audito ataskaitų supaprastinimą. Kiekvienas žingsnis apima praktinį pavyzdį ir įspėjimą, parašytą rinkodaros specialistams, kurie turi pagrįsti saugumo darbus netechniškam vadovui. Laikydamiesi šio metodo, galite sutelkti ribotus išteklius į rizikas, kurios iš tikrųjų svarbios, o ne vytis kiekvieną įspėjimą.

Tą pačią dieną lopyti kiekvieną papildinį yra vienas iš tų saugumo įpročių, kurie atrodo atsakingi, bet iš tikrųjų gali būti kontrproduktyvūs. Jų logika yra pagrįsta: pramonės tyrimai nuosekliai priskiria daugiau nei 96% „WordPress“ ekosistemos pažeidžiamumų trečiųjų šalių papildiniams, o pastarasis atskleistų spragų tempas daro baimę skubia — „SecurityWeek“ pranešė apie 8 000 naujų „WordPress“ pažeidžiamumų vien 2024 metais. Tačiau „vienodai atnaujinti viską“ traktuoja visus pažeidžiamumus taip, lyg jie keltų tokią pačią riziką, o taip nėra. Didelė dalis papildinių trūkumų reikalauja, kad atakuotojas pirmiausia būtų prisijungęs; skaičiavimai rodo, kad neautentifikuota dalis sudaro maždaug 43%. Tai yra trūkumai, į kuriuos anoniminis botas gali pataikyti masteliu, ir jie nusipelno visiškai kitokio atsako nei tas, kuriam reikia egzistuojančios paskyros.

Šiame straipsnyje pateikiamas pirmiausia rūšiuojantis auditas: kontrolinis sąrašas, sukurtas aplink pasiekiamumą, aktyvumą ir liekamąją riziką, o ne lopymo greitį. Jis parašytas turint omenyje asmenį, kuris turi paversti saugumo radinius į biudžeto pokalbį su netechnišku sprendimų priėmėju, nes sunkiausia „WordPress“ audito dalis yra ne įrankių paleidimas — o paaiškinimas, kodėl ramus, prioritetinis sąrašas yra naudingesnis nei dramatiškas „lopykite viską“ signalas.

Rūšiuokite savo pažeidžiamumų sąrašą pagal „Kas gali jį pasiekti neprisijungęs“

Pažeidžiamumo sunkumo balas parodo, kokia didelė gali būti žala; jis neparodo, kokia tikimybė, kad kažkas jį suaktyvins. Autentifikavimo reikalavimai yra pirmasis filtras, kurį reikia pritaikyti.

Įsivaizduokite, kad jūsų svetainėje veikia puslapio konstruktorius, turintis saugomą XSS trūkumą, kuriam reikalingi administratoriaus kredencialai, ir mažas importavimo papildinys, leidžiantis bet kuriam lankytojui įkelti failą į laikiną aplanką. Puslapio konstruktoriaus pažeidžiamumas gali gauti aukštesnį CVSS balą, tačiau atakuotojas, norėdamas jį suaktyvinti, jau turi turėti administratoriaus paskyrą. Kita vertus, importavimo papildinys yra atviras kiekvienam praeinančiam skenavimo botui. Pirmiausia lopyti puslapio konstruktorių, nes jis gavo aukštesnį balą, yra tokia klaida, kuri palieka jūsų tikrąsias duris atviras.

Ištraukite papildinių pažeidžiamumų sąrašą iš savo saugumo skaitytuvo ar saugumo pranešimų kanalų ir padalykite jį į dvi krūvas: „nuotolinis, be autentifikacijos“ ir „reikalauja vaidmens“. Lopykite neautentifikuotą krūvą per kelias valandas — o jei pažeidžiamumas atsiranda CISA žinomų išnaudotų pažeidžiamumų kataloge, vertinkite jį kaip avarinį, nes tas katalogas seka spragas, kurios jau naudojamos realiose atakose. Autentifikuota krūva tampa įprasta priežiūros užduotimi, planuojama kartu su atnaujinimų testavimu.

Ar tai reiškia, kad galite ignoruoti autentifikuotus pažeidžiamumus? Ne. Tačiau jie priklauso kitam ritmui, ypač jei jūsų svetainėje yra daug autorių ar redaktorių. Rūšiavimas nėra rizikos ignoravimas; tai jos sekos nustatymas. Standartinis papildinių auditas seka versijas, bet ne pasiekiamumą. Būtent šis žingsnis daro skirtumą.

Ištrinkite tai, ko nenaudojate (arba bent paslėpkite)

Kiekvienas įdiegtas papildinys yra kelias, kuriuo atakuotojas gali eiti, o neaktyvūs papildiniai dažnai yra blogiausi iš visų: niekas jų nestebi, niekas jų neatnaujina, ir jie guli žinomoje katalogų struktūroje, kurią skeneriai atpažįsta.

Apsvarstykite planavimo papildinį, kurį buvęs praktikantas naudojo dviejų savaičių paleidimo kampanijai. Jis yra deaktyvuotas, bet vis dar diske, o tiekėjas trejus metus neišleido atnaujinimo. Atakuotojui nesvarbu, kad jūs jo nenaudojate; jam rūpi, kad failas /wp-content/plugins/launch-scheduler/ajax.php egzistuoja ir priima neautentifikuotas užklausas. Deaktyvuoti papildiniai yra dažnas „nemaniau, kad reikia tai atnaujinti“ temos šaltinis incidentų peržiūrose. Egzistuojantis papildinys yra atakos paviršius, nesvarbu, ar jis aktyvus, ar ne.

Sudarykite inventorių ir pažymėkite kiekvieną papildinį: „aktyviai naudojamas“, „reikalingas, bet neaktyvus“ arba „nebereikalingas“. Viską, kas yra paskutinėje grupėje, deaktyvuokite ir ištrinkite — ne tik deaktyvuokite, nes papildinio kodas lieka skaitomas, kol jis nėra pašalintas. „Reikalingas, bet neaktyvus“ grupei bent jau apribokite prieigą prie papildinio failų arba perkelkite jo duomenis į užrakintą vietą. Nustebsite, kiek papildinių buvo įdiegta vienai kampanijai ir niekada nepašalinta. Apleisti papildiniai turi įprotį tapti įsipareigojimais, kaip aptarta mūsų išsamiame straipsnyje apie apleistus „WordPress“ papildinius.

Net ištrynimas kelia riziką. Jei papildinys palaikė turinį, kuris vis dar yra jūsų puslapyje, jo pašalinimas gali ką nors sulaužyti. Taigi inventoriaus žingsnis nėra įpareigojimas beatodairiškai trinti; tai priežastis raštu nuspręsti, ką paliekate ir kodėl.

Vertinkite nuskaitymą kaip atskaitos tašką, o ne nuosprendį

Automatinis nuskaitymas yra parašo atitikimo pratimas: jis lygina jūsų svetainės žinomus modelius su duomenų baze, kurioje yra žinomų blogų modelių. Jis nemąsto apie jūsų konfigūraciją, vartotojų vaidmenis ar pasirinktinio kodo sąveiką.

Ką nuskaitymas pagauna	Ko jis įprastai nepastebi
Pasenusias papildinių versijas su žinomais CVE	Per plačias vartotojų paskyras
Atskleistus failus ir numatytuosius administratoriaus vartotojų vardus	Neįprastus prisijungimo modelius ar naujus administratorius
Žinomų išnaudojimų parašus	Neteisingai sukonfigūruotus failų leidimus
Naujausius kenkėjiškos programos modelius	Logikos klaidas pasirinktiniame kode ir papildinių sąveikoje

Tokie vadovai kaip SANS WordPress papildinių skenavimas dėl pažeidžiamumų aiškiai parodo, kad skenavimas yra specializuota veikla, turinti realią metodiką, o OWASP žiniatinklio saugumo testavimo vadovas statinį ir dinaminį testavimą (SAST ir DAST) apibrėžia kaip papildančius sluoksnius, o ne pakaitalus. Nuskaitymas, kuris grįžta švarus, tiesiog reiškia, kad žinomi parašai nesutapo; tai nieko nesako apie tai, ar jūsų svetainė iš tikrųjų saugi.

Naudokite nuskaitymą potencialiems radiniams generuoti, tada kiekvieną radinį patikrinkite rankiniu būdu. Ir prieš įdiegdami dar vieną saugos skenavimo papildinį, pagalvokite, kad saugos papildinių kaupimas gali atnešti priešingą efektą ir sukurti akląsias zonas. Jei ataskaitos švarumas tampa svarbesnis už faktinę riziką, praradote esmę.

Audituokite vartotojus taip, kaip atakuotojas juos enumeruoja

„Neautentifikuotas“ atakos paviršius reikalauja jūsų skubaus dėmesio, tačiau autentifikuotos atakos taip pat yra prieinamos atakuotojams — jiems tiesiog reikia kredencialų. Vartotojai yra kelias į sistemą, o jūsų vartotojų sąrašas yra to kelio žemėlapis.

Jūsų „WordPress“ vartotojų sąraše tikriausiai yra „admin“ paskyra su tokiu vartotojo vardu kaip marketing ir slaptažodžiu kaip Marketing2020, buvusio laisvai samdomo darbuotojo redaktoriaus paskyra, kuri niekada nebuvo pašalinta, ir sauja paskyrų, kurių kūrimo beveik neprisimenate išoriniams tiekėjams. Atakuotojai naudoja viešai matomus el. pašto adresus ir nutekintų duomenų bazes, kad sudarytų kandidatų sąrašus, tada bando tuos vartotojų vardus ir slaptažodžius milijonuose svetainių. Užmiršta paskyra su pakartotinai naudojamu slaptažodžiu yra visiškai tinkamas prisijungimas: jiems nereikia laužyti papildinio pažeidžiamumo, jei jie gali įeiti pro priekines duris.

Eksportuokite visų vartotojų sąrašą, skirkite laiko jį peržiūrėti ir pašalinkite arba sumažinkite paskyras, kurioms nebereikia prieigos. Įdiekite dviejų veiksnių autentifikaciją kiekvienai administratoriaus paskyrai ir pakeiskite bet kurį slaptažodį, kuris atrodo kaip jūsų įmonės pavadinimo variantas. Po to apsvarstykite minimalios privilegijos struktūrą: daugumai kasdienių turinio redaktorių pakanka Redaktoriaus vaidmens — Administratoriaus vaidmenys turėtų būti skirti tik tiems, kurie iš tikrųjų diegia papildinius ar keičia kodą.

„WordPress“ REST API atskleidžia vartotojų ID bet kam, todėl negalite visiškai paslėpti vartotojų vardų. Bet galite juos padaryti sunkiau atspėjamus, vengdami nuspėjamų pavadinimų konvencijų, ir galite automatiškai blokuoti akivaizdžius brutalios jėgos bandymus.

Ieškokite to, ką palieka atakuotojai

Kompromisas nėra vienas momentas; tai procesas. Įėjimo taškas gali būti užlopytas, tačiau atakuotojas, įdiegęs užpakalines duris, vis tiek turės prieigą po to, kai pažeidžiamumas bus ištaisytas. Auditas dėl išlikimo (persistencijos) skiriasi nuo audito dėl įėjimo.

„Fastly“ saugumo komanda rašė apie aktyvų neautentifikuoto saugomo XSS išnaudojimą „WordPress“ papildiniuose — scenarijus, leidžiančius atakuotojui perimti sesiją iš teisėto vartotojo naršyklės. Nepriklausomas „Invicti“ tyrimas rodo PHP objektų injekcijų padidėjimą — techniką, kuri dažnai prasprūsta pro parašais pagrįstus skenerius. O garsiai žinomu WP2Shell atveju net pagrindiniame „WordPress“ buvo RCE spragų su viešais išnaudojimais. Nė vienas iš šių dalykų nėra toks, kokį įprastas „ieškoti žinomų kenkėjiškų programų“ nuskaitymas patikimai pagauna. Jų bendras bruožas yra tai, kad jie palieka pėdsakus: papildomą administratoriaus vartotoją, PHP failą, įkeltą į wp-content/uploads/, prisijungimą 3 val. nakties iš naujo IP.

Bent kartą per mėnesį peržiūrėkite prieigos žurnalus dėl POST užklausų į .php failus uploads aplanke ir dėl administratoriaus prisijungimų iš netikėtų vietų. Stebėkite savo vartotojų sąrašą dėl naujų administratoriaus paskyrų, kurių nesukūrėte. Jei galite paleisti failų vientisumo monitorių, sukonfigūruokite jį įspėti apie wp-admin ir wp-includes pakeitimus; jei ne, vienos eilutės failų modifikavimo laikų skirtumas yra tinkamas žemo technologinio lygio pakaitalas.

Žurnalų peržiūra sukuria klaidingus teigiamus rezultatus. Triukas yra apibrėžti savo „įprastą“ bazinę liniją prieš incidentą, o ne po jo. Jei sužinosite, kaip atrodo įprastas jūsų srautas, anomalijos taps garsesnės.

Parašykite vieno puslapio audito atmintinę, kurios jūsų bosui iš tikrųjų reikia

Saugumo patarimas pristatymo formato pavidalu yra bevertis, jei jis nevirto prioritetais. Tikslas nėra įtikinti savo bosą, kad esate puolami; tikslas parodyti, kad žinote, ką patikrinote, ką pataisėte ir kas vis dar yra atviras sprendimas.

Kai jūsų vadovas klausia „Ar esame saugūs?“, sąžiningas atsakymas nėra vienas žodis. Tai trumpas pasakojimas: „Praėjusią savaitę patikrinome papildinių sąrašą ir pašalinome keturis nenaudojamus papildinius. Radome vieną administratoriaus paskyrą, priklausiusią buvusiam darbuotojui, ir ją deaktyvavome. Yra du atviri klausimai: vis dar turime nuspręsti, ar pakeisti seną papildinį, ir vienai paskyrai neįdiegėme 2FA. Mūsų kita peržiūra po mėnesio.“ Toks atsakymas paverčia klausimą apie baimę klausimu apie procesą — ir suteikia netechniškam klausytojui tai, ką jis iš tikrųjų gali perpasakoti aukščiau.

Rašykite vieno puslapio audito pastabą kiekvieno patikros seanso pabaigoje. Naudokite paprastą lentelę: patikrinta, pataisyta, atvira, kita peržiūra. Paprasta kalba, ne rizikos simboliais ar bauginančia statistika. Jei einate atostogų, pastaba tampa perdavimo dokumentu tam, kas turi administratoriaus prieigą. Tai taip pat ištrauksite, kai po dviejų savaičių bosas staiga paklaus: „Ar viskas gerai?“ Jei tai tampa mėnesiniu ritmu, atliekate proaktyvų saugumo auditą, o ne vienkartinį nuskaitymą.

Nepildykite atmintinės kiekvienu nuskaitymo pažeidžiamumo balu. Esmė parodyti, kad palaikote ritmą, o ne kad per naktį tapote įsiskverbimo testuotoju. Ramus vieno puslapio dokumentas yra naudingesnis nei bauginanti išsami ataskaita.

Geriausiai apsaugota „WordPress“ svetainė nėra ta, kuri turi daugiausiai papildinių ar garsiausias nuskaitymo ataskaitas; tai ta, kurioje kažkas priėmė apgalvotus sprendimus dėl pasiekiamumo, prieigos ir išlikimo. Pradėkite nuo neautentifikuoto atakos paviršiaus, apkarpykite tai, ko nereikia, vertinkite nuskaitymus kaip užuominas, peržiūrėkite vartotojų vaidmenis ir planuokite padarinius. Lopykite protingiau, o ne viską — ir leiskite prioritetams būti tuo, ką ginsite kitame biudžeto pokalbyje.