Механизмы защиты, настроенные клиентами Cloudflare (например, брандмауэр, предотвращение DDoS-атак) для веб-сайтов, могут быть обойдены из-за пробелов в межсетевых контролях безопасности, что потенциально подвергает клиентов атакам, которые Cloudflare должен предотвратить. Злоумышленники могут использовать свои собственные аккаунты Cloudflare для злоупотребления доверительными отношениями между Cloudflare и веб-сайтами клиентов, делая механизм защиты неэффективным. Клиенты Cloudflare должны пересмотреть свою стратегию защиты исходного сервера, чтобы убедиться, что настроенные ими механизмы защиты надежно применяются.
Серьезное последствие использования общего «сертификата Cloudflare вместо специфического для арендатора собственного CA заключается в том, что разрешаются все подключения, исходящие от Cloudflare, независимо от того, какой арендатор Cloudflare инициирует подключение. Злоумышленник может настроить собственный домен с Cloudflare и указать DNS A запись на IP-адрес жертвы. Затем злоумышленник отключает все функции защиты для этого собственного домена в своем арендаторе и туннелирует свою (или свои) атаку (атаки) через инфраструктуру Cloudflare. Этот подход позволяет злоумышленникам обходить функции защиты, настроенные жертвой.
Это можно устранить только с помощью собственных сертификатов, что требует от клиента создания и поддержания своих собственных сертификатов для проверки подлинности исходного сервера.
Как и в случае с проверкой подлинности исходных запросов, серьезное последствие этого механизма заключается в том, что разрешаются все подключения, исходящие от Cloudflare, независимо от арендатора. Злоумышленник может создать собственный домен с Cloudflare, направить DNS A запись на IP-адрес жертвы. Затем он отключает все функции защиты для этого собственного домена и направляет свою (или свои) атаку (атаки) через инфраструктуру Cloudflare, фактически обходя функции защиты, настроенные жертвой.
В настоящее время эту проблему можно смягчить только с помощью Cloudflare Aegis , которая предлагает выделенные выходные IP-адреса вместо использования общего диапазона IP-адресов. Эта услуга может быть доступна не всем клиентам.
Мы рекомендуем 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. Этот подход позволяет злоумышленникам обходить функции защиты, настроенные жертвой.
Это можно устранить только с помощью собственных сертификатов, что требует от клиента создания и поддержания своих собственных сертификатов для проверки подлинности исходного сервера.
Белый список 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, используя "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 дней).
Больше подробностей
