Защиту Cloudflare от DDoS удалось обойти через Cloudflare

Механизмы защиты, настроенные клиентами Cloudflare (например, брандмауэр, предотвращение DDoS-атак) для веб-сайтов, могут быть обойдены из-за пробелов в межсетевых контролях безопасности, что потенциально подвергает клиентов атакам, которые Cloudflare должен предотвратить. Злоумышленники могут использовать свои собственные аккаунты Cloudflare для злоупотребления доверительными отношениями между Cloudflare и веб-сайтами клиентов, делая механизм защиты неэффективным. Клиенты Cloudflare должны пересмотреть свою стратегию защиты исходного сервера, чтобы убедиться, что настроенные ими механизмы защиты надежно применяются.

Обзор уязвимости​

Cloudflare описывает различные механизмы для «предотвращения атак, направленных на обнаружение и перегрузку вашего исходного сервера запросами» в своей официальной документации по различным уровням модели OSI (уровень приложений, уровень транспорта и уровень сети). Механизмы аннотируются с разной степенью уровней безопасности, либо «умеренно безопасными», либо «очень безопасными», а также связанными с ними техническими сложностями. В ходе нашего анализа мы обнаружили, что два предложенных механизма основаны на предположении, что весь трафик к исходному серверу, исходящий от Cloudflare, должен быть доверенным, в то время как трафик от других сторон должен быть отклонен. Мы показываем, что злоумышленники могут злоупотреблять этим доверием к Cloudflare, отправляя свой злонамеренный код через платформу Cloudflare, обходя различные механизмы защиты (например, брандмауэр веб-приложений), которые клиент мог настроить для своей среды. Эффективное воздействие этого обхода зависит от конфигурации исходного сервера клиента.

Authenticated Origin Pulls​

При использовании механизма «Authenticated Origin Pulls» на уровне транспорта, который в документации Cloudflare описан как «очень безопасный», обратные прокси-серверы Cloudflare аутентифицируются на исходном сервере с помощью клиентского SSL-сертификата. Документация по настройке зоны представляет два варианта аутентификации подключений от клиентов, которые маршрутизируются через обратный прокси-сервер Cloudflare, к исходному серверу. Клиенты могут выбрать либо «сертификат Cloudflare», либо собственный сертификат. Однако документация не обсуждает последствия для безопасности, связанные с этими вариантами. Также следует отметить, что собственный сертификат можно настроить только с помощью API. Без дополнительной информации разумно предположить, что клиенты выберут более удобный вариант использования сертификата Cloudflare.

Серьезное последствие использования общего «сертификата Cloudflare вместо специфического для арендатора собственного CA заключается в том, что разрешаются все подключения, исходящие от Cloudflare, независимо от того, какой арендатор Cloudflare инициирует подключение. Злоумышленник может настроить собственный домен с Cloudflare и указать DNS A запись на IP-адрес жертвы. Затем злоумышленник отключает все функции защиты для этого собственного домена в своем арендаторе и туннелирует свою (или свои) атаку (атаки) через инфраструктуру Cloudflare. Этот подход позволяет злоумышленникам обходить функции защиты, настроенные жертвой.
1696263974867.webp

Это можно устранить только с помощью собственных сертификатов, что требует от клиента создания и поддержания своих собственных сертификатов для проверки подлинности исходного сервера.

Белый список IP-адресов Cloudflare​

При использовании механизма «Разрешить IP-адреса Cloudflare» на сетевом уровне, который в документации Cloudflare описан как «умеренно безопасный», исходный сервер отклоняет любое подключение, не исходящее из диапазонов IP-адресов Cloudflare. Документация по настройке описывает, как настроить эти диапазоны с помощью файла .htaccess или iptables.

Как и в случае с проверкой подлинности исходных запросов, серьезное последствие этого механизма заключается в том, что разрешаются все подключения, исходящие от Cloudflare, независимо от арендатора. Злоумышленник может создать собственный домен с Cloudflare, направить DNS A запись на IP-адрес жертвы. Затем он отключает все функции защиты для этого собственного домена и направляет свою (или свои) атаку (атаки) через инфраструктуру Cloudflare, фактически обходя функции защиты, настроенные жертвой.

1696264162862.webp

В настоящее время эту проблему можно смягчить только с помощью Cloudflare Aegis , которая предлагает выделенные выходные IP-адреса вместо использования общего диапазона IP-адресов. Эта услуга может быть доступна не всем клиентам.

Доказательство концепции​

Ниже приведена настройка успешного обхода защищенного WAF-домена victim.test, который пытается защитить исходный сервер 203.0.113.42, используя "Authenticated Origin Pulls" с сертификатом Cloudflare Origin, а также "Allowlist Cloudflare IP addresses", как указано в официальной документации. Атакующий просто настраивает домен attacker.test без какой-либо защиты WAF и устанавливает тот же IP-адрес источника, что и victim.test. Это позволяет атакующему успешно отправлять запросы на 203.0.113.42 через attacker.test, которые были бы заблокированы при попытке сделать это через victim.test

Рекомендации для клиентов 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 дней).

Больше подробностей
 
Назад
Сверху Снизу