Luka w PHP z 21 października: co zrobiliśmy i dlaczego

Co się stało

W środę rano projekt PHP ujawnił dwie krytyczne podatności, szybko nazwane “PHP2Shell”, obie z oceną 9,2 na 10. Przez te luki ktoś z zewnątrz mógł uruchomić własny kod na serwerze z PHP, bez logowania. W ten sposób można dostać się do kont, haseł i chronionych części strony, a w najgorszym razie do samego serwera.

Co dodatkowo podniosło napięcie: informacje o lukach wyciekły już dzień wcześniej i krążyły w mediach społecznościowych. Poprawka była zaplanowana na dalszą część tygodnia i została przyspieszona na środę, godz. 16.00. Do tego momentu każdy serwer z PHP dostępny z internetu był prawdopodobnie podatny — i osoby o złych zamiarach też o tym wiedziały.

Dlatego wiele dużych organizacji podjęło tę samą decyzję co my i zapobiegawczo wyłączyło swoje strony, w tym izba niższa holenderskiego parlamentu, NCSC, DigiD i MijnOverheid. Relacja na żywo serwisu NU.nl dobrze oddaje przebieg tamtego popołudnia.

Co zrobiliśmy

Nie czekaliśmy, aż coś pójdzie nie tak. Tak wyglądał ten dzień na naszych serwerach:

• godz. 13.30Wyłączenie PHP na wszystkich naszych serwerach. Strony działające na PHP wyświetlały odwiedzającym krótkie wyjaśnienie.
• W międzyczasiePoczta e-mail w Państwa domenie była normalnie wysyłana i odbierana. Państwa strona i dane pozostały nienaruszone: nic nie zostało usunięte ani zmienione.
• godz. 16.00Zaktualizowane wersje PHP działały, a strony znów były dostępne.
• PotemSprawdzenie serwerów pod kątem śladów nadużyć. W naszych logach nie znaleziono żadnych oznak włamania.

To, że zaktualizowane wersje działały u nas już o godz. 16.00, wynika z tego, że od popołudnia nieustannie śledziliśmy aktualizację i zainstalowaliśmy ją od razu, gdy się pojawiła.

Przepraszamy za utrudnienia

Dwie i pół godziny niedostępnej strony to przykra sprawa, zwłaszcza jeśli klienci szukali Państwa akurat tego popołudnia. Część z Państwa zobaczyła, że strona jest offline, zanim dotarła nasza wiadomość. Ze względu na powagę luki zdecydowaliśmy się najpierw zabezpieczyć serwery, a dopiero potem wysłać maile. Przepraszamy za utrudnienia.

Jednocześnie ten krok pasuje do tego, jak Państwa hostingiem zarządzamy: sami aktywnie pilnujemy serwerów, a gdy trzeba, szybko interweniujemy. Lepiej jedno popołudnie ze stroną z wyjaśnieniem niż strona, która później okazuje się przejęta.

Dlaczego będzie się to zdarzać częściej

Podatny kod tkwił w PHP od ponad dziesięciu lat, a teraz został znaleziony z pomocą AI. To narzędzie jest dostępne także dla osób o złych zamiarach. Dlatego spodziewamy się, że luki będą pojawiać się jedna po drugiej w coraz szybszym tempie. Strony z CMS takim jak WordPress czy Joomla wymagają szczególnej uwagi: opierają się zarówno na PHP, jak i na wtyczkach i rozszerzeniach od dziesiątek różnych twórców, a każdy z tych elementów może zawierać kolejną lukę.

Dlatego coraz częściej przenosimy istniejące strony na strony statyczne, bez PHP, WordPress czy Joomla. W ten sposób znika wiele potencjalnych podatności, a przy kolejnej luce w PHP taka strona po prostu pozostaje online. Tylko formularz kontaktowy korzysta wtedy jeszcze z niewielkiego skryptu PHP, chyba że dostępne jest inne rozwiązanie. Jak to działa, wyjaśniamy tutaj: budowa strony internetowej bez PHP.

Chcą Państwo wiedzieć, czy to odpowiednie rozwiązanie dla Państwa strony, albo mają Państwo pytania dotyczące środy? Prosimy napisać na adres info@innodigi.nl lub skontaktować się z nami.