Вступ

Вразливість Server-Side Request Forgery (SSRF) є критичною для безпеки веб-застосунків і дозволяє зловмисникам маніпулювати сервером для здійснення несанкціонованих запитів. Ці запити можуть націлюватися на внутрішні ресурси, які зазвичай недоступні з публічного Інтернету, обхід заходів безпеки і потенційно розкривати чутливу інформацію. У цій статті розглядаються механізми вразливостей SSRF, демонструється, як їх можна експлуатувати для компрометації внутрішніх мереж, і надаються комплексні стратегії з їх усунення.

Розуміння SSRF

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

Наслідки успішних атак SSRF можуть включати:

Несанкціонований доступ до внутрішніх сервісів і додатків
Розкриття чутливих API для метаданих хмарних сервісів
Витік даних з внутрішніх баз даних
Виконання віддаленого коду в певних випадках
Ескалація привілеїв через внутрішні системи авторизації

Типові сценарії атак SSRF

Розвідка внутрішньої мережі

Зловмисники можуть використовувати SSRF для дослідження та картографування внутрішніх мереж, які інакше були б недоступні з Інтернету. Аналізуючи часи відгуку, статус-коди та повідомлення про помилки, вони можуть перерахувати активні хости та сервіси в приватних мережевих сегментах організації.

Експлуатація хмарних метаданих

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

Класичним прикладом є доступ до сервісу метаданих інстанса AWS:

Обхід брандмауерів і контролю доступу

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

Техніки витоку даних

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

Етап 2: Витік даних

Відомі реальні експлойти SSRF

Вразливість Capital One (2019)

Одна з найбільш значущих атак SSRF в останні роки сталася під час витоку даних Capital One. Зловмисник використав вразливість SSRF у неправильно налаштованому веб-додатку брандмауера для доступу до сервісу метаданих EC2. Це надало тимчасові облікові дані AWS, що дозволили зловмиснику отримати доступ і витягнути чутливу інформацію про клієнтів, що вплинуло на понад 100 мільйонів осіб. Цей витік призвів до штрафів на суму 80 мільйонів доларів і орієнтовних витрат на відновлення в 150 мільйонів доларів.

Вразливість GitHub Actions SSRF (2022)

Дослідник безпеки Вільям Боулінг виявив вразливість SSRF у GitHub Actions, яка могла дозволити зловмисникам робити несанкціоновані запити до внутрішніх сервісів GitHub і AWS-метаданих. Вразливість виникла через недостатню перевірку наданих користувачем URL-адрес в сервісі GitHub runner.
GitHub швидко виправив проблему і виплатив $25,000 через свою програму Bug Bounty.

Інцидент з SSRF у Alibaba Cloud (2021)

Дослідники виявили вразливість SSRF в сервісах Alibaba Cloud, яка дозволяла зловмисникам отримати метадані з внутрішніх інстансів. Вразливість існувала в компоненті веб-інтерфейсу, який обробляв URL-адреси, надані користувачем, без належної перевірки, що могло призвести до розкриття облікових даних і подальшого переміщення в межах хмарного середовища.

Комплексні стратегії запобігання SSRF

1. Сувора перевірка вводу і дозволи URL

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

2. Мережевий рівень захисту

Налаштуйте брандмауери для запобігання вихідним з’єднанням до внутрішніх діапазонів IP з публічних серверів
Заблокуйте доступ до поширених адрес сервісів метаданих (169.254.169.254, 169.254.170.2 тощо)
Впровадьте фільтрацію вихідного трафіку для контролю, до яких адрес сервери можуть підключатися
Розмістіть вразливі додатки в ізольованих сегментах мережі з чіткими контролями доступу

3. Безпечні шаблони проектування

Використовуйте спеціалізовані проксі або API шлюзи для отримання зовнішніх ресурсів з суворими контрольними заходами безпеки
Впровадьте підписування запитів або попередньо підписані URL для авторизованого доступу до зовнішніх ресурсів
Повертайте тільки необхідну інформацію з HTTP-відповідей, щоб уникнути витоку даних

4. Заходи захисту у глибину

Розгорніть веб-брандмауери (WAF) з правилами для виявлення специфічних для SSRF атак
Використовуйте мінімальні привілеї для облікових записів сервісів, що використовуються веб-додатками
Налаштуйте сервіси метаданих, щоб вимагати додаткову аутентифікацію (IMDSv2 для AWS)
Моніторте вихідні мережеві з’єднання на наявність незвичних патернів або напрямків

5. Сучасні хмарні засоби безпеки

В AWS впровадьте IMDSv2, який вимагає запитів, що базуються на токенах сесії, до сервісів метаданих
Впровадьте відповідні ролі IAM і політики, що обмежують дозволи для компрометованих облікових даних
Налаштуйте кінцеві точки VPC з обмеженими групами безпеки для обмеження доступу до хмарних API

Висновок

Server-Side Request Forgery представляє собою складний вектор атак, який може надати зловмисникам безпрецедентний доступ до внутрішніх систем і чутливих даних. Організації повинні впроваджувати комплексні стратегії захисту, що охоплюють SSRF на кількох рівнях — від перевірки вводу до архітектури мережі та конфігурації хмарних сервісів.

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

Посилання

OWASP SSRF Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/ServerSideRequestForgeryPreventionCheatSheet.html
Cloud Security Alliance: “Top Threats to Cloud Computing”
NIST Special Publication 800–95: “Guide to Secure Web Services”
PortSwigger Web Security Academy: Дослідження вразливостей SSRF

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

Перекладено з: Server-Side Request Forgery (SSRF): Attacking Internal Networks via External Requests