VirtueMart e la vulnerabilità JUser, un hack facile facile

La vulnerabilità di Virtuemart

La vulnerabilità di VirtueMart™ qui trattata è davvero grave e riguarda tutte le versioni 2.x, spero che tutti ne siano al corrente ed abbiano provveduto ad aggiornare la loro piattaforma a versioni pari o superiori alla 2.6.10. Ma che è successo? Molto semplicemente, chi si registra in un e-commerce VirtueMart, può accedere al proprio profilo e trasformare il suo account in quello di 'Super User', e ciò può essere fatto senza bisogno di alcuna attrezzatura speciale, basta una qualsiasi estensione di debug dell'html installata nel vostro browser preferito.

Questo articolo è stato scritto subito dopo che l'hack è stato reso noto, per rispetto della sicurezza e del lavoro di tutti è stata rinviata la pubblicazione a novembre, in modo da lasciare il tempo di aggiornare i sistemi vulnerabili.

Il problema è dovuto all'uso per lo meno spensierato, ma ci torneremo in coda all'articolo, della classe JUser e dei suoi metodi. In particolare il codice di VirtueMart usa la classe JUser, come fanno parecchie estensioni, per aggiornare le informazioni dell'utente per la parte che riguarda Joomla!, ovvero l'autenticazione e la ACL dell'utente, poi gestisce le proprie informazioni aggiuntive (indirizzi). Fin qui tutto bene: è il comportamento corretto, tuttavia non è mai un comportamento saggio considerare sicuri i dati provenienti dal web, soprattutto quelli che non ci si aspetta.

I medoti bind() delle varie classi Jtable di Joomla, servono a 'legare' i dati che si inviano al sistema ad una tabella del database; tabella che può essere sia dell'estensione sia di Joomla. Ciò che è da ricordare è i citati metodi collegano i dati loro passati alla tabella relativa e basta la validazione è compito del programmatore.

 

Procediamo ora ad analizzare il codice. Nel controller relativo alla registrazione dell'utente di VirtueMart (VirtueMartControllerUser->saveData() in /components/com_virtuemart/controllers/user.php ) troviamo:

/*codice semplificato */
$data = JRequest::get('post');
$userModel = VmModel::getModel('user');
$ret = $userModel->store($data);
 

notate che alla variabile $data viene associato l'intero contenuto di $_POST senza alcuna verifica sul contenuto dello stesso!

ora verifichiamo in codice in VirtueMartModelUser->store(&$data,$checkToken = TRUE). ll file in questione, il model, è /administrator/components/com_virtuemart/models/user.php; il numero di linea può variare secondo la versione di VM che state usando.

Seguite il percorso di $data, e dopo qualche riga di codice troverete:

// Bind Joomla userdata
if (!$user->bind($data)) {
  foreach($user->getErrors() as $error) {
    vmError('user bind '.$error,JText::sprintf('COM_VIRTUEMART_USER_STORE_ERROR',$error));
  }
  $message = 'Couldnt bind data to joomla user';
  array('user'=>$user,'password'=>$data['password'],'message'=>$message,'newId'=>$newId,'success'=>false);
}

ed ecco fatto il pasticcio!

Tutti i dati che sono stati ricevuti dal canale $_POST (la form) sono inviati così come sono alla classe JUser e sono pronti per essere salvati nella tabella degli utenti di Joomla!. Quali dati, vi state chiedendo? Semplicemente il fatto che l'utente sia root e che appartenga al gruppo 'Super user' e per far ciò è bastato aggiungere due campi alla form di edit dei dati dell'utente VirtueMart.

Non commettete l'errore di pensare che per aggiungere due campi alla form, ovvero per aggiungere due dati a $_POST, bisogni accedere al server od essere hackers esperti per poter usare tool fantascientifici tipo cinematografia! Basta e avanza FireBug!

 

Ovviamente mi guarderò bene dal dire esattamente come si fa; non ho visto il codice su internet ed eviterò di pubblicarlo io, ma sappiate che qualunque programmatore degno di questo nome capisce come si realizza l'hack in meno di venti minuti e in meno di due diventa amministratore del vostro sito.

 

La soluzione alla vulnerabilità JUser->bind() in VirtueMart

Ovviamente la soluzione più semplice è aggiornare VM ad una versione successiva alla 2.6.10, e, sicuramente, non avevate bisogno che ve lo dicessi io.

Ma, nella mia esperienza, difficilmente un e-commerce VirtueMart esce così come è, e, anche quando così è stato, forse per esperienze non piacevoli, anche se magari ormai legate solo al passato, si ha paura ad aggiornare per il rischio di trovarsi con un sistema bloccato. E ciò è tanto più vero, quanto più sono distanti le versioni tra di loro o quanti più moduli si sono aggiunti o templates cambiati...

Riprendiamo il file prima visto (/administrator/components/com_virtuemart/models/user.php) e modifichiamo il codice nel modo seguente:

// Bind Joomla userdata
$safeData = array();
foreach(explode(',','name,username,email,password,password2') as $k){
  if(isset($data[$k])) $safeData[$k] = $data[$k];
}
if (!$user->bind($safeData)) {
  foreach($user->getErrors() as $error) {
    vmError('user bind '.$error,JText::sprintf('COM_VIRTUEMART_USER_STORE_ERROR',$error));
  }
  $message = 'Couldnt bind data to joomla user';
  array('user'=>$user,'password'=>$data['password'],'message'=>$message,'newId'=>$newId,'success'=>false);
}

Personalmente non ritengo che debba essere verificato se l'utente è un amministratore per passare, in tale caso, l'array $data originario, dato che non vedo per quale motivo VirtueMart dovrebbe modificare le impostazioni 'avanzate' (gruppo, ricezione mail, blocco, ...) degli utenti di Joomla: questo è un compito da eseguire con Joomla.

A questo punto l'iniezione di altri dati in $_POST non avrà più effetto, almeno sull'utente Joomla.

Non siete capaci di applicare la patch personalmente? rivolgetevi a noi: è uno dei nostri servizi.

 

La vulnerabilità JUser->bind() in generale

Sucuri.net ha scritto che la vulnerabilità in questione potrebbe trovarsi anche in altre estensioni, e non penso sia un caso, che, dopo la pubblicazione di questa vulnerabilità di VirtueMart, sono apparse diverse patch relative ad altri prodotti che prevedono la registrazione degli utenti. Tutte sicure, tutte insicure? Il consiglio, se avete un sito Joomla con estensioni che prevedono la registrazione utente, è di far leggere questo articolo al vostro IT di fiducia e fargli analizzare il vostro sito.

 

Un commento personale

Forse è da biasimare il comportamento di ambo le parti.

Sucuri.net ha reso disponibile l'hack, non tanto per concorrere allo sviluppo del programma, quanto per ribadire che gli utilizzatori del loro sistema a pagamento sono sicuri, e niente è meglio di qualche migliaia di siti bucati per rendere clamorosa la notizia e formidabile la pubblicità. Si sa: gli script kiddies sono sempre alla ricerca di hacks preparati da terzi, e non posso credere che gli esperti di questo team, di certo professionisti, non lo sappiano.

VirtueMart ha risposto scaricando la colpa a destra e sinistra, invece di assumersi le proprie responsabilità. Suvvia, un errore può capitare a tutti, soprattutto quando si scrive il codice con il tic-tac dell'orologio alle spalle, e nessun programmatore serio gliene avrebbe fatto una colpa. Certo è che, quando stai per inaugurare il nuovo prodotto con supporto a pagamento, essere beccati con uno dei bug più gravi e più facili da realizzare che si siano mai visti in Joomla non fa certo piacere. Io non posso però credere che gli sviluppatori di VM non sappiano che l'input debba sempre essere validato: chi ha presente i miei interventi di moderatore sul forum di Joomla Italia sa quanto poco io sia tollerante con chi scientemente ignora questi aspetti e pubblica codice insicuro.

Personalmente quanto trovo un bug del genere io scrivo una mail all'autore e basta, mi sembra il comportamento più corretto; se poi non ho risposta dall'autore provvedo a pubblicare un avviso, ma non pubblico mai il codice dell'hack. Vi consiglio lo stesso atteggiamento.

---

 

Anche questa volta ci siamo dedicati ad argomenti di sicurezza, se avete un sito con e-commerce virtuemart analizzate bene il codice o rivolgetevi al vostro IT, vi risparmierete delle belle sorprese.

happy coding

marco maria leoni