phpSysInfo 3.4.5: obejście listy dozwolonych adresów IP prowadzi do ujawnienia informacji systemowych

Wprowadzenie do problemu / definicja

W phpSysInfo 3.4.5 ujawniono podatność pozwalającą na obejście mechanizmu kontroli dostępu opartego na liście dozwolonych adresów IP. Problem wynika z błędnego ustalania adresu klienta przez aplikację, która akceptowała również nagłówki HTTP możliwe do sfałszowania przez użytkownika. W efekcie atakujący mógł uzyskać dostęp do chronionego endpointu i odczytać informacje systemowe bez posiadania faktycznie autoryzowanego adresu IP.

W skrócie

Podatność dotyczy phpSysInfo w wersjach do 3.4.5.
Mechanizm PSI_ALLOWED mógł zostać ominięty przez spreparowane nagłówki X-Forwarded-For lub Client-IP.
Nieuprawniony użytkownik mógł uzyskać dostęp do danych udostępnianych przez xml.php.
Problem powiązano z identyfikatorem CVE-2026-55584.
Poprawkę wskazano w wersji 3.4.6.

Kontekst / historia

phpSysInfo to webowe narzędzie służące do prezentacji informacji diagnostycznych i telemetrycznych o systemie hosta. Rozwiązanie bywa wykorzystywane w środowiskach administracyjnych, serwerowych i monitoringowych, gdzie operatorzy potrzebują szybkiego wglądu w stan systemu, zasoby sprzętowe oraz parametry pracy.

Z uwagi na charakter prezentowanych danych, dostęp do takiego interfejsu jest często ograniczany do wybranych adresów IP. Sama idea allowlisty pozostaje poprawna, jednak jej skuteczność zależy od prawidłowej implementacji. W tym przypadku nie zawiódł model ochrony jako taki, lecz sposób, w jaki aplikacja identyfikowała źródło żądania.

To klasyczny przykład błędnego zaufania do danych przesyłanych w warstwie HTTP. W środowiskach korzystających z reverse proxy nagłówki przekazujące adres klienta mogą mieć uzasadnienie operacyjne, ale powinny być honorowane wyłącznie wtedy, gdy pochodzą od jawnie zdefiniowanych i zaufanych pośredników.

Analiza techniczna

Istota podatności sprowadzała się do niewłaściwej kolejności przetwarzania danych wejściowych. Aplikacja najpierw analizowała nagłówek X-Forwarded-For, następnie Client-IP, a dopiero na końcu wykorzystywała REMOTE_ADDR, czyli parametr zwykle odzwierciedlający rzeczywisty adres źródłowy połączenia widziany przez serwer WWW.

Taki schemat był niebezpieczny, ponieważ dwa pierwsze nagłówki mogą zostać ustawione bezpośrednio przez atakującego. Jeżeli infrastruktura nie posiada zaufanego proxy, które nadpisuje i waliduje te wartości, aplikacja porównuje allowlistę nie z prawdziwym adresem klienta, lecz z wartością całkowicie kontrolowaną przez napastnika.

W praktyce atak był stosunkowo prosty. Standardowe żądanie do endpointu xml.php mogło zostać odrzucone, jednak powtórzenie go z nagłówkiem X-Forwarded-For lub Client-IP ustawionym na adres znajdujący się na liście dozwolonej pozwalało obejść zabezpieczenie.

Z technicznego punktu widzenia jest to przykład błędnego modelu zaufania na styku warstwy sieciowej i aplikacyjnej. Bezpieczne użycie nagłówków przekazujących adres klienta wymaga kilku warunków:

jawnie określonej listy zaufanych proxy,
walidacji łańcucha pośredników,
bezpiecznego fallbacku do REMOTE_ADDR,
spójnej polityki obsługi nagłówków wielowartościowych.

Z opisu poprawki wynika, że bezpieczniejsze zachowanie wprowadzono w wersji 3.4.6. Domyślnie wykorzystywany ma być REMOTE_ADDR, a nagłówki X-Forwarded-For oraz Client-IP powinny być honorowane wyłącznie wtedy, gdy żądanie pochodzi od skonfigurowanego zaufanego proxy.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem podatności jest nieautoryzowany dostęp do danych diagnostycznych i systemowych publikowanych przez xml.php. Zakres ujawnianych informacji zależy od konfiguracji wdrożenia, ale może obejmować szczegóły dotyczące systemu operacyjnego, zasobów sprzętowych, pamięci, procesora, interfejsów sieciowych, obciążenia oraz innych elementów środowiska.

Tego typu wyciek bywa niedoszacowany, ponieważ nie daje od razu pełnego przejęcia systemu. W rzeczywistości dane rozpoznawcze mają dużą wartość na etapie rekonesansu i mogą znacząco zwiększyć skuteczność kolejnych działań ofensywnych.

Ułatwiają profilowanie celu przed dalszym atakiem.
Pozwalają identyfikować używane technologie i rolę hosta.
Pomagają ocenić zasoby oraz topologię środowiska.
Umożliwiają lepsze dopasowanie technik eksploatacyjnych.
Wspierają wykrywanie potencjalnych słabości konfiguracyjnych i operacyjnych.

Ryzyko rośnie szczególnie wtedy, gdy administratorzy zakładają, że sama lista dozwolonych adresów IP w aplikacji stanowi wystarczającą ochronę. Jeśli interfejs monitorujący jest publicznie osiągalny lub częściowo wystawiony poza strefę zaufaną, obejście takiej kontroli istotnie obniża poziom bezpieczeństwa całego środowiska.

Rekomendacje

Najważniejszym krokiem jest aktualizacja phpSysInfo do wersji zawierającej poprawkę, czyli co najmniej 3.4.6. Organizacje korzystające z wersji 3.4.5 lub starszych powinny potraktować problem jako podatność umożliwiającą obejście kontroli dostępu i przeprowadzić pilny przegląd ekspozycji usługi.

Warto również wdrożyć dodatkowe środki ograniczające ryzyko:

ograniczyć dostęp do phpSysInfo na poziomie serwera WWW, zapory sieciowej lub reverse proxy,
jawnie i minimalistycznie skonfigurować zaufane proxy,
odrzucać albo nadpisywać nagłówki X-Forwarded-For i Client-IP na brzegu infrastruktury, jeśli nie są niezbędne,
monitorować logi pod kątem prób dostępu z nietypowymi nagłówkami adresowymi,
sprawdzić, czy endpoint xml.php rzeczywiście musi być publicznie dostępny,
przeanalizować inne aplikacje wewnętrzne pod kątem analogicznych błędów zaufania do nagłówków klienta.

Z perspektywy zespołów bezpieczeństwa zasadne jest także przeprowadzenie retrospektywnej analizy logów HTTP. Występowanie żądań zawierających niestandardowe wartości X-Forwarded-For lub Client-IP może wskazywać na próby obejścia ochrony i potencjalne nieautoryzowane pobranie danych systemowych.

Podsumowanie

Podatność w phpSysInfo 3.4.5 pokazuje, że nawet proste mechanizmy ograniczania dostępu mogą zostać podważone przez błędne założenia dotyczące zaufania do danych wejściowych. Problem nie wynikał z samej koncepcji allowlisty, lecz z niewłaściwego priorytetu nadanego nagłówkom HTTP, które użytkownik końcowy może sfałszować.

Dla administratorów to ważne przypomnienie, że identyfikacja źródłowego adresu IP musi uwzględniać architekturę proxy, walidację pośredników i zasadę ograniczonego zaufania. Aktualizacja do poprawionej wersji oraz dodatkowe zabezpieczenia warstwy sieciowej powinny być traktowane jako działania priorytetowe.