WordPress. Bezpieczeństwo 4- Co robić. Włamanie. Luki. Aktualizacje.

wordpress

Chwyciłem desperacko za logi co uznajmy za krok piąty. Logi serwera to pliki tekstowe zawierające zapisany cały ruch jaki odbywa się na stronie. Sprawdziłem przedział godzinowy, kiedy mogło dojść do ataku. Na kartce zapisałem godzinę 19:28. To godzina zauważenia zmian na stronie. Wcześniej na stronie byłem rano i jej zawartość wydawała mi się nietknięta. Zatem znałem przybliżony przedział godzinowy. Dzień wcześniej strona na pewno była nietknięta. Ten przykład pokazuje też jak ważne jest częste bywanie na swojej stronie. Otworzyłem logi i najpierw wpis po wpisie zacząłem analizować ruch jaki się tam odbywał. Szukałem najpierw nachalnych prób włamania metodą brute force, to daje ładną wiązankę płynących lawinowo zapytań z jednego adresu IP. Nie było tego. Szukałem prób włamu po wtyczkach i szablonach. Owszem takie były jak zawsze, ale żadna z odpytywanych w ciemno wtyczek nie istniała w moim systemie. Zamiast tego czyste regularne odwiedziny botów, znanych i nieznanych mi pojedynczych zapytań z różnych adresów IP ale nie niosące większych podejrzeń. (Trudno się dziwić, jak się okazało później podejrzane były tylko 4 linijki na przynajmniej 10.000). Cisza i pozorny spokój. Przewertowałem cały log linijka po linijce, co zajęło dobre pół godziny. Nic podejrzanego… Oczywiście gdyby włamanie nastąpiło na serwer logi też byłyby spalone i tego się zacząłem obawiać. Ale to jedyny punkt zaczepienia… Szukałem dalej aż dojechałem do samego końca. Do godziny ~19:28 czyli moich odwiedzin kiedy to zauważyłem atak (poznałem oczywiście po moim IP odnotowanym w logach w momencie wejścia na stronę).

Wróciłem do Google. Wrzuciłem do wyszukiwarki zapytanie ze słowami kluczowymi z wpisu na mojej stronie i moim oczom ukazała się długa na wiele tysięcy stron lista zainfekowanych stron, które nie zareagowały w porę i Google zindeksowało niechciane treści. Wiedziałem już że to plaga a nie jednorazowy incydent. Poszukiwania po odpowiednich słowach kluczowych zawiodły mnie do strony Sucuri, i artykułu Marca Alexandra Montpas. Firma Sucuri zajmuje się od dawna poprawą zabezpieczeń i wyszukiwaniem problemów wynikłych z włamań na strony internetowe oparte na WordPress. Opisał on dopiero co odkryty problem jakim jest luka w bezpieczeństwie do wersji WordPress-a 4.7.1 wraz z jego przyczyną. Czy to może być aż tak banalne – pomyślałem? Tak. Za pomocą wysłania do serwera odpowiednio skonstruowanego zapytania możemy umieścić na czyjejś stronie w dowolnym wpisie dowolną treść. Oczywiście bez włamywania się do jego panelu zarządzania, czysto w białych rękawiczkach!

Atak zaczyna się od odpytania specjalnego pliku kontrolującego posty /wp-json/wp/v2/posts/ tak poznajemy ID ostatniego posta. Później drugie zapytanie to wstrzyknięcie nowego kodu zamiast starej treści.

Natychmiast wróciłem od swojego loga serwerowego, wyszukałem próbę odpytania w/w miejsca i bingo. Dwie krótkie, czyste akcje podjęte z dwóch adresów IP. Kompletnie bez wysiłku… Krótki strzał i gotowe. Pobierz (GET), wstaw (POST) – tak to działa.

Zrzut ekranu z mojego loga w jaki sposób nastąpił atak tą metodą:

fragmenty logów serwera pokazujące moment ataku i sprawcę

Oba celnie zamieściły na mojej stronie niepożądane wpisy. Z tym, że jeden włamywacz nadpisał działania drugiego. Widać z tego jak wiele osób dorwało się do tej metody niemal prześcigając się w zamieszczaniu swoich wpisów na jak największej liczbie stron uważając że to taka dobra zabawa. Oba ataki dotyczyły tylko najnowszego posta. Zatem w historii wpisu widać obie udane próby wykorzystania w/w luki.
Rozwiązanie problemu jest proste i banalne – aktualizacja systemu WordPress do najnowszej wersji a przynajmniej 4.7.2 całkowicie rozwiązuje ryzyko związane z opisaną przeze mnie luką, co oczywiście od razu zastosowałem uprzednio przywróciwszy wszystko z kopii bezpieczeństwa offline, choć w tym przypadku szczęśliwie nie było to potrzebne.