Un ghid definitiv despre XMLRPC pentru WordPress (+ Cum se dezactivează)

Securitatea site-ului web este un lucru greu de rezolvat în mod corect . În special cu problemele de securitate legate de XML-RPC – așa cum sunt exploatate în mod obișnuit în atacurile asupra site-urilor WordPress. Există o mulțime de informații disponibile pe internet care oferă tot felul de soluții, dar care sunt corecte? Acest articol va explica cum, soluțiile existente și care este de fapt cea mai bună soluție. Să ne scufundăm!

XMLRPC este mai vechi decât WordPress însuși. Acest sistem a fost introdus în WordPress pentru a combate dilema conexiunii lente la internet, ajutând utilizatorii să scrie noi postări offline și apoi le-au încărcat pe server. Capacitatea de a conecta WordPress de la distanță cu alte aplicații a fost posibilă doar cu fișierul xmlrpc.php.

Chiar și unii dezvoltatori experimentați nu înțeleg pe deplin XMLRPC și amenințările de securitate asociate cu acesta. Este o posibilitate destul de mare ca site-ul/site-urile pe care le gestionați să aibă un fișier XMLRPC activ care necesită atenția dumneavoastră imediată, dar puteți executa un plan de acțiune eficient doar după ce știți cum este operat XMLRPC și care este cel mai bun mod de a-l gestiona în siguranță.

Deși WordPress are acum propriul API REST, fișierul xmlrpc.php este încă prezent în interiorul nucleului și este activat implicit, expunând site-ul WordPress la diferite atacuri cibernetice. În acest articol, vom afla cum se utilizează acest fișier, vulnerabilitățile asociate cu acesta și cum să gestionăm acest lucru fără a pune în pericol securitatea site-ului dvs.

Ce este un fișier xmlrpc.php?

În forma sa cea mai simplă, XML-RPC (Remote Procedure Call) a fost creat pentru comunicarea pe mai multe platforme. Acest protocol a folosit pentru a efectua apeluri de procedură utilizând HTTP ca transport și XML ca codificator. Clientul efectuează aceste apeluri trimițând o solicitare HTTP către server și primește răspunsul HTTP în schimb. XML-RPC invocă funcții prin cerere HTTP și apoi aceste funcții efectuează unele acțiuni și trimit răspunsuri codificate în schimb.

Să comparăm acest lucru cu un apel API REST pentru a înțelege pe deplin conceptul.

REST consumă parametri URL pentru a identifica resursele, în timp ce RPC utilizează parametrii de interogare pentru a furniza ca argumente ale funcției.

WordPress a folosit XMLRPC pentru a permite utilizatorilor săi să interacționeze cu site-ul lor de la distanță. Îl folosește în continuare pentru a-și alimenta aplicația mobilă și pentru a sprijini pluginuri precum JetPack, WooCommerce etc. Folosirea fișierului xmlrpc.php are dezavantajele sale, dar dezactivarea completă este singura soluție viabilă? Pentru a răspunde că trebuie mai întâi să ne uităm la vulnerabilitățile asociate cu acesta și care sunt soluțiile disponibile pentru a le evita.

Cât de vicioși pot fi hackerii cu fișierul xmlrpc.php?

Folosind XMLRPC, hackerii folosesc apelurile de procedură de la distanță (RPC) și invocă funcții pentru a prelua datele pe care le doresc. În majoritatea site-urilor WordPress, fișierul xmlrpc.php este ușor de urmărit și doar prin trimiterea de date XML arbitrare, hackerii controlează site-ul pentru a rula codul pe care l-au pregătit pentru a executa un anumit tip de atac.

Pentru a înțelege cum este compromis WordPress XMLRPC, să ne uităm la cele mai populare atacuri cibernetice asociate cu acesta.

Atacul Bruteforce

În atacul Bruteforce, hackerul încearcă să ghicească numele de utilizator și parola corecte executând numeroase încercări de conectare. Din păcate, un număr mare de site-uri WordPress folosesc parole de administrator slabe sau nu au niciun strat de securitate adăugat pentru a opri atacatorii. Acele site-uri sunt ușor compromise cu acest tip de atac.

Alții folosesc o parolă puternică și au, de asemenea, mecanisme de securitate, cum ar fi reCaptcha și blocarea IP automată, care este eficientă împotriva atacurilor cu forță brută, dar dacă hackerul decide să folosească XMLRPC; ea nici măcar nu are nevoie să acceseze administratorul WordPress.

Un instrument foarte comun de la Kali Linux, WPSCAN este folosit pentru a enumera toate numele de utilizator și, odată terminat, hackerii forțează parola folosind fișierul xmlrpc.php trimițând următoarea solicitare HTTP către site-ul victimei.

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>

În exemplul de mai sus, un hacker poate trimite mii de variații până când recuperează parola corectă.

Următorul răspuns este returnat împotriva cererii de mai sus. Răspunsul conține codul de eroare și un mesaj clar care afirmă că numele de utilizator și parola încercate au fost incorecte. Este o indicație clară care îi spune hackerului să încerce din nou până când parola corectă este potrivită.

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>

Răspunsul a returnat codul HTTP 200 și mesajul că numele de utilizator și parola furnizate au fost incorecte. Trecând prin canalul XMLRPC, un hacker nu trebuie să-și facă griji cu privire la reCaptchas sau să limiteze pluginurile încercărilor de autentificare. Ea poate continua să ruleze variațiile până când este preluată parola corectă.

Notă: atacurile Brute Force necesită resurse mari și cauzează, de asemenea, probleme de performanță. Procesul de încercare și eroare rulează într-o buclă pentru o perioadă mai lungă de timp, ceea ce vă poate menține serverul ocupat pentru a servi vizitatorii efectivi. Acest consum inutil de resurse face ca serverele să consume mai multă energie.

Atac DDoS

Distributed Denial of Service (DDoS) este unul dintre cele mai letale atacuri cibernetice care poate paraliza serverul prin lovirea lui cu sute și mii de solicitări simultane. Hackerii folosesc funcția de pingback a WordPress împreună cu fișierul xmlrpc.php pentru a executa astfel de atacuri.

În mod ideal, hackerul vizează punctul final sau o pagină care poate fi lovită de mai multe ori și durează mai mult să răspundă. În acest fel, o singură lovitură poate avea un impact maxim asupra resurselor serverului și, în cazul nostru, XMLRPC servește bine hackerului în expunerea unor astfel de puncte finale.

Mai multe site-uri WordPress deja compromise sunt folosite pentru a executa metoda pingback.ping pentru a viza o singură victimă. Solicitările copleșitoare HTTP GET și POST blochează traficul obișnuit și în cele din urmă blochează serverul.

Mai întâi, hackerul verifică dacă fișierul xmlrpc.php este activat sau nu, trimițând următoarea solicitare.

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>

Odată ce se confirmă că XMLRPC este activat pe site-ul țintă, atacatorul începe să-l lovească folosind rețeaua de site-uri exploatate pentru a trimite mai multe solicitări de pingback către un site victimă. Acest lucru poate fi automatizat de la mai multe gazde și poate fi folosit pentru a provoca un atac DDoS în masă pe site-ul victimei.

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>

Atac de porturi între site-uri (XSPA)

Cross-site Port Attacks (XSPA) sunt foarte frecvente în care hackerul injectează script-ul rău intenționat pentru a prelua informații despre porturile TCP și adresele IP. În cazul WordPress, XMLRPC este folosit împreună cu mecanismul său de pingback pentru a ocoli orice mascare IP, cum ar fi WAF de bază, cum ar fi Cloudflare.

Într-un atac XSPA, hackerul folosește metoda pingback.ping pentru a trimite ping-back la o postare pe un site web țintă, care trimite, în schimb, adresa IP ca răspuns. Hackerul folosește un sniffer pentru a crea punctul final pentru trimiterea pingback-ului și a unei adrese URL live a unei postări de blog.

Hackerii trimit următoarea cerere de pe serverul ei.

<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>

Dacă răspunsul conține faultCode și o valoare mai mare decât 0, înseamnă că portul este deschis pentru ca tu să începi să trimiți direct pachetele HTTP.

Metode ineficiente de blocare a atacurilor XMLRPC

Până în prezent, în articol, am stabilit că fișierul xmlrpc.php este predispus la unele atacuri cibernetice grave, cum ar fi DDoS, Bruteforce și Cross-site Port Attack, prin urmare, este esențial să îl gestionați corect pentru a bloca aceste atacuri. .

Prin ștergerea completă a XMLRPC

Puteți șterge pur și simplu fișierul XMLRPC care va face serverul dvs. să înceapă să arunce erori 404 oricui încearcă să îl acceseze. Dezavantajul acestei soluții este că fișierul va fi re-creat de fiecare dată când actualizați WordPress.

Prin dezactivarea completă a XMLRPC

Cealaltă opțiune mai viabilă este dezactivarea fișierului xmlrpc.php . Puteți face acest lucru prin simpla adăugare a blocului de cod în fișierul dvs. .htaccess . Asigurați-vă că faceți acest lucru înainte de regulile .htaccess care nu se schimbă niciodată adăugate de WordPress.

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

Acest lucru va dezactiva fișierul xmlrpc.php pentru fiecare aplicație sau serviciu care îl utilizează. Puteți lista albă o anumită adresă IP în cazul în care doriți totuși să accesați site-ul dvs. WordPress prin XMLRPC. Pentru aceasta, trebuie să adăugați următoarea comandă:

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

Pro

• Elimină riscurile ca XMLRPC să fie abuzat în atacurile cibernetice.
• Beneficii de performanță pe termen lung și economii la resursele serverului.

Contra

• Dezactivarea XMLRPC este aceeași cu dezactivarea accesului la distanță pentru aplicațiile care utilizează această versiune de acces la distanță. Aceasta înseamnă că Jetpack, aplicația mobilă WP sau orice altă soluție care se conectează cu site-ul dvs. WordPress prin XMLRPC nu se mai poate conecta la site-ul dvs.
• Nici codul vechi pentru aplicațiile personalizate ar putea să nu funcționeze.

De ce instalarea unui plugin de securitate vă dăunează de fapt site-ul

Utilizatorii WordPress se sprijină adesea pe pluginuri pentru orice caracteristică sau funcționalitate necesară, fără să se gândească prea mult la impactul lor asupra performanței site-ului. Există mai multe plugin-uri de securitate WordPress care promit să vă protejeze site-ul de problemele de securitate legate de XMLRPC, dar, în realitate, vă rănesc mai mult site-ul.

Iată câteva dintre motivele pentru care securizarea site-ului dvs. cu un plugin nu este cea mai bună alegere.

• Pluginurile de securitate sunt eficiente doar la nivel de aplicație și nu vă protejează serverul împotriva loviturilor.
• Aceștia adaugă cod inutil pe site-ul dvs., care reduce performanța acestuia și crește timpul până la primul octet (TTFB).
• Unele dintre aceste plugin-uri fac mai mult rău decât bine și sunt folosite de hackeri pentru a crea uși în spate către site-ul tău.
• Aceste pluginuri necesită o gestionare frecventă care adaugă mai multă sarcină de lucru.

Din evaluarea de mai sus, niciuna dintre opțiuni nu oferă o soluție ideală pentru a gestiona problema de securitate XMLRPC. Acest lucru ne duce la Accelerated Domains. Un serviciu care este creat pentru a rezolva probleme complexe legate de securitate și multe altele. Să ne uităm la modul în care Accelerated Domains poate rezolva în mod eficient problema XMLRPC pentru tine.

Cum Accelerated Domains gestionează problemele XMLRPC pentru clienții săi?

Accelerated Domains rezolvă probleme complexe de performanță, securitate și scalabilitate în cel mai eficient mod. Accelerated Domains oferă securitate gestionată la nivel de întreprindere care blochează orice tip de atacuri cibernetice, inclusiv cele asociate cu XMLRPC.

Motorul inteligent de securitate al Accelerated Domains se află în fața serverului și filtrează aproape 40% din tot traficul HTTP. Detectează chiar și cele mai sofisticate atacuri cibernetice la începutul cronologiei prin capacitățile sale euristice inteligente, alimentate de alimentarea continuă a datelor și de cunoștințele practice și analiza traficului Servebolt. Accelerated Domains își face magia fără a degrada în vreun fel performanța site-ului dvs. De fapt, o accelerează.

Motorul de securitate proactiv Accelerated Domains vă protejează automat site-ul de atacuri DDoS. Cu o capacitate de rețea de aproape 60 Tbps, este bine echipat pentru a rezista chiar și la unele dintre cele mai mari atacuri DDoS de pe internet. În mod similar, oferă un mecanism de apărare eficient împotriva atacurilor Bruteforce printr-o funcție de limitare automată a ratei în care numărul de cereri generate dintr-o singură sursă este identificat și limitat pentru a preveni activitățile rău intenționate.

Pro

• Accelerated Domains atenuează majoritatea vulnerabilităților de securitate asociate cu XMLRPC, deci nu este nevoie să-l dezactivați.
• Permite utilizatorului să folosească în continuare pluginuri precum Jetpack, aplicația WooCommerce și alte instrumente care depind de fișierul xmlrpc.php.
• Integrare fără probleme pe orice domeniu, deci nu este nevoie să modificați fișierul .htaccess .
• Nu este nevoie să instalați pluginuri suplimentare.

Contra

• Nu are niciunul.

Gânduri finale

Atacurile cibernetice devin din ce în ce mai sofisticate și, în calitate de webmaster și proprietar de afaceri, este vital să le înțelegeți și să cunoașteți instrumentele pentru a le întâlni. Majoritatea atacurilor sunt evitate printr-o abordare proactivă, cum ar fi monitorizarea constantă și actualizarea software-ului sau prin adăugarea de instrumente precum Accelerated Domains care fac toate acestea pe pilot automat. Odată activat, Accelerated Domains filtrează în mod inteligent traficul și ia acțiunile necesare acolo unde este necesar pentru a vă proteja serverul de origine și site-ul dvs. de atacuri cibernetice.