AktualnościKryptoPoprawka PHP2Shell jest już dostępna, ale niezałatane serwery pozostają zagrożone

Poprawka PHP2Shell jest już dostępna, ale niezałatane serwery pozostają zagrożone

Autor: Decrypt·

Najważniejsze informacje

  • •PHP wydało załatane wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 w dniu 21 października, a właściciele serwerów muszą ręcznie zainstalować aktualizacje i zrestartować PHP, aby ochrona zaczęła obowiązywać.
  • •Cloudflare zaobserwowało eskalację prób eksploatacji z tysięcy do milionów, a serwery-pułapki Amazona zarejestrowały próbę wykorzystania 17 października, cztery dni przed publicznym ujawnieniem luk.
  • •Niemiecki BSI i rząd Japonii nie zgłosiły potwierdzonych udanych wtargnięć, a na dzień 22 października żadna giełda kryptowalut nie zgłosiła publicznie włamania związanego z PHP2Shell.
  • •PHP Foundation przypisało powolne rozwiązanie luki po raz pierwszy wykrytej w 2024 roku błędowi strukturalnemu w procesie decyzyjnym i zasobach zespołu bezpieczeństwa i oświadczyło, że będzie teraz decydować większością głosów.
  • •Około 884 000 hostów z dostępem do internetu uruchamia wersje PHP bez oficjalnych poprawek, a organizacje takie jak Wikimedia, 32 brytyjskie służby rządowe i holenderskie szpitale czasowo wyłączyły swoje strony.
Poprawka PHP2Shell jest już dostępna, ale niezałatane serwery pozostają zagrożone

Październikowe poprawki bezpieczeństwa PHP z 21 października pozostają jedynym rozwiązaniem problemu PHP2Shell — pary luk, które mogą pozwolić nieuwierzytelnionemu atakującemu na przejęcie kontroli nad podatnym serwerem. Poprawki chronią serwer dopiero po ich zainstalowaniu i restarcie PHP przez właściciela.

Dyrektor generalny Cloudflare Matthew Prince powiedział, że liczba prób eksploatacji w sieci firmy wzrosła z tysięcy do milionów. Federalna agencja cyberbezpieczeństwa Niemiec, BSI, oraz rząd Japonii oświadczyły, że nie potwierdziły żadnych udanych włamań. PHP Foundation, która finansuje prace nad samym PHP, poinformowała, że po raz pierwszy wykryła oznaki jednej z luk w 2024 roku i określiła opóźnienie w jej usunięciu jako „błąd strukturalny”.

Te wydarzenia nastąpiły dzień po tym, jak dwie luki w PHP skłoniły rządy i organizacje do wyłączenia stron internetowych. Kluczowym pytaniem dla użytkowników internetu jest to, czy bezpiecznie jest normalnie korzystać z sieci. Krótka odpowiedź brzmi: sam internet się nie zepsuł, a większość użytkowników napotyka ryzyko poprzez odwiedzane strony, a nie przez własne telefony czy komputery. Wiele serwerów nadal jednak wymaga załatania.

PHP, otwartoźródłowy język server-side, jest używany w tle przez około 70% stron internetowych, dla których znany jest język programowania po stronie serwera. To zasięg sprawia, że luka wym PHP staje się ogólnoświatowym wydarzeniem związanym z łatkami, a nie problemem jednej firmy. Dwie luki, zbiorczo nazywane PHP2Shell, mogą pozwolić obcemu na przejęcie kontroli nad podatnym serwerem bez logowania.

Czy PHP2Shell zostało naprawione?

PHP wydało wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 w dniu 21 października, zgodnie z informacjami o wydaniu. W komunikacie wydania czytamy: „Nie istnieją kompletne środki zaradcze, aktualizacja to jedyny bezpieczny wybór”. Na dzień 22 października PHP nie wydało żadnej kolejnej poprawki.

Dostępność poprawki nie oznacza, że każda dotknięta strona jest chroniona. PHP nie aktualizuje się samo, więc firmy hostingowe, działy IT i indywidualni właściciele stron muszą zainstalować odpowiednie wydanie na swoich serwerach i zrestartować oprogramowanie, aby zmiana weszła w życie. W praktyce ochrona rozprzestrzenia się w tempie prac serwerowych, a nie w momencie wydania, więc liczba serwerów pozostających narażonych zależy od tego, jak szybko operatorzy zakończą wdrażanie.

PHP 8.1 i wcześniejsze wersje nie otrzymują już oficjalnych wydań, co czyni starsze serwery szczególnie słabym punktem. Zespół bezpieczeństwa PHP opublikował jednak uproszczone poprawki dla wersji 7.4, 8.0 i 8.1 dla użytkowników, którzy sami kompilują oprogramowanie.

Czy serwery zostały przełamane?

Atakujący szybko zaczęli skanować systemy w poszukiwaniu podatnych maszyn. Prince powiedział, że Cloudflare zaobserwowało tysiące prób eksploatacji w ciągu 10 godzin przed publicznym ogłoszeniem, dziesiątki tysięcy w kolejne 45 minut, setki tysięcy w ciągu dwóch godzin i miliony później.

https://x.com/eastdakota/status/2113079352682570051?ref_src=twsrc%5Etfw

Amazon poinformował, że jego serwery-pułapki zarejestrowały próbę ataku 17 października, cztery dni przed publicznym ujawnieniem luk. CISO Amazona CJ Moses napisał, że „pozostaje niejasne, w jaki sposób sprawca zdobył informacje o eksploatacji przed ujawnieniem”, i stwierdził, że PHP2Shell jest „obecnie szeroko wykorzystywane w praktyce”.

W wpisie na blogu o bezpieczeństwie Amazon powiedział, że aktywność została zaobserwowana przed publicznym ujawnieniem.

Rdy nie zgłosiły jednak potwierdzonych udanych wtargnięć. Thomas Caspers, wiceprezes niemieckiej federalnej agencji cyberbezpieczeństwa BSI, powiedział, że agencja zaobserwowała ataki, ale nie odnotowała skutecznego wykorzystania luk. Dodał: „Wykorzystanie tej luki wydaje się nieco bardziej skomplikowane, niż oczekiwano”. Sekretarz stanu Japonii, Minoru Kihara, również oświadczył, że nie potwierdzono żadnych ataków wykorzystujących te luki.

Próba eksploatacji i udane włamanie to dwa różne zdarzenia. Miliony prób mogą wystąpić, podczas gdy żadne potwierdzone włamanie nie zostało jeszcze zidentyfikowane, a udane wtargnięcia mogą zostać odkryte po fakcie, a nie w czasie rzeczywistym. Dla śledzących sprawę oznacza to, że informacje o potwierdzonych włamaniach, jeśli takie się pojawią, nadejdą w wyniku późniejszych dochodzeń i oficjalnych ujawnień, a nie w czasie rzeczywistym.

Dlaczego problem nie został rozwiązany wcześniej?

PHP Foundation powiedziało, że prace nad bezpieczeństwem w 2024 roku „wykryły pierwsze oznaki problemu OOM stojącego za CVE-2026-109618”, odnosząc się do błędu wyczerpania pamięci stanowiącego sedno jednej z dwóch luk.

Zgodnie z relacją fundacji na temat wydania bezpieczeństwa, zespół opracował „kilka konkurencyjnych podejść”, ale „miał trudności z wyborem między nimi i obawiał się konsekwencji wdrożenia niewłaściwego rozwiązania”. Fundacja stwierdziła, że jej finansowanie umożliwiło kilku osobom pełnoetatową pracę nad tym problemem.

„Nie będziemy udawać inaczej: opóźnienie było błędem strukturalnym, spowodowanym zarówno procesem decyzyjnym zespołu bezpieczeństwa, jak i brakiem zasobów” — napisała fundacja. Poinformowała, że zespół bezpieczeństwa, który wcześniej wymagał konsensusu, będzie teraz podejmował decyzje większością głosów.

Fundacja dodała również, że prace nad bezpieczeństwem oprogramowania obsługującego większość sieci „nadal zależą od niewielkiej grupy finansowanych przez fundację programistów i nieco pomocy wolontariuszy”.

Dlaczego niektóre strony nadal nie działają?

Wdrażanie poprawek wymaga czasu, a organizacjom, które nie mogły natychmiast zastosować poprawki, zalecono wyłączenie systemów. Brytyjskie Narodowe Centrum Cyberbezpieczeństwa (National Cyber Security Centre) zaleciło organizacjom rozważenie „wyłączenia systemu do czasu pełnego usunięcia zagrożenia” w swoich wytycznych.

Według TechRadara dotknięte 21 października były strony i usługi, w tym usługi Wikimedia, strony i aplikacje Orange w kilkudziesięciu krajach, 32 brytyjskie służby rządowe, holenderskie szpitale oraz niemiecki federalny dostawca IT, ITZBund.

Brytyjski Urząd Odpowiedzialności Budżetowej (Office for Budget Responsibility) i strona rady Edynburga zostały przywrócone do 22 października. Inne usługi, w tym holenderska strona do anonimowego zgłaszania przestępstw Meld Misdaad Anoniem, pozostały offline w czwartek rano, według DutchNews.

Czy użytkownicy powinni zmienić hasła?

Nie wyłącznie z powodu PHP2Shell — przynajmniej na podstawie dostępnych informacji. Żadne potwierdzone naruszenie danych nie zostało powiązane z tymi lukami, a zmiana wszystkich haseł nie ochroni strony, której serwer pozostał niezałatany.

Standardowe środki bezpieczeństwa pozostają przydatne: używaj unikalnego hasła do każdego konta, włącz uwierzytelnianie dwuskładnikowe i zwracaj uwagę na powiadomienia od firm o możliwych naruszeniach w nadchodzących tygodniach. Jeśli firma potwierdzi naruszenie, użytkownicy powinni zmienić dotknięte hasło oraz każde inne ponownie użyte hasło.

Właściciele stron mają dodatkową pracę, ponieważ zastosowanie poprawki zamyka lukę, ale nie pokazuje, czy atakujący uzyskał wcześniej dostęp do serwera. Firma zajmująca się bezpieczeństwem Tag1 zaleca właścicielom szukanie plików PHP, których nie przesyłali, nowych zaplanowanych zadań i nowo utworzonych kont. Zaleca również rotację haseł do baz danych i kluczy API na każdym serwerze z dostępem do internetu, na którym działała podatna wersja. Wytyczne Tag1 są dostępne tutaj.

Co oznacza PHP2Shell dla użytkowników kryptowalut?

Założyciel Binance Changpeng Zhao ostrzegł użytkowników na X: „Nazwijcie mnie paranoikiem, ale bądźcie wyjątkowo ostrożni odwiedzając JAKĄKOLWIEK stronę internetową przez najbliższe dni”.

https://x.com/cz_binance/status/2113029289155178716

Zhakowany serwer może wyświetlić fałszywą wersję prawdziwej strony. W sektorze kryptowalut taka strona może poprosić użytkownika o podłączenie portfela i zatwierdzenie transakcji, która go opróżni. Sieć blockchain może pozostać nietknięta, podczas gdy strony zapewniające do niej dostęp zostaną skompromitowane.

Użytkownicy powinni dokładnie sprawdzać, co podpisują, zapisywać strony w zakładkach zamiast klikać linki i korzystać z portfela sprzętowego, jeśli go posiadają. Na dzień 22 października żadna giełda kryptowalut nie zgłosiła publicznie włamania związanego z PHP2Shell.

Czy bezpiecznie jest korzystać z internetu?

Preglądanie internetu było ogólnie tak samo bezpieczne jak tydzień wcześniej, choć żadna aktywność w sieci nie jest całkowicie pozbawiona ryzyka. Główna ekspozycja dotyczyła serwerów, które nie zostały załatane. Firma bezpieczeństwa Mallory zliczyła około 884 000 hostów z dostępem do internetu, uruchamiających wersje PHP, które nie otrzymują już oficjalnych poprawek.

Amazon wezwał obrońców do nieprzyjmowania założenia, że data publicznego ujawnienia była najwcześniejszą datą eksploatacji. „Obrońcy nie powinni zakładać, że data publicznego ujawnienia jest najwcześniejszą datą eksploatacji” — powiedziała firma. Każdy serwer, który działał na podatnej wersji PHP co najmniej od 17 października, powinien zostać zbadany, a nie tylko załatany.

Źródło oryginalne: Decrypt