Przejdź do treści
Security · 4 min czytania

PHP2Shell: dwa miesiące na łatkę, kilka godzin na atak

Lukę znaleziono w sierpniu z pomocą AI, łatka wyszła w październiku, a od wycieku do pierwszych ataków minęło pięć godzin. Czego PHP2Shell uczy o czasie, odpowiedzialności i o tym, kiedy jedyną kontrolą jest wyłączenie.

Tekst:
Komunikat to nie stan serwera Ten sam październik, dwa światy, jedna kontrola: wyłączyć
PHP2Shell: dwa miesiące na łatkę, kilka godzin na atak

21 października zespół PHP wydał awaryjne poprawki dla dwóch krytycznych luk, nazwanych wspólnie PHP2Shell. Pozwalały wykonać kod na serwerze bez logowania, jednym spreparowanym żądaniem, zanim WordPress czy jakakolwiek inna aplikacja zdążyła się załadować. Dzień później w studiu napisałem dwa poradniki: co się stało i co zrobić na hostingu współdzielonym. Tutaj chcę zrobić coś innego: rozłożyć tę sprawę na części, bo przez kilka dni pokazała w miniaturze prawie wszystko, o czym w tym roku pisaliśmy przy agentach.

Oś czasu, czyli dwa zegary

Pierwszą z luk zespół Wiz znalazł 19 sierpnia, korzystając z narzędzi do badań wspomaganych przez AI. W ciągu dwóch dni potwierdził, że daje zdalne wykonanie kodu na Drupalu i WordPressie, a 24 sierpnia zgłosił ją zespołowi PHP. Potwierdzenie zgłoszenia przyszło 21 września. 20 października PHP zapowiedziało wydanie poprawek na następny dzień, na godzinę 14:00 czasu UTC.

Potem zaczął tykać drugi zegar. 21 października o 2:29 w nocy w VirusTotal pojawiło się archiwum z informacjami o luce. O 7:34 Patchstack raportował od partnerów hostingowych aktywne próby ataków. Poprawki wyszły o 13:52, osiem minut przed zapowiedzianą godziną, ale kilka godzin za atakującymi.

Odpowiedzialne ujawnianie luk zakłada, że ten, kto broni, ma przewagę czasu. Tu proces koordynacji trwał dwa miesiące, a droga od wycieku do ataku zajęła mniej niż pięć godzin. Przewaga obrońców nie zniknęła przez czyjś błąd. Zniknęła, bo zegary chodzą w różnym tempie. Lukę znaleziono z pomocą AI, i nie ma powodu sądzić, że druga strona nie korzysta z tych samych narzędzi.

Kto trzyma łatkę

Na własnym serwerze aktualizujesz PHP sam. Na hostingu współdzielonym robi to dostawca, na tysiącach serwerów naraz, a ty w tym czasie nie masz na nic wpływu. Napisałem w studiu zdanie, które moim zdaniem jest najważniejsze z całej tej sprawy dla właściciela małej strony: komunikat hostingodawcy to jedno, a stan twojego serwera to drugie.

„Poprawki wdrożone” na stronie statusu to deklaracja. Stan serwera sprawdzasz sam: wersją PHP i datą kompilacji. Plik z datą sprzed 21 października oznacza, że działasz na podatnej wersji, niezależnie od tego, co mówi komunikat. Przy okazji: niższy numer wersji nie zawsze oznacza brak poprawki, bo część dostawców przenosi łatki do starszych wydań. Liczy się to, co faktycznie działa na serwerze, a nie to, co ktoś o nim napisał.

To ta sama zasada, którą w radarze opisaliśmy przy agentach: sprawozdanie z działania nie jest jego zapisem. Tam chodziło o agenta, który zaprzeczył, że wyłączył monitor. Tu chodzi o zwykły komunikat dostawcy, pisany w dobrej wierze. Mechanizm jest jednak ten sam: kontrola oparta na tym, co ktoś deklaruje, a nie na tym, co da się sprawdzić, nie jest kontrolą.

Ślady, których nie ma

Atak odbywał się poniżej warstwy aplikacji, więc logi WordPressa czy sklepu mogły nic nie pokazać. Badacze zalecają przeglądanie danych od 20 października, a nawet wcześniej. Czyste logi aplikacji nie dowodzą, że strona jest bezpieczna.

W sierpniowym radarze nazwaliśmy to awarią bez sygnału: najgroźniejsze jest to, co nie zostawia śladu tam, gdzie zwykle patrzymy. PHP2Shell jest podręcznikowym przykładem. Kto po aktualizacji ograniczy się do sprawdzenia, czy strona działa, może nie zauważyć, że ktoś był w środku przed łatką.

Wyłączyć

22 października Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w systemie SSDIP. Ograniczenia albo wyłączenia stron państwowych pojawiły się też w kilku innych krajach europejskich.

Łatwo to uznać za nadgorliwość. Ale jeśli luka jest łatwa do wykorzystania, ataki już trwają, a łatka jeszcze nie dotarła na serwer, wyłączenie strony bywa najrozsądniejszą decyzją. To jedyna kontrola, która nie zależy od tego, czy ktoś po drugiej stronie zdążył coś zrobić.

Tego samego dnia, 21 października, OpenAI ujawniło, że dwóch jego wewnętrznych agentów osłabiło mechanizm nadzorujący ich zachowanie. W radarze pisaliśmy, że w świecie agentów najpewniejszą kontrolą okazało się odcięcie od sieci. Ten sam październik pokazał to w świecie, który z agentami nie ma nic wspólnego: technologia starsza niż większość jej użytkowników, zwykłe strony urzędów, i ta sama odpowiedź.

Trzecia luka, której nie trzeba było łatać

23 października PHP opisało kolejną lukę, osobną od PHP2Shell, która w nietypowej konfiguracji również pozwalała wykonać kod. Na razie bez osobnej poprawki. Tymczasowe zabezpieczenie polega na wyłączeniu śledzenia postępu przesyłania plików, czyli dokładnie tej samej funkcji, którą PHP zalecało wyłączyć dwa dni wcześniej przy PHP2Shell.

Kto 21 października wyłączył tę funkcję, był chroniony przed luką, o której jeszcze nikt nie wiedział. Ograniczenie zasięgu, czyli wyłączenie tego, czego się nie używa, chroni przed całą klasą błędów, a nie przed jednym. Łatka chroni przed konkretnym błędem. Dobrze mieć jedno i drugie, ale tylko pierwsze działa, zanim ktoś znajdzie kolejny.

Co z tego wynika

Dla właściciela strony na hostingu współdzielonym trzy rzeczy. Sprawdź sam, na czym działa twoja strona, zamiast polegać na komunikacie. Wyłącz to, czego nie używasz, zanim ktoś znajdzie powód. Ustal z góry, kto u ciebie decyduje o wyłączeniu strony, bo w takiej sytuacji nie ma czasu na zebranie zarządu. Szczegółowe kroki są w poradniku na studiu.

A szerzej: na stronie działa ponad pięć milionów adresów z PHP. Okno między odkryciem a atakiem skurczyło się do godzin, bo luki znajdują teraz maszyny, i to po obu stronach. Obrona, która zakłada, że zdąży się zareagować, przegrywa z obroną, która nie wymaga reakcji.

Źródła