Już miałem zamykać, wszystkich w redakcji puścić do domu, by mogli ten wieczór spędzić z rodzinami, a tu niespodzianka – na liście ostrzeżeń pojawiła się informacja o nowej podatności na WordPressa. Na szczęście relatywnie niegroźnej, bo nie ma tu raczej mowy o jakimś włamaniu, czy wykradaniu danych. Po prostu, gdy komuś podpadliście, to może on spróbować troszkę poddusić Wasz serwer, aż jedyne co będzie można wyświetlić w przeglądarce, to błędy dostępności serwera/strony (5xx, np. 502, 503, 504 czy 522 od Cloudflare).
Atak DoS na WordPressa (CVE-2018-6389)
Kilka dni temu gdzieś w moich RSSech śmignął artykuł o tym, że aktualizacja WordPressa do wersji 4.9.3 będzie jednak dopiero za kilka dni, bo pojawiły się problemy z licencją jednej z bibliotek odpowiedzialnych za nowy edytor kodu wbudowany w WordPressa. Może to i dobrze, bo dzięki temu od razu załatają podatność, o której informuje m.in. na swojej stronie Barak Tawily. Tam też odsyłam po bardziej szczegółowe informacje…
Tak jak napisałem w pierwszym akapicie – szczęście w nieszczęściu nie mamy tu do czynienia z jakimś przełamaniem zabezpieczeń, a pewnym błędem, który może zostać wykorzystany do przeprowadzenia ataku DoS (Denial-of-Service, czyli odmowa dostępu) na naszą stronę, przez co ta może przestać być dostępna. Oczywiście taki atak można przeprowadzić prawie zawsze, i prawie na każdej stronie, i czasem jest łatwiej, a czasem trudniej.
Barak tym razem wziął „na warsztat” plik „script-loader.php”, który odpowiada za wczytywanie wykorzystywanych przez WordPressa skryptów w taki sposób, by były przesyłane do przeglądarki w ramach jednego żądania, co odbywa się poprzez wczytanie wszystkich wymaganych skryptów (JavaScript) i przesłanie ich w formie jednego „pliku”. Ma to oczywiście jak najbardziej sens, tyle tylko, że taka operacja – generowanie jednego pliku – może pochłonąć trochę zasobów, zwłaszcza, gdy czyjaś „przeglądarka” zażąda wszystkie możliwe pliki, a do tego wielokrotnie w krótkim czasie. Zwłaszcza, że można to zrobić bez uwierzytelnienia, a więc właściwie dowolna osoba na dowolnej stronie. Wtedy mogą się zacząć problemy – dla serwera z wydajnością, i ewentualnie dla „dowcipnisia” z prawem… ;-)
Jakby ktoś z Was obawiał się, że jakiś dowcipniś może „zapolować” na jego WordPressa, to jest przygotowana już poprawka, choć na razie jest to poprawka nieoficjalna.
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.
Dumny przyjaciel swoich psów :-)
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
A tu psikus, 4.9.3 już jest …ale brak w niej fixa ;p
No to cóż, czekamy na 4.9.4, ew. łatamy ręcznie… Na szczęście mamy tu do czynienia „tylko” z potencjalnym DoSem, więc nie ma bezpośredniego zagrożenia danych, do tego zapewne można to wyciąć za pomocą odpowiednich reguł po stronie serwera, czy też na usłudze Cloudflare (WAF).
4.9.4 też już jest i ( contains 1 bug fix. #43235 – WP Automatic Updates broken in 4.9.3. ) :)
Nawet w kolejnych to wątpliwe – aktualna wersja tłumaczeń: to nie „security”, to tylko „performance” ….to nie wina WP, tylko hostingu …autoryzacja tam nie ma sensu, bo wiele stron ma otwarta rejestrację itd. itp. xD
Więc lepiej łatać we własnym zakresie, bo można się nie doczekać poprawki.
Ze sposobów dla zwykłego zjadacza chleba wystarczy define + prosta regułka w .htaccess.
Właśnie tak też opisywał to BT, stąd brak nagrody w ramach „bug bounty”, oraz taka a nie inna reakcja. Na razie nie zaobserwowałem na swoich serwerach (stronach) wzmożonego obciążenia, więc albo „dzieci” jeszcze nie wiedzą, albo keszowanie i Cloudflare dają sobie radę. Pewnie podczas którejś aktualizacji „po cichu” coś z tym zrobią. W każdym razie zgadzam się, że nie mogą tego od tak, globalnie wyciąć dla niezalogowanych, bo – jak piszesz/cytujesz – wiele stron ma otwarty dostęp dla „zewnętrznych użytkowników”, a więc… W każdym razie jak ktoś sam – lub w wąskim, zaufanym gronie – korzysta z panelu zarządzania WP, to jest to kolejny powód, by np. ograniczyć dostęp do tego fragmentu strony…
Na temat podatności WP ostatnio można znaleźć sporo artykułów. I pojawia się myśl, że tam są tyle dziur, że ich nie mogą załatać. :)
System się rozrasta, do tego ostatnio spore zmiany w silniku (nowe funkcje, choćby rozbudowa API) to zawsze coś… Ważne, że ewentualne błędy są zauważane i szybko naprawiane. Ten o którym jest artykuł to zresztą nie tyle błąd związany z bezpieczeństwem, co bardziej ewentualny atak „na wydajność” z wykorzystaniem standardowych mechanizmów WP.