No i doczekaliśmy się – mamy pierwszą (jeśli tytuł ten należy się komu innemu, to piszcie w komentarzach) dużą podatność z polskiej wtyczce, a „nagroda” ta wędruje do Flexible Checkout Fields od WP Desku. Przyjrzyjmy się, z czego owa podatność wynikała, jak została wykorzystana do atakowania stron i co zrobić, jeśli Twoja strona została zaatakowana…
Sprawdzanie uprawnień, sanityzacja i walidacja
Dokładnie tak samo, jak w przypadku wtyczki ThemeGrill Demo Importer i tym razem przyczyna całego zamieszania jest prozaiczna – autorzy wtyczki zapomnieli o dobrych praktykach tworzenia bezpiecznego kodu i de facto polegli na tym samym szczególe, co zespół ThemeGrill.
Jeśli zajrzymy do pliku classes/settings.php wtyczki w wersji 2.3.1, to w okolicach wiersza 269, zobaczymy taki oto kod:
Problematyczny fragment kodu wtyczki pochodzący z pliku classes/settings.php (wersja wtyczki 2.3.1)
Zwróć uwagę na fakt, że w kodzie tym nigdzie nie ma sprawdzania uprawnień. Jeśli $_POST nie jest pusty i zawiera określone pola, to funkcja się wykona i zaktualizuje ustawienia wtyczki. Brzmi znajomo? Dodam zatem jeszcze, że metoda ta podpięta jest pod hook admin_init. Czyli, jak już wiemy z opisu błędu ThemeGrill, atakujący może stosunkowo łatwo sfałszować request i spowodować wykonanie tego fragmentu kodu.
Z opisu udostępnionego przez WP Desk na ich stronie wiemy, że dokładnie tak przebiegał atak. W pierwszej fazie atakujący przy użyciu powyższej podatności, wstrzykiwał na stronę złośliwy kod JS. Tu wychodzi drugi błąd wtyczki – nie zapewniała ona wystarczającej sanityzacji i walidacji danych pochodzących od użytkownika. Wtyczka ta nie powinna przecież pozwolić na wstawienie do bazy i wyświetlenie na stronie dowolnego kodu.
Po opublikowaniu na stronie kodu JS, atakujący uzyskiwał w zasadzie nieograniczony dostęp do strony. Za pomocą tego kodu mógł wykonać dowolną akcję w imieniu użytkownika, który się na stronę zalogował, wprost z przeglądarki tego użytkownika i z jego poświadczeniami uprawnień. Czyli np. po zalogowaniu się administratora, możliwe było utworzenie nowych kont, zainstalowanie dodatkowych wtyczek, itd.
Właśnie dlatego w kontekście bezpieczeństwa stron tak ważne jest, aby maksymalnie ograniczać możliwość umieszczania na stronie wszelkiego rodzaju skryptów JS, czy, o zgrozo, kodu PHP. Jeśli więc używasz na stronie wtyczek typu Code Snippets czy Insert Headers and Footers, musisz się liczyć z tym, że przy ich użyciu można na Twoją stronę wstrzyknąć złośliwy kod, a z jego pomocą dokonać ataku na stronę.
Wzorowa reakcja WP Desku
O ile trudno pochwalić ekipę WP Desku za samo zaistnienie tej podatności, o tyle za reakcję pochwała zdecydowanie się należy. Pierwsze sygnały o problemach zostały zgłoszone przez klientów rano 26 lutego i zespół od razu zajął się ich namierzaniem. W ciągu kilku godzin została wydana wersja 2.3.2 zawierająca poprawkę tej luki, a następnie kolejne 2 wersje z dodatkowymi usprawnieniami i zabezpieczeniami.
Na stronie WP Desku opublikowany został też artykuł informujący o podatności, tłumaczący spowodowane przez nią zagrożenie i nawołujący do pilnych aktualizacji.
I spóźnione reakcje użytkowników
Nieco gorzej ocenić należy natomiast reakcję użytkowników wtyczki, czy też właścicieli stron i osób zajmujących się ich utrzymaniem. Cały czas trafiają do nas zgłoszenia „dziwnego zachowania strony” lub „pojawiających się dziwnych użytkowników” i mało kto łączy te problemy z opisywaną tu podatnością, a niestety są to właśnie przypadki tego ataku.
Często słyszymy, że użytkownik stara się nie aktualizować wtyczek za często, bo potem „mogą być problemy”, albo bo nie ma na to czasu. Zdarza się też, że aktualizacjami zajmuje się osoba/firma odpowiedzialna za utrzymanie strony, ale według umowy aktualizacje wykonywane są raz na 2 tygodnie.
Jak widać – powyższe podejście do aktualizacji jest skrajnie niewystarczające w przypadku, gdy chodzi o krytyczne poprawki bezpieczeństwa. Właśnie dlatego tak istotne jest, aby utrzymując stronę, na bieżąco śledzić wszelkie aktualizacje i reagować zgodnie z potrzebami (część aktualizacji można odłożyć na później, a część trzeba wykonywać pilnie, bez zastanowienia).
Moja strona została zaatakowana. Co teraz?
Sugerowałbym nieco ostrzejsze podejście niż to, które zaproponował WP Desk w swoim artykule. Jeśli strona została zaatakowana i osoby trzecie mogły na niej osadzić własny kod PHP lub utworzyć użytkowników, to całą stronę należy uznać za skompromitowaną. Nie da się jednoznacznie stwierdzić, jakie operacje atakujący wykonał i jakie informacje o stronie posiada. Nie da się także łatwo określić, kiedy strona została zainfekowana – czyli przywracanie backupu będzie kłopotliwe.
Co zrobić, aby pozbyć się skutków ataku?
- Oczyść stronę i zapewnij, że nie zawiera ona żadnych backdoorów, dodatkowych ukrytych użytkowników, czy wklejek w bazie danych. Zapraszam oczywiście do skorzystania z naszej usługi czyszczenia stron po ataku.
- Wprowadź na stronie zabezpieczenia i ograniczenia dostępów.
- Zweryfikuj pozostałe wtyczki, które na stronie są używane. Jeśli np. wtyczki Flexible Checkout Fields używasz tylko do tego, by dodać na stronie pole NIP, to znacznie bezpieczniej będzie to pole dodać bezpośrednio z kodu.
- Zapewnij prawidłowe bieżące utrzymanie strony tak, aby tego typu podatności nie zostały wykorzystane przez atakujących w przyszłości. Jeśli nie masz na to czasu lub nie chcesz się tym zajmować – powierz opiekę nad stroną profesjonalistom.