Lis
13
2018

Setki stron przejętych przez dziurę we wtyczce WP GDPR Compliance. Jak wyglądał atak?

Wtyczka jest już załatana, ale na forach i grupach WordPressowych cały czas zgłaszają się osoby wystraszone faktem, że nagle ich strona przestała działać lub robi nie to, czego właściciel oczekuje. Nic dziwnego: po wejściu w życie RODO, WP GDPR Compliance stała się nagle jedną z najpopularniejszych wtyczek dobijając do ponad 100 tysięcy instalacji. A że w poprzednim tygodniu okazało się, że hakerzy taśmowo wykorzystują w niej podatność na atak, mamy takie a nie inne konsekwencje.

Aktualizacja: podobne włamanie może odbyć się także za pomocą wciąż nie załatanej wtyczki AMP for WP lub Kiwi Social Share, więc jeśli jej używacie, wyłączcie natychmiast (nawet jeśli autorzy udają, że używanie nie zagraża stronom)!

Symptomy ataku

Proces, w którym właściciel strony dowiadywał się, że jest zainfekowany, wyglądał mniej więcej zawsze tak samo:

  • właściciel strony budzi się rano i sprawdza pocztę email
  • w skrzynce odnajduje informację, że na jego stronie zarejestrował się nowy użytkownik
  • właściciel jest bardzo zdziwiony, bo przecież wyłączył (lub nigdy nie włączał) możliwości rejestracji, więc idzie na stronę by sprawdzić co się dzieje
  • okazuje się, że nie może zalogować się do panelu wp-admin
  • odwiedza główną stronę swojego bloga czy witryny i okazuje się ona zmieniona nie do poznania: albo od razu przekierowuje pod inne adresy, albo wyświetla zestaw linków do spamerskich stron albo robi mnóstwo innych rzeczy zamiast po prostu pokazywać (zgodny z RODO) serwis

Co się stało się?

Jak już wyżej wspomniałem, winna była dziurawa wtyczka WP GDPR Compliance (dziura została naprawiona wraz z wydaniem 1.4.3).

GDPR/RODO wymaga by użytkownicy strony mogli usuwać z niej dotyczące ich dane i wtyczka ta to umożliwia, ale nieprawidłowo sprawdzała co i kto chce usunąć.

Błąd dokładnie występował w kodzie aktualizującym zapisy w tabeli wp_options. Nawet niezalogowana osoba mogła przesłać do strony zapytanie proszące o zmianę dowolnego pola w tej tabeli.

Hakerzy więc zaczęli masowo wysyłać takie zapytania do stron, a dokładniej następujące dwa:

  • zapytanie zmieniające w tabeli wp_options pole users_can_register do wartości 1 (tak by włączyła się opcja umożliwiająca rejestrację użytkowników),
  • zapytanie zmieniające pole default_role do wartości „administrator” tak by każdy nowy użytkownik był tworzony z uprawnieniami administratora.

I dalej było już z górki (tak jakby powyższe było trudne dla włamywacza: tak naprawdę cały proces odbywał się w ciągu kilku sekund dzięki automatycznym skryptom przeczesującym sieć) – włamywacz rejestrował się na naszej stronie (to jest właśnie moment gdy otrzymywaliśmy emaila o rejestracji), kasował konta istniejących administratorów (to jest moment, po którym nie mogliśmy zalogować się do wp-admin) i instalował wszelki szkodliwy kod (to jest moment, w którym było już po naszej stronie).

OK, jak to wszystko odkręcić?

Jeśli twoja strona padła ofiarą takiego ataku i  ręczne jej przywracanie to dla ciebie czarna magia, możesz zlecić te zmiany na stronie WPzlecenia.pl

Jeśli jednak czujesz się na siłach, oto co musisz zrobić:

Tymczasowo ogranicz dostęp do swojej strony tylko do swojego adresu IP dodając następujący wpis do pliku .htaccess:

 # ALLOW USER BY IP
<limit GET POST>
 order deny,allow
 deny from all
 allow from 1.2.3.4
</limit>

(Zastąp 1.2.3.4 twoim adresem ip)

Nie jest to krok konieczny. ale warto go zrobić na wypadek jeśli włamywacz cały czas monitoruje automatycznie zarażone strony i w wypadku rozpoczęcia odzyskiwania, uruchamia także automatyczny kod ponownego przejęcia – cały proces ataku można zautomatyzować tak by wykonywał się w kilka sekund.

Następnie przywróć stronę z kopii zapasowej z ostatniego momentu, gdy wiesz, że strona działała prawidłowo. Przywróć nie tylko bazę danych, ale i wszystkie pliki strony – włamywacz na pewno pozostawił w dziesiątkach plików rootkity umożliwiające mu ponowne włamanie, nawet gdy nie masz już dziurawej wtyczki. Po przywróceniu strony upewnij się, że wciąż jest dodany przez ciebie kod do pliku .htaccess (lub dodaj go jeszcze raz)

Zaktualizuj wtyczkę WP GDPR Compliance do najnowszej wersji.

Upewnij się, że wszystko wygląda ok: nie masz dodatkowych użytkowników, a zapisy w tabeli wp_options nie pozwalają na automatyczną rejestrację administratorów.

Gdy już jesteś pewien/pewna, że wszystko jest ok, usuń dodany limit z pliku .htaccess.

Więcej szczegółow odnośnie ataku znajdziecie na stronie WordFence.


O autorze: Konrad Karpieszuk

Jak każdy chyba tutaj zacząłem po prostu od blogowania. WordPress jednak tak mnie zafascynował, że szybko zabrałem się za tworzenie stron na nim opartych. Później przyszedł czas na pisanie poradników z nim związanych, zdarzyła się nawet książka. Współorganizowałem pierwszy polski WordCamp. Opiekuję się serwisem WPzlecenia.pl, a teraz także tym podserwisem, na którym właśnie jesteście: dev.WPzlecenia. Wszystkim życzę jak najwięcej wyniesionej WIEDZY odnośnie WordPressa. Zaparzcie kawę, usiądźcie wygodnie i - do lektury! :)

Obecnie jestem pracownikiem firmy tworzącej wtyczkę WPML (pozwala tworzyć wielojęzykowe strony), gdzie odpowiadam za jej rozwój. Jestem także autorem bardzo popularnej wtyczki sklepowej TradeMatik

2 komentarze + Dodaj komentarz

  • Dobry artykuł, sporo ciekawych i aktualnych informacji :)

  • No i weekend z głowy;/

    W moim jednym przypadku w tabeli wp_options na samym początku był podmieniony url na pastebin

Zostaw komentarz

Uwaga, leci reklama:

Firefox jest znów szybki!

Gdzie nas czytać?

Autorzy »
Komentujący »
#wpzlecenia »