Przejdź do treści

Szukaj w Security Magazine

Szukaj w Security Magazine

NewsletterNewsletter
Menu

PHP2Shell w PAN-OS: atak na panel zarządzania Palo Alto

Podatności PHP2Shell w PAN-OS są aktywnie wykorzystywane przeciw interfejsom zarządzania zapór Palo Alto Networks dostępnym z internetu. Według firmy badawczej Dream atakujący, łącząc je z drugą luką, w jądrze systemu, uzyskali uprawnienia root na 25 serwerach, a zespół badawczy producenta potwierdził te wyniki. Najpilniej muszą działać firmy, których panel zarządzania zaporą jest osiągalny z sieci publicznej: tam samo załatanie nie wystarczy, trzeba też sprawdzić, czy urządzenie nie zostało już przejęte.

Front urządzenia sieciowego w szafie rack z jednym kablem w porcie zarządzania, wyprowadzonym poza kadr w jasną przestrzeń.
W tym tekście (7)

Analiza zagrożenia: PHP2Shell w PAN-OS i Panoramie

PHP2Shell to dwie krytyczne luki w silniku PHP, CVE-2026-109618 i CVE-2026-109619, załatane przez projekt PHP 21 października. Obie pozwalają zdalnie wykonać kod bez logowania; Unit 42, zespół badawczy Palo Alto Networks, podaje dla obu ocenę 9.2 w skali CVSS 4.0. Pierwsza wynika z wadliwej obsługi braku pamięci, druga ze stanu wewnętrznego, który przetrwał zwolnienie pamięci poprzedniego żądania. Samym lukom w PHP i ich znaczeniu dla serwerów WWW Security Magazine poświęcił tekst z 22 października.

Palo Alto Networks potwierdziło, że luki dotyczą systemu PAN-OS na zaporach PA-Series i VM-Series oraz Panoramy (wersji wirtualnej i M-Series), w gałęziach 10.2, 11.1, 11.2, 12.1 i 12.2. Według producenta podatny jest wyłącznie interfejs zarządzania przez WWW, czyli panel HTTPS i usługa XML API. Interfejs przesyłu danych (dataplane) jest narażony tylko wtedy, gdy ma przypisany profil zarządzania. Do podatności nie jest potrzebna żadna szczególna konfiguracja. Producent podaje, że portal i brama GlobalProtect, Clientless VPN i Captive Portal nie są podatne, podobnie jak m.in. Cloud NGFW i Prisma Access.

Producent ocenia problem jako krytyczny (CVSS 9.2) i nadaje mu najwyższą pilność. Ryzyko jest według niego najwyższe, gdy do interfejsu zarządzania można się dostać z adresów w internecie. Jeśli jedynym systemem z dostępem do panelu jest jump box, producent podaje dla tego scenariusza ocenę bazową CVSS-B 7.7 i ocenę CVSS-BT 5.2 oraz poziom średni (Medium). W advisory (stan na 29 października) Palo Alto Networks podaje: „Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet".

Poprawki mają postać wersji hotfix PAN-OS. Według advisory (aktualizacja z 30 października) wydane są już wszystkie wersje minimalne z tabeli advisory, w tym 11.1.7-h12, a wydane hotfixy usuwają obie luki. Wersje minimalne według gałęzi:

  • PAN-OS 12.2: 12.2.4-h1.
  • PAN-OS 12.1: 12.1.4-h13, 12.1.7-h11 lub 12.1.10-h3, zależnie od wersji podrzędnej.
  • PAN-OS 11.2: 11.2.4-h23, 11.2.7-h23, 11.2.10-h16, 11.2.13-h4 lub 11.2.16-h1. Producent zaznacza, że 11.2.10-h16 łata tylko PHP, a poprawkę także dla luki w bibliotece Brotli zawiera dopiero 11.2.10-h17.
  • PAN-OS 11.1: 11.1.4-h38, 11.1.6-h40, 11.1.7-h12, 11.1.10-h36, 11.1.13-h16 lub 11.1.16-h4. Dla 11.1.7 advisory dopuszcza też przejście na 11.1.16-h4.
  • PAN-OS 10.2: 10.2.7-h39, 10.2.10-h42, 10.2.13-h27, 10.2.16-h12 lub 10.2.18-h13.
  • Starsze, niewspierane wersje PAN-OS: producent zaleca przejście na wspieraną wersję z poprawką.

Według Dream PAN-OS w gałęziach 12.1 i 12.2 korzysta z PHP 8.0.30, a w 11.1 z PHP 7.4.33. Projekt PHP wydał poprawione wersje 8.2.35, 8.3.36, 8.4.27 i 8.5.12, a linii 7.4 i 8.0 nie ma na jego liście wspieranych wersji; dla nich, jak Security Magazine pisał 22 października, zespół PHP opublikował jedynie minimalne poprawki źródłowe. Poprawkę dla zapór i Panoramy producent dostarcza w hotfixach PAN-OS.

Amerykańska agencja CISA wpisała obie luki PHP2Shell do katalogu podatności wykorzystywanych w atakach (KEV) 26 października. 28 października dodała do niego lukę w jądrze Linuksa CVE-2026-46300 (Fragnesia) z adnotacją, że można ją połączyć z PHP2Shell, by umieścić na serwerze web shell i wykonywać polecenia jako root. Przy wszystkich trzech wpisach CISA oznaczyła, że oprócz poprawki wymagana jest analiza, czy system nie został przejęty wcześniej. Wymóg wynika z dyrektywy BOD 26-04, która obowiązuje tylko cywilne agencje federalne USA; CISA zachęca jednak wszystkie organizacje do priorytetowego usuwania podatności z katalogu KEV. Termin dla agencji minął dla PHP2Shell 29 października, a dla Fragnesii mija 31 października.

Co pokazała kampania opisana przez Dream

Izraelska firma Dream opublikowała raport 26 października i zaktualizowała go 29 października. Unit 42, zespół badawczy Palo Alto Networks, podał, że niezależnie zweryfikował narzędzia atakującego i potwierdził opisane wyniki. Atakujący połączył PHP2Shell z luką Fragnesia: pierwsza dawała wykonanie kodu na zaporze z ograniczonymi uprawnieniami, druga podnosiła je do poziomu root. Według Dream exploit był własną, niepubliczną implementacją przygotowaną pod PAN-OS, a cały łańcuch od pierwszego żądania do trwałego dostępu trwał poniżej 15 minut. W odzyskanych artefaktach były profile exploitu dla gałęzi 12.1 i 12.2 oraz niepełne dla 11.1. Dream ostrzega, że atakujący może wrócić do zidentyfikowanych zapór, gdy przygotuje profile dla kolejnych wersji PAN-OS.

Przebieg kampanii Dream odtworzył z danych zostawionych przez atakującego. Ten zidentyfikował około 19 tys. zapór PAN-OS z panelem zarządzania wystawionym do internetu, z czego około 5 tys. podało wersję oprogramowania. Po zawężeniu do USA, Japonii, Tajwanu i Korei Południowej oraz do gałęzi 12.1 i 12.2 zostało 240 celów. Na 24 zaporach atakujący uzyskał uprawnienia root i zostawił web shell; 22 z nich według Dream pozostawił bez dalszych działań, z możliwością powrotu w dowolnej chwili.

Dwie przejęte zapory należały do organizacji powiązanej z rządem USA. Jedna przestała działać krótko po przejęciu. Przez drugą atakujący zbudował tunel SSH do sieci wewnętrznej, odporny na restart urządzenia, i tą samą metodą przejął wewnętrzny serwer zarządzający zaporami organizacji, osiągalny tylko przez tunel. Był to 25. przejęty serwer. Z niego atakujący odszyfrował hasło konta serwisowego LDAP zapisane w konfiguracji, pobrał listę wszystkich użytkowników i grup Active Directory, próbował odgadywać hasła wszystkich kont (domena nie blokowała kont po nieudanych próbach) i zakładać ukryte konta. Dream zastrzega, że nie ustalił, czy te próby się powiodły, więc pełna skala włamania pozostaje nieznana.

Dream nie przypisuje ataku nazwanej grupie i wskazuje przesłanki operacji powiązanej z Chinami; według Dream Unit 42 śledzi tę aktywność jako CL-UNK-1280. W infrastrukturze atakującego Dream znalazł zainstalowane narzędzia AI, ale podkreśla, że nie ma bezpośredniego dowodu, iż posłużyły do napisania exploitu, a operacja nie wygląda na w pełni autonomiczną.

Skalę wśród klientów podaje Unit 42: około 0,02 proc. bazy instalacji Palo Alto Networks miało interfejs zarządzania dostępny z internetu i zostało dotkniętych problemem. Według Unit 42 producent skontaktował się z każdym z tych klientów indywidualnie, a dostępne poprawki przerywają zaobserwowany łańcuch ataku.

Wpływ na biznes: przejęta zapora otwiera drogę do tożsamości firmy

Według Dream konfiguracja przejętej zapory zawierała pełną topologię sieci wewnętrznej organizacji, a z systemu plików zapory atakujący pobrał klucze prywatne. Na wewnętrznym serwerze zarządzającym zaporami odszyfrował z konfiguracji hasło konta serwisowego LDAP, którego serwer używa do uwierzytelniania użytkowników VPN. Luka w panelu zarządzania nie wymaga hasła: kto ma dostęp sieciowy do panelu, może wykonać na zaporze kod bez logowania. W kampanii opisanej przez Dream pełne przejęcie z uprawnieniami root wymagało połączenia jej z luką Fragnesia. Dla firmy oznacza to, że incydent nie kończy się na zaporze: w kampanii opisanej przez Dream atak na konta w domenie zaczął się w ciągu kilku godzin od przejęcia urządzenia.

Druga cecha ma znaczenie dla decyzji po aktualizacji. Na 24 zaporach z masowej kampanii atakujący zostawił web shell, a na zaporze organizacji rządowej także tunel uruchamiany przy każdym starcie systemu. Źródła nie mówią, czy instalacja hotfixa usuwa takie ślady. Załatanie zamyka drogę dla kolejnych ataków, ale nie odpowiada na pytanie, czy urządzenie było przejęte wcześniej.

Wystawienie panelu zarządzania do internetu to decyzja o ryzyku, nie szczegół konfiguracji. Unit 42 podaje, że zgodnie z dobrymi praktykami bezpieczeństwa interfejs zarządzania domyślnie nie jest dostępny z internetu, a klienci, którzy zainstalowali dostępne poprawki, nie są dotknięci. Rzecznik Palo Alto Networks powiedział The Hacker News, że nie są dotknięci także klienci, którzy nie wystawiają panelu do internetu. W ocenie redakcji zapewnienie o niewystawionym panelu dotyczy obserwowanej kampanii, która zaczynała się od panelu dostępnego z internetu; w tej samej kampanii wewnętrzny serwer zarządzający został zaatakowany już po wcześniejszym włamaniu, przez tunel z przejętej zapory. Osobno: instalacja poprawki nie rozstrzyga, czy urządzenie nie zostało przejęte wcześniej.

Ocena pilności według warunków:

  • Panel zarządzania lub interfejs z profilem zarządzania dostępny z internetu: pilne dziś. Urządzenie należy traktować jako potencjalnie przejęte do czasu sprawdzenia, także po aktualizacji.
  • Panel dostępny tylko z sieci wewnętrznej: ryzyko niższe, ale luka pozostaje. Producent ocenia ryzyko na średnie (CVSS-B 7.7, CVSS-BT 5.2) tylko wtedy, gdy jedynym systemem z dostępem do panelu jest jump box. W kampanii Dream wewnętrzny serwer zarządzania został zaatakowany przez tunel z przejętej zapory, więc odcięcie od internetu nie zastępuje aktualizacji. Hotfix należy zainstalować także tutaj, bez odkładania.
  • Zapora PAN-OS służy głównie jako brama GlobalProtect: według producenta portal i brama GlobalProtect nie są podatne, ale sama zapora działa na PAN-OS i wymaga hotfixa, a jej panel zarządzania trzeba sprawdzić jak w pierwszym scenariuszu. Dream opisuje atakowany serwer WWW jako ten sam, który obsługuje portal GlobalProtect; producent utrzymuje, że portal nie jest podatny.
  • Cloud NGFW i Prisma Access: według producenta nie są podatne.

Co z tego wynika dla decyzji:

  • Konieczne według Palo Alto Networks: natychmiastowe usunięcie dostępu z internetu do interfejsów zarządzania, ograniczenie go do zaufanych adresów wewnętrznych i instalacja hotfixa PAN-OS na wszystkich podatnych zaporach i Panoramach.
  • Konieczne dla urządzeń, których panel był dostępny z internetu: sprawdzenie śladów przejęcia na urządzeniu i w Active Directory. W ocenie redakcji wynika to z kampanii opisanej przez Dream; przy wszystkich trzech lukach CISA wymaga od cywilnych agencji federalnych USA sprawdzenia, czy system nie został przejęty przed załataniem.
  • Rozwiązanie przejściowe: sygnatury Threat Prevention. Producent zaleca je do czasu udostępnienia wersji z poprawką; w ocenie redakcji mają sens także tam, gdzie hotfix nie może zostać zainstalowany od razu. Wymagają subskrypcji Threat Prevention i włączenia 25 identyfikatorów zagrożeń (Threat ID) z wersji treści 9162, 9163, 9164 i nowszych. Producent zastrzega, że chronią panel dopiero po czterech zmianach: przekierowaniu ruchu zarządzania przez port dataplane, wymianie certyfikatu dla przychodzącego ruchu zarządzania, jego deszyfracji i włączeniu na nim ochrony przed zagrożeniami. Te cztery warunki oznaczają przebudowę dostępu do zarządzania, a nie jedno ustawienie.

Rekomendacje: kolejność działań przy PHP2Shell w PAN-OS

DZIŚ:

  • Zinwentaryzować wszystkie zapory PAN-OS i instancje Panoramy z wersją i gałęzią; sprawdzić, czy interfejs zarządzania lub interfejs z profilem zarządzania jest osiągalny z internetu. To zadanie dla administratorów sieci.
  • Tam, gdzie jest osiągalny: usunąć dostęp z internetu i ograniczyć go do zaufanych adresów wewnętrznych lub jednego jump boxa. Palo Alto Networks zaleca zrobić to natychmiast.
  • Zainstalować hotfix właściwy dla gałęzi na wszystkich podatnych zaporach i Panoramach, zaczynając od tych, których panel był dostępny z internetu. Producent nadaje problemowi najwyższą pilność. Na 11.1.7 advisory wskazuje 11.1.7-h12 albo 11.1.16-h4 lub nowszą.
  • Urządzenia na niewspieranych wersjach PAN-OS przenieść na wspieraną wersję z poprawką, zgodnie z advisory. Do czasu migracji obowiązuje ogólne zalecenie producenta: dostęp do panelu zarządzania tylko z zaufanych adresów wewnętrznych. Ograniczenie dostępu zmniejsza ryzyko, ale nie usuwa luki.
  • Gdzie hotfix nie może zostać zainstalowany od razu: wdrożyć sygnatury Threat Prevention z warunkami opisanymi wyżej.
  • Zlecić zespołowi SOC lub dostawcy usług bezpieczeństwa sprawdzenie urządzeń, których panel był dostępny z internetu. Według obserwacji Dream ślady to m.in. nieznane pliki PHP w publicznie dostępnych katalogach zapory, nowe usługi i skrypty uruchamiane przy starcie systemu oraz trwałe połączenia SSH wychodzące do nieznanych adresów. Dream odsyła po wskaźniki przejęcia do Palo Alto Networks; w advisory i w opracowaniu Unit 42 (stan na 29 października) redakcja ich nie znalazła.
  • Jeśli zapory lub serwer zarządzający nimi łączą się z Active Directory: przejrzeć logi domeny pod kątem zapytań LDAP z używanego przez nie konta serwisowego, serii nieudanych logowań na wiele kont i nowych kont użytkowników lub komputerów, czyli działań opisanych przez Dream.
  • W ocenie redakcji, jeśli są ślady przejęcia: traktować hasła i klucze przechowywane na zaporze i serwerze zarządzającym jako ujawnione; Dream opisuje pobranie kluczy prywatnych z systemu plików zapory i odszyfrowanie hasła konta LDAP z konfiguracji serwera zarządzającego.

W TYM TYGODNIU:

  • Śledzić advisory, które producent aktualizuje na bieżąco, pod kątem nowych zaleceń i wskaźników przejęcia.
  • Na urządzeniach z 11.2.10-h16 zaplanować przejście na 11.2.10-h17, która według producenta zawiera także poprawkę Brotli; advisory nie podaje jej statusu wydania.
  • Firmy z produktami Cisco i Fortinet: sprawdzić w advisory producentów, czy używane modele są na liście podatnych (patrz Kontekst).

DO ZAPLANOWANIA:

  • Zasada dla wszystkich zapór: interfejs zarządzania dostępny tylko z zaufanych adresów wewnętrznych lub z jump boxa, zgodnie z zaleceniami wdrożeniowymi producenta. W ocenie redakcji warto ją objąć okresowym sprawdzaniem ekspozycji z zewnątrz i rozciągnąć na inne urządzenia brzegowe.
  • W ocenie redakcji: przegląd kont serwisowych, którymi zapory i serwery zarządzające łączą się z Active Directory, oraz polityki blokady kont po nieudanych logowaniach. W kampanii opisanej przez Dream domena nie blokowała kont, co pozwalało na nieograniczone próby odgadywania haseł.

Kontekst: PHP2Shell u innych producentów urządzeń

Ta sama luka w PHP ma różne skutki u różnych producentów. Cisco w advisory zaktualizowanym 28 października wymienia jako podatne Ultra-Reliable Wireless Backhaul i Unified Industrial Wireless Software (poprawka 27.1.1 zapowiedziana na listopad 2026 r., luka wymaga uprawnień administratora), Expressway i Expressway Select (15.5.21) oraz Duo Access Gateway (3.2.0); ISE Portal Builder jest wyłączony na czas usuwania problemu. Zapory Cisco Secure Firewall nie są podatne, a Cisco nie wie o złośliwym wykorzystaniu luki w swoich produktach. Fortinet w advisory zaktualizowanym 28 października uznaje FortiOS, system zapór FortiGate, za niepodatny, nadal analizuje FortiDDoS, FortiSOAR i FortiSOAR PaaS i nie odnotowuje wykorzystania luki.

Podsumowanie

PHP2Shell w PAN-OS przestał być ryzykiem teoretycznym: producent potwierdza ataki, a Dream opisuje, w wynikach potwierdzonych przez Unit 42, przejęcie zapór z panelem zarządzania wystawionym do internetu i dalszy atak na Active Directory jednej z ofiar. Firma, której panel był dostępny z sieci publicznej, powinna dziś odciąć dostęp, zainstalować hotfix i sprawdzić, czy urządzenie nie zostało przejęte wcześniej, bo aktualizacja nie odpowiada na to pytanie. Pozostałe zapory i Panoramy również wymagają hotfixa bez odkładania, bo producent nadaje problemowi najwyższą pilność.

Pytania, na które zarząd powinien znać odpowiedź:

  • Czy którykolwiek interfejs zarządzania naszych zapór był dostępny z internetu i od kiedy?
  • Czy wszystkie zapory i Panoramy mają już hotfix z advisory Palo Alto Networks?
  • Kto sprawdził, czy urządzenia z wystawionym panelem nie zostały przejęte przed aktualizacją, i z jakim wynikiem?
  • Jakim kontem zapory i serwer zarządzający nimi łączą się z Active Directory i czy domena blokuje konta po serii nieudanych logowań?

Źródła