03.05.2017 | 21:05

Adam Haertle

Zdalne wykonanie kodu w WordPressie odkryte przez Polaka (tylko do wersji 4.7)

Pod kontrolą WordPressa działa przynajmniej co czwarta strona w internecie (w tym także nasza). Nasz rodak, Dawid Gołuński, odkrył i opublikował sposób na zdalne przejęcie kontroli nad każdym z tych serwisów.

Jeśli zarządzacie WordPressem i w tym roku nie instalowaliście jeszcze aktualizacji, to zróbcie teraz chwilkę przerwy w lekturze, aktualizujcie WordPressa do wersji 4.7.4 i dopiero później wróćcie do lektury. Jeśli tego nie zrobicie, to istnieje ryzyko, że zrobi to za Was ktoś inny… Poniżej opisujemy exploita na domyślną instalację WordPressa, opartego wyłącznie na czystym kodzie, bez żadnych wtyczek, w domyślnej wersji.

Stary – nowy błąd

W ostatniej Weekendowej Lekturze zeszłego roku linkowaliśmy do ciekawego błędu odkrytego przez naszego rodaka, Dawida Gołuńskiego. Błąd, umożliwiający zdalne, nieuwierzytelnione wykonanie dowolnego kodu istniał w popularnym skrypcie PHPMailer. Wówczas społeczność uznała, że błąd jest ciekawy i w niektórych warunkach możliwy do wykorzystania, jednak skala zagrożenia jest niewielka, ponieważ większość najpopularniejszego oprogramowania jak np. WordPress, choć korzysta z PHPMailera, to jednak nie poddaje się atakowi. Dawid jednak najwyraźniej nie należy do osób, które tak łatwo się poddają i właśnie ogłosił, że jednak znalazł sposób na wykonanie kodu na domyślnej instalacji WordPressa. Na szczęście dla większości administratorów blogów:

  • Dawid czekał dość długo z ujawnieniem błędu i metody jego wykorzystania,
  • Podatna na pewno jest wersja 4.6 i prawdopodobnie także inne do 4.7 włącznie,
  • Jeśli ktoś zaktualizował WordPressa w roku 2017 to może spać spokojnie.

Szczegóły ataku

Nie będziemy udawać, ze potrafimy go w 5 minut opisać tak, byście zrozumieli, co musiał zrobić Dawid, by WordPress poddał się jego atakowi. Przeczytajcie sami u źródła, bo nikt nie opisze tego lepiej od autora. My powiemy tylko, ze to – jak na nasze oko – wirtuozeria omijania wszelkich filtrów, walidatorów i innych zabezpieczeń. Dawid połączył błąd w PHPMailerze, omijając filtry WordPressa i walidację PHPMailera a także ograniczenia nagłówków HTTP, wykorzystał niszowy element RFC i wewnętrzne zmienne Exima by w końcu dojść do żądania o następującej treści:

POST /wordpress/wp-login.php?action=lostpassword HTTP/1.1
Host: xenial(tmp1 -be ${run{${substr{0}{1}{$spool_directory}}usr${substr{0}{1}{$spool_directory}}bin${substr{0}{1}{$spool_directory}}touch${substr{10}{1}{$tod_log}}${substr{0}{1}{$spool_directory}}tmp${substr{0}{1}{$spool_directory}}test}}  tmp2)
Content-Type: application/x-www-form-urlencoded
Content-Length: 56


user_login=admin&redirect_to=&wp-submit=Get+New+Password

To wystarczyło, by wykonać kod po stronie serwera. Dawid udostępnił także pełny PoC, dający zdalną powłokę na podatnym serwerze. Poniżej możecie zobaczyć działanie exploita w praktyce.

Jeśli w sieci istnieje niezałatany serwer WordPressa, to jest spora szansa, że w ciągu najbliższych godzin będzie już przejęty i załatany przez osoby trzecie. Pozostaje pogratulować Dawidowi i cieszyć się, że aktualizacje są już dostępne od paru miesięcy. Przy okazji warto także zajrzeć na ciekawy projekt Dawida – ExploitBox.io.

Powrót

Komentarze

  • 2017.05.03 21:46 w4cky

    Gratuluję;)

    Odpowiedz
    • 2017.05.07 00:15 Xn

      Tylko jedną gratulację?

      Odpowiedz
  • 2017.05.03 21:49 Birkoff

    A selinux jest nadal jedynie po to, żeby go wyłączać.

    Odpowiedz
    • 2017.05.04 09:19 Sebastian

      Serio?

      Co ma selinux do błędu w aplikacji webowej?

      BTW szkoda że z3s nie napisało o grsecurity.

      Odpowiedz
      • 2017.05.04 22:02 gen. Italia

        SElinux rozdzieli konteksty serwera www i exima

        Odpowiedz
  • 2017.05.03 23:07 Profesor

    To działa w 1 na 100000000000000 przypadków i nie ma się czym ekscytować.

    Odpowiedz
  • 2017.05.04 00:15 Mihel

    Działa bardzo ładnie :) i wcale nie 1 na 1000000 :) tyle wordpressow niezaktualizowanych :) a czasem sami tworcy stron na wordpress zabraniaja aktualizacji bo cos przestanie dzialac :)

    Odpowiedz
    • 2017.05.04 09:08 MIchal

      Nie wiem czy zauwazyles, ale podatne pole jest pole „Host”, ktorego maniupulacja zadziala tylko jesli serwis na wordpressie jest strona glowna serwera.

      Odpowiedz
  • 2017.05.04 06:01 Stefan

    Wydaje mi się, czy to zadziała tylko jeśli WordPress jest na defaultowym vhoscie?

    Odpowiedz
    • 2017.05.04 09:21 YozinBadzin

      zawsze mozna probowac wywolac jakis blad w PHP, aby zdobyc info o sciezce do plikow wordpressa

      Odpowiedz
    • 2017.05.04 10:08 Marcin

      Tak, tylko na defaultowym hoscie.

      Odpowiedz
    • 2017.05.04 14:53 Oleq

      1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.

      Odpowiedz
  • 2017.05.04 21:40 gen. Italia

    Zadziała wtedy, gdy exim działa na tej samej maszynie co webserver. Komendy są wstrzykiwane poprzez „exim -be”. W praktyce taka konfiguracja jest rzadko spotykana.

    Odpowiedz
  • 2017.05.05 09:24 m,dsklfnkdjf

    ja mam prosbe do tych wszystkich 'nie zainteresowanych’ jakoscia buga: znajdzcie 'tylko takiego’. pozniej piszcie debilne komencie.
    ktos siedzi nocami, kopie w kodzie a pozniej polaczkowe anonymołsy i tak okazują niesamowita wdziecznosc. idzcie szybko pobiegac.

    Odpowiedz
  • 2017.05.05 09:48 Janusz Kamiński

    Zawsze te dziury. WordPress to świetny system ze strony zarządzania treścią i jednak fatalny ze strony bezpieczeństwa.

    Odpowiedz

Zostaw odpowiedź do Mihel

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Zdalne wykonanie kodu w WordPressie odkryte przez Polaka (tylko do wersji 4.7)

Komentarze