Dostępność xmlrpc.php

Dostępność xmlrpc.php to parametr monitoringu stron WordPress, który sprawdza, czy plik /xmlrpc.php przyjmuje wywołania XML-RPC, zamiast je odrzucać. Pomiar polega na wysłaniu zapytania o listę metod i kończy się jednym z trzech wyników: serwer zwraca listę metod, odrzuca wywołanie albo nie odpowiada w wyznaczonym czasie. XML-RPC to interfejs WordPressa do zdalnej pracy z witryną, który zastąpił starsze interfejsy Blogger, MovableType i metaWeblog ^[1].

Jak działa

Serwer XML-RPC w WordPressie przyjmuje wyłącznie żądania POST. Na żądanie innego typu odpowiada kodem 405, nagłówkiem Allow: POST i komunikatem, że obsługuje tylko POST ^[3]. Zwykłe otwarcie pliku metodą GET nie mówi więc, czy interfejs działa. Lista metod obejmuje przestrzenie wp., blogger., metaWeblog., mt. i pingback., a filtr xmlrpc_methods pozwala metody dodawać i usuwać ^[4]. Do tej listy serwer zawsze dokłada trzy metody systemowe: system.getCapabilities, system.listMethods i system.multicall ^[3].

Metoda system.multicall wykonuje w pętli tablicę wywołań przekazaną w jednym żądaniu HTTP. Kod nie ogranicza liczby wywołań w tablicy, blokuje jedynie zagnieżdżanie system.multicall w samym sobie ^[3]. Metody wymagające uwierzytelnienia przyjmują login i hasło w każdym wywołaniu i sprawdzają je funkcją logowania serwera ^[4].

RYS. 1.1system.multicall: wiele haseł w jednym żądaniu

Wyłączenie interfejsu bywa rozumiane zbyt szeroko. Filtr xmlrpc_enabled, dostępny od wersji 3.5.0 i domyślnie ustawiony na true, steruje tylko metodami wymagającymi uwierzytelnienia, na przykład publikowaniem ^[2]. Dokumentacja zaznacza, że filtr nie decyduje o pingbackach ani o innych metodach bez uwierzytelnienia ^[2]. Po jego wyłączeniu logowanie przez XML-RPC kończy się błędem 405 z komunikatem „XML-RPC services are disabled on this site” ^[4], ale plik nadal przyjmuje wywołania.

Standardy i specyfikacje

• XML-RPC WordPress API opisuje interfejs jako następcę API Blogger, MovableType i metaWeblog, z grupami metod dla wpisów, taksonomii, mediów, komentarzy, opcji i użytkowników ^[1].
• Filtr xmlrpc_enabled (od 3.5.0) włącza i wyłącza wyłącznie metody z uwierzytelnieniem ^[2].
• Serwer IXR w kodzie WordPressa odpowiada za obsługę tylko metody POST, metody systemowe i wykonywanie system.multicall ^[3].
• Metoda pingback.ping przyjmuje adres strony źródłowej i docelowej. Sprawdza, czy cel jest wpisem tej witryny z otwartymi pingami, a potem pobiera stronę źródłową z limitem 10 s, bez przekierowań, do 150 KB, z nagłówkiem X-Pingback-Forwarded-For zawierającym adres zlecającego ^[4].

Zagrożenia i skutki

Amplifikacja zgadywania haseł. W październiku 2015 roku Sucuri opisał ataki, w których jedno żądanie z system.multicall zawierało setki prób hasła. Trzy lub cztery żądania HTTP wystarczały na tysiące haseł i omijały narzędzia wykrywające zgadywanie haseł ^[5]. W większości ataków używano metody wp.getCategories, ale nadaje się do tego każda metoda wymagająca uwierzytelnienia ^[5]. Sucuri śledził te ataki od 10 września 2015 roku, a 7 października zanotował ok. 60 000 takich żądań ^[5]. Obecny kod rdzenia po pierwszym nieudanym uwierzytelnieniu oznacza instancję serwera i każdą kolejną próbę w tym samym żądaniu odrzuca bez sprawdzania hasła ^[4]. Jedno żądanie daje wtedy jedną próbę hasła, ale zgadywanie przez XML-RPC pojedynczymi żądaniami pozostaje możliwe.

Odbicie ruchu przez pingback. W marcu 2014 roku Sucuri naliczył ponad 162 000 legalnych stron WordPress, które w ciągu kilku godzin wzięły udział w ataku DDoS na jedną witrynę, generując setki żądań na sekundę ^[6]. Atakujący wysyłał do xmlrpc.php żądanie POST z metodą pingback.ping i adresem ofiary jako stroną źródłową, a strony pobierały ten adres ^[6]. W logach ofiary żądania miały w nagłówku User-Agent wersję WordPressa, a losowe parametry w adresie omijały pamięć podręczną ^[6]. Sucuri zaznaczył, że zachowanie nie zostanie poprawione, bo jest funkcją, z której korzystają wtyczki, i zalecił filtr usuwający pingback.ping z listy metod ^[6].

RYS. 1.2Pingback jako odbicie ruchu

SSRF przez pingback. CVE-2013-0235 dotyczy WordPressa przed wersją 3.5.1: spreparowany adres źródłowy pingbacku pozwalał wysyłać żądania HTTP do serwerów w sieci wewnętrznej i skanować porty ^[7]. CVE-2022-3590 opisuje ślepy SSRF w pingbacku bez uwierzytelnienia: wyścig między walidacją adresu a żądaniem HTTP pozwala dotrzeć do wewnętrznych hostów, które walidacja miała wykluczyć; NVD ocenia go na 5,9 w skali CVSS ^[8].

Przykłady

XML-RPC ma legalnych użytkowników. Jetpack łączy się przez ten protokół z WordPress.com, a zablokowanie pliku zrywa to połączenie ^[9]. Jetpack nie przesyła przy tym loginu i hasła, tylko używa tokenów podobnych do OAuth ^[9]. Aplikacja mobilna wymaga dostępnego punktu końcowego XML-RPC; część firm hostingowych i wtyczek bezpieczeństwa go blokuje, a obejściem jest logowanie kontem WordPress.com, gdy strona ma połączony Jetpack ^[10].

Konfiguracja	Odpowiedź na POST system.listMethods	Znaczenie
Instalacja domyślna [3] [4]	200 z listą metod, w tym system.multicall i pingback.ping	pełny interfejs
xmlrpc_enabled ustawione na false [2]	200 z listą metod	logowanie odrzucane kodem 405, pingback działa [4]
Filtr usuwający pingback.ping [6]	200 z listą bez pingbacku	brak odbicia, logowanie działa
Żądanie GET zamiast POST [3]	405 z Allow: POST	wynik bez znaczenia dla stanu interfejsu
Plik zablokowany przez hosting lub wtyczkę [10]	odmowa dostępu	Jetpack i aplikacja mobilna tracą połączenie [9]
WordPress przed 3.5.1 [7]	200 z pingback.ping	SSRF do sieci wewnętrznej