Иронично: Cloudflare срещу Cloudflare

Иронично: Cloudflare срещу Cloudflare

Защитната стена на Cloudflare и предотвратяването на DDoS могат да бъдат заобиколени чрез специфичен процес на атака, който използва логически грешки в контрола на сигурността между наемателите.

Това заобикаляне може да постави клиентите на Cloudflare под голямо бреме, като направи системите за защита на интернет фирмата по-малко ефективни.

За да се влошат още повече нещата, единственото изискване за атаката е хакерите да създадат безплатен акаунт в Cloudflare, който се използва като част от атаката.

Трябва да се отбележи обаче, че за да злоупотребят с тези недостатъци, нападателите трябва да знаят IP адреса на набелязания уеб сървър.

Cloudflare срещу Cloudflare

Изследователят на Certitude Стефан Прокш откри, че източникът на проблема е стратегията на Cloudflare да използва споделена инфраструктура, която приема връзки от всички клиенти.

По-конкретно, анализаторът идентифицира две уязвимости в системата, засягащи „Authenticated Origin Pulls“ и „Allowlist Cloudflare IP Addresses“ на Cloudflare.

Authenticated Origin Pulls е функция за сигурност, предоставяна от Cloudflare, за да се гарантира, че HTTP(s) заявките, изпратени до сървър за произход, идват през Cloudflare, а не от нападател.

При конфигурирането на тази функция клиентите могат да качат своите сертификати чрез API или да генерират такива чрез Cloudflare, което е методът по подразбиране и най-лесен.

След като бъде конфигурирана, Cloudflare използва SSL/TLS сертификата за удостоверяване на всички HTTP(S) заявки между обратните проксита на услугата и сървъра на клиента за произход, като предотвратява достъпа на неоторизирани заявки до уебсайта.

Въпреки това, както обяснява Прокш, нападателите могат да заобиколят тази защита, тъй като Cloudflare използва споделен сертификат за всички клиенти, вместо специфичен за всеки поотделно, в резултат на което всички връзки, произхождащи от Cloudflare, са разрешени.

„Нападателят може да създаде потребителски домейн в Cloudflare и да насочи DNS A записа към IP адреса на жертвите“, обяснява Прокш.

„След това нападателят деактивира всички функции за защита за този потребителски домейн в своя клиент и тунелира атаката(ите) си през инфраструктурата на Cloudflare.“

„Този подход позволява на нападателите да заобиколят функциите за защита от страна на жертвата.“

Exploiting shared Cloudflare certificates

Проблемът, произтичащ от този логически пропуск, е, че нападателите с акаунт в Cloudflare могат да насочват злонамерен трафик към други клиенти на Cloudflare или да насочват атаките си през инфраструктурата на компанията.

Прокш казва, че единственият начин да се намали тази слабост е да се използват собствени сертификати, а не генерирани от Cloudflare.

Вторият проблем влияе върху списъка с IP адреси на Cloudflare – мярка за сигурност, която позволява на трафика, произхождащ само от обхвата на IP адресите на Cloudflare, да достига до сървърите на клиентите.

И в този случай нападателят може да се възползва от недостатък в логиката, като създаде домейн в Cloudflare и насочи DNS A записа на своя домейн към IP адреса на сървъра на целевата жертва.

След това те изключват всички функции за защита на персонализирания домейн и насочват злонамерения трафик през инфраструктурата на Cloudflare, която ще се разглежда като надеждна от гледна точка на жертвата и следователно ще бъде разрешена.

Exploiting Cloudflare shared IP address range

Прокш сподели и доказателство за концепция с подробности за конфигурацията, за да демонстрира колко лесно е да се заобиколят защитите на Cloudflare, като се използват недостатъците.

Certitude предлага следните мерки за защита срещу тези атаки:

  • Използвайте потребителски сертификат за конфигуриране на механизма „Authenticated Origin Pulls“ вместо споделения сертификат на Cloudflare.
  • Използвайте Cloudflare Aegis (ако е наличен), за да дефинирате по-специфичен диапазон от изходящи IP адреси, предназначени за всеки клиент.

Изследователите Флориан Швайцер и Щефан Прокш, които са открили логическите недостатъци, са докладвали за тях на Cloudflare чрез HackerOne на 16 март 2023 г., но проблемът е бил затворен като „информативен“.

Източник: e-security.bg

Сподели в:

Категории:

Следвай ни в: