Сучасні підходи до атаки на інфраструктуру: що потрібно знати CTO - Сергій Сарайчиков

Ось конспект доповіді, підготовлений згідно з вашими інструкціями.

1. Тема та контекст

Доповідь: «Атака на вашу інфраструктуру: як хакери знаходять ваші слабкі місця»
Конференція/Формат: fwdays (відео опубліковано 30 квітня 2026 року)
Спікер: Сергій. Має понад 15 років досвіду в розробці та 5+ років у кібербезпеці. Займається тестуванням державних сайтів, бере участь у bug bounty (2-ге місце на українській платформі Prozoro), є засновником компанії 42, яка впроваджує рішення для запобігання витокам даних.

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

2. Ключові тези

• 80% успіху атаки залежить від якості розвідки (Reconnaissance). Хакери не гадають, де у вас вразливість. Вони автоматично збирають всю доступну інформацію: всі IP-діапазони, субдомени (через Fofa, Shodan, DNS Grabbing), а потім проганяють кожен знайдений ресурс через автоматичні сканери. Якщо автоматика знаходить вразливість, починається ручна експлуатація. Ваша IP-адреса, потрапивши в бази сканерів (а потрапляють вони туди дуже швидко), буде скануватися автоматично.

• Найпоширеніша помилка — це «забуті» сервери (Dev, Stage, QA) та «тіньові» субдомени. Компанії фокусуються на захисті основного домену (топ-20% ресурсів), забуваючи про 80% іншої інфраструктури — dev-сервери, старі лендінги на WordPress, Grafana, Prometheus, PhpMyAdmin. Саме ці незахищені або занедбані ресурси стають «заднім входом» для хакера. Приклад: навіть якщо назвати dev-сервер super-secret-stage.mycompany.com, хакери легко знайдуть його через парсинг сертифікатів або аналіз мобільних застосунків.

• Проблема сучасних інструментів сканування — це фокус на хибно-позитивних спрацюваннях (False Positives). Стандартні інструменти (OWASP ZAP, Burp Suite) генерують величезні звіти (наприклад, 180 сторінок на один субдомен), де 95% — це або False Positive, або вразливості без реального імпакту. Це забирає багато часу команди безпеки на аналіз сміття, замість того, щоб одразу фокусуватися на критичних проблемах.

• Ланцюжок атаки (Chain of Exploitation) — ключ до компрометації. Хакер рідко знаходить «ідеальну» вразливість одразу. Він комбінує кілька невеликих помилок. У доповіді наведено реальний кейс: хакер знайшов dev-сервер медичної системи з увімкненим Laravel Debug Bar. Через нього він отримав сесійний токен адміністратора. В адмінці завантажив shell-файл (Remote Code Execution). З сервера здобув хешований пароль, який виявився однаковим для адміністратора на dev- та prod-серверах (reuse password). З цим паролем він отримав доступ до продакшну і всю базу пацієнтів.

3. Технічні деталі

• Методологія збору субдоменів (Subdomain Enumeration):

  1. Парсинг IP-діапазонів Cloud-провайдерів: Cloud-провайдери публікують свої IP-діапазони. Сканер парсить 443-й порт усіх цих IP, отримує SSL-сертифікати та витягує з них назви субдоменів.
  2. GitHub Recon (OSINT): Навіть якщо репозиторій приватний, хакери моніторять публічні парсинги, коміти, Issue трекери, де випадково можуть бути згадки про внутрішні домени або IP. За даними спікера, GitHub дає близько 5-10% знахідок від загальної маси.
  3. Мутація (Mutating): Автоматична генерація варіантів назв: stage, dev, test, qa, admin, backup тощо, які додаються до основного домену.

• Режим Debug (Laravel Debug Bar): Увімкнений laravel-debugbar (або аналог) дозволяє не тільки бачити SQL-запити та час виконання, але й у старих версіях (до 8-ї) дозволяв перехоплювати сесійні токени інших користувачів, включно з адміністраторами.

• Публічна Swagger/OpenAPI документація: Це «дорожня карта» для хакера. Вона вказує на всі доступні endpoints, методи запитів та параметри. Відкритий Swagger — це «сейф з грошима, ключ від якого лежить поруч». Якщо Swagger закритий, хакеру доведеться перебирати можливі endpoints вручну або через словники (наприклад, 10 млн рядків), що займає тижні. Відкритий Swagger дозволяє автоматизованій тулі просканувати всі роути за 10 хвилин, використовуючи всі можливі типи атак.

• Архітектура ідеального сканера: Запропонована спікером архітектура сучасного зовнішнього сканера включає три шари:

  1. Reconnaissance Layer: Автоматично збирає всі субдомени, IP, виявляє веб-застосунки, аналізує технологічний стек (PHP, Java, Redis, Laravel), GitHub, Cloud.
  2. Exposure Mapping: Створює карту відкритих портів та сервісів.
  3. Vulnerability Scanning: Сканує на наявність типових вразливостей (SQLi, XSS, SSRF, RCE), а також підтягує актуальні Proof-of-Concept (PoC) з GitHub для сканування на нові CVE.

• Проблема AI-інструментів та витоку даних: Спікер наводить реальний приклад вразливості в ChatGPT Plugins, яка дозволяє будь-якому користувачеві отримати файли будь-якого іншого користувача, який завантажив їх у плагін. Він особисто в такий спосіб отримав 100 документів з процесами ISO 27001 від співробітника великої компанії, який використовував GPT для пришвидшення роботи. Це показує, що дані, передані в LLM, не є приватними, навіть якщо здається інакше.

4. Практичні поради

1. Регулярно аудитуйте свою зовнішню інфраструктуру. Автоматизуйте пошук усіх субдоменів. Не покладайтеся лише на ручний список. Якщо у вашій компанії більше 10-50 субдоменів, моніторити їх вручну неможливо.

2. Закривайте dev/stage/QA сервери. Вони не повинні бути доступні з інтернету без VPN та авторизації. Якщо вони все ж публічні, на них має бути той самий рівень безпеки, що й на продакшні (WAF, моніторинг, сканування).

3. Не використовуйте однакові паролі (Password Reuse) між середовищами. Пароль адміністратора на dev-сервері не повинен збігатися з паролем на prod-сервері. Інакше компрометація dev-сервера веде до компрометації всього бізнесу.

4. Не хардкодьте паролі в коді. Навіть якщо ви виправили помилку і прибрали хардкоджений пароль, той факт, що хтось міг його побачити, означає, що пароль скомпрометований. Його потрібно змінювати на повністю новий, а не на варіацію старого (наприклад, MySecret2024 на MySecret2025).

5. Захищайте Swagger/Aдмін-панелі. Внутрішня документація (для адмін-панелі) повинна бути прихована за VPN, Basic Auth або IP-білими списками. Навіть публічна документація — це ризик, тому її також варто закрити.

6. Не передавайте чутливі дані (токени, конфігурації, медичні дані, комерційні таємниці) в AI-інструменти. Пам'ятайте, що, завантажуючи щось у сторонній сервіс (навіть платний), ви втрачаєте контроль над цією інформацією.

5. Дискусійні моменти

• Чи правда, що PHP/Laravel — найвразливіші? Спікер однозначно заперечує це. Він вважає, що проблема не в конкретній мові чи фреймворку, а в тому, як організований процес безпеки. Laravel та WordPress мають багато вразливостей, тому що вони популярні та мають відкритий код, що спрощує пошук дірок. Але якщо їх правильно налаштувати та постійно оновлювати, вони так само безпечні, як і будь-які інші технології. Головна помилка — людський фактор та занедбані субдомени, а не мова програмування.

• Чи актуальні SQL-ін'єкції в 2026 році? Так, вони все ще існують, хоча й не так масово. Спікер зазначає, що проблема з'являється там, де розробнику потрібно виконати складний SQL-запит (наприклад, для формування звітів), і він, щоб не писати складний ORM-код, вставляє прямий запит. Саме в таких «складних» місцях SQL-ін'єкції й живуть досі, що підтверджується його особистим досвідом у bug bounty.

• Чи можна замінити Swagger перебором роутів (Brute-force)? Технічно так, але це дуже ресурсоємно, повільно (займає дні) і не гарантує успіху, якщо endpoints названі не за стандартним словником. Відкритий же Swagger надає хакеру готову «дорожню карту» для миттєвої автоматизованої атаки. Тому ризик від закритого Swagger значно нижчий, хоча й не нульовий.