Krótko: CERT-EU radzi według doniesień, aby zinwentaryzować instalacje PHP, natychmiast łatać i izolować publicznie dostępne aplikacje, jeśli nie da się ich załatać w krótkim czasie. CERT-Bund i BSI zalecają w swoim ostrzeżeniu natychmiastową aktualizację, a jeśli nie jest to możliwe, czasowe odłączenie dotkniętych serwerów WWW od sieci. Zalecenia pokrywają się w zasadniczej części: najpierw aktualizacja, izolacja jako rozwiązanie awaryjne, środki przejściowe tylko jako uzupełnienie.
Kto ostrzega i dla kogo?
W przypadku PHP2Shell kilka oficjalnych instytucji zareagowało w ciągu godzin. Dla firm w Niemczech pierwszym adresem jest BSI wraz ze swoim zespołem reagowania na incydenty komputerowe CERT-Bund (zespołem niemieckiej administracji federalnej). CERT-EU to służba cyberbezpieczeństwa instytucji UE; jego wskazówki są skierowane przede wszystkim do nich, ale czytane w całej Europie. Według BleepingComputer ostrzegło także brytyjskie National Cyber Security Centre. Z sektora prywatnego odezwali się między innymi Huntress i Cloudflare.
Dla Państwa jako operatora pochodzenie jest mniej ważne niż zgodność. Jeśli kilka niezależnych instytucji radzi to samo, jest to silny sygnał.
CERT-Bund, CERT-EU i inne: ostrzeżenia dotyczące PHP w porównaniu
| Instytucja | Zasadnicze zalecenie | Cecha szczególna |
|---|---|---|
| BSI / CERT-Bund | natychmiast zaktualizować, w przeciwnym razie czasowo odłączyć serwer WWW od sieci | poziom ostrzeżenia 3 / pomarańczowy |
| CERT-EU | zinwentaryzować instalacje PHP, natychmiast załatać, w przeciwnym razie odizolować aplikacje publiczne | uważał według doniesień za możliwe, że dotknięte są wersje od PHP 5 |
| UK NCSC | natychmiast zaktualizować lub do czasu poprawki odłączyć dotknięte systemy od sieci | według BleepingComputer |
| php.net | zaktualizować do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, środki przejściowe tylko jako częściowa ochrona | źródło pierwotne dla wersji i ustawień |
Żadna z instytucji nie zaleca polegania wyłącznie na Web Application Firewall lub na ustawieniach w php.ini. Wszystkie wskazują aktualizację jako właściwe rozwiązanie. Co BSI radzi ponadto w szczegółach, opisuje strona Co BSI zaleca w sprawie PHP2Shell.
Kwestia wersji: co oznacza „od PHP 5”
CERT-EU uważał według doniesień za możliwe, że dotknięte są wersje od PHP 5. Instytucja opierała się przy tym według doniesień fachowych na informacjach, które krążyły przed oficjalnym zgłoszeniem. Prasa branżowa mówi o niemal wszystkich wersjach aż do PHP 5.4.
W praktyce dokładna granica niewiele zmienia. Dla PHP 8.1 i starszego projekt PHP nie dostarcza już oficjalnych aktualizacji. Istnieją minimalne backporty źródłowe dla 7.4, 8.0 i 8.1, ale nie ma wydań. Kto nadal prowadzi PHP 5 lub 7, jest zdany na dystrybucje, zewnętrznych dostawców lub migrację. Czy Państwa dystrybucja dostarczyła poprawkę, pokazują jej własne strony bezpieczeństwa, na przykład Debian Security Tracker, Ubuntu Security Notices lub komunikaty Red Hat. Istnieją też komercyjne oferty długoterminowego wsparcia dla starych wersji PHP; czy obejmują PHP2Shell, należy kazać sobie potwierdzić przez dostawcę na piśmie. Szczegóły dotyczące gałęzi znajdą Państwo pod hasłami Które wersje PHP są dotknięte? i PHP 8.1 i starsze.
Izolowanie: jak wdrożyć zalecenie
„Izolowanie” brzmi abstrakcyjnie. Chodzi o to, aby żądania z internetu nie docierały już do podatnej aplikacji PHP. W zależności od aplikacji istnieje kilka stopni:
- Całkowite wyłączenie: Strona zostaje zastąpiona statyczną stroną awaryjną bez PHP. To najbezpieczniejszy wariant.
- Ograniczenie dostępu: Aplikacja pozostaje w działaniu, ale jest osiągalna tylko przez VPN lub dla ustalonych adresów IP, na przykład w przypadku portali wewnętrznych.
- Logowanie przed aplikacją: Logowanie na poziomie serwera WWW lub proxy przed aplikacją. Uwaga: w przypadku mod_php pokazano exploit, zanim uruchomi się kod aplikacji. Logowanie musi więc działać przed PHP, a nie w aplikacji.
- Zablokowanie bezpośredniego dostępu do źródła: Kto korzysta z usługi proxy lub CDN, powinien upewnić się, że serwer nie jest dodatkowo osiągalny bezpośrednio.
Ograniczenie w serwerze WWW może wyglądać tak (przykładowa, nieszkodliwa konfiguracja dla Apache):
# Zezwalaj na dostęp tylko z sieci wewnętrznej (dostosować przykładowy zakres)
<Location "/">
Require ip 192.0.2.0/24
</Location>
Skutek należy przetestować z zewnątrz, na przykład przez połączenie komórkowe. Izolacja sprawdzona tylko w sieci biurowej nie jest sprawdzoną izolacją.
Izolowanie jest rozwiązaniem pomostowym. Przy izolowaniu od razu ustalić, do kiedy przyjdzie aktualizacja i kto ją zainstaluje. W przeciwnym razie z rozwiązania awaryjnego robi się stan trwały.
Czego wspólnie wymagają zalecenia: inwentarza
Wszystkie oficjalne instytucje zakładają, że wiedzą Państwo, gdzie działa PHP. Właśnie na tym wiele firm zawodzi: mikrostrony ze starych kampanii, zapomniany portal klienta, system testowy z publicznym adresem, aplikacja na NAS. CERT-EU wyraźnie wymienia zinwentaryzowanie instalacji PHP jako pierwszy krok.
Zapomniane systemy najłatwiej znaleźć trzema drogami: strefami DNS Państwa domen, listą wystawionych certyfikatów TLS i umowami z agencjami, dostawcami hostingu i dostawcami oprogramowania. Każdy wpis, o którym nikt nie potrafi od razu powiedzieć, co za nim działa, trafia na listę do sprawdzenia. Właśnie takie systemy są w sytuacji takiej jak PHP2Shell niebezpieczne, ponieważ nikt ich nie łata i nikt nie zauważy, gdy zostaną skompromitowane.
Użyteczny inwentarz zawiera dla każdego systemu: adres, cel, operatora, wersję PHP i tryb pracy, źródło pakietów oraz osobę kontaktową do aktualizacji. Jak go zbudować i utrzymywać w aktualności, pokazuje artykuł Inwentarz wszystkich stron i serwerów.
Jak konkretnie pomaga PHP SOS?
- Inwentaryzacja: Ustalamy Państwa publicznie dostępne systemy PHP i porządkujemy je według ryzyka.
- Poprawka lub izolacja: Instalujemy aktualizacje lub izolujemy aplikacje, których nie da się załatać od razu, i sprawdzamy skutek z zewnątrz.
- Stare wersje: Dla systemów z PHP 8.1 i starszym planujemy z Państwem drogę do wspieranego stanu.
- Dowód: Otrzymują Państwo dokumentację wdrożonych zaleceń dla każdego systemu.
Jak doprowadzamy stare aplikacje do wspieranych wersji, opisuje usługa migracja PHP dla systemów legacy.
Podsumowanie
CERT-EU, CERT-Bund, BSI i projekt PHP mówią jednym głosem: aktualizować, a gdzie nie da się tego zrobić od razu, izolować. Różnice tkwią w szczegółach, takich jak granica wersji. Dla Państwa praktyki liczy się pierwszy krok, który zakładają wszyscy: wiedzieć, gdzie wszędzie działa PHP.
Częste pytania
Jaka jest różnica między CERT-Bund a CERT-EU?
CERT-Bund to zespół reagowania na incydenty komputerowe przy BSI (niemieckim Federalnym Urzędzie ds. Bezpieczeństwa w Technice Informatycznej), który ostrzega w Niemczech przed lukami. CERT-EU to służba cyberbezpieczeństwa instytucji i organów Unii Europejskiej. Obie publikują zalecenia, które są użyteczne także dla firm.
Co znaczy odizolować aplikację PHP?
Aplikacja nie jest wtedy już swobodnie dostępna z internetu. Można to osiągnąć przez stronę awaryjną, dostęp tylko przez VPN lub z określonych adresów IP albo przez całkowite wyłączenie. Decydujące jest, aby żądania z zewnątrz nie docierały już do podatnego procesu PHP.
Czy według CERT-EU dotknięte są także wersje PHP 5?
CERT-EU uważał według doniesień za możliwe, że dotknięte są wersje od PHP 5, opierając się na informacjach, które krążyły przed oficjalnym zgłoszeniem. Prasa branżowa wymienia niemal wszystkie wersje aż do PHP 5.4. Dla tak starych wersji nie ma oficjalnych aktualizacji.
Czy istnieją oficjalne cechy rozpoznawcze ataków?
Nie. Jak dotąd nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise) dotyczących PHP2Shell. Wykrywanie opiera się na analizie zachowania, na przykład procesów serwera WWW uruchamiających powłoki lub nowych plików PHP w katalogach przesyłania.