Одитирате WordPress? Започнете с плъгините си

Резюме

Повечето одити на сигурността на WordPress са назад: те наблягат на актуализациите на ядрото и докладите от скенерите, докато уязвимостите, които наистина засягат, се крият в плъгините. Бяла книга на SANS установи, че над 96% от уязвимостите в екосистемата произхождат от добавки на трети страни, а около 43% не изискват удостоверяване. Тази статия преминава през ориентиран към плъгините одит за малък вътрешен маркетингов екип, използвайки историята на сайт, който беше хакнат, защото всички сканираха грешния слой. Ще научите как да инвентаризирате и класифицирате всеки плъгин, да тествате неудостоверени атакуеми повърхности, ръчно да преглеждате потребители и логове и да превеждате констатациите на език за риска, който нетехнически шеф разбира. Резултатът е тримесечен ритуал за триаж вместо упражнение с отметка.

Повечето одити на сигурността на WordPress са театър. Прекарвате следобед в актуализиране на ядрото, смяна на администраторската парола и пускане на скенер за плъгини, който гордо отчита „Няма критични проблеми.“ Междувременно плъгинът, който приема качвания на файлове и е актуализиран за последно преди три години, седи тихо в директорията ви за качвания, чакайки някой, който не е в списъка с гости.

Числата потвърждават това. Бяла книга на SANS за сканиране на плъгини на WordPress установи, че повече от 96% от уязвимостите в екосистемата на WordPress произхождат от добавки на трети страни, като темите са 4%, а ядрото под 1%. Около 43% от тези дефекти могат да бъдат експлоатирани без никакво удостоверяване. Така че, когато вашият одит харчи повечето си енергия за ядрото, вие разглеждате дърветата, докато горски пожар започва в съседната директория с плъгини.

Това не е призив за паника относно ядрото. Уязвимостите в ядрото като wp2shell RCE пропуските, които получиха публични експлойти наскоро, трябва да бъдат коригирани в деня, в който бъдат обявени. Но те са достатъчно редки, за да не заслужават по-голямата част от часовете ви за одит. По-голямата част принадлежи на плъгините и там започва истинският работен процес.

Представете си сценария „преди“: неделя сутрин, сайтът ви пренасочва към страница за казино, а шефът ви пише имейл: „Мислех, че имаме сигурност.“ Имахте сигурност — имахте одит с отметка. Сценарият „след“ е система за триаж, която третира плъгините като атакуемата повърхност, каквато всъщност са, тества ги отвън и проверява нещата, които скенерите не могат да видят.

Вие сте в малък маркетингов екип със сайт на WordPress, който работи от 2017 г. Той има персонализиран плъгин за регистрация на събития, създаден от фрийлансър през 2019 г., плъгин за контактна форма с поле за качване на файлове и плъгин за слайдер, който е бил продаден и вече няма публична страница за актуализации. Това не е необичаен стек. Тук започва вашият одит.

---

Инвентаризацията на плъгините е вашата политика за сигурност

Направете инвентаризация на всеки плъгин и тема. Запишете версията, датата на последна актуализация, дали доставчикът е все още жив и дали някой наистина го използва. След това класифицирайте всеки в категория: поддържан и използван, поддържан и неизползван, изоставен, но използван, изоставен и неизползван. Премахнете неизползваните веднага. Игнорирайте защитата „това е само $50/месец“ — неизползван плъгин е отговорност, а не функция. За изоставените, но използвани, решете: заменете го или приемете риска и го запишете в регистър на рисковете, който шефът ви е виждал.

Плъгинът за регистрация на събития попада в категорията „изоставен, но използван“. Той приема плащания и изпраща имейли за потвърждение, а замяната му е проект, така че засега го запазвате. Но си пишете бележка, която казва: „това е най-вероятният източник на бъдещ пробив“, и го добавяте в началото на списъка за тестване.

Атакуема повърхност	Дял от известните уязвимости на WordPress	Приоритет за одит
Добавки на трети страни	Над 96%	Най-висок — инвентаризация, сканиране, тестване, замяна
Теми	Около 4%	Среден — само ако са персонализирани или остарели
Ядро на WordPress	Под 1%	Нисък — поддържайте го актуализирано, продължете напред

Когато SecurityWeek преброи повече от 8 000 нови уязвимости на WordPress през 2024 г., по-голямата част бяха от този тип: проблеми с плъгини, а не кръпки за ядрото. Скенерът ще ви каже за тези, които са били разкрити и са получили CVE. Той няма да ви каже за персонализирания код на фрийлансъра без CVE, защото никой никога не го е разглеждал внимателно. Този ръчен поглед е ваша работа. За по-задълбочено разглеждане на проверки, специфични за плъгини, вижте това ръководство за одит на вашите WordPress плъгини за уязвимости.

---

Тествайте го като непознат: 43-те процента, които не изискват парола

Вашият скенер вече ви е казал, че всичко е наред. Сега направете това, което той не може: изследвайте сайта отвън, без влизане. Започнете с всяко поле за качване на файлове, всяка форма, която обработва POST, всяка крайна точка admin-ajax. Дали качването действително проверява съдържанието на файла или само разширението? Къде попадат качените файлове и може ли уеб сървърът да изпълнява PHP в тази директория? 43-те процента от дефектите в плъгините, които не изискват удостоверяване, обикновено се намират точно на тези места: неудостоверен съхранен XSS, произволно качване на файлове и инжектиране на PHP обекти.

Плъгинът за контактна форма позволява на посетителите да прикачат автобиография. Той преименува файла, използвайки оригиналното име на посетителя, така че качвате „resume.php“ и той го записва в папка /uploads/contact/, която е записваема по дизайн. Ако сървърът също позволява изпълнение на PHP в тази директория, нападателят току-що е получил уебшел. Fastly е документирал активно експлоатиране на неудостоверен съхранен XSS в WordPress плъгини — това не е нишeв риск от слайдове. Вашият тест е прост: създайте файл с известно съдържание, качете го и вижте дали се връща с оригиналното си име и тип. След това опитайте да качите .php файл. Ако се върне като .php, току-що сте открили експлоатируема дупка.

Тук също се проваля аргументът „но нашият плъгин за сигурност има WAF“. WAF може да блокира известно полезно натоварване, но правилата за нормализиране на пътя, на които разчита, често се разминават с това, което сървърът действително прави. Ръководството за тестване на уеб сигурността на OWASP е по-добра референция от всеки табло: то описва как да тествате за дефекти при качване на файлове и съхранен XSS по методичен начин. И ако откриете, че плъгинът е изоставен, е време да приложите протокола за почистване: скритата опасност от изоставени WordPress плъгини обяснява защо оставянето на мъртво разширение на място е по-лошо, отколкото да го премахнете и да коригирате работния си процес.

---

Какво не вижда скенерът: потребители, логове и стар код

Динамичните тестове улавят това, което е изложено в момента. Ръчният преглед улавя това, което вече е вътре. Започнете с потребителските акаунти: отворете списъка с администратори и потърсете акаунти, които не сте създали. Администратор на име „support“ с безплатен имейл адрес и без човек зад него е задна врата, а не колега. Проверете времевите клейма на файловете в wp-content/uploads за нещо наскоро променено, което не е ваше съдържание. Проверете лога за достъп на сървъра за заявки, които приличат на curl команда на бот, а не на браузър на човек.

Плъгинът за събития има качване на „снимка на лектор“, което записва в uploads/event-headshots/. По време на теста откривате файл, който не е ваш — малък PHP файл с произволно изглеждащо име. Това е вашият уебшел. Той е попаднал там чрез същия дефект при качването, който тествахте преди две седмици, и досега скенерът пак няма да го „види“, защото не е уязвимост на плъгин; това е доказателство за такава. Ръчният преглед го открива, изтрива го и проверява лога за IP адреса, който го е поставил там. Invicti отбеляза, че инжектирането на PHP обекти в плъгините е във възход и е почти невидимо за black-box сканирания, защото злонамереният обект се материализира едва по време на изпълнение. Единственият начин да го забележите е да четете код за опасни модели като извикване на unserialize() върху въведени от потребителя данни. Четенето на няколкостотин реда от персонализирания плъгин е по-евтино от плащането на ретейнер за реагиране при инциденти.

Тук също стандартният съвет „просто инсталирайте повече плъгини за сигурност“ достига своята граница. Натрупването на три плъгина за сигурност ви дава припокриващи се WAF правила, които се блокират взаимно, поток от дублирани имейли от логове и случайната грешка „вие сте баннати“ при вашето собствено администраторско влизане. Един активен плъгин за сигурност, добре конфигуриран, е достатъчен. Прочетете за защо твърде много плъгини за сигурност имат обратен ефект, преди да добавите нещо друго към купчината.

---

Казвайки истината на шефа си, без да предизвиквате паника

Вашият шеф не го е грижа за CVSS резултати или инжектиране на PHP обекти. Той го е грижа за спирането на сайта, магазинът да не приема поръчки и ИТ бюджета. Преводът е прост: „Този плъгин има известен неудостоверен дефект при изпълнение на отдалечен код. Непознат може да изтрие съдържанието на сайта ни или да инсталира задна врата. Трябва да го заменим през това тримесечие.“ След това покажете списъка с приоритети: заменете плъгина за събития, деактивирайте качването на файлове в контактната форма, докато не валидира правилно типовете файлове, ротирайте всички администраторски идентификационни данни и планирайте следващия тримесечен преглед.

Имате и езиково предимство: CISA поддържа каталога Known Exploited Vulnerabilities, който ви казва точно кои публикувани дефекти се използват активно в дивата среда. Ако някой от вашите плъгини се появи там, аргументът вече не е теоретичен — съществува известен експлойт и сте под напрежение. Ако не се появят, използвайте го все пак като стандарт за това какво означава „спешно“. Проследяването на CISA улеснява убеждаването на нетехнически шеф, че това не е фишинг имейл; това е публична база данни за това какво правят нападателите в момента. Когато тримесечието приключи, ще имате работен процес за отстраняване, а не еднократно упражнение с отметка. Работен процес за превръщане на уязвимостите в цикъл на кръпки поддържа навика жив.

„Преди“ беше счупен сайт, трескав имейл и чист доклад от скенера, който казваше, че нищо не е наред. „След“ е тримесечен ритуал: инвентаризация, класификация, тестване отвън, преглед на потребители и логове и записване на решенията, които сте взели, и рисковете, които сте приели. Скенерът се превръща в карта къде да гледате, а не в свидетелство за здраве. Плъгините стават списък, който познавате по име. И следващият път, когато шефът ви попита за одита, ще имате отговор, който не включва кръстосване на пръсти.