Jeśli nie, to być może Wasza strona jest już wśród licznych „szczęśliwców”, którzy wygrali „darmową infekcję swojej strony” (a być może i komputerów swoich czytelników/użytkowników).
Spis treści w artykule
WordPress REST API i pierwsze ofiary
Jak można przeczytać na blogu Sucuri i zobaczyć w Google mamy już pierwsze ofiary – i to liczone w setkach tysięcy. Poniżej przykłady z Google tylko na 2 z kilku zapytań jakie można wyszukać:
223 000 + 28 200 wyników robi wrażenie, nawet jeśli uznać, że tylko część z nich to faktycznie zarażone strony…
Google Search Console Team
Dostałem też kilka wiadomości od Google Search Console Team, w których pojawia się „zachęta to pilnej aktualizacji” WordPressa:
Wykryliśmy, że Twoja witryna korzysta z WordPress 4.7.0 or 4.7.1, czyli starszej wersji WordPress. Nieaktualne lub pozbawione poprawek oprogramowanie może być celem ataku, a luki w jego zabezpieczeniach może wykorzystać złośliwe oprogramowanie, działając na szkodę potencjalnym gościom Twojej witryny. Zalecamy jak najszybciej zaktualizować oprogramowanie witryny.
Na szczęście – przynajmniej dla mnie – nie są to (już) witryny którymi aktualnie się zajmuję, a wiadomości dostałem, bo niektóre z nich zostały (nadal) na moim koncie Google Search Console (dawne Narzędzia dla Webmasterów, Google Webmasters Tools).
Na szczęście – tym razem dla byłych klientów – większość tych stron cały czas jest ukrytych za Cloudflare, dzięki czemu tym razem brak aktualizacji zapewne się im upiecze, przynajmniej jeśli chodzi o błąd związany z REST API.
WordPress REST API
Oddzielny akapit należy się dla ekipy odpowiedzialnej za WordPressa, i nie będą tym razem to podziękowania – rozumiem, że nowa odsłona REST API, jaka pojawiła się z WordPressem 4.7 to nowe możliwości, zwłaszcza w kontekście integracji z zewnętrznymi narzędziami, ale ten przypadek doskonale pokazuje, że wprowadzając tak potężne narzędzia warto się dobrze zastanowić. A już na pewno można było – przynajmniej na początku – dać to jako opcję do ręcznej aktywacji (ew. też jakąś regułę do wykorzystania w wp-config.php, by móc wyłączyć/zablokować REST API).
Oczywiście nie mam dostępu do statystyk, i nie wiem jaki procent użytkowników WordPressa faktycznie korzysta z REST API, ale wydaje mi się, że – przynajmniej na razie – korzysta z tego niewielka grupa użytkowników, a na pewno mniejsza niż Ci, co nie zaktualizowali swoich stron i teraz możemy na nich trafić choćby w Google (choć oczywiście też są winni, bo aktualizacja była, i to całkiem szybko, zanim zostały wykryte próby wykorzystania podatności).
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
Na początku zrobią złą wersję, padnie 1mln stron, a dalej oni odmawiają się od tych aktualizacji :_)
Wiesz, przy tak złożonym oprogramowaniu (CMSie) błędy się zdarzają, choć mogli REST API dać domyślnie wyłączone, z ew. informacją w panelu po aktualizacji, że jest taka „fajna nowość” i czy chcesz ją włączyć. Plus za szybką reakcję i aktualizację, choć niestety jak zawsze to najsłabszy okazał się czynnik ludzki – tym razem właściciele/obsługa stron, gdzie nie wykonano aktualizacji, ale i nie ma wdrożonej innej metody obrony (choćby wspomniane we wpisie Cloudflare, gdzie już jakiś czas temu została wdrożona ochrona przed tą podatnością). A z tego co widzę po swoim kanale RSS, to oberwało też kilka stron poruszających kwestie bardziej techniczne, gdzie z założenia można byłoby przypuszczać, że co jak co, ale przynajmniej aktualizacje są robione na bieżąco…
Dla tych co korzystają z wordpress polecam https://sucuri.net oraz polski odpowiednik https://webanti.com, skanery które potrafią wykryć jeśli ktoś podmieni stronę lub załaduje wirusa.
Niestety z tym nie jest aż tak fajnie, bo każde zabezpieczenie działające w skompromitowanym środowisku jest skuteczne na tyle, na ile pozwoli szkodnik – jeśli na naszej stronie (webserwerze) znajdzie się szkodliwy kod, to nie ma żadnych przeszkód, by ten kod modyfikował również działanie samych wtyczek zabezpieczających (nieraz widziałem tego typu przykłady, sam kiedyś testowałem, i to nie tylko kwestia WordPressa, ale ogólnie WWW).
Dlatego jeśli już, to powinien to być tylko jeden z elementów systemu zabezpieczeń. Sam preferuje np. Cloudflare, bo jest to usługa która działa między odwiedzający/atakującym a naszym (web)serwerem, a więc niejako niezależnie od tego co ew. dostało się na stronę. Do tego podstawowe – i często wystarczające – zabezpieczenia mamy zupełnie za darmo, i to dla dowolnej liczby stron.
Co do skutecznych alternatyw to testuje i jak narazie nie mam żadnych zastrzeżeń do ispectio.com .
Monitoruje zmiany w plikach na bieżąco więc mogę spać spokojnie :)
Z doświadczenia wiem, że najczęściej tego typu komentarze okazują się reklamą (SPAM) i zapewne i tym razem tak jest, a więc pozwolę sobie na wykazanie kilku problemów tego – potencjalnie reklamowanego – rozwiązania:
Być może mamy tu do czynienia z serwisem/narzędziem zewnętrznym (ne mam pojęcia, bo na stronie właściwie zero informacji na ten temat, a nie widzę powodu by zakładać tam choćby testowe konto, zwłaszcza że na start widzę, że „za darmo” jest tylko 14 dni), co może być akurat zaletą, ale wtedy taki serwis widzi tylko pliki wygenerowane przez webserwer, a więc HTML, CSS i JavaScript, bez wglądu w kod PHP.
Być może jest też jakaś wtyczka np. do WordPressa (strzelam, bo na stronie informacji właściwie zero…), która pozwala monitorować zmiany w plikach lokalnie, od strony webserwera, a więc jest też dostęp do plików PHP. Ale w takim przypadku taka wtyczka podatna jest zapewne na manipulację jak każda inna wtyczka tego typu, czyli zobaczy to co chcemy by zobaczyła, a nie zobaczy tego, co nie chcemy by zobaczyła.
Do tego w żywym systemie, który podlega ciągłym zmianą (aktualizacje samego WordPressa, jak i motywów i wtyczek) monitorowanie tylko zmian w plikach wydaje się bezcelowe, bo albo będziemy co chwilę dostawali fałszywe alarmy (po każdej aktualizacji), albo będziemy musieli dodać do wyjątków (niemonitorowane) odpowiednie foldery, co w przypadku choćby wspomnianego WordPressa oznacza dodanie właściwie wszystkich plików i folderów (aktualizacje wtyczek, motywów, samego WordPressa, czy zmiany w katalogu „upload”).
Dlatego jeśli już miałbym wybierać, to raczej wybrałbym jedno z wielu innych tego typu rozwiązań, często dostępnych bezpłatnie bez limitu czasu, nawet jeśli w wersji podstawowej, a do tego nie ograniczających swojego działania tylko do monitorowania zmian w plikach, a zarazem z odpowiednim stażem na rynku.
Ale życzę powodzenia, bo zawsze lepiej mieć więcej rozwiązań tego typu do wyboru niż mniej…
PS. Widzę, że jest dostępne jakieś konto demo, i nawet jakaś pomoc z jego poziomu – plus, może warto to jakoś mocniej zaakcentować na stronie…