Аудит WordPress? Почніть зі своїх плагінів

Резюме

Більшість аудитів безпеки WordPress є неправильними: вони наголошують на оновленнях ядра та звітах сканерів, тоді як вразливості, які насправді кусають, живуть у плагінах. У білій книзі SANS зазначено, що понад 96% вразливостей екосистеми походять із сторонніх плагінів, і приблизно 43% не потребують автентифікації. Ця стаття проводить через аудит, орієнтований на плагіни, для невеликої внутрішньої маркетингової команди, використовуючи історію сайту, який був зламаний, бо всі сканували не той рівень. Ви навчитеся інвентаризувати та класифікувати кожен плагін, тестувати неавтентифіковані поверхні атак, вручну переглядати користувачів і журнали, а також перекладати знахідки на мову ризиків, яку розуміє нетехнічний начальник. Результатом є щоквартальний ритуал тріажу замість вправи «для галочки».

Більшість аудитів безпеки WordPress — це театр. Ви проводите післяобідній час, оновлюючи ядро, змінюючи пароль адміністратора та запускаючи сканер плагінів, який гордо повідомляє «Критичних проблем немає». Тим часом плагін, який приймав завантаження файлів і востаннє оновлювався три роки тому, тихо сидить у вашій теці uploads, чекаючи на когось, кого немає в списку гостей.

Цифри це підтверджують. У білій книзі SANS про сканування плагінів WordPress зазначено, що понад 96% вразливостей екосистеми WordPress походять із сторонніх плагінів, з темами — 4% та ядром — менше 1%. Приблизно 43% цих дефектів можна експлуатувати без будь-якої автентифікації. Тож коли ваш аудит витрачає більшу частину своєї енергії на ядро, ви розглядаєте дерева, поки лісова пожежа починається в сусідній теці плагінів.

Це не заклик панікувати через ядро. Вразливості ядра, як-от нещодавно оприлюднені експлойти RCE wp2shell, слід виправляти в день їх оголошення. Але вони досить рідкісні, щоб не заслуговувати на більшу частину ваших аудиторських годин. Основна частина належить плагінам, і саме там починається реальний робочий процес.

Уявіть сценарій «до»: недільного ранку ваш сайт перенаправляє на сторінку казино, а ваш начальник пише електронною поштою: «Я думав, у нас є безпека». У вас була безпека — у вас був аудит «для галочки». Сценарій «після» — це система тріажу, яка розглядає плагіни як реальну поверхню атаки, тестує їх ззовні та перевіряє те, що сканери не бачать.

Ви працюєте в невеликій маркетинговій команді з сайтом на WordPress, який працює з 2017 року. На ньому є спеціальний плагін реєстрації подій, який фрілансер створив у 2019 році, плагін контактної форми з полем завантаження файлів і плагін слайдера, який був проданий і більше не має публічної сторінки оновлень. Це не незвичайний стек. Саме тут починається ваш аудит.

---

Інвентаризація плагінів — це ваша політика безпеки

Проведіть інвентаризацію кожного плагіна та теми. Запишіть версію, дату останнього оновлення, чи живий постачальник, і чи насправді хтось його використовує. Потім класифікуйте кожен у категорію: підтримується та використовується, підтримується та не використовується, залишений, але використовується, залишений і не використовується. Негайно видаліть невикористовувані. Ігноруйте захист «це лише $50/місяць» — невикористовуваний плагін є зобов’язанням, а не функцією. Для залишених, але використовуваних, вирішіть: замініть його або прийміть ризик і запишіть його в реєстр ризиків, який бачив ваш начальник.

Плагін реєстрації подій потрапляє в категорію «залишений, але використовується». Він приймає платежі та надсилає підтверджувальні листи, і його заміна є проєктом, тому ви поки що залишаєте його. Але ви робите запис: «це найбільш імовірне джерело майбутнього порушення», і додаєте його на початок списку тестів.

Поверхня атаки	Частка відомих вразливостей WordPress	Пріоритет аудиту
Сторонні плагіни	Понад 96%	Найвищий — інвентаризація, сканування, тестування, заміна
Теми	Близько 4%	Середній — лише якщо власні або застарілі
Ядро WordPress	Менше 1%	Низький — підтримуйте виправленим, рухайтесь далі

Коли SecurityWeek нарахував понад 8000 нових вразливостей WordPress у 2024 році, переважна більшість була саме такого типу: проблеми плагінів, а не виправлення ядра. Сканер розповість вам про ті, що були розкриті та отримали CVE. Він не розповість вам про власний код фрілансера без CVE, бо ніхто ніколи його ретельно не переглядав. Цей ручний перегляд — ваша робота. Для глибшого ознайомлення з перевірками, специфічними для плагінів, дивіться цей посібник із аудиту плагінів WordPress на вразливості.

---

Тестуйте як незнайомець: 43%, які не потребують пароля

Ваш сканер уже сказав вам, що все гаразд. Тепер зробіть те, що він не може: дослідіть сайт ззовні, без входу. Почніть з кожного поля завантаження файлів, кожної форми, що обробляє POST, кожної кінцевої точки admin-ajax. Чи дійсно завантаження перевіряє вміст файлу, чи лише розширення? Куди потрапляють завантажені файли, і чи може веб-сервер виконувати PHP у цій теці? 43% дефектів плагінів, які не потребують автентифікації, зазвичай знаходяться саме в цих місцях: неавтентифікований збережений XSS, довільне завантаження файлів та ін’єкція PHP-об’єктів.

Плагін контактної форми дозволяє відвідувачам прикріплювати резюме. Він перейменовує файл, використовуючи оригінальне ім’я відвідувача, тому ви завантажуєте «resume.php», і він зберігає його в теці /uploads/contact/, яка доступна для запису за замовчуванням. Якщо сервер також дозволяє запускати PHP у цій теці, зловмисник щойно отримав веб-шелл. Fastly задокументувала активну експлуатацію неавтентифікованого збереженого XSS у плагінах WordPress — це не ризик з нішевої презентації. Ваш тест простий: створіть файл із відомим вмістом, завантажте його та перевірте, чи повернеться він зі своїм оригінальним ім’ям і типом. Потім спробуйте завантажити файл .php. Якщо він повернеться як .php, ви щойно знайшли експлуатовану діру.

Це також місце, де аргумент «але наш плагін безпеки має WAF» руйнується. WAF може заблокувати відомий корисний вантаж, але правила нормалізації шляхів, на які він спирається, часто розходяться з тим, що насправді робить сервер. Посібник OWASP з тестування безпеки веб-додатків є кращим орієнтиром, ніж будь-яка інформаційна панель: він описує, як методично тестувати дефекти завантаження файлів і збережений XSS. І якщо ви виявите, що плагін залишений, настав час застосувати протокол очищення: прихована небезпека залишених плагінів WordPress пояснює, чому залишення мертвого розширення гірше, ніж його видалення та коригування вашого робочого процесу.

---

Що сканер не бачить: користувачі, журнали та старий код

Динамічні тести виявляють те, що зараз відкрите. Ручний перегляд виявляє те, що вже всередині. Почніть з облікових записів користувачів: відкрийте список адміністраторів і пошукайте облікові записи, які ви не створювали. Адміністратор на ім’я «support» з безкоштовною поштовою адресою та без людини за нею — це бекдор, а не колега. Перевірте часові позначки файлів у wp-content/uploads на наявність нещодавно змінених, які не є вашим вмістом. Перевірте журнал доступу сервера на наявність запитів, які схожі на команду curl бота, а не на браузер людини.

Плагін подій має завантаження «фото спікера», яке зберігається в uploads/event-headshots/. Під час тесту ви знаходите файл, який не є вашим — невеликий PHP-файл із випадковим ім’ям. Це ваш веб-шелл. Він потрапив туди через той самий дефект завантаження, який ви тестували два тижні тому, і до цього часу сканер усе ще його не «побачив», бо це не вразливість плагіна; це доказ такої. Ручний перегляд знаходить його, видаляє та перевіряє журнал на IP-адресу, яка його туди поклала. Invicti зазначила, що ін’єкція PHP-об’єктів у плагінах зростає, і вона майже непомітна для сканування «чорної скриньки», оскільки шкідливий об’єкт матеріалізується лише під час виконання. Єдиний спосіб його виявити — читати код на наявність небезпечних патернів, таких як виклик unserialize() на введених користувачем даних. Читання кількох сотень рядків спеціального плагіна дешевше, ніж сплата ретейнера за реагування на інциденти.

Це також місце, де стандартна порада «просто встановіть більше плагінів безпеки» досягає своєї межі. Встановлення трьох плагінів безпеки дає вам правила WAF, які перекриваються та блокують одне одного, потік дублікатів листів журналів і періодичні помилки «вас забанено» на вашому власному вході адміністратора. Один активний плагін безпеки, правильно налаштований, достатньо. Прочитайте про чому занадто багато плагінів безпеки дає зворотний ефект перед тим, як додавати ще щось до купи.

---

Розповідаємо начальнику правду без паніки

Ваш начальник не дбає про бали CVSS чи ін’єкцію PHP-об’єктів. Він дбає про те, щоб сайт не впав, магазин не приймав замовлення та про ІТ-бюджет. Переклад простий: «Цей плагін має відомий неавтентифікований дефект віддаленого виконання коду. Незнайомець може видалити вміст нашого сайту або встановити бекдор. Нам потрібно замінити його цього кварталу». Потім покажіть список пріоритетів: замініть плагін подій, вимкніть завантаження файлів у контактній формі, доки воно не почне належно перевіряти типи файлів, ротуйте всі облікові дані адміністратора та заплануйте наступний щоквартальний огляд.

Ви також маєте мовну перевагу: CISA підтримує каталог Known Exploited Vulnerabilities, який точно показує, які опубліковані дефекти активно використовуються у дикій природі. Якщо будь-який із ваших плагінів там з’явиться, аргумент більше не теоретичний — існує відомий експлойт, і ви на годиннику. Якщо ні, використовуйте його як стандарт для того, що означає «терміново». Відстеження CISA полегшує переконання нетехнічного начальника, що це не фішинг-лист; це публічна база даних того, що зараз роблять зловмисники. Коли квартал закінчиться, у вас буде робочий процес виправлення, а не разова вправа «для галочки». Робочий процес перетворення вразливостей на цикл виправлень підтримує цю звичку.

«До» — це зламаний сайт, панічний лист і чистий звіт сканера, який сказав, що все гаразд. «Після» — це щоквартальний ритуал: інвентаризація, класифікація, тестування ззовні, перегляд користувачів і журналів, а також запис рішень, які ви прийняли, і ризиків, які ви прийняли. Сканер стає картою того, куди дивитися, а не сертифікатом здоров’я. Плагіни стають списком, який ви знаєте на ім’я. І наступного разу, коли ваш начальник запитає про аудит, у вас буде відповідь, яка не потребує схрещених пальців.