Cloudflare łata dotychczasowe luki bezpieczeństwa pozwalające atakującym ominąć firewall

Firma Cloudflare załatała krytyczną lukę typu zero-day w swojej zaporze sieciowej aplikacji internetowej (WAF), która umożliwiała atakującym ominięcie reguł bezpieczeństwa zdefiniowanych przez klientów i bezpośredni dostęp do chronionych serwerów źródłowych, budząc obawy dotyczące konsekwencji dla bezpieczeństwa automatycznych systemów zarządzania certyfikatami, powszechnie stosowanych w Internecie.

Luka, odkryta przez badaczy bezpieczeństwa z FearsOff, polegała na niezamierzonej interakcji między siecią brzegową Cloudflare a protokołem ACME (Automatic Certificate Management Environment), standardowym mechanizmem używanym przez urzędy certyfikacji (CA), takie jak Let’s Encrypt, do weryfikacji własności domen i wydawania certyfikatów SSL/TLS.

Według badaczy z FearsOff infrastruktura Cloudflare traktowała ruch kierowany tą ścieżką jako przypadek szczególny. Żądania kierowane do katalogu ACME challenge mogły dotrzeć do serwera źródłowego, nawet jeśli klienci wyraźnie skonfigurowali reguły WAF tak, aby blokowały cały ruch przychodzący z wyjątkiem ruchu pochodzącego z zaufanych źródeł.

„Takie zachowanie skutecznie stworzyło ukryty tunel przez warstwę zabezpieczeń Cloudflare” – stwierdzili badacze, zaznaczając, że wyjątek ten nie był widoczny dla klientów i nie można go było złagodzić poprzez konfigurację.

Aby ustalić, czy problem dotyczył wyłącznie określonych konfiguracji klientów, firma FearsOff utworzyła kilka środowisk testowych przy użyciu popularnych stosów internetowych, w tym PHP, Spring/Tomcat i Next.js. Hosty testowe zostały skonfigurowane zgodnie z rygorystycznymi zasadami WAF, mającymi na celu blokowanie wszelkiego niechcianego ruchu.

Podczas gdy standardowe żądania były prawidłowo przechwytywane i blokowane przez sieć brzegową Cloudflare, żądania wysyłane do ścieżki ACME całkowicie omijały kontrolę WAF. Zamiast otrzymywać strony blokujące Cloudflare, badacze zaobserwowali bezpośrednie odpowiedzi generowane przez aplikacje źródłowe, zazwyczaj strony błędów specyficzne dla danego frameworka, takie jak odpowiedzi HTTP 404.

Wyniki potwierdziły, że luka miała charakter systemowy, a nie wynikała z nieprawidłowej konfiguracji klienta.

Cloudflare potwierdziło później, że luka wynikała z logiki używanej do obsługi własnych usług certyfikatów zarządzanych. Aby zapobiec zakłóceniom w wydawaniu certyfikatów, Cloudflare tymczasowo wyłącza niektóre kontrole bezpieczeństwa podczas obsługi ważnych tokenów wyzwania ACME HTTP-01 dla domen klientów.

Jednak implementacja zawierała krytyczny błąd logiczny. Jeśli przychodzące żądanie było skierowane do ścieżki ACME challege, ale nie odpowiadało aktywnemu zamówieniu certyfikatu zarządzanego przez Cloudflare, żądanie pomijało całkowicie ocenę WAF i było przekazywane bezpośrednio do serwera źródłowego.

To, co miało być wąskim wyjątkiem dotyczącym walidacji certyfikatów, zostało skutecznie przekształcone w uniwersalne obejście zabezpieczeń WAF we wszystkich witrynach hostowanych przez Cloudflare.

Obwodnica otworzyła drzwi dla wielu wektorów ataków wysokiego ryzyka, szczególnie przeciwko aplikacjom, które wykorzystują WAF Cloudflare jako podstawową kontrolę bezpieczeństwa.

W aplikacjach opartych na Spring i Tomcat badacze zademonstrowali techniki przechodzenia ścieżki serwletów przy użyciu specjalnie spreparowanych adresów URL, takich jak ..;/, aby uzyskać dostęp do ograniczonych punktów końcowych aktuatorów. Punkty te ujawniały poufne dane operacyjne, w tym zmienne środowiskowe, poświadczenia baz danych, tokeny API i klucze dostępu dostawców usług w chmurze.

Aplikacje Next.js wykorzystujące renderowanie po stronie serwera również zostały dotknięte tym problemem. Ponieważ żądania docierały bezpośrednio do źródła, ujawniono wewnętrzne komunikaty o błędach i metadane operacyjne, które normalnie są chronione przed publicznym dostępem.

Aplikacje oparte na PHP również okazały się podatne na ataki. W przypadkach, gdy występowały luki związane z lokalnym włączaniem plików (LFI), osoby atakujące mogły wykorzystać obejście WAF do odczytania dowolnych plików z systemu plików serwera, co znacznie zwiększało ryzyko ujawnienia danych lub zdalnego wykonania kodu.

Problem ten podważał również zasady WAF na poziomie konta, które blokują żądania na podstawie nagłówków, geolokalizacji lub wymagań uwierzytelniających, ponieważ kontrole te były całkowicie ignorowane w przypadku ruchu ACME-path.

FearsOff zgłosił lukę w zabezpieczeniach do Cloudflare za pośrednictwem programu HackerOne bug bounty w dniu 9 października 2025 r. Cloudflare rozpoczęło wewnętrzną weryfikację cztery dni później, a HackerOne formalnie rozpatrzyło zgłoszenie 14 października.

Po potwierdzeniu problemu firma Cloudflare wdrożyła 27 października trwałe rozwiązanie, modyfikując swoją logikę brzegową, aby zapewnić, że WAF i kontrole bezpieczeństwa są wyłączane tylko wtedy, gdy żądanie dokładnie odpowiada prawidłowemu tokenowi wyzwania ACME HTTP-01 dla konkretnej nazwy hosta.

Testy przeprowadzone po usunięciu luki potwierdziły, że reguły WAF są teraz konsekwentnie egzekwowane we wszystkich ścieżkach URL, w tym w katalogu wyzwań ACME, który wcześniej był wyłączony z tego wymogu.

Cloudflare oświadczyło, że klienci nie muszą podejmować żadnych działań i że nie znaleziono żadnych dowodów wskazujących na to, że luka została wykorzystana w praktyce. Firma podkreśliła, że luka została całkowicie usunięta i że wprowadzono dodatkowe zabezpieczenia, aby zapobiec podobnym problemom w przyszłości.

Incydent ten podkreśla ryzyko związane ze złożoną logiką sieci brzegowej i zautomatyzowanymi mechanizmami zaufania. Chociaż automatyzacja certyfikatów oparta na ACME znacznie poprawiła stosowanie szyfrowania w Internecie, przypadek ten pokazuje, jak wąsko zakrojone wyjątki mogą nieumyślnie podważyć wielowarstwowe modele bezpieczeństwa, gdy są wdrażane na dużą skalę.

Wniosek jest taki, że wyjątki dotyczące bezpieczeństwa — nawet te wprowadzone w dobrej wierze — należy traktować jako ścieżki kodu wysokiego ryzyka. Na obrzeżach sieci pojedynczy błąd logiczny może mieć konsekwencje dla całego Internetu.

Zainteresowanych większą ilością szczegółów zapraszamy tutaj: How we mitigated a vulnerability in Cloudflare’s ACME validation logic