Błędy w oprogramowaniu powinno się naprawiać możliwie najszybciej po ich wykryciu lub zgłoszeniu w ramach programów typu bug bounty. Niektóre błędy nie są aż tak poważne, np. ich praktyczne wykorzystanie jest mocno ograniczone. Jednym z takich błędów jest podatność w mechanizmie pingback w WordPress zgłoszona w styczniu 2017 roku. Jej opis jest jednak ciekawy i pozwala częściowo zapoznać się z działaniem najpopularniejszego systemu CMS od strony backendu.
Pingback służy do poinformowania administratora określonej witryny, że link do niej został umieszczony na innej (także opartej na WordPress), przykładowo jako komentarz. Za obsługę tego mechanizmu odpowiada plik wp-trackback.php. Opcja jest domyślnie włączona:
Do komunikacji pomiędzy serwisami WordPress wykorzystuje protokół XML-RPC. Pingback korzysta z metody (czyli funkcji działającej w kontekście obiektu) pingback.ping, która z kolei przyjmuje argumenty zawierające nazwy poszczególnych wpisów.
Takie zastosowanie już na podstawie opisu wydaje się ryzykowane. W istocie jest pewne zagrożenie, natomiast WordPress wykonuje odpowiednie sprawdzenia (funkcja wp_http_validate_url() w pliku wp-includes/http.php). Odrzuca w ten sposób adresy URL, które m.in. są rozwiązywane na lokalne adresy IP czy zawierają dane logowania:
- The destination can’t contain a username and password;
- The hostname must not contain the following characters: #:?[]
- The domain name should not point to a local or private IP address like 127.0.0.1, 192.168.*, etc.
- The destination port of the URL must be either 80, 443, or 8080.
W dalszym etapie na podstawie otrzymanego adresu jest tworzony ciąg w postaci tcp://host:port, który będzie poprawnie rozpoznawany przez interpreter języka PHP.
Generalnie cała walidacja po stronie WordPress jest jak najbardziej poprawna. Źródłem opisywanego błędu jest możliwość bardzo szybkiego zmiany adresu w DNS, na który wskazuje analizowana domena. W praktyce niezwykle trudno osiągnąć taki efekt, walidacja po stronie WP zajmuje dosłownie ułamki sekund, a czas propagacji DNS może być zdecydowanie dłuższy.
Autorzy opisu przyznają, że nie znają zastosowania tego „ataku”. Można ewentualnie próbować wykorzystać ten sposób w połączeniu z inną skuteczniejszą podatnością, aby cokolwiek osiągnąć. Natomiast przedstawiony typ błędu nosi nazwę time-of-check to time-of-use i jest warty przeanalizowania.
Możliwe, że większe zagrożenie stanowi plik xmlrpc.php. W skrajnych przypadkach może posłużyć do różnych ataków na serwis. Jeśli plik nie jest wykorzystywany (zwykle nie jest), warto zablokować do niego dostęp. Wystarczy połączyć się z serwerem (jeśli nie ma takiej możliwości, można użyć wtyczki File Manager) i na poziomie .htaccess zablokować dostęp:
<Files xmlrpc.php>
deny from all
</Files>
Spowoduje to zwrócenie kodu błędu 403:
curl -X POST http://site1.lan/xmlrpc.php
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at site1.lan Port 80</address>
</body></html>
Jeśli strona błędu 403 nie została zdefiniowana, można dodatkowo ustawić własną, zawierającą naszą treść. W tym celu dodaje się dyrektywę ErrorDocument 403 /<nazwa_strony>.
Na własnych serwerach możemy używać NGINX, gdzie blokada pliku xmlrpc.php może mieć postać:
location = /xmlrpc.php {
deny all;
}
