Ostateczny przewodnik po XMLRPC dla WordPress (+ Jak to wyłączyć)

Bezpieczeństwo witryny to trudna sprawa do rozwiązania we właściwy sposób. W szczególności z kwestiami bezpieczeństwa związanymi z XML-RPC – co jest powszechnie wykorzystywane w atakach na witryny WordPress. W Internecie dostępnych jest wiele informacji, które zawierają wszelkiego rodzaju rozwiązania, ale które są poprawne? W tym artykule wyjaśnimy, w jaki sposób, dostępne rozwiązania i co jest najlepszym rozwiązaniem. Zanurzmy się!

XMLRPC jest starszy niż sam WordPress. Ten system został wprowadzony do WordPressa, aby walczyć z dylematem wolnego połączenia internetowego, pomagając użytkownikom pisać nowe posty offline, a następnie przesyłać je na serwer. Możliwość zdalnego połączenia WordPressa z innymi aplikacjami była możliwa tylko z plikiem xmlrpc.php.

Nawet niektórzy doświadczeni programiści nie rozumieją w pełni XMLRPC i związanych z nim zagrożeń bezpieczeństwa. Jest całkiem możliwe, że witryna/witryny, którymi zarządzasz, mają aktywny plik XMLRPC, który wymaga Twojej natychmiastowej uwagi, ale skuteczny plan działania możesz wykonać tylko po zapoznaniu się z obsługą XMLRPC i najlepszym sposobem na jego bezpieczną obsługę.

Chociaż WordPress ma teraz własne REST API, plik xmlrpc.php nadal znajduje się w rdzeniu i jest domyślnie włączony, narażając witrynę WordPress na różne cyberataki. W tym artykule dowiemy się, jak korzystać z tego pliku, jakie są związane z nim luki w zabezpieczeniach oraz jak sobie z tym poradzić bez narażania bezpieczeństwa witryny.

Co to jest plik xmlrpc.php?

W najprostszej formie XML-RPC (Remote Procedure Call) został stworzony do komunikacji międzyplatformowej. Ten protokół używany do wykonywania wywołań procedur przy użyciu HTTP jako transportu i XML jako kodera. Klient wykonuje te wywołania, wysyłając żądanie HTTP do serwera i otrzymuje w zamian odpowiedź HTTP. XML-RPC wywołuje funkcje za pośrednictwem żądania HTTP, a następnie te funkcje wykonują pewne czynności i w zamian wysyłają zakodowane odpowiedzi.

Porównajmy to z wywołaniem interfejsu API REST, aby w pełni zrozumieć koncepcję.

REST wykorzystuje parametry adresu URL do identyfikowania zasobów, podczas gdy RPC używa parametrów zapytania do dostarczania jako argumentów funkcji.

WordPress wykorzystał XMLRPC, aby umożliwić swoim użytkownikom zdalną interakcję z ich witryną. Nadal używa go do zasilania swojej aplikacji mobilnej i obsługi wtyczek, takich jak JetPack, WooCommerce itp. Korzystanie z pliku xmlrpc.php ma swoje wady, ale czy całkowite wyłączenie go jest jedynym realnym rozwiązaniem? Aby odpowiedzieć na to pytanie, najpierw musimy przyjrzeć się związanym z nim podatnościom i jakie są dostępne rozwiązania, aby ich uniknąć.

Jak złośliwi hakerzy mogą być z plikiem xmlrpc.php?

Korzystając z XMLRPC, hakerzy wykorzystują zdalne wywołania procedur (RPC) i wywołują funkcje, aby pobrać żądane dane. W większości witryn WordPress plik xmlrpc.php można łatwo prześledzić, a wysyłając dowolne dane XML, hakerzy kontrolują witrynę w celu uruchomienia kodu, który przygotowali do wykonania określonego rodzaju ataku.

Aby zrozumieć, w jaki sposób zagrożony jest WordPress XMLRPC, przyjrzyjmy się najpopularniejszym cyberatakom z tym związanym.

Brutalny atak

W ataku Bruteforce haker próbuje odgadnąć poprawną nazwę użytkownika i hasło, wykonując wiele prób logowania. Niestety, duża liczba witryn WordPress używa słabych haseł administratora lub nie ma dodanej warstwy bezpieczeństwa, aby powstrzymać atakujących. Te witryny są łatwo zagrożone tego typu atakiem.

Inni używają silnego hasła, a także mają mechanizmy bezpieczeństwa, takie jak reCaptcha i automatyczne blokowanie adresów IP, które jest skuteczne w przypadku ataków typu brute force, ale jeśli haker zdecyduje się użyć XMLRPC; nie musi nawet uzyskiwać dostępu do administratora WordPressa.

Bardzo popularne narzędzie z Kali Linux, WPSCAN służy do wyliczania wszystkich nazw użytkowników, a gdy to zrobi, hakerzy brutalnie wymuszają hasło za pomocą pliku xmlrpc.php , wysyłając następujące żądanie HTTP do ofiary.

POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

W powyższym przykładzie haker może wysyłać tysiące odmian, dopóki nie odzyska prawidłowego hasła.

Na powyższe żądanie zwracana jest następująca odpowiedź. Odpowiedź zawiera kod błędu i czytelny komunikat informujący, że wypróbowana nazwa użytkownika i hasło były nieprawidłowe. Jest to wyraźna wskazówka, która mówi hakerowi, aby spróbował ponownie, dopóki nie zostanie dopasowane prawidłowe hasło.

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

Odpowiedź zwróciła kod HTTP 200 oraz komunikat, że podana nazwa użytkownika i hasło są nieprawidłowe. Przechodząc przez kanał XMLRPC, haker nie musi się martwić o reCaptchas czy ograniczać wtyczki prób logowania. Może uruchamiać odmiany, dopóki nie zostanie odzyskane prawidłowe hasło.

Uwaga: Ataki Brute Force wymagają dużej ilości zasobów i powodują również problemy z wydajnością. Proces prób i błędów działa w pętli przez dłuższy czas, co może sprawić, że serwer będzie zajęty, aby obsłużyć rzeczywistych odwiedzających. To niepotrzebne zużycie zasobów powoduje, że serwery zużywają więcej energii.

Atak DDoS

Rozproszona odmowa usługi (DDoS) to jeden z najbardziej śmiertelnych cyberataków, który może sparaliżować serwer, uderzając go setkami tysięcy jednoczesnych żądań. Hakerzy wykorzystują funkcję pingback WordPress wraz z plikiem xmlrpc.php do przeprowadzania takich ataków.

W idealnym przypadku haker atakuje punkt końcowy lub stronę, na którą można trafić kilka razy, a reakcja trwa dłużej. W ten sposób pojedyncze trafienie może mieć maksymalny wpływ na zasoby serwera, aw naszym przypadku XMLRPC dobrze służy hakerowi w ujawnianiu takich punktów końcowych.

Kilka już zhakowanych witryn WordPress jest używanych do wykonania metody pingback.ping w celu zaatakowania pojedynczej ofiary. Przytłaczające żądania HTTP GET i POST blokują normalny ruch i ostatecznie powodują awarię serwera.

Najpierw haker sprawdza, czy plik xmlrpc.php jest włączony, czy nie, wysyłając następujące żądanie.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 175

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>

Po potwierdzeniu, że XMLRPC jest włączony na docelowej witrynie, atakujący zaczyna uderzać w nią, korzystając z sieci wykorzystywanych witryn, aby wysyłać wiele żądań pingback do witryny ofiary. Można to zautomatyzować z wielu hostów i wykorzystać do wywołania masowego ataku DDoS na zaatakowaną witrynę.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>

Atak między lokacjami na porty (XSPA)

Ataki między witrynami (XSPA) są bardzo powszechne, w których haker wstrzykuje złośliwy skrypt w celu pobrania informacji o portach TCP i adresach IP. W przypadku WordPressa XMLRPC jest używany wraz z mechanizmem pingback, aby ominąć wszelkie maskowanie IP, takie jak podstawowe WAF, takie jak Cloudflare.

W ataku XSPA haker wykorzystuje metodę pingback.ping do odpingowania posta na docelowej stronie internetowej, która w odpowiedzi wysyła adres IP. Haker używa sniffera do stworzenia punktu końcowego do wysyłania pingbacka i aktywnego adresu URL posta na blogu.

Hakerzy wysyłają następujące żądanie z jej serwera.

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

Jeśli odpowiedź zawiera errorCode i wartość większą niż 0, oznacza to, że port jest otwarty i możesz zacząć wysyłać pakiety HTTP bezpośrednio.

Nieskuteczne metody blokowania ataków XMLRPC

Jak dotąd w artykule ustaliliśmy, że plik xmlrpc.php jest podatny na poważne cyberataki, takie jak DDoS, Bruteforce i Cross-site Port Attack, dlatego ważne jest, aby odpowiednio się nim zająć, aby zablokować te ataki .

Całkowite usunięcie XMLRPC

Możesz po prostu usunąć plik XMLRPC, który sprawi, że Twój serwer zacznie zgłaszać błędy 404 każdemu, kto próbuje uzyskać do niego dostęp. Wadą tego rozwiązania jest to, że plik będzie odtwarzany za każdym razem, gdy aktualizujesz WordPress.

Całkowite wyłączenie XMLRPC

Inną bardziej realną opcją jest wyłączenie pliku xmlrpc.php . Możesz to zrobić, po prostu dodając blok kodu w pliku .htaccess . Upewnij się, że zrobisz to przed niezmiennymi regułami .htaccess dodanymi przez WordPress.

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

Spowoduje to wyłączenie pliku xmlrpc.php dla każdej aplikacji lub usługi, która go używa. Możesz umieścić na białej liście określony adres IP, jeśli nadal chcesz uzyskać dostęp do swojej witryny WordPress za pośrednictwem XMLRPC. W tym celu musisz dodać następujące polecenie:

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

Plusy

• Eliminuje ryzyko nadużyć XMLRPC w cyberatakach.
• Długoterminowe korzyści w zakresie wydajności i oszczędności na zasobach serwera.

Cons

• Wyłączenie XMLRPC jest takie samo jak wyłączenie dostępu zdalnego dla aplikacji korzystających z tej wersji dostępu zdalnego. Oznacza to, że Jetpack, aplikacja mobilna WP lub jakiekolwiek inne rozwiązanie, które łączy się z Twoją witryną WordPress za pośrednictwem XMLRPC, nie może już łączyć się z Twoją witryną.
• Starszy kod dla aplikacji niestandardowych również może nie działać.

Dlaczego instalacja wtyczki zabezpieczającej faktycznie szkodzi Twojej witrynie?

Użytkownicy WordPressa często opierają się na wtyczkach dla dowolnej wymaganej funkcji lub funkcjonalności, nie zastanawiając się zbytnio nad ich wpływem na wydajność witryny. Istnieje kilka wtyczek bezpieczeństwa WordPress, które obiecują zabezpieczyć Twoją witrynę przed problemami związanymi z bezpieczeństwem XMLRPC, ale w rzeczywistości bardziej szkodzą Twojej witrynie.

Oto kilka powodów, dla których zabezpieczenie witryny za pomocą wtyczki nie jest najlepszym wyborem.

• Wtyczki zabezpieczające działają tylko na poziomie aplikacji i nie chronią Twojego serwera przed trafieniem.
• Dodają niepotrzebny kod do Twojej witryny, który obniża jej wydajność i wydłuża czas do pierwszego bajtu (TTFB).
• Niektóre z tych wtyczek wyrządzają więcej szkody niż pożytku i są wykorzystywane przez hakerów do tworzenia tylnych drzwi do Twojej witryny.
• Te wtyczki wymagają częstego zarządzania, co zwiększa obciążenie pracą.

Z powyższej oceny żadna z opcji nie oferuje idealnego rozwiązania problemu bezpieczeństwa XMLRPC. To prowadzi nas do przyspieszonych domen. Usługa stworzona do rozwiązywania złożonych problemów związanych z bezpieczeństwem i nie tylko. Przyjrzyjmy się, jak Accelerated Domains może skutecznie rozwiązać problem XMLRPC.

Jak przyspieszone domeny rozwiązują problemy klientów z XMLRPC?

Accelerated Domains rozwiązuje złożone problemy z wydajnością, bezpieczeństwem i skalowalnością w najbardziej efektywny sposób. Accelerated Domains oferuje zarządzane zabezpieczenia na poziomie przedsiębiorstwa, które blokują wszelkiego rodzaju cyberataki, w tym te związane z XMLRPC.

Inteligentny silnik zabezpieczeń Accelerated Domains znajduje się przed serwerem i filtruje blisko 40% całego ruchu HTTP. Wykrywa nawet najbardziej wyrafinowane cyberataki na wczesnym etapie osi czasu dzięki inteligentnym funkcjom heurystycznym zasilanym przez ciągłe dostarczanie danych oraz praktyczną wiedzę i analizę ruchu Servebolt. Przyspieszone domeny wykonują swoją magię, nie obniżając w żaden sposób wydajności Twojej witryny. W rzeczywistości to przyspiesza.

Accelerated Domains Proactive Security Engine automatycznie chroni Twoją witrynę przed atakami DDoS. Dzięki przepustowości sieci wynoszącej prawie 60 Tb/s jest dobrze wyposażone, aby wytrzymać nawet niektóre z największych ataków DDoS w Internecie. Podobnie zapewnia skuteczny mechanizm obrony przed atakami Bruteforce poprzez funkcję automatycznego ograniczania szybkości, w której identyfikowana jest liczba żądań generowanych z jednego źródła i ograniczana w celu zapobiegania złośliwym działaniom.

Plusy

• Przyspieszone domeny łagodzą większość luk w zabezpieczeniach związanych z XMLRPC, dlatego nie trzeba go wyłączać.
• Pozwala użytkownikowi na dalsze korzystanie z wtyczek, takich jak Jetpack, aplikacja WooCommerce i innych narzędzi zależnych od pliku xmlrpc.php.
• Bezproblemowa integracja w dowolnej domenie, bez konieczności modyfikowania pliku .htaccess .
• Nie ma potrzeby instalowania dodatkowych wtyczek.

Cons

• Nie ma żadnego.

Końcowe przemyślenia

Cyberataki stają się coraz bardziej wyrafinowane z dnia na dzień, a jako webmaster i właściciel firmy bardzo ważne jest, abyś je zrozumiał i znał narzędzia, dzięki którym możesz się z nimi zmierzyć. Większości ataków można uniknąć dzięki proaktywnemu podejściu, takiemu jak ciągłe monitorowanie i aktualizacja oprogramowania lub dodanie narzędzi, takich jak Accelerated Domains, które robią to wszystko w trybie autopilota. Po włączeniu Accelerated Domains inteligentnie filtruje ruch i w razie potrzeby podejmuje niezbędne działania, aby chronić serwer pochodzenia i witrynę przed cyberatakami.