Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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 

internet bezpieczeństwo programowanie

Komentarze

0 nowych
Pangrys WSPÓŁPRACOWNIK  18 #1 11.08.2014 19:58

Wytykam :P

Dzięki za info :)

command-dos   17 #2 11.08.2014 20:03

faken szit - wp 3.9.2 też podatne?

SebaZ   15 #3 11.08.2014 20:08

@command-dos: 3.9.2 właśnie naprawia błąd, czyli mając 3.9.1 i starsze jesteś narażony

Indy   8 #4 11.08.2014 20:11

@command-dos: Nie, w 3.9.2 zostało to właśnie załatane http://codex.wordpress.org/Version_3.9.2
btw. gdzieś czytałem, że update'y 3.9.x miały się samodzielnie instalować. Trzeba to gdzieś włączyć?

command-dos   17 #5 11.08.2014 20:14

dzięki - tak dawno nie byłem w panelu, że nie wiem nawet, gdzie sprawdzić wersję wp ;) wygląda na to, że mam 3.4.2 O_o - jest to możliwe chłopaki?

SebaZ   15 #6 11.08.2014 20:14

@Indy: Tak, musisz mieć włączoną automatyczną aktualizację w panelu administracyjnym.

SebaZ   15 #7 11.08.2014 20:18

@command-dos: jeśli nie aktualizowałeś wcześniej...

command-dos   17 #8 11.08.2014 20:21

@SebaZ: może tak starych nie chwyta ;)

command-dos   17 #9 11.08.2014 20:28

dobra, poszło bezboleśnie (chyba) ;)

meta name="generator" content="WordPress 3.9.2"

Autor edytował komentarz.
  #10 11.08.2014 20:55

dzieki za info. juz naprawione :)

mktos   9 #11 11.08.2014 20:58

Można też rozważyć - jeśli nie jest to potrzebne - wyrzucić obsługę XML-RPC w Wordpressie, jest wtyczka "disable XML-RPC" (kiedyś była opcja w menu, ale wyrzucili).

Indy   8 #12 11.08.2014 21:07

@SebaZ: No chyba jednak nie ma specjalnej opcji z tym związanej. Teoretycznie od WP 3.7 powinno to być domyślnie włączone i można wyłączyć poprzez wp_config.php. Jednak żadna z moich stron na 3.9.1 sama się nie zaktualizowała. Może nie zdążyła?
Więcej na temat:
http://codex.wordpress.org/Configuring_Automatic_Background_Updates
Dodatek do sprawdzenia czy WP na serwerze może się sam aktualizować:
http://wordpress.org/plugins/background-update-tester/

SebaZ   15 #13 11.08.2014 21:20

@Indy: Nie jestem fanem Wordpressa, ani tym bardziej jakimś ekspertem, wiec nie będę się upierał, bo nie mam wiedzy na ten temat. Po prostu dziura dotyczy WP i Drupala to napisałem i o nim :P

Autor edytował komentarz.
Indy   8 #14 11.08.2014 21:24

@SebaZ: No to podrzucam nowy temat: automatyczne aktualizacje CMSów - złe czy dobre
:)

SebaZ   15 #15 11.08.2014 21:25

@Indy: Przeszedłem ten etap w życiu, żeby instalować każdy możliwy CMS i testować go :P Jakoś mi się nie chce :P

  #16 11.08.2014 22:40

wordpess i drupal dwa cms-y z którymi nie ma problemów z aktualizacją ... zresztą widać to w statystykach które zwiększają się na przewagę z joomli - tu to jest dopiero dziur ..

KyRol   17 #17 13.08.2014 11:34

No wpis taki spóźniony, bo info o łacie Drupal mi wysyłał już tydzień temu...

  #18 14.08.2014 21:34

Lighttpd*

cyryllo   16 #19 21.11.2014 18:54

@KyRol: Co z tego że stary. Ale może komuś się przyda info ;) Nie każdy zagląda na niebezpieczniki itp stronki ;)

KyRol   17 #20 22.11.2014 01:33

@cyryllo: No ja otrzymuje mailowe powiadomienia, skoro crontab działa, to trzeba go wykorzystywać ;)

AndroidFan   4 #21 05.09.2016 21:59

bardzo ciekawa metoda ale warto też wspomnieć że możemy w prosty sposób wyświetlać liczbę wszystkich użytkowników wordpress wystarczy tylko skorzystać z odpowiedniej wtyczki jak tu - download.net.pl/wordpress-zarejestrowani-uzytkownicy/n/8961/ i najzwyczajniej w świecie ustawić odpowiednie wyświetlanie za pomocą naszej strony