Патчі для вразливостей нульового дня: встановлено ще не означає запущено

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

Більшість команд добре справляються з першим кроком. Інциденти трапляються на решті трьох.

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

Довготривалі служби тримають старий код у пам’яті. Вебсервер, пул PHP-FPM, сервер застосунків Java чи база даних обслуговуватимуть вразливу збірку, доки їх щось не перезапустить. Менеджер пакетів, облік активів і сканер відповідності можуть показувати «оновлено», поки живий процес досі вразливий.

PHP2Shell — наочний приклад. Це вразливість середовища виконання PHP у жовтні 2026 року, яка давала зловмисникам виконання коду одним запитом без автентифікації. Виправлення складалося з оновлення пакета й перезапуску Apache або PHP-FPM. Хости, що зробили лише першу половину, далі відповідали на запити експлойта, показуючи номер виправленої версії.

Типові причини буденні:

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

Перевіряйте запущений процес, а не базу пакетів. Запитайте службу, що вона обслуговує: заголовок версії, ендпоінт стану або шлях до бінарного файлу й час запуску живого процесу.

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

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

• Шукайте закріплення. Вебшели, нові заплановані завдання, неочікувані облікові записи й файли, яких ваше розгортання ніколи не постачало.
• Замініть секрети, які могла прочитати система. Конфігураційні файли й змінні середовища на скомпрометованому хості вже скомпрометовані, навіть після закриття діри.
• Повідомте. Якщо персональні дані були досяжні, команда із захисту даних має дізнатися зараз, бо строки повідомлення про порушення рахуються від моменту обізнаності, а не від завершення розслідування.

Патч — це запобігання. Прибирання — це реагування на інцидент, і йому потрібен окремий відповідальний.

Не лише сервери страждають від відкладеного патча. На кінцевих пристроях саме людина перед екраном часто вирішує, чи встановиться критичне оновлення сьогодні, чи пролежить тиждень за кнопкою «нагадати пізніше».

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

1. Інвентаризуйте кожну копію вразливого компонента, зокрема контейнери, пристрої й забуті хости.
2. Застосуйте правило WAF або на периметрі, якщо воно є, і сприймайте його як куплений час, а не виправлення.
3. Встановіть виправлену збірку, а тоді перезапустіть або перерозгорніть службу, щоб вона справді працювала.
4. Перевірте живу версію й повторіть експлойт, щоб переконатися, що він не спрацьовує.
5. Шукайте закріплення, замініть розкриті секрети й передайте будь-яке розкриття даних.
6. Зафіксуйте, що було розкрито, що закрило діру і яке прибирання ще лишилося.

Хочете, щоб ваші інженери й працівники відпрацювали це до наступної вразливості нульового дня? Подивіться, як платформа RansomLeak проводить практичне навчання на інцидентах, або напишіть нам.