Дякуємо!
Ми зв'яжемося з вами найближчим часом
Практичний захист від SSRF: показуємо атаку та захист на прикладах.
Згідно з останнім звітом OWASP Web Application Top 10, SSRF є однією з найпоширеніших атак на веб-додатки. Розуміння того, як саме влаштована загроза, є ключем до ефективної протидії. В статті ми змоделюємо атаку SSRF і розглянемо техніку її пом’якшення за допомогою платформи F5 Distributed Cloud.
Про атаку SSRF
Атака підробки запитів на стороні сервера (SSRF) — це техніка, яка дозволяє зловмиснику маніпулювати вразливістю програми на стороні сервера та робити зловмисний запит до внутрішніх ресурсів. Мова йде про ті складники додатка, які відповідають за отримання правильних конфігурацій, метаданих інформації про підключення до баз даних тощо. В нормальному стані ці ресурси не взаємодіють із зовнішнім світом, розташовуючись «під капотом» додатку та забезпечуючи його функціонування. Суть SSRF полягає у створенні чи зміні URL-адрес, з якими взаємодіють внутрішні ресурси, у такий спосіб, щоб сервер отримував та розкривав конфіденційні дані з внутрішніх серверів.
Демонстрація
У ході демонстрації створимо SSRF-атаку та нейтралізуємо її за допомогою платформи F5 Distributed Cloud.
Ми використовуємо:
Коротко про сценарій атаки SSRF в AWS:
Інстанс AWS використовує внутрішню веб-службу для збору власних метаданих про самого себе, і отримати їх можна лише з інстансу. Коли примірнику EC2 потрібні будь-які метадані, він ініціює запит до цієї служби, і інформація надається відповідно до зробленого запиту. AWS використовує адресу 169.254.169.254 для отримання метаданих інстансу.
Як показано в наведеній вище архітектурі, вразливий додаток розгортається в екземплярі AWS. Зловмисники можуть отримати доступ до програми та спробувати використати цю вразливу програму. Це можна зробити, змінивши або надавши URL-адресу, яка буде ініціювати запит від примірника AWS до внутрішньої веб-служби та отримувати конфіденційні метадані.
Покроковий процес:
Зверніть увагу, що сторінка програми відображає конфіденційні метадані примірника EC2.
Отримані метадані відображаються у вразливому додатку:
Конфігурація HTTP Load Balancer для пом’якшення атаки
Крок 1: Створення вихідного пулу
● З потрібного простору імен переходимо до пункту Manage > Load Balancers > Origin pools ● Натискаємо "Add Origin Pool" і вводимо назву для вихідного пулу. ● Налаштовуємо деталі вихідного сервера з дійсними деталями порту.
Крок 2: Конфігурація балансувальника навантаження з увімкненим WAF
● Переходимо до пункту Manage -> Load Balancers -> HTTP Load Balancers ● Натискаємо "Add HTTP load balancer" і вводимо ім’я для балансувальника навантаження ● Вказуємо дійсне доменне ім’я та обираємо відповідний тип балансувальника навантаження в базовій конфігурації ● Зв’язуємо створений вище вихідний пул із балансувальником навантаження ● Включаємо "Web Application Firewall" і створюємо конфігурацію WAF з режимом блокування Натискаємо "Continue" та спостерігаємо, що використовується створена вище конфігурація WAF. ● Натискаємо "Save and Exit"
Крок 3. Отримуємо доступ до вразливої програми та повторюємо сценарій атаки.
● У браузері відкриваємо серверну програму за допомогою налаштованого домену балансувальника навантаження. ● Чекаємо, поки програма завантажиться, і входимо в неї ● Переходимо на сторінку "File Inclusion" у програмі.
● В URL-адресі змінюємо значення параметра запиту «page» на http://169.254.169.254/latest/meta-data/ ● Зверніть увагу, що сторінка не може прочитати метадані сервера, і запит блокується через політику WAF.
Крок 4. Перевіряємо журнали та деталі заблокованого запиту
● Переходимо до Virtual Hosts -> HTTP Load Balancers -> choose appropriate load balancer -> Security Monitoring -> Security events ● Зверніть увагу, що зловмисний запит блокується через застосовану політику WAF ● Розгортаємо запит і переглядаємо деталі про нього
Висновок
Як бачимо з наведеної вище демонстрації, атак SSRF можна уникнути, налаштувавши політику WAF у F5 Load Balancer, яка автоматично виявляє сигнатури атак і блокує їх.