Joomla, Drupal e Wordpress sotto scacco

ma personalmente non mi preoccupo troppo in quanto di exploit ne esistono tantissimi e non sono gli unici modi per mettere in ginocchio un server o un CMS... certo non è da starsene con le mani in mano ma neanche da allarmarsi troppo, al momento sarà sufficente tenere aggiornato il proprio CMS, tenere sottocontrollo accessi ed eventuali diritti a file e folder... ed in generale possiamo stare piuttosto tranquilli. Ad ogni modo un backup costantemente aggiornato del nostro sito web non fa mai male, in caso di problemi gravi si fa presto a ripristinare la situazione....

Io mi preoccupo, però non sono riuscito a replicare il problema usando l'exploit pubblicato: su OS X ho dovuto modificare leggermente lo script e quello che ho ottenuto non è esattamente un DOS, quanto un rallentamento molto significativo (e teniamo conto che l'ho fatto su una macchina con una GUI che non è nata per funzionare come server per migliaia di richieste).

Inoltre, mi chiedo con che criterio Gentilini abbia pubblicato l'exploit come zero day, soprattutto considerato che è un esperto di sicurezza: che bisogno aveva di pubblicarlo senza prima contattare i team di Drupal, Joomla e Wordpress? Tra l'altro lui stesso è nel team di sicurezza di Joomla, che immagino sarà stato felicissimo di questa rivelazione! Boh, a me sembra tutto un po' bizzarro e mi preoccupano sia le minacce di sicurezza (ammesso che siano verificate), sia queste modalità di pubblicazione, abbastanza irresponsabili.

Ho discusso brevemente della cosa con un collega che sviluppa per Joomla e lui ha fatto qualche prova su un server con l'exploit per Joomla. Il risultato è che il sito va giù per qualche secondo, insieme alla connessione al db. Insieme al server, comunque, si pianta anche la connessione locale e (in un caso) il PC, il che ci fa supporre che ci voglia qualcosina di più dell'ADSL per provocare danni seri. L'attacco comunque assomiglia più che altro a un flood di richieste generiche e ci vorrebbero prove più scientifiche per capire se effettivamente la vulnerabilità è nel sistema di caching o in altri punti più esposti (il webserver).

Il security team sa della questione.
La cache si refresha ogni cron run, inoltre ha un expire time, che se non settato alto aiuta a proteggersi. L'attacco comporta l'uso di un numero elevato di client che in contemporanea vanno a saturare le risorse del server come lo spazio su disco, in alternativa va a rallentare mysql per le dimensioni che la cache ha assunto. E' più facile che un attacco di questo tipo secondo me faccia crollare apache, perchè deve essere effettuato in un tempo ristretto, prima che la cache venga pulita, di conseguenza servono molti client che cercano di effettuare le richieste in contemporanea.

Emgent ha riportato anche alcuni xss che sono assolutamente low priority e sono stati riportati 2 anni fa dal sottoscritto come semplici bug. Se leggete i case study che lui stesso riporta, è scritto chiaramente che il requisito è quello di sniffare la password admin per poterli effettuare, e se avete in mano la password admin, bè a questo punto non credo proprio che metterete un xss in una pagina dell'area amministrativa a cui accedono 2-3 dei vostri utenti, lo metterete in ogni pagina attivando il filtro php-code.

Il problema è reale, il team di Joomla ci sta lavorando e consigliano di aspettare la soluzione prima di fare il porting anche verso gli altri applicativi. Il problema è reale e vale per tutti i CMS, il problema (solitamente) è risolto lato networking andando ad impostare delle lergole di filtraggio in modo da impedire da parte dello stesso utente troppe chiamate al sistema.

La cosa è una versione semplicificata di DDoS, in questo caso l'attaccante è sempre la stessa macchina, quindi con IP univoco e più facilmente filtrabile (diverso è il caso d proxy distribuiti intermedi), quindi se vi trovate su server managed solitamente la cosa è curata dalla server farm (o cmq i sysadmin) che gestiscono il tutto, magari informatevi presso di loro che policy usando sui firewall, mentre se avete server in housing contattate i vostri sysadmin per fare in modo che iptables non accetti più di X richieste al secondo dallo stesso utente (X configurabile in base alla tipologia di macchina, di sito, ....).