Wykryto krytyczny błąd w WordPress 5.1 pozwalający hackerom na zdalną egzekucję kodu (Remote Code Execution) bez uwierzytelnienia. 

Atakujący ma możliwość przejęcia strony, posiadającej system komentarzy, poprzez zwabienie administratora na specjalnie przygotowaną przez siebie wrogą stronę. Po wejściu na stronę-pułapkę wykorzystany zostaje cross-site request forger (CSRF) exploit.

Bug dotyczy wszystkich wersji starszych od 5.1.1, które zachowują wyjściową konfigurację. 

Analiza techniczna

WordPress nie przeprowadza walidacji CSRF podczas postowania na blogu - takie rozwiązanie zostało wymuszone poprzez niezgodność niektórych z funkcjonalności z walidacją. To oznacza, że atakujący, wykorzystując CSRF, mają możliwość dodania komentarza w imieniu administratora.

Staje się to niebezpieczne w połączeniu z cechą CMSa, która pozwala administratorowi używania dowolnych tagów HTML w komentarzach - łącznie z <script> . To prowadzi do możliwości użycia złośliwego kodu JavaScript w komentarzu. 

WordPress rozwiązuje ten problem generując specjalny numer nonce dla administratorów - system sprawdza czy komentarz zawiera prawidłowy nonce i w przypadku gdy tak nie jest przeprowadza walidację. 

Zwykłe komentarze poddawane są walidacji przez wp_filter_kses(). W wypadku komentarza administratora (który automatycznie posiada unfiltered_html), ale nie posiada poprawnego numeru nonce walidacja przeprowadzana jest przez wp_filter_post_kses(). Jak się okazuje jest różnica w obostrzeniach pomiędzy tymi dwiema funkcjami. Obje funkcje zostawiają tylko listę tagów, które mogą zostać użyte - ta druga daje więcej możliwości. To samo w sobie nie wystarcza by móc wykorzystać Cross-Site-Scripting. 

By tego dokonać wykorzystuje się tu sposób w jaki CMS parsuje atrybuty. Po skończeniu walidacji komentarza WordPress modyfikuje tagi znajdujące się w komentarzach pod optymalizacje SEO.

WP pobiera ciąg z tagu (np. href="#" title="tyrants" rel="nofollow") i zapisuje je w tablicy asocjacyjnej z parami nazw atrybutów i ich wartości.

WordPress sprawdza, czy atrybut rel jest ustawiony. Atrybut ten może być ustawiony jedynie, gdy komentarz jest przefiltrowany przez wp_filter_post_kses(). Jeśli jest relzostaje przeprocesowane i tag zostaje złożony w całość. 

Jak widać wyżej wartości atrybutów są składane w niebezpieczny sposób.

Atakujący ma możliwość wykorzystania tego konstruując złośliwy tag . Dla przykładu tag title może zostać ustawiony do title='XSS " onmouseover=alert(1) id="' - tak skonstruowany atrybut przejdzie walidację. Gdy atrybuty składane są w całość używany jest podwójny cytat. <a title='XSS " onmouseover=evilCode() id=" "> zostanie przeprocesowane do 

<a title "XSS " onmouseover=evilCode() id=" " przechodzi weryfikacje i ta procedura obsługi może zostać wykorzystana przez połączenie XSS z CSRF. 

Bezpośrednia egzekucja XSS poprzez iframe

Następnym krokiem by dokonać zdalnej egzekucji kodu jest sprawienie by JavaScript został odpalony przez administratora. Komentarz jest wyświetlony przez front-end WordPress'a, który nie jest zabezpieczony przez X-Frame-Options co oznacza, że może być wyświetlony w ukrytym <iframe>  na stronie atakującego. Zaaplikowany atrybut używa *onmouseover* co oznacza, że iframe automatycznie odpali złośliwy payload XSS. To pozwala na egzekucje dowolnego kodu JavaScript w sposób, który może być niemożliwy do zauważenia.

### Eskalacja wykonania kodu JavaScript do pełnej zdalnej egzekucji kodu
Przy możliwości użycia dowolnego kodu JavaScript osiągnięcie RCE jest proste. WordPress pozwala administratorom na bezpośrednią edycję plików .*php* motywów i pluginów z panelu administratora. Poprzez instalacje backdoor'a atakujący zdobywa pełną kontrole nad egzekucją kodu PHP na serwerze.