Ten tydzień mija nam pod znakiem ratowania stron, które padły ofiarą ataku wykorzystującego podatność we wtyczce ThemeGrill Demo Importer. Przyjrzyjmy się, jak do tego całego zamieszania doszło i pomyślmy, jak można się było uchronić.

Zacznijmy od początku. ThemeGrill to firma tworząca motywy. Ich wtyczka Demo Importer miała ponad 200 tys. aktywnych instalacji, a na początku lutego WebARX znalazł w niej podatność, która pozwala zresetować bazę danych i hasło administratora każdej stronie, która z tej wtyczki korzysta.

Jak doszło do tej podatności? Otóż jej przyczyna jest bardzo błacha – autorzy wtyczki zapomnieli o podstawowej zasadzie bezpieczeństwa – sprawdzaniu uprawnień przed wykonaniem akcji. Spójrzmy w jej kod, a dokładnie w metodę, która odpowiedzialna jest za zresetowanie zawartości strony:

ThemeGrill Demo Import - kod odpowiedzialny za podtaność

Problematyczny fragment kodu wtyczki pochodzący z pliku includes/class-demo-importer.php (wersja wtyczki 1.6.1)

Przycisk, który wywołuje daną akcję, umieszczony jest oczywiście w panelu administracyjnym. Programista zapewne założył zatem, że tylko administrator może tę akcję wykonać i jak widzimy, powyższy kod nigdzie nie próbuje nawet sprawdzać, czy użytkownik, który akcję wykonał, ma uprawnienia administratora. Czyli popełnił jeden z podstawowych błędów, o których opowiadałem już szerzej 5 lat temu w prezentacji “Bezpieczny kod – trzy łatwe kawałki”.

Metoda ta jest przez wtyczkę wykonywana zawsze, gdyż podpinana jest ona pod hook “admin_init”. Teoretycznie zatem, wykonywana jest jedynie w panelu administracyjnym – co i tak jest błędne, bo każdy użytkownik (niezależnie od roli) byłby w stanie zresetować bazę.

Na nieszczęście autorów wtyczki, hook “admin_init” wykonywany jest także podczas obsługi requestów AJAXowych. A to oznacza, że jeśli na stronie obecna jest ta wtyczka, to wystarczy wysłać do strony request AJAXowy z ustawionym parametrem “do_reset_wordpress”, a wtyczka posłusznie wykona nasze polecenie.

Czy dało się tego problemu uniknąć?

OK, programiści wtyczki popełnili błąd – zdarza się i, powiedzmy sobie szczerze, zdarzać się będzie, bo nikt nie jest nieomylny. Czy mogliśmy się jednak jakoś przed tym problemem uchronić?

Tak. I to na kilka sposobów, bo jeśli strona padła ofiarą tego ataku, to w dużej mierze jest to niestety wina Twoich zaniedbań.

Pilnuj aktualizacji

Zgodnie z timeline’em opublikowanym przez WebARX, podatność wykryta została 6 lutego i tego samego dnia została zgłoszona developerowi. Kolejny kontakt z developerem nastąpił 11 lutego, a dopiero 14 lutego przyszła od niego odpowiedź. 16 lutego opublikowana została poprawiona wersja wtyczki, a 18 lutego – artykuł opisujący tę podatność. 

Poprawka oznaczona była jako krytyczna i powinna zostać wykonana pilnie. Jeśli zatem jakaś strona została zaatakowana po 16 lutego, to jest to tylko i wyłącznie wina osób zarządzających tą stroną, gdyż nie wykonały one pilnej aktualizacji.

Jeśli nie masz pewności, które aktualizacje wykonywać trzeba pilnie, z którymi można poczekać, a które zdecydowanie trzeba odłożyć w czasie, to zapraszam do lektury artykułu “Aktualizować, zwlekać, ignorować?”, a zawsze możesz też powierzyć to zajęcie komuś i np. skorzystać z naszej usługi opieki technicznej.

Nie pozostawiaj wtyczek zadaniowych

Wtyczka Demo Importer, jak sama nazwa wskazuje, służy do importowania treści demo udostępnionych razem z motywem. Jest to zatem wtyczka, która w zasadzie nigdy nie powinna być użyta na produkcyjnej wersji strony, bo treści demo jedynie zaśmiecają bazę danych.

Jeśli jednak została ona użyta, to do niczego nie jest już później potrzebna. A skoro tak, to powinna zostać usunięta. Nawet, jeśli wtyczka nie miałaby podatności, to po co nam na stronie wtyczka, która pozwala jednym kliknięciem przycisku skasować całą bazę danych?

Niestety wykonując audyty stron dla klientów, często trafiam na różne wtyczki, które użyte były tylko do określonej, jednorazowej czynności, a potem nie zostały usunięte. A przecież całkiem nie tak dawno, do bardzo podobnej fali ataków na strony doprowadziła luka we wtyczce Duplicator – także wtyczce zadaniowej.

Rób kopie zapasowe

W przypadku tej podatności skutki infekcji są dość proste do usunięcia. Stosunkowo łatwo jest także stronę oczyścić i zabezpieczyć. Natomiast w przypadku kilku klientów borykaliśmy się z innym, dość prozaicznym problemem – brakiem backupów.

Sytuacja wyglądała zazwyczaj tak. Strona klienta została zaatakowana, zresetowana i zainfekowana (przy użyciu zresetowanego hasła administratora). Klient zauważył problem po 2-3 dniach.

I tu zgrzyt – okazało się bowiem, że baza danych została wyczyszczona, klient nie posiada żadnych backupów, a kopia zapasowa na hostingu… Owszem jest dostępna – ale tylko z poprzedniego dnia. Czyli baza danych w tej kopii także jest już pusta. I wtedy zaczyna się mailowanie z hostingiem, nerwy, proszenie, sprawdzanie, itd.

O ile spokojniejsza byłaby sytuacja, gdyby klient posiadał własne backupy strony z wczoraj, sprzed 3 dni, sprzed tygodnia, itd.?

Monitoruj poprawność działania strony

Powyższy problem z brakiem kopii zapasowej nie musi wystąpić, jeśli od razu zauważysz, że strona ma jakieś problemy i niezwłocznie zareagujesz.

W takim przypadku backup uda się jeszcze uzyskać. Natomiast rzadko się zdarza, że właściciel strony reaguje tak szybko. I to opóźnienie dodatkowo komplikuje sprawę.

Podatności są i będą, ale prawidłowe zabezpieczenie i utrzymanie strony może nas przed nimi uchronić

Jak widzisz, nawet proste błędy programistów mogą doprowadzić do bardzo poważnych skutków i zagrożeń dla strony. Jednak wystarczy świadomość i kilka nawyków, aby znacznie podnieść jej bezpieczeństwo. Jeśli natomiast szkoda Ci na to czasu lub nie chcesz się tego uczyć – powierz to zadanie specjalistom.