Критична вразливість як тест для IT-підрядника: 5 питань, які варто поставити після PHP2Shell

Як зрозуміти, що у вас хороший IT-підрядник? Поки все працює – ніяк. Справжня перевірка починається тоді, коли стається щось критичне. PHP2Shell – саме такий момент.

21 жовтня розробники PHP випустили екстрені оновлення для двох вразливостей рівня 9,2 з 10. Вони дозволяють захопити сервер без пароля. Під загрозою опинилися сайти на PHP, а це, за даними W3Techs, приблизно 69% сайтів з відомою серверною технологією. Першу спробу атаки фахівці Amazon зафіксували ще 17 жовтня, до публічного оголошення.

Якщо ваш сайт, інтернет-магазин чи особистий кабінет клієнта працює на PHP, ось п'ять питань, які варто поставити команді, що його підтримує. До кожного – тривожний сигнал і те, як виглядає зріла відповідь.

Питання 1. «Яка версія PHP стоїть на всіх наших серверах?»

Ключове слово тут – «всіх». Не лише основний сайт, а й тестові копії, старі лендинги, адмінки, CRM та внутрішні сервіси.

Тривожний сигнал: підрядник називає версію лише для основного сайту або обіцяє «подивитися».

Зріла відповідь: у перші години команда складає повну інвентаризацію PHP-середовищ, включно з тими, про які давно забули.

Питання 2. «Чи перевіряли нас на ознаки зламу, а не лише оновили?»

Оскільки спроби атак були ще до виходу патча, оновлення закриває вразливість, але не прибирає наслідки, якщо зловмисник уже встиг зайти.

Тривожний сигнал: «Ми оновили PHP, все гаразд».

Зріла відповідь: команда аналізує активність на серверах щонайменше з 17 жовтня, коли було зафіксовано першу спробу атаки.

Питання 3. «Що робимо із застарілими версіями?»

Виправлення вийшли для гілок 8.2–8.5. PHP 8.1 і старші версії офіційно вже не підтримуються, і для них є лише мінімальні тимчасові латки. Багато магазинів досі працюють на PHP 7.x, і тут «просто оновити» не вийде: потрібна міграція з допрацюванням коду та тестуванням.

Тривожний сигнал: підрядник не може пояснити, що буде з вашою версією, або пропонує неперевірені «латки» із форумів.

Зріла відповідь: для кожного проєкту на застарілій гілці є окремий план міграції з термінами, оцінкою та регресійним тестуванням.

Питання 4. «Чи змінили ключі доступу до наших сервісів?»

Якщо зловмисник отримав контроль над сервером, він міг отримати й паролі та ключі доступу до платіжних систем, служб доставки, CRM. Оновлення PHP ці дані не поверне.

Тривожний сигнал: питання викликає здивування.

Зріла відповідь: якщо є підстави вважати сервер скомпрометованим, заміну паролів і ключів планують разом із клієнтом, щоб не зупинити роботу інтеграцій.

Питання 5. «Що буде, коли з'явиться наступна вразливість?»

PHP2Shell не остання. Важливо не лише те, як підрядник відреагував цього разу, а й те, чи є в нього процес на майбутнє.

Тривожний сигнал: кожна критична новина – це аврал і пошук винних.

Зріла відповідь: регулярні оновлення, актуальний перелік усіх середовищ і моніторинг безпеки. Тоді реакція на наступний інцидент займає години, а не тижні.

Якщо чітких відповідей немає

Це не обов'язково означає, що підрядник поганий. Але це означає, що у вас немає ясності щодо ризиків, а в ситуації з PHP2Shell це дорогий стан.

У такому випадку варто почати з короткого аудиту безпеки. Його мінімальний обсяг:

• інвентаризація всіх PHP-середовищ;
• перевірка на обидві вразливості;
• експрес-перевірка на ознаки зламу з 17 жовтня;
• план дій із пріоритетами та термінами.

На практиці така перевірка часто показує, що сайт потребує допрацювання, навіть якщо власник вважав, що все гаразд.

Висновок

Критична вразливість – неприємний, але чесний тест для IT-підрядника. Він показує не те, як команда працює в звичайні дні, а чи є в неї процеси, які спрацьовують під тиском.

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