W ciągu ostatnich dwóch tygodni trafiło do nas kilka sklepów zainfekowanych przez podatność we wtyczce WooCommerce Dynamic Pricing and Discounts, więc warto chyba napisać o tym kilka słów.
Wtyczka WooCommerce Dynamic Pricing and Discounts pochodząca z Envato jest jedną z wielu tego typu wtyczek. Służy ona do ustalania dynamicznych rabatów i przecen dla produktów na podstawie różnych warunków. Trudno mi do końca powiedzieć, dlaczego ktoś miałby wybrać akurat tę wtyczkę, bo istnieje kilka świetnych darmowych alternatyw. Nie zmienia to jednak faktu, że wtyczka ta została kupiona prawie 20 tys. razy, więc jak na wtyczkę sklepową, jest dość popularna.
Wtyczka powstała w 2014 roku i przeglądając jej changelog, można odnieść wrażenie, że jest ciągle rozwijana, usprawniana i nie ma w niej prawie żadnych błędów. Opisy zmian są jednak bardzo lakoniczne, a to nigdy nie wróży niczego dobrego.
I tak po 7 latach istnienia wtyczki, 18 sierpnia wykryto w niej krytyczną podatność, która pozwala każdemu wykonać import ustawień. Nie wymaga to nawet zbyt wiele trudu.
Na czym polega ta podatność?
Autorzy wtyczki stworzyli mechanizm importu ustawień. Założyli jednak, że skoro opcja importu widoczna jest tylko dla administratora, to tylko administrator może z niej skorzystać. Kod odpowiadający za import (klasa RP_WCDPD_Settings, metoda __construct) wygląda tak:
Już ten fragment powinien budzić spore wątpliwości. Jeśli do serwera wysłany został jakiś plik w ramach określonej zmiennej, to automatycznie uruchamiana jest metoda importu. Znacznie lepiej już w tym kroku byłoby sprawdzać, czy aktualny użytkownik w ogóle ma prawo ów plik wysłać. A co zawiera metoda importująca? Może to ona zawiera wszelkie sprawdzenia?
Jak widać w powyższym kodzie – niestety brak tu jakichkolwiek sprawdzeń. Nie tylko nie jest sprawdzane, czy użytkownik ma uprawnienia do aktualizacji ustawień. Wtyczka nie sprawdza nawet, czy ktokolwiek jest w danej chwili zalogowany. Nie sprawdza też, czy przesłany plik w ogóle zawiera poprawne ustawienia wtyczki.
Jak ten błąd wykorzystują atakujący?
Wiemy już, że wystarczy wysłać request zawierający odpowiednio przygotowany plik, aby wtyczka nadpisała swoje ustawienia przygotowanymi przez nas. Już to jest w przypadku sklepu bardzo groźne, bo atakujący może dzięki temu wpływać na ceny. Może np. ustawić rabat 100% na wszystkie produkty.
Niestety wtyczka, jak wiele wtyczek z Envato, jest bardzo rozbudowana. Poza samymi rabatami, można m.in. ustawiać dodatkowe komunikaty. I tu pojawia się kolejna podatność. Komunikaty te nie są poprawnie escape’owane. I właśnie to połączenie dwóch błędów bezpieczeństwa wykorzystywane jest do ataków.
Na stronę wstrzykiwane są ustawienia, które zawierają kod JS. Kod ten jest następnie umieszczany na stronie i wykonywany w przeglądarce odwiedzających. W przypadkach, które trafiły do nas, JS używany był do przekierowywania użytkowników sklepu na inne strony. Natomiast nie zapominajmy, że wykonanie kodu JS w przeglądarce użytkownika, daje także inne możliwości (kradzież danych, modyfikacje i podsłuchiwanie wprowadzanych informacji, itp.).
Używam tej wtyczki. Co mam robić?
22 sierpnia wydana została poprawka, która częściowo poprawia błąd. W funkcji importującej dodane zostało sprawdzenie, czy aktualny użytkownik ma uprawnienia do modyfikowania ustawień strony.
Nie jest to niestety wystarczające i pełne zabezpieczenie. Owszem, aby przeprowadzić atak, trzeba teraz wykorzystać konto użytkownika z odpowiednimi uprawnieniami. Nadal możliwy jest jednak atak XSS. Jeśli zatem atakujący spreparuje odpowiedni request i wykona go z przeglądarki właściciela sklepu, to nadal będzie w stanie nadpisać ustawienia. Procedura ta jednak będzie wymagać już sporo więcej trudu.
Biorąc pod uwagę powyższe, sugerowałbym w pierwszej kolejności wykonać pilnie aktualizację wtyczki. W ten sposób niemożliwe będzie przeprowadzenie ataku przez każdego. W drugiej kolejności, już na spokojnie, radziłbym poszukać alternatywy dla tej wtyczki i jej zmianę.
Jeśli natomiast Twoja strona została już zainfekowana i zauważyłeś, że występują na niej przekierowania, konieczne będzie jej oczyszczenie. Zgłoś się do nas – pomożemy – usuniemy skutki ataku i zabezpieczymy stronę.
Jakie wnioski należałoby wyciągnąć z historii tej podatności i ataków?
Przede wszystkim taki, że nawet płatne wtyczki zawierają błędy (z moich doświadczeń znacznie częściej niż darmowe). Autorzy wtyczek często skupiają się na funkcjonalnościach i możliwościach, a nie na bezpieczeństwie. Funkcje są sexy. To nimi można się chwalić. To one sprzedają. Bezpieczeństwo? Kupujący nie zwracają na nie niestety uwagi, a autorzy wciąż popełniają podstawowe błędy.
Dlatego doboru wtyczek nie należy wykonywać jedynie na podstawie opisu funkcjonalności. Warto także przejrzeć ich changelogi, a wręcz ocenić jakość kodu. Tylko w ten sposób można mieć pewność, że dane rozwiązanie jest sprawdzone i bezpieczne.
Strony, które do nas trafiają, zaatakowane zostały dopiero na przełomie sierpnia i września. Czyli wtedy, gdy wydana już była poprawka. Jest to częste zjawisko, bo o błędzie wtyczki najprościej dowiedzieć się właśnie na podstawie poprawki tego błędu. Przed infekcją można było się zatem prosto uchronić. Wystarczyło na bieżąco aktualizować wtyczki. Sytuacja ta pokazuje także (kolejny raz), dlaczego nie wystarczy wykonywać aktualizacji raz na jakiś czas.
Dlatego właśnie w ramach naszej usługi Opieki technicznej na bieżąco monitorujemy wtyczki i zmiany w ich kodzie. Pozwala to nam reagować na krytyczne podatności znacznie szybciej i zapobiegać ich wykorzystaniu. Wiemy też, jaka jest jakość kodu danej wtyczki i możemy sugerować zmianę lub ograniczyć ryzyko poprzez wprowadzenie dodatkowych poprawek.