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

17 lutego 2025, 16:34 | W biegu | 1 komentarz

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

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. SeeM

    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.

    Odpowiedz

Odpowiedz