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.
Komentarze
Gratuluję;)
Tylko jedną gratulację?
A selinux jest nadal jedynie po to, żeby go wyłączać.
Serio?
Co ma selinux do błędu w aplikacji webowej?
BTW szkoda że z3s nie napisało o grsecurity.
SElinux rozdzieli konteksty serwera www i exima
To działa w 1 na 100000000000000 przypadków i nie ma się czym ekscytować.
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 :)
Nie wiem czy zauwazyles, ale podatne pole jest pole „Host”, ktorego maniupulacja zadziala tylko jesli serwis na wordpressie jest strona glowna serwera.
Wydaje mi się, czy to zadziała tylko jeśli WordPress jest na defaultowym vhoscie?
zawsze mozna probowac wywolac jakis blad w PHP, aby zdobyc info o sciezce do plikow wordpressa
Tak, tylko na defaultowym hoscie.
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.
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.
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.
Zawsze te dziury. WordPress to świetny system ze strony zarządzania treścią i jednak fatalny ze strony bezpieczeństwa.