Infatti sembra proprio che tutti i lavori fatti per irrobustire password e salt nella nuova 1.5 siano quantomeno discutibili. L'intelligente "scoperta" è stata fatta da Federico aka Sergetto un bravo e simpatico appassionato di informatica di Roma.

Innanzitutto è bene specificare che non si tratta di una vulnerabilità, joomla è attualmente molto sicuro, si tratta unicamente di un modo intelligente di sfuttarne una, nello specifico una sql injection.
Se joomla è sicuro, altrettanto non si può sempre dire per le migliaia di extensions che vagano nel web, per cui non è esclusa una vulnerabilità di questo tipo se non avete personalmente testato tutto ciò che avete aggiunto alla vostra versione di joomla base.
Diciamo appunto che partiamo da questo scenario:
joomla 1.5.x base con l'aggiunta di una extension vulnerabile a sql injection. L'abilitazione o meno della registrazione non inficia sulla riuscita. La possibilità o meno che il sistema mandi mail all'admin neppure.

La tabella in questione è la jos_users, sulla quale farò una query che mi restituirà la riga dell'amministratore.
A questo punto presumo che la password sia di quelle impossibili da decriptare, perchè l'admin non è uno sprovveduto, quindi come posso fare si è chiesto sergetto?
Semplice se non banale.
Nella proceduta di cambio password non vi è differenza se appartiene all'admin o ad un user, e questo è il primo errore.
Non avendo a disposizione un pulsante per il recupero (il login è disabilitato e pure la registrazione) si sfrutta una parte di una vecchia falla di joomla, praticamente basta aggiungere la stringa index.php?option=com_user&view=reset.

Ci apparirà la pagina che ci chiede di inserire l'email della persona di cui si vuole cambiare (NON RECUPERARE) la password, dall'inj noi sappiamo qual'è quella dell'admin.
E' ovvio che hanno pensato ad una qualche sicurezza e comunque la mail viene inviata a quella mail, noi non la vedremo mai e non potremo vedere il codice che viene inviato all'admin.

Quel codice che si chiama "activation" deve essere inserito per avere accesso alla form di cambio password, come lo recuperiamo? Anche qui ...banale...
Ripetiamo l'injection sulla tabella jos_users e stavolta la riga dell'admin avrà un campo occupato in più: l'activation!
Basta inserirlo nel modulo e avremo accesso alla tanto sospirata pagina di inserimento della nuova password.
Siamo i nuovi admin!

Cosa serve l'[[MD5]]? Nulla! .....e complimenti Federico!

Ora la mia patch, da inserire in: dominio/components/com_user/models/reset.php

intorno alla riga 78 c'è questa query, trasformatela così:
{codecitation}$query = 'UPDATE #__users'
. ' SET activation = '.$db->Quote(md5($token))
. ' WHERE id = '.(int) $id
. ' AND block = 0';{/codecitation}

intorno alla riga 120 c'è questa query, trasformatela così:
{codecitation}$db->setQuery('SELECT id FROM #__users WHERE block = 0
AND activation = '.$db->Quote(md5($token)));{/codecitation}

Nel database verrà scritta criptata in md5, all'utente rimarrà il token originale non criptato che verrà trasformato per il paragone in md5 al momento della verifica.
Quindi anche recuperando la stringa dell'activation dal database sarà necessario decriptarla per inserirla nella form per l'autorizzazione al cambio password.

... fino ad idee più intelligenti, questa è la mia soluzione