Manuel Roccon

ICT & Cyber Security Specialist

WordPress – plugin non aggiornati ci mettono a rischio

Broken Link Checker: Basta Link Rotti, con un Plugin WordPress

In questo post vedremo come un semplice plugin non aggiornato di WordPress possa aprire una serie di escalation di sicurezza tra cui aprire dei punti di accesso alla propria infrastruttura.

In molti casi l’aggiornamento di questi plugin è sotto valutato e con il tempo vengono scoperte sempre più falle che possono essere usate per intrufolarsi nei server che lo ospitano. In alcuni casi anche alle infrastrutture informatiche se l’ambiente risiede dentro all’infrastruttura aziendale.

Vediamo alcuni passi di una recente analisi di un installazione wordpress e come un malintenzionato potrebbe procedere nel individuare questi plugin e sfruttarli a proprio favore.

Per prima cosa è necessario analizzare la superfice d’attacco. Utilizziamo uno strumento per poter analizzare l’installazione di WordPress, in particolare useremo uno dei più famosi utility, wpscan. Oltretutto facendo un ulteriore analisi si è scoperto che il server ha un accesso a un gestore database, attualmente poco interessante, ma lo sarà nei punti successivi.

Ora però continuiamo con l’analisi dei plugin di WordPress.

Il tool analizzerà tutti i plugin e configurazioni alla ricerca di plugin vulnerabili, è necessario avere un api key per poter avere queste informazioni. Verificando attentamente l’output ci soffermiamo su un plugin particolare dove è indicato una vulnerabilità RCE unauthenticated.

Una vulnerabilità RCE (remote code execution) è una delle vulnerabilità più pericolose che esistano in quanto come dice l’acronimo permette di eseguire del codice remoto, oltretutto in aggiunta è indicato anche la possibilità di eseguire del codice senza essere autenticati, quindi perfetto come punto di attacco.

Oltretutto andando più a fondo, Aminer 4.6.2 soffrirebbe anch’esso di una vulnerabilità RCE, ma in questo caso non autenticata e in questo momento non avendo gli accessi non ci è utile.

https://podalirius.net/en/cves/2021-xxxxx/

Ora è necessario capire come sfruttarlo a nostro vantaggio, la cosa migliore è cercare su Google qualcuno che l’abbia già sfruttata o se esiste qualche PoC pubblicato su GitHub. Il PoC è uno script o procedura che spiega operativamente come sfruttarla, può essere uno script (di solito python) da modificare con i dati del sistema da attaccare per poi eseguirlo.

In questo caso però è già presente una documentazione completa per sfruttare questa vulnerabilità nelle referenze di wpscan.

https://sh3llcon.org/la-debilidad-de-wordpress/

La vulnerabiltà in questione permette di creare in una determinata path un file con del contenuto albitrario, ottimo per creare del contenuto php per poi far eseguire dal server web.

Non mi soffermo sulla spiegazione di come funziona la vulnerabilità in quanto il link fornisce già una descrizione esaustiva. Invece proviamo a verificare e sfruttarla.

Usando postman proviamo a verificare che effettivamente la vulnerabilità sia sfruttabile cercando di leggere la configurazione php.

Dopo aver effettuato la chiamata, la risposta conferma che è stato creato il file, ora occorre solo aprire il file creato seguendo il percorso indicato.

Boom! A questo punto abbiamo verificato che è possibile sfruttare la vulnerabilità per poter introdurre del codice da far eseguire al server, possiamo fare un’altra prova verificando se è possibile eseguire dei comandi della shell di Linux tramite php. Questo ci è utile per poter interagire direttamente con il server.

Ottimo, in questo caso abbiamo utilizzato la funzione exec di php per far eseguire il comando della shell del server pwd, che ci restituisce il percorso assoluto del file info.php nel server.

Ora avendo trovato e confermato il punto di accesso possiamo procedere in diversi modi. Possiamo tentare di aprire una reverse shell tramite la funzione exec dimostrato in precedenza, oppure possiamo cercare di leggere alcune informazioni interessanti di WordPress.

Avendo in precedenza scoperto un punto di accesso al database, proviamo a leggere il file di configurazione dove sono presenti le credenziali del database. In questo caso non utilizziamo exec ma passthrou in quanto exec restituisce solo la prima riga dell’output.

Ora analizziamo i possibili scenari possibili arrivati a questo punto:

Innanzi tutto avendo accesso al database potremmo resettare le password di amministratore per accedere all’istanza WordPress, ma essendo un sito istituzionale l’accesso è poco interessante. Ben diverso invece se dietro al sito ci fosse un e-commerce magari con il modulo woocomerce per cui potrebbe essere possibile cambiare le destinazioni dei pagamenti oppure modificare del codice per poter sottrare i dati di pagamento.

Un altro scenario possibile, avendo accesso al database (come nel nostro caso avendo accesso a Adminer) è quello di provare a decifrare le password dei vari account presenti. In questo caso sono presenti varie mail di accesso, questo non tanto per poi usare le credenziali per accesso a WordPress ma è solito in molti caso riutilizzare le stesse credenziali per molti servizi, se le password fossero uguali a quelle che gli utenti hanno nelle mail si potrebbe aprire un altra escalation, andando a cercare magari le loro webmail degli utenti e tentare di accederci.

L’ultimo scenario che avevo accennato potrebbe anche essere il più grave, se il nostro server che ospita WordPress è collocato all’interno dell’infrastruttura aziendale, in questo caso un attaccante può tentare di muoversi lateralmente su sistemi adiacenti.

Dopo aver visto questa casistica che può riguardare moltissimi plugin, il consiglio è tenere monitorati costantemente gli aggiornamenti dei plugin, utilizzare il più possibile aggiornamenti automatici o un sistema che lo faccia per voi (per esempio Plesk) e dotarsi di strumenti difensivi come firewall applicativi (WAF) su server o plugin similari come WordFence (che consiglio altamente).

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.