Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Nieoczywista podatność w interface administracyjnym urządzeń Palo Alto. Możliwość ominięcia uwierzytelnienia. CVE-2025-0108
Dla lubiących korzystać tylko z materiałów źródłowych polecam to opracowanie oraz informacje o łatce producenta.
No dobra, o co tutaj chodzi?
Urządzenie ma skonfigurowany Nginx na froncie (w szczególności podejmuje on decyzję, które żądanie uwierzytelnić, a które nie), oraz serwer webowy Apache w backendzie (tutaj działa aplikacja).
Na starcie Nginx ustawia nagłówek X-pan-AuthCheck 'on’. Tj. wszystko musi być uwierzytelnione. So far, so good ;)
To lecimy do samego ataku. Dlaczego żądaniem poniżej można ominąć uwierzytelnienie ?
/unauth/%252e%252e/php/ztp_gate.php/PAN_help/x.css
Mamy tutaj tzw. podwójne kodowanie HTTP (%25 to znak %, %2e to kropka). Nginx po otrzymaniu takiego żądania dekoduje je (jednorazowo), mamy więc:
/unauth/%2e%2e/php/ztp_gate.php/PAN_help/x.css
Teraz działa reguła w Nginx:
if ($uri ~ ^\/unauth\/.+$) { set $panAuthCheck 'off’;}
Czyli dla tego żądania ustawiany jest nagłówek X-pan-AuthCheck 'off’
Zwróć uwagę na to, że ten warunek nie zadziałałby, gdyby w ataku było: /unauth/../ lub /unauth/%2e%2e/
W obu tych przypadkach Nginx wykonałby normalizację ścieżki URI – czyli mielibyśmy żądanie do /php/ztp_gate.php/PAN_help/x.css (które nie złapałoby się na if-a).
Następnie całość (oryginalny URI) jest wysyłana do serwera webowego Apache w backendzie, który wykonuje dla odmiany podwójne dekodowanie i mamy żądanie do:
/php/ztp_gate.php/PAN_help/x.css
TO traktowane jest jak żądanie do /php/ztp_gate.php z jakimiś tam dodatkowymi parametrami ;) Taki ciekawy lekko ukryty ficzer PHP / Apache.
Ważne, Nginx ustawił wcześniej nagłówek X-pan-AuthCheck 'off’ – więc serwer backendowy nie realizuje już uwierzytelnienia. Co było celem atakującego.
Jakby się ktoś zastanawiał gdzie tutaj tak naprawdę jest istota błędu – to wyjaśniam: w tym przypadku odpowiednio spreparowany URI inaczej jest traktowany przez Nginx (pojedyncze dekodowanie), a inaczej przez Apache (podwójne dekodowanie). Zainteresowanych tego typu klimatami – odsyłam też tutaj.
~Michał Sajdak
Też trzymam Nginxa na froncie, ale nie realizuje żadnej logiki poza nagłówkami http, terminacją szyfrowania i skierowaniem ruchu na inne hosty. Niektóre php-owe aplikacje dziwnie na to reagują, nawet wp-config wymaga dodatkowej linii kodu.
To nie jest łatwy problem. Czy zaufać aplikacji i skierować na nią podejrzany ruch, który będzie w stanie zaklasyfikować i odpowiednio zmienić swoje działanie – a więc programista jest świadomy zagrożenia i wbuduje w nią mechanizmy obronne – czy zatrzymać to wszystko na proxy i trochę sobie odpuścić uszczelnianie aplikacji. Zwykle skutkuje to tylko czasem błędami 500 aplikacji, która nie dostaje całej, spodziewanej odpowiedzi. Sztuczki z %252e nie znałem.