Continuano gli exploit di vulnerabilità dell'API REST di WordPress

Sono trascorse quasi due settimane da quando il team di sicurezza di WordPress ha rivelato una vulnerabilità di escalation dei privilegi non autenticata in un endpoint API REST in 4.7 e 4.7.1. La vulnerabilità è stata corretta in silenzio e la divulgazione è stata ritardata di una settimana per offrire ai proprietari di siti WordPress un vantaggio sull'aggiornamento alla 4.7.2. La scorsa settimana centinaia di migliaia di siti vulnerabili erano già stati deturpati e le segnalazioni sui danni sono ancora in arrivo.

Durante il fine settimana gli attacchi sono aumentati e le società di sicurezza di WordPress hanno visto più tentativi bloccati dai loro firewall. Sucuri, la società di sicurezza del sito Web che ha segnalato la vulnerabilità a WordPress, la scorsa settimana stava monitorando la campagna "Hacked by w4l3XzY3" e ha stimato 66.000 deturpazioni. Quella particolare campagna ha ora superato le 260.000 pagine indicizzate da Google. È una delle quasi due dozzine di campagne di deturpazione che prendono di mira la vulnerabilità.

"Nelle ultime 24 ore abbiamo assistito a una crescita media delle pagine cancellate per campagna del 44%", ha dichiarato venerdì il CEO di Wordfence Mark Maunder. “Il numero totale di pagine cancellate per tutte queste campagne, come indicizzato da Google, è passato da 1.496.020 a 1.893.690. Si tratta di un aumento del 26% del totale delle pagine cancellate in sole 24 ore".

Maunder ha fatto riferimento a un grafico di Google Trends che, secondo lui, dimostra il successo che le campagne di defacement hanno avuto nell'ultima settimana. Il picco è iniziato il giorno in cui WordPress ha rivelato la vulnerabilità.

Tuttavia, White Fir Design, un'altra società che offre servizi di sicurezza, contesta le affermazioni di Wordfence secondo cui 1,8 milioni di pagine sono state violate. La cifra di circa 2 milioni di pagine è citata nei rapporti di BBC, The Enquirer, Ars Technica, CIO.com e altre pubblicazioni. White Fir Design sostiene che le pagine compromesse che sono state indicizzate da Google non sono una rappresentazione accurata.

Anche il CTO di Sucuri Daniel Cid non è pienamente d'accordo con la valutazione della situazione di Wordfence. Dopo aver svolto alcune ricerche durante il fine settimana, Sucuri stima che oltre 50.000 siti violati con 20-30 pagine per sito deturpati. Questo sarebbe circa un milione all'estremità inferiore della stima e varia fino a 1,5 milioni.

Sucuri sta anche iniziando a vedere tentativi più seri sulla vulnerabilità dell'API REST sotto forma di attacchi RCE (Remote Code Execution) su siti che utilizzano plug-in che consentono l'esecuzione di PHP dall'interno di post e pagine. Una di queste campagne tenta di inserire un PHP include per aggiungere contenuto da un sito compromesso e quindi iniettare una backdoor nascosta in /wp-content/uploads.

"Le deturpazioni non offrono ritorni economici, quindi probabilmente moriranno presto", ha detto Cid. "Quello che rimarranno sono i tentativi di eseguire comandi (RCE) in quanto offre agli aggressori il pieno controllo di un sito - e offre diversi modi per monetizzare - e SPAM SEO / link di affiliazione / iniezioni di annunci. Stiamo iniziando a vederli tentati su alcuni siti e questa sarà probabilmente la direzione in cui questa vulnerabilità verrà utilizzata in modo improprio nei prossimi giorni, settimane e forse mesi".

Gli hacker prendono di mira tutti i siti che non sono stati aggiornati alla 4.7.2: non sembra esserci alcun modello tra di loro. Una rapida occhiata ai risultati di Google per le campagne più attive mostra che i siti compromessi includono blog, media, governo, istruzione, sport, medicina e siti Web di tecnologia.

Perché l'API REST è abilitata per impostazione predefinita

L'API REST di WordPress è abilitata per impostazione predefinita, poiché il piano prevede che più funzionalità di amministrazione e plug-in facciano affidamento sull'API REST in futuro. Dopo i recenti attacchi, diversi utenti hanno commentato la divulgazione della vulnerabilità per chiedere perché è abilitata per impostazione predefinita.

"Il problema di sicurezza è in una funzionalità che non utilizzo su nessuno dei miei siti (API REST) ​​e tuttavia, questa funzionalità è prima abilitata per impostazione predefinita e in secondo luogo da WordPress 4.7 è persino necessario un plug-in - che potrebbe introdurre ulteriori problemi di sicurezza - disabilitare la funzione?" un utente (@helios2121) ha commentato il post. “Per favore, ripensa al tuo approccio alla sicurezza. Crea funzionalità per le quali non tutti hanno bisogno del consenso. O almeno dare un modo per rinunciare senza richiedere plug-in aggiuntivi. "

Morten Rand-Hendriksen ha aperto un ticket di trac per discutere della disabilitazione dell'API REST per impostazione predefinita e dell'abilitazione solo quando l'amministratore del sito lo richiede o un tema o un plug-in dipende da esso.

Il core Committer Sergey Biryukov ha confermato che il piano è quello di introdurre più funzionalità di base che si basano sull'API REST. "Disattivare l'API REST è come disattivare admin-ajax.php: entrambi interromperanno il tuo sito", ha affermato Biryukov.

Rand-Hendriksen ha chiesto perché gli endpoint di contenuto non possono essere protetti per impostazione predefinita consentendo al contempo l'attivazione dell'API REST per impostazione predefinita per scopi di amministrazione. Un altro utente ha chiesto perché l'endpoint Utenti non è protetto per impostazione predefinita (ad esempio https://news.microsoft.com/wp-json/wp/v2/users o https://www.obama.org/wp-json/wp /v2/users), che "rende più facile che mai ottenere tutti i nomi utente" su qualsiasi sito utilizzando 4.7+.

"Se vuoi davvero disabilitare l'API REST sui tuoi siti, questa è la nostra attuale raccomandazione: limitala agli utenti autenticati", ha detto il core committente James Nylen. "Tuttavia, vogliamo continuare ad aumentare l'adozione e l'utilizzo dell'API REST e mi aspetto che anche questa modifica interromperà sempre più funzionalità WP con il passare del tempo, come temi e incorporamenti basati su API".

Nylen consiglia il plug-in Disable JSON API per coloro che desiderano seguire tale raccomandazione sui siti che utilizzano WordPress 4.7+. Il plugin ha attualmente più di 10.000 installazioni attive.

Il team di sicurezza di WordPress ha lavorato diligentemente per mitigare gli attacchi aiutando gli host e le società di sicurezza a mettere in atto le protezioni prima che il problema fosse reso pubblico. Tuttavia, la piena divulgazione della vulnerabilità è stata sepolta sul blog Make/Core, un sito che non è molto letto tra i normali proprietari di siti WordPress. Il collegamento alla divulgazione è stato pubblicato come aggiunta al post precedente sul blog di notizie di WordPress una settimana dopo.

"Anche se apprezzo la divulgazione responsabile di questo problema e lo sforzo per risolverlo, spero che tu consideri la possibilità di fare annunci futuri tramite un nuovo post sul sito WordPress News, piuttosto che aggiungere semplicemente un aggiornamento a un post precedente", ha commentato l'utente @johnrork sulla divulgazione ufficiale. "Probabilmente non sono l'unico che avrebbe potuto evitare di essere compromesso se questo fosse apparso come nuovo elemento nel mio lettore RSS mercoledì."

Coloro che hanno letto i blog di Make hanno avuto un vantaggio nel sistemare i propri siti e/o i siti dei propri clienti. Coloro che dipendono dal blog di notizie di WordPress per informazioni sugli aggiornamenti di sicurezza probabilmente hanno letto il post quando è stato pubblicato inizialmente e non sono mai tornati per vedere l'aggiornamento una settimana dopo. Un problema così grave ha garantito la trasparenza di WordPress in un nuovo post sul suo blog di notizie. Ciò avrebbe anche inviato automaticamente un tweet a più di mezzo milione di follower sull'account WordPress ufficiale e sull'account Facebook che ha più di un milione di Mi piace.

Fortunatamente, il numero di siti vulnerabili che dispongono anche di plug-in che potrebbero consentire agli aggressori di sfruttare questa vulnerabilità è un numero molto inferiore. I siti danneggiati sono imbarazzanti ma facili da riparare. Nella maggior parte dei casi gli amministratori devono solo aggiornare a 4.7.2 e ripristinare i post cancellati alla revisione più recente. La maggior parte dei proprietari di siti non ha idea di quanto velocemente inizino a comparire gli exploit dopo la divulgazione al pubblico, ma questa situazione ha fornito un gentile promemoria dell'importanza dell'aggiornamento di WordPress e del vantaggio di lasciare gli aggiornamenti automatici attivi.