Механізми захисту, налаштовані клієнтами Cloudflare (наприклад, брандмауер, запобігання DDoS-атакам) для веб-сайтів, можуть бути обійдені через прогалини в міжмережевих контролю безпеки, що потенційно піддає клієнтів атакам, які Cloudflare має запобігти. Зловмисники можуть використовувати свої власні облікові записи Cloudflare для зловживання довірчими відносинами між Cloudflare та веб-сайтами клієнтів, роблячи механізм захисту неефективним. Клієнти Cloudflare мають переглянути свою стратегію захисту вихідного сервера, щоб переконатися, що налаштовані ними механізми захисту надійно застосовуються.
Огляд уразливості
Cloudflare описує різні механізми для «запобігання атакам., спрямованих на виявлення та перевантаження вашого вихідного сервера запитами» у своїй офіційній документації за різними рівнями моделі OSI (рівень додатків, рівень транспорту та рівень мережі). Механізми анотуються з різним ступенем рівнів безпеки, або «помірковано безпечними», або «дуже безпечними», а також пов'язаними з ними технічними складнощами. У ході нашого аналізу ми виявили, що два запропоновані механізми засновані на припущенні, що весь трафік до вихідного сервера, вихідний від Cloudflare, має бути довіреним, у той час як трафік від інших сторін має бути відхилений. Ми показуємо, що зловмисники можуть зловживати цією довірою до Cloudflare, відправляючи свій зловмисний код через платформу Cloudflare, обминаючи різні механізми захисту (наприклад, брандмауер веб-додатків), які клієнт міг налаштувати для свого середовища. Ефективна дія цього обходу залежить від конфігурації вихідного сервера клієнта.
Автентифіковане джерело залучення
При використанні механізму Authenticated Origin Pulls на рівні транспорту, який у документації Cloudflare описаний як «дуже безпечний», зворотні проксі-сервери Cloudflare аутентифікуються на вихідному сервері за допомогою SSL-сертифіката клієнта. Документація з налаштування зони представляє два варіанти аутентифікації підключень від клієнтів, які маршрутизуються через зворотний проксі-сервер Cloudflare, до вихідного сервера. Клієнти можуть вибрати або "сертифікат Cloudflare", або власний сертифікат. Проте документація не обговорює наслідки безпеки, пов'язані з цими варіантами. Також слід зазначити, що власний сертифікат можна налаштувати лише за допомогою API. Без додаткової інформації розумно припустити, що клієнти оберуть зручніший варіант використання сертифіката Cloudflare.
Серйозний наслідок використання загального сертифікату Cloudflare замість специфічного для орендаря власного CA полягає в тому., що дозволяються всі підключення, вихідні від Cloudflare, незалежно від того, який орендар Cloudflare ініціює підключення. Зловмисник може налаштувати власний домен з Cloudflare та вказати DNS A запис на IP-адресу жертви. Потім зловмисник відключає всі функції захисту для цього власного домену у своєму орендарі та тунелює свою (або свої) атаку (атаки) через інфраструктуру Cloudflare. Цей підхід дозволяє зловмисникам оминати функції захисту., налаштовані жертвою.
Це можна усунути лише за допомогою власних сертифікатів, що вимагає від клієнта створення та підтримки своїх власних сертифікатів для перевірки автентичності вихідного сервера.
Білий список IP-адрес Cloudflare
При використанні механізму "Дозволити IP-адреси Cloudflare" на мережному рівні, який у документації Cloudflare описаний як «помірно безпечний», вихідний сервер відхиляє будь-яке підключення, не виходить із діапазонів IP-адрес Cloudflare. Документація з налаштування описує, як налаштувати ці діапазони за допомогою .htaccess або iptables..
Як і у випадку з автентичністю вихідних запитів, серйозний наслідок цього механізму полягає в тому, що дозволяються всі підключення, вихідні від Cloudflare, незалежно від орендаря. Зловмисник може створити власний домен із Cloudflare, направити DNS A запис на IP-адресу жертви. Потім він відключає всі функції захисту для цього власного домену і направляє свою (або свої) атаку (атаки) через інфраструктуру Cloudflare, фактично обминаючи функції захисту, налаштовані жертвою.
В даний час цю проблему можна пом'якшити лише за допомогоюCloudflare Aegis , яка пропонує виділені вихідні IP-адреси замість використання загального діапазону IP-адрес. Ця послуга може бути доступна не всім клієнтам.
Доказ концепції
Нижче наведено налаштування успішного обходу захищеного WAF-домену victim.test, який намагається захистити вихідний сервер 203.0.113.42, використовуючи “Автентифіковане залучення джерела” із сертифікатом Cloudflare Origin, а також “Білий список IP-адрес Cloudflare”, як зазначено в офіційній документації. Атакуючий просто налаштовує домен attacker.test без будь-якого захисту WAF і встановлює ту саму IP-адресу джерела, що і victim.test. Це дозволяє атакуючому успішно надсилати запити на 203.0.113.42 через attacker.test, які були б заблоковані при спробі зробити це через victim.test
Конфігурація облікового запису жертви в Cloudflare
Домен: жертва.тест
A-запис DNS вказує на: 203.0.113.42
Установки Cloudflare:
- Режим шифрування SSL/TLS: «Повний (суворий)».
- Включено запити до автентифікованого джерела
- Сертифікат походження Cloudflare створено.
- Керований набір правил WAF Cloudflare включений
- Базовий набір правил WAF Cloudflare OWASP включений
- Рівень безпеки: "Я під атакою" - завжди використовувати HTTPS включено.
Конфігурація вихідного сервера жертви
- Встановлено сертифікат Cloudflare Origin (SSL/TLS увімкнено)
- Встановлено Authenticated Origin Pulls CA (SSLVerifyClient увімкнено)
- iptables дозволяє лише вхідний трафік від IP-адрес Cloudflare на порту 443
Конфігурація облікового запису зловмисників у Cloudflare
Домен: attacker.test DNS A запис вказує на: 203.0.113.42 Установки Cloudflare:
- Режим шифрування SSL/TLS: «Повний».
- Включено запити до автентифікованого джерела
- Керований набір правил WAF Cloudflare вимкнено.
- Основний набір правил WAF Cloudflare OWASP вимкнено.
- Рівень безпеки: «Практично вимкнено»
Обхід захисту
Cloudflare WAF захищає сервер жертви від потенційно шкідливого введення.
> ОТРИМАТИ https://жертва.тест/?test=cat /etc/passwd HTTP/2
< HTTP/2 403 Заборонено
Cloudflare перенаправляє потенційно шкідливе введення на сервер джерела жертви, обходячи конфігурацію WAF жертви.
> ОТРИМАТИ https://attacker.test/?test=cat /etc/passwd HTTP/2
< HTTP/2 200 в порядку
Рекомендації для клієнтів Cloudflare
“Механізм ‘Allowlist Cloudflare IP addresses’ слід розглядати як міру глибокої оборони і не використовувати як єдиний механізм захисту вихідних серверів. Механізм 'Authenticated Origin Pulls’ має бути налаштований з використанням власних сертифікатів, а не сертифіката Cloudflare. При захисті вихідних серверів слід також розглянути інші механізми автентифікації орендаря Cloudflare (а не самої Cloudflare), описані у документації, а також їх різні компроміси (наприклад, запуск стороннього коду на чутливих веб-серверах).
Ми рекомендуємо Cloudflare впровадити механізми захисту від таких атак та попередити клієнтів з ненадійними конфігураціями.”
Хронологія розкриття інформації:
- 2023-03-16: Повідомлення про проблему надіслано Cloudflare через HackerOne (звіт 1909867).
- 2023-03-16: Cloudflare визнав наявність проблеми та закрив її (баг інформативний).
- 2023-09-28: Публічне розкриття (>180 днів).