La storia ha inizio qualche mese fa, quando sono incominciati ad accadere misteriosi deface, incomprensibili cercando di ricostruire un probabile scenario. Quando non capisci nulla, l'unica cosa è cercare con google e provare. Così si è arrivati in breve tempo ad accorgersi di una cosa comune in quasi tutti i più famosi servizi di hosting italiano: caricando una shell sul proprio spazio e sfruttando la possibilità di eseguire comandi, con un semplice ls -l  era possibile scorrazzare per tutto il server che ospitava il nostro e gli altri siti.
Il limite era evidente, i permessi. Infatti pur potendo vedere i nomi dei files e delle cartelle non era possibile leggerne il contenuto, così se vedevo che sul mio stesso server c'era la home di pippo.it contenente il file config.php, non potevo comunque fare nulla, pur sapendo che quel file conteneva tutti i dati per poter accedere al servizio ftp e mysql.
Come è possibile che un hoster permetta comunque anche la sola visualizzazione dei files altrui non me lo so spiegare e chiederlo a loro, spesso, è fonte di inutili diatribe con supercevelloni che per definizione "sanno".

Le "dimostrazioni di potenza" di chi conosceva questa tecnica continuavano e anche siti come questo, molto controllato, subivano iniezione di codice un po' ovunque, database, index, etc.
Per accorgersi di quello che accadeva bisognava essere i possessori della macchina e spulciare per bene i log, secondo voi un hoster permette questo? Infatti i soli log di accesso, sentinel e ammennicoli vari a protezione dell'applicazione venivano beatamente skippati.
Finalmente, l'11 di novembre veniva pubblicata questa disclosure con poc allegato: PHP 5.2.12/5.3.1 symlink() open_basedir bypass
E questa è proprio la soluzione! Ciò che non era leggibile ora poteva diventarlo, come? Semplicemente creando un link simbolico tra un nostro fantomatico file ciccio.txt e l'altrui config.php.
Visitando ciccio.txt ottieni il print a video del contenuto del file config.php, contenente tutti i dati necessari per accedere come proprietario sullo spazio, sulla casella mail e sul database MySql... poco noo?

Nonostante chi mi ospita ad una tariffa veramente competitiva, abbia solertemente messo una patch a questo problema, per cui quì, questa vulnerabilità, non è più sfruttabile, ci sono da fare molte considerazioni.

La prima, la più importante è che, visto che l'advisory reca una data di un mese fa, questo lasso di tempo non è bastato ai sysadmin per riuscire a capire il problema. Ancor più grave il fatto che possedevano tutti gli strumenti per le ricerche, contrariamente ad un cliente.
La seconda, e che non riguarda questo hosting, è che un'altro molto importante e noto, era stato avvertito della prima parte di questo problema molto  prima dell'11 novembre.
Aveva anche le sue ragioni a ritenersi diffamato per quello che era stato pubblicato, ma come tutti gli stolti si è limitato a guardare il modo e non la sostanza, che lo riguardava più direttamente e a cui avrebbe potuto mettere una pezza già da tampo assicurando la tutela della privacy dei propri clienti.
Sì, perchè tra le promesse e le garanzie che ci forniscono, è compresa anche questa forma di attenzione verso il cliente, cosa che viene tranquillamente sottovalutata da tutti: sono nostri i dati che prendono il volo e sono nostre le successive rotture di scatole  nel sistemare l'applicazione e cestinare migliaia di mail di spam.

Grazie a chi ha divulgato questa vulnerabilità, oggi, abbiamo un gradino di sicurezza certamente maggiore, quindi onori a chi ci ha lavorato (un po' meno a chi si è divertito a ownare), e grazie anche al solito Federico (aka Sergetto) che non mi dimentica e mi tiene sveglio quando con la sua solita coincitazione tenta di spiegarmi cose che per lui sono chiarissime attraverso un susseguirsi di mail, che puntualmente comprendo solamente il giorno dopo...

EDIT:
visto che la domanda conseguente è: "...e ora cosa faccio?", cerco di darvi una mia "procedura" per cavarvela in fretta.

se avete installato joomla 1.5.15 (ultima), senza aver installato extensions prese chissà dove, il problema è quasi sicuramente del server quindi dell'hoster, e su server dove sono presenti più siti (no dedicati o housing)

1) Scaricare in locale solo ciò che è vostro, non appartenente a Joomla, css, immagini e template.
Questo vale sia per i files che per il db MySql (ovviamente il db va backuppato tutto).
Non usate backup automatici che potrebbero già contenere manomissioni a meno che non siate più che certi che sia di un periodo antecedente l'attacco.

1-a) Se avete accesso FTP o Sql nessun problema
1-b) Se non riuscite perchè vi hanno cambiato user e pw, chiedete assistenza all'hoster che ve le cambierà, dopodichè procedete. Assicuratevi che il vostro hoster sia a conoscenza del problema, semmai includete nella mail che gli inviate anche il link alla disclosure:http://securityreason.com/achievement_exploitalert/14, e che risolva il problema, altrimenti cambiate hosting.

2) Cancellate tutti i files sul vostro spazio e mettete un bell'html "lavori in corso". Svuotate anche il db.

3) Ora dipende dalle vostre capacità.

3-a) Neofiti
Scaricate una nuova installazione Joomla e procedete, usate gli stessi parametri della precedente installazione tranne la pw ovviamente.
Cercate nei files di vostra proprietà, scaricati precedentemente, cose che non vi appartengano, es. file php nelle cartelle immagini, files dai nomi strani (joomla è abbastanza standard nei nomi), script all'interno dei files dei templates.
Se siete sicuri che non ci sia nulla sostituite le cartelle del template con le vostre e rimettete sotto la stessa path le varie immagini etc.
Magari provate in locale se non siete sicuri, eventuali script creano comunque evidenti malfunzionamenti.
Riuppate anche il db.
ATTENZIONE: nel db sono contenuti i dati di accesso precedenti!
Dovrete per cui resettare la pw seguendo le mille guide che si trovano in rete, e poi reimpostarla.

3-b)Esperti
Beh ... credo non ci sia bisogno di dire nulla, scegliete voi cosa e come controllare, ma fatelo.

PER IMPOSTARE UNA PASSWORD di admin sicura fate così:
- scelgo -> pippo
- vado su un tool md5 online o uso un mio script e inserisco pippo (ne prendo uno a caso http://md5-hash-online.waraxe.us/)
- il risultato sarà 0c88028bf3aa6a6a143ed846f2be1ea4, ben più complesso di pippo.

l'md5 di pippo darà sempre quella stringa, non è per cui necessario ricordarsela.
Scegliete comunque di criptare nomi complessi, con caratteri speciali, altrimenti attaccando con un vocabolario di stringhe in md5 è comunque semplice arrivarci.


Nel caso di attacchi che non dipendono dall'hosting
La procedura rimane quella sopra citata, ovviamente ci sarà da scoprire il perchè, quindi:

- Se avete l'ultima release controllate che non ci siano vulnerabilità note su joomla, controllate sui siti degli sviluppatori di eventuali extensions che non ci siano vulnerabilità note.

- EXTENSIONS - Gli aggiornamenti di Joomla non aggiornano le extensions installate, che sono le più colpite, lo sviluppo e l'aggiornamento delle stesse è SOLO e UNICAMENTE responsabilità vostra.

Se avete versioni precedenti di joomla.... spiegatemi il perche..