Luka CSRF w popularnym dodatku Elementor do WordPressa. Wystarczy kliknąć w link, aby zdobyć uprawnienia administratora

O WordPressie piszemy na łamach sekuraka na tyle często, że tym razem odpuścimy Wam fragment o tym jak bardzo jest ważny i przejdziemy od razu do rzeczy. W popularnym kreatorze stron dla WordPressa – Elementor Website Builder wykryto poważną podatność (CVSS 8.8) typu Cross-Site-Request-Forgery (CSRF). Na chwilę obecną nie otrzymała jeszcze identyfikatora CVE.

TLDR:

• Luka występuje w popularnym dodatku Elementor Website Builder w wersjach 4.3.0 i 4.3.1.
• Błąd wynika z niepoprawnej weryfikacji żądań w module Editor Events. Jeżeli w dowolnym miejscu w adresie URL pojawi się ciąg elementor/v1/events/ serwer pomija sprawdzanie tokenu CSRF.
• W konsekwencji istnieje możliwość utworzenia nowego konta z uprawnieniami administratora.
• Jest jeden warunek: zalogowany użytkownik (najlepiej z uprawnieniami administratora) musi kliknąć w złośliwy link.
• Podatność została naprawiona w wersji 4.3.2.

Luka pozwala na wykonanie w kontekście sesji zalogowanego użytkownika dowolnej akcji w interfejsie REST API. Inaczej mówiąc, jedno niewinne kliknięcie w link może skutkować utworzeniem nowego konta administratora. Błąd występuje wyłącznie w wersjach 4.3.0 oraz 4.3.1. 

Najbardziej niepokojący jest fakt, że dziurawe wersje wtyczki mogą znajdować się na ponad 2 milionach stron internetowych (spośród ponad 10 milionów witryn ogółem korzystających z Elementora).

Jak informują analitycy z Patchstack, błąd występuje w module Editor Events, odpowiedzialnym za przesyłanie danych telemetrycznych. Twórcy zaimplementowali regułę wyłączającą sprawdzanie tokenu CSRF dla żądań REST API w przypadku, gdy w adresie URL pojawi się konkretny ciąg (elementor/v1/events/).

Deweloperzy zapewne założyli, że endpoint będzie służył wyłącznie do zbierania danych telemetrycznych i nie będzie wpływał na stan aplikacji (zmiana w bazie danych, tworzenie nowych użytkowników, usuwanie treści, itp.). W tej sytuacji dodatkowe sprawdzenie tokenu CSRF mogło zostać uznane za zbędne.

Popełnili jednak dosyć istotny błąd, ponieważ weryfikacja żądania nie skupiała się jedynie na konkretnym endpoincie lecz obejmowała całe REQUEST_URI razem z parametrem zapytania (query string) kontrolowanym przez atakującego. W efekcie możliwe było przygotowanie takiego adresu, aby dowolne żądanie REST API omijało weryfikację tokenu CSRF. 

W przypadku większości podatności CSRF w interfejsach REST API, atakujący musi skłonić ofiarę do odwiedzenia złośliwej strony, która w tle spowoduje wykonanie kodu JavaScript (np. przy użyciu funkcji fetch() lub automatycznie wysłanego formularza POST). W analizowanym przypadku sprawa wygląda inaczej.

Eksploit nie wymaga znajomości JavaScript ani dodatkowej witryny kontrolowanej przez atakującego. Wszystko za sprawą natywnego mechanizmu w rdzeniu WordPressa, który pozwala nadpisać metodę HTTP za pomocą parametru żądania _method. Dzięki temu zwykłe żądanie GET może zostać zinterpretowane jako POST. 

Poniżej przedstawiono przykład złośliwego żądania umożliwiającego utworzenie nowego użytkownika. Co ważne, aby eksploit zadziałał osoba klikająca w link musi być zalogowana oraz posiadać odpowiednie uprawnienia (np. administratora).

W efekcie cały atak mieści się w jednym adresie URL, a rola cyberprzestępcy sprowadza się do skłonienia administratora do kliknięcia w przesłany odnośnik.

W najnowszej wersji Elementora (4.3.2) deweloperzy naprawili błąd wdrażając rozbudowany mechanizm weryfikacji żadania (is_own_route_request()).

W pierwszym kroku następuje odczyt sparsowanej ścieżki (rest_route), pobranej ze zmiennej $wp->query_vars[‘rest_route’]. Ze ścieżki usunięto ciąg zapytania (query string), a co za tym idzie atakujący nie ma już możliwości wstrzyknięcia złośliwego ciągu w parametrze URL żądania. 

Następnie zmodyfikowano warunek sprawdzający czy ciąg elementor/v1/events/ znajduje się na samym początku ścieżki (wcześniej mógł się znajdować w dowolnym miejscu w URI). Dołożono również sprawdzenie typu (is_string), zabezpieczające przed przekazaniem parametru rest_route np. w formie tablicy, co mogłoby prowadzić do nieoczekiwanego zachowania serwera.

Ponieważ wersje Elementora starsze niż 4.3.0 nie zawierały jeszcze modułu Editor Events, problem ich nie dotyczy. W przypadku posiadania rozszerzenia w wersji 4.3.0 lub 4.3.1 zaleca się jak najszybszą aktualizację do wersji 4.3.2. Warto również sprawdzić, czy w panelu administracyjnym WordPressa (zakładka Użytkownicy) nie znajduje się konto użytkownika nieznanego pochodzenia.

Źródło: patchstack.com  

~_secmike