Check Point VS Joomla!: bug sul sistema Jmail? Joomla Italia alza la voce

 

Qualche settimana fa abbiamo assistito ad un piccolo “batti e ribatti” tra Joomla, noto CMS e Check Point, azienda informatica; quest’ultima ha dichiarato che Joomla sarebbe afflitto da una falla che andrebbe a sfruttare il servizio di posta JMail, strumento per la comunicazione tra il CMS Joomla e l’utente che lo utilizza, il tutto per scopi di lucro. 

Ovviamente la risposta di Joomla non si è fatta attendere ma ripercorriamo tutto dal principio per capire cosa è successo:

in questo articolo l’azienda Check Point dichiara che Joomla sarebbe afflitto da un grosso bug di sicurezza che interessa il servizio email Jmail, ma scopriamo di cosa si tratta.

Vulnerabilità Joomla! nel corso degli anni

Vulnerabilità Joomla nel corso degli anni

Cos’è e come funziona il sistema di posta di Joomla JMail

Per chi non lo sapesse, Jmail è il servizio di posta di Joomla che consente all’utente di inviare email attraverso la piattaforma.

Sebbene questo servizio sia destinato ad inviare email per l’accesso alla piattaforma, cambio password etc, quando non dispone dei meccanismi di sicurezza appropriati può essere manipolato per l’utilizzato di pratiche illegali come il phishing, lo spam e persino per implementare alcune backdoor all’interno del CMS stesso.

Modificando l’intestazione User-Agent sulle richieste HTTP, si può manipolare la piattaforma e sovrascrivere il servizio Jmail esistente.

Check Point Research ha menzionato come autore della minaccia un certo Alarg53, il quale qualche anno fa, aveva bucato i server della Stanford University tramite una vulnerabilità di WordPress.

[adrotate banner=”1″]

Come funziona l’attacco di Alarg53

Come dicevamo, Alarg53 sfrutta l’object injection Remote Code execution (RCE), in cui il codice viene iniettato nel campo dell’intestazione User-Agent nelle richieste HTTP.

Nel nostro caso, l’utente inietta la stringa base64 nel campo User-Agent.

stringa base64 nel campo User-Agent

Stringa base64 nel campo User-Agent

Il codice PHP scarica quindi i file e li memorizza in un percorso specifico.

Una volta decodificato, viene trasformato in codice PHP eseguito sulla macchina della vittima.

Il codice tenta di scaricare file specifici e li memorizza in un percorso designato. In uno dei tentativi di download, il percorso designato è “./libraries/joomla/jmail.php”: il gestore email di Joomla.

Joomla! RCE

Joomla RCE

Sovrascrittura del servizio JMail

Il file che contiene codice HTML e PHP include due sezioni principali che comprendono due funzionalità: l’invio di posta e il caricamento di file. Una volta scaricato e archiviato, il file sovrascrive il servizio Joomla Jmail originale.

Sovrascrittura del servizio JMail

Sovrascrittura del servizio JMail

Sezione upload

Sezione upload

Una vera infrastruttura di backdoor e phishing

D’ora in poi questo file sarà in realtà una vera e propria infrastruttura in cui l’autore dell’attacco può caricare file e inviare email per i propri scopi: phishing e spam in primis. 

Esempio di attacco

Esempio di attacco

Chi c’è dietro l’attacco?

L’azienda CheckPoint dichiara che dietro a tutto ciò c’è un hacker denominato Alarg53.

Negli ultimi anni, Alarg non solo ha provato ad hackerare siti Web, ma ha anche provato a creare un’infrastruttura di phishing e spamming. Due anni fa lo stesso autore ottenne l’attenzione di tutto il mondo attaccando The Biology of Aging Center sul sito web della Stanford University.

Inizialmente, si pensava che fosse solo un altro attacco “Hacked By Alarg53”, ma nel giro di poche ore, due file PHP sono stati caricati sui server consentendo loro di inviare grandi quantità di email di spam.

A seguire la schermata del sito bucato da Alarg53:

Hacked By Alarg53

Hacked By Alarg53

Ma chi è Alarg53?

Alarg53 è principalmente un hacktivist che ha bucato molti siti (circa 15 mila secondo la fonte) per sostenere la propria ideologia oltre che per la pura sfida dell’hacking. Di recente però ha iniziato a monetizzare le sue attività tramite gli attacchi di crittografia e l’infrastruttura di phishing.

I suoi attacchi hanno colpito molti paesi del mondo tra cui Stati Uniti, Messico, Portogallo, Regno Unito, Francia, India e Giappone. Sono state colpite anche molte industrie ma anche governi e banche.

La risposta di Joomla

Dopo la notizia pubblicata da Check Point Research di cui sopra, un comunicato ufficiale di Joomla Italia cerca di far ancora più luce sulla vicenda dichiarando sia che questa vulnerabilità è già stata risolta nel lontano dicembre 2015 quando è stato rilasciato un aggiornamento per Joomla 1.5, Joomla 2.5 e Joomla 3 oltre ad una patch dedicata, sia che ci sarebbero molte inesattezze sul comunicato Check Point.

Ovviamente Joomla NON presenta vulnerabilità di sicurezza nella classe Jmail.

Le versioni di PHP invece che sono ormai immuni dalla falla Jmail, se così la possiamo chiamare, sono:

  • PHP 5.4.45,
  • PHP 5.5.29;
  • PHP 5.6.13 e successive.

Inoltre Joomla fa sapere che la vulnerabilità è relativa a PHP, noto linguaggio di programmazione lato server, dove si sfrutterebbe questa falla per creare e salvare una backdoor e che il file menzionato nel report Check Point non fa parte del core di Joomla ma si tratterebbe di una copia della classe originale utilizzata dall’attaccante per nascondere una backdoor.

Joomla insomma fa sentire la sua voce, dichiarando successivamente che:

Il pattern descritto da Check Point è uno classico – dove un attaccante sfrutta una ben nota vulnerabilità di sicurezza. Questa vulnerabilità è più vecchia di 3 anni e deriva da una vulnerabilità di sicurezza riscontrata in PHP, più che nel core di Joomla. Ulteriori informazioni a riguardo sono disponibili:

Il comunicato di Joomla poi continua dicendo:

Sfruttando questa vulnerabilità, un attaccante può caricare nel sito una backdoor che può essere utilizzata per attività malevole. Per nascondere meglio la backdoor, gli attaccanti spesso utilizzano copie di file dell’applicazione reale (in questo caso una copia della classe di invio mail di Joomla) per integrare il loro codice malevolo. Queste copie non saranno mai utilizzate dall’esecuzione normale dell’applicazione, quindi non c’è un override (una sovrascrittura) come invece indicato nel report, è invece semplicemente utilizzato il file per nascondere la backdoor.

Conclusione

Insomma un “batti e ribatti” che di certo non fa bene agli utenti che continuano a sviluppare siti web proprio con questo CMS. Dal canto nostro però vogliamo dirvi una cosa: l’unico modo per evitare problemi è tenere aggiornati i CMS che state utilizzando e munirvi di un servizio di Backup che vi consenta di recuperare il sito in caso di problemi.

Per tenere aggiornati non intendiamo una vera e propria corsa all’aggiornamento come è successo per WordPress 5.0, ma aggiornare il CMS dando la possibilità agli sviluppatori di mettere al riparo le varie problematiche che, di solito, affliggono una qualunque nuova versione di un CMS, tenendo presenti le problematiche e stando attendi a quello che succede.

Ovviamente noi continueremo a tenere monitorata la situazione quindi non appena ci saranno novità a riguardo, vi faremo sapere.

Fonte 1, Fonte 2

Rispondi all'articolo

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *


Il periodo di verifica reCAPTCHA è scaduto. Ricaricare la pagina.