Luka w zabezpieczeniach Wordpress i Drupal może wyłączyć stronę internetową

Jeśli Twoja strona internetowa działa na własnej instalacji Wordpressa lub Drupala - natychmiast zaktualizuj oprogramowanie CMSa.

Badacz bezpieczeństwa - Nir Goldshlager - z zespołu bezpieczeństwa produktów salesforce.com odktył lukę bezpieczeństwa związaną z XML wpływającą na najpopularniejsze platformy do tworzenia stron internetowych: Wordpress i Drupal. Wykorzystuje ona atak XML Quadratic Blowup Attack, który w przypadku użycia może unieruchomić niemal natychmiast całą witrynę lub serwer ją utrzymujący.

Zagrożenie jest poważne, bo Wordpress i Drupal jest wykorzystywany przez miliony stron internetowych na całym świecie. Według najnowszych statystyk z W3Techs, sam tylko Wordpress posiada 23% udziału w rynku serwisów www.

Odkryta luka dotyczy Wordpressa w wersjach <=3.9.1 oraz Drupala w wersjach <=6.32 i <=7.30.

Dobrą wiadomością jest to, że zarówno twórcy WordPressa jak i Drupala wydali poprawki dla swoich aplikacji. Użytkownicy i dostawcy mający w swojej ofercie te CMSy wystarczy, że uaktualnią je do najnowszej wersji, aby ochronić się przed usterką.

Gdy luka jest wykorzystywana, to witryna lub serwer www stają się nie do użytku. Podatność może spowodować 100% użycia procesora i pamięci RAM, sprawia, że serwer staje się niedostępny, a także wywołać atak DoS do serwera bazy danych MySQL (jeśli nie stoi na tej samej maszynie).

Innymi słowy, Twoja strona i serwer mogą stać się całkowicie niedostępne.

Zagrożenie? Etyka odkrycia i wykorzystania luki

Ze względu na potencjalne zagrożenie w postaci wektora ataku, Goldshlager zadbał, aby w sposób odpowiedzialny ujawnić lukę do WordPressa i Drupala ich twórcom przed jej upublicznieniem.

Pozwoliło to na czas załatać twórcom swoje części oprogramowania, zanim usterka została wykorzystana na szeroką skalę.

Ze względu na charakter tego rodzaju ataku - oraz względną łatwość jego wykorzystania - reperkusje dla mnóstwa właścicieli stron internetowych mogły być ogromne (patrz statystyki wykorzystania Wordpressa).

Warto zauważyć, że twórcy WordPressa i Drupala pracowali razem nad tym problemem wspólnie planowali aktualizacje zabezpieczeń, aby były ze sobą zbieżne. Luka skierowana jest na moduł XML‑RPC w pliku WordPressa - Drupal używa jego zmodyfikowanej wersji - w związku z tym taka współpraca była jak najbardziej wskazana.

Jak działa atak?

Atak to bomba XML wrzucona na interfejs XML RPC obecny i używany przez oba CMSy.

Luka ta wykorzystuje tzw. XML Quadratic Blowup Attack. Jest on podobny do ataku Billion Laughs, który umożliwia, nawet bardzo małemu dokumentowi XML, całkowicie zakłócić usługi na serwerze w ciągu kilku sekund poprzez zagnieżdżanie innych obiektów w sobie. Jedno wywołanie powoduje wywołanie wielu innych obiektów i tym samym blokadę maszyny.

Natomiast XML Quadratic Blowup Attack opiera się na powtarzaniu jednego dużego obiektu (encji) z dziesiątkiem tysięcy znaków w kółko, w pętli, aż do wykorzystania wszystkich zasobów serwera.

W tego typu ataku, dokument XML o rozmiarze zaledwie kilkaset kilobajtów, może skończyć wywołanie wymagając setek megabajtów lub nawet gigabajtów pamięci RAM. W ten sposób można łatwo zablokować całą witrynę lub zablokować cały serwer.

Przykładowo, jeśli atakujący zdefiniuje obiekt o długości 55 000 znaków i odwoła się do niego 55 000 razy wewnątrz spreparowanego dokumentu XML, to w momencie jego wywołania nastąpi XML Quadratic Blowup attack, który przeładuje pamięć z 200 KB do ponad 2,5GB. To wystarczy do zabicia procesu parsowania lub często całej maszyny.

Wykorzystanie ataku

Atak wykorzystujący opisywaną lukę opiera się na domyślnych ustawieniach serwera. Domyślny limit dla alokacji pamięci w PHP to 128MB dla procesu. Teoretycznie powinno to skutecznie zablokować wszelkie próby ataku, prawda?

Niestety istnieje problem z Apache'm, najpopularniejszym na świece serwerem webowym (nginx czy lighhttpd są jeszcze daleko w tyle, a IIS nie liczę, bo jest jednoplatformowym webserverem).

Mianowicie Apache ma swoje Max Clients (maksymalna liczba jednoczesnych wywołań - procesów) ustawione domyślnie na 256. Do tego dochodzi baza danych MySQL, używana zarówno przez Drupala jak i Wordpressa, które domyślnie obsłuży 151 jednoczesnych połączeń (Max Connections).

Iloczyn minimalnych i domyślnych wartości 128MB x 151 połączeń daje = 19328MB (18,8GB), co z pewnością zapełni całą dostępną pamięć.

Oczywiście atakujący musi wcześniej poznać ustawione limity serwera ofiary, aby uczynić atak skutecznym. W przeciwnym razie nadpisanie limitów np. PHP spowoduje odrzucenie wywołania i skuteczną obronę przed atakiem.

W przypadku powodzenia ataku, wywołanie spowoduje wstrzyknięcie do pamięci nadmiarowych ilości danych, zapchanie serwera i w najlepszym wypadku zablokowanie strony, a w najgorszym zawieszenie fizycznej maszyny serwera i blokadę wielu innych usług - nie tylko witryny internetowej.

Odkrywca luki przygotował filmik prezentujący jak to wszystko działa: WordPress Denial Of Service PoC Video (niestety nie można umieszczać filmików spoza YT dlatego link do vimeo).

Jeśli używasz WordPressa czy Drupala, zaktualizuj go teraz!

Aktualizacja 10 sierpnia 2014

Zdaję sobie sprawę, że informacja o tej luce pojawiła się też na niebezpiecznym blogu o bezpieczeństwie, ale już wcześniej miałem przygotowany tekst wpisu i szkoda mi nie publikować. Hejterom dziękuję za wytykanie tego faktu :P