Exploatările de vulnerabilitate ale API-ului REST WordPress continuă

Au trecut aproape două săptămâni de când echipa de securitate WordPress a dezvăluit o vulnerabilitate neautentificată de escaladare a privilegiilor într-un punct final API REST în 4.7 și 4.7.1. Vulnerabilitatea a fost corectată în tăcere, iar dezvăluirea a fost amânată cu o săptămână pentru a oferi proprietarilor de site-uri WordPress un avans în actualizarea la 4.7.2. Săptămâna trecută, sute de mii de site-uri vulnerabile au fost deja degradate, iar rapoartele de daune încă apar.

În weekend, atacurile au crescut, iar firmele de securitate WordPress au văzut mai multe încercări blocate de firewall-urile lor. Sucuri, firma de securitate a site-ului web care a raportat vulnerabilitatea la WordPress, urmărea campania „Hacked by w4l3XzY3” săptămâna trecută și a estimat 66.000 de deformari. Campania respectivă a trecut acum de 260.000 de pagini indexate de Google. Este una dintre cele aproape două duzini de campanii de deformare care vizează vulnerabilitatea.

„În ultimele 24 de ore, am observat o creștere medie a paginilor deteriorate per campanie de 44%”, a declarat CEO-ul Wordfence, Mark Maunder, vineri. „Numărul total de pagini deformate pentru toate aceste campanii, indexate de Google, a crescut de la 1.496.020 la 1.893.690. Aceasta reprezintă o creștere cu 26% a numărului total de pagini deteriorate în doar 24 de ore.”

Maunder a făcut referire la un grafic Google Trends, despre care a spus că demonstrează succesul pe care l-au avut campaniile de deformare în ultima săptămână. Creșterea a început în ziua în care WordPress a dezvăluit vulnerabilitatea.

Cu toate acestea, White Fir Design, o altă companie care oferă servicii de securitate, contestă afirmațiile Wordfence conform cărora 1,8 milioane de pagini au fost sparte. Cifra de aproximativ 2 milioane de pagini este citată în rapoarte de la BBC, The Enquirer, Ars Technica, CIO.com și alte publicații. White Fir Design susține că paginile piratate care au fost indexate de Google nu reprezintă o reprezentare exactă.

De asemenea, CTO Sucuri, Daniel Cid, nu este pe deplin de acord cu evaluarea situației făcută de Wordfence. După ce a făcut câteva cercetări în weekend, Sucuri estimează că peste 50.000 de site-uri piratate, cu 20-30 de pagini per site deteriorate. Acesta ar fi de aproximativ un milion în partea inferioară a estimării și variază până la 1,5 milioane.

Sucuri începe, de asemenea, să vadă încercări mai serioase asupra vulnerabilității API-ului REST sub formă de atacuri de execuție de cod la distanță (RCE) asupra site-urilor care folosesc pluginuri care permit execuția PHP din postări și pagini. O astfel de campanie încearcă să injecteze un PHP include să adauge conținut de pe un site compromis și apoi să injecteze o ușă din spate ascunsă în /wp-content/uploads.

„Defacerile nu oferă profituri economice, așa că probabil că va muri în curând”, a spus Cid. „Ceea ce vor rămâne sunt încercările de a executa comenzi (RCE), deoarece le oferă atacatorilor controlul deplin asupra unui site – și oferă mai multe modalități de monetizare – și SPAM SEO / link afiliat / injecții de anunțuri. Începem să vedem că acestea sunt încercate pe câteva site-uri și probabil că aceasta va fi direcția în care această vulnerabilitate va fi folosită greșit în următoarele zile, săptămâni și, eventual, luni.”

Hackerii vizează orice site-uri care nu s-au actualizat la 4.7.2 – nu pare să existe niciun model între ele. O privire rapidă asupra rezultatelor Google pentru cele mai active campanii arată că site-urile compromise includ bloguri, media, guvern, educație, sport, medical și site-uri tehnologice.

De ce API-ul REST este activat implicit

API-ul REST WordPress este activat în mod implicit, deoarece planul este ca mai multe funcționalități de administrator și plugin să se bazeze pe API-ul REST în viitor. După atacurile recente, mai mulți utilizatori au comentat divulgarea vulnerabilității pentru a întreba de ce este activată implicit.

„Problema de securitate se află într-o caracteristică pe care nu o folosesc pe niciunul dintre site-urile mele (API-ul REST) ​​și totuși, această caracteristică este mai întâi activată implicit, iar în al doilea rând, de la WordPress 4.7, aveți nevoie chiar de un plugin – care ar putea introduce probleme de securitate suplimentare – pentru a dezactiva funcția?” un utilizator (@helios2121) a comentat postarea. „Vă rog să vă regândiți abordarea cu privire la securitate. Creați funcții pentru care nu toată lumea are nevoie de înscriere. Sau cel puțin oferiți o modalitate de a renunța fără a necesita pluginuri suplimentare.”

Morten Rand-Hendriksen a deschis un bilet trac pentru a discuta despre dezactivarea API-ului REST în mod implicit și activarea acestuia numai atunci când administratorul site-ului o solicită sau o temă sau un plugin depinde de acesta.

Core Committer Sergey Biryukov a confirmat că planul este de a introduce mai multe funcționalități de bază care se bazează pe API-ul REST. „Oprirea API-ului REST este ca și cum ați dezactiva admin-ajax.php – ambele vă vor distruge site-ul”, a spus Biryukov.

Rand-Hendriksen a întrebat de ce punctele finale de conținut nu pot fi protejate implicit, permițând în același timp activarea implicită a API-ului REST în scopuri administrative. Un alt utilizator a întrebat de ce punctul final al utilizatorilor nu este protejat implicit (adică https://news.microsoft.com/wp-json/wp/v2/users sau https://www.obama.org/wp-json/wp /v2/users), ceea ce „face mai ușor ca niciodată obținerea tuturor numelor de utilizator” pe orice site folosind 4.7+.

„Dacă doriți cu adevărat să dezactivați API-ul REST pe site-urile dvs., aceasta este recomandarea noastră actuală: restricționați-l la utilizatorii autentificați”, a spus Core Committer James Nylen. „Cu toate acestea, dorim să creștem în continuare adoptarea și utilizarea API-ului REST și mă aștept ca chiar și această modificare să rupă din ce în ce mai multă funcționalitate WP pe măsură ce trece timpul, cum ar fi temele și încorporarile bazate pe API.”

Nylen recomandă pluginul Disable JSON API pentru cei care doresc să urmeze această recomandare pe site-urile care utilizează WordPress 4.7+. Pluginul are în prezent peste 10.000 de instalări active.

Echipa de securitate WordPress a lucrat cu sârguință pentru a atenua atacurile, ajutând gazdele și firmele de securitate să pună în aplicare protecții înainte ca problema să fie făcută publică. Cu toate acestea, dezvăluirea completă a vulnerabilității a fost îngropată pe blogul Make/Core, un site care nu este citit pe scară largă printre proprietarii obișnuiți de site-uri WordPress. Linkul către dezvăluire a fost publicat ca un addendum la postarea anterioară pe blogul de știri WordPress o săptămână mai târziu.

„Deși apreciez dezvăluirea responsabilă a acestei probleme și efortul de a o rezolva, sper că vă gândiți să faceți anunțuri viitoare printr-o nouă postare pe site-ul de știri WordPress, mai degrabă decât să adăugați o actualizare la o postare anterioară”, a comentat utilizatorul @johnrork cu privire la dezvăluirea oficială. „Probabil că nu sunt singurul care ar fi putut evita să fie compromis dacă acest lucru ar fi apărut miercuri ca un articol nou în cititorul meu RSS.”

Cei care au citit blogurile Make au avut un avans în repararea propriilor site-uri și/sau a site-urilor clienților lor. Cei care depind de blogul de știri WordPress pentru informații despre actualizările de securitate au citit probabil postarea când a fost publicată inițial și nu s-au mai întors să vadă actualizarea o săptămână mai târziu. O problemă atât de gravă a garantat transparența WordPress într-o nouă postare pe blogul său de știri. Acest lucru ar fi trimis, de asemenea, automat un tweet către mai mult de jumătate de milion de urmăritori pe contul oficial WordPress și pe contul Facebook care are peste un milion de aprecieri.

Din fericire, numărul de site-uri vulnerabile care au și pluginuri care ar putea permite atacatorilor să se apropie de această vulnerabilitate este un număr mult mai mic. Site-urile deformate sunt jenante, dar ușor de remediat. În majoritatea cazurilor, administratorii trebuie doar să actualizeze la 4.7.2 și să revină la cea mai recentă revizuire a postărilor deteriorate. Majoritatea proprietarilor de site-uri habar n-au cât de repede încep să apară exploit-urile după dezvăluirea publică, dar această situație a oferit un memento blând asupra importanței actualizării WordPress și a beneficiului de a lăsa actualizările automate activate.