Joomla.it Forum
Non solo Joomla... => Sicurezza => : mau_develop 02 Jun 2010, 21:34:31
-
oggi sono state scoperte due importanti vulnerabilità nel componente chronoform.
Siccome è molto "popular" cercate, chi lo usa ovviamente, di fare l'update velocemente appena lo rilasceranno, per ora è meglio disabilitarlo, e magari abbassare i permessi alle cartelle relative così che non venga sfruttato qualche callback.
Fino ad ora sul sito dello sviluppatore non c'è nulla per patchare ma ne stanno discutendo sul forum:
http://www.chronoengine.com/forums/viewtopic.php?f=6&t=4802
M
-
Ciao Maurizio,
ma la discussione nel forum di ChronoConnectivity si riferisce ad una vulnerabilità storica di Joomla, si parla della 1.0.14.
Girando in lungo e largo per quel forum non ho trovato traccia della vulnerabilità di Chrono-tutto, visto che anche Connectivity e Comments hanno qualche problema di Blind SQL.
Il sito dello sviluppatore sembra dismesso, così come lo sviluppo del componente (spero di sbagliarmi).
Credo ci sarà una rapida migrazione verso qualche altro componente di gestione forms.
-
mmmhh, nel pomeriggio controllo come girava il fumo :) ... ricordo cmq di averlo già fatto quando l'ho pubblicata perchè qualche domanda me l'ero fatta anch'io... poi qualcosa mi aveva fatto decidere che era valida..
a jeckoooo ... son vecchio! non mi puoi chiedere cose di 10 giorni fa :):)
M.
-
io mi sono presi 10 giorni per vedere se la vuln veniva corretta.... ma purtroppo niente!
-
azz ho dei problemucci a rimettere in piedi il serverino col joomla da attaccare... cmq jecko, qs funziona?
( da qui : hXXp://inj3ct0r.com/exploits/12504 )
http://localhost/index.php?option=com_chronocontact&itemid=1 [Blind-SQL]
http://localhost/[PATH]/index.php?option=com_chronocontact&itemid=1 [Blind-SQL]
M.
-
quindi il blind SQL funziona? non ho capito...
-
come ti dicevo, studiando un po' da stupidotto un tool, mi sono compromesso il server e non capisco più dove e come fare a rimetterlo a posto, così l'ho piallato e ora devo reistallarlo :) altrimenti avevo tutto per capire al volo se e cosa funzionava, tanto il pacchetto come dicevi tu è sempre quello.
Quello per la 1.0.x è stato ufficialmente abbandonato,l'altro per 1.5 nella pagina di download è dato per mantenuto, quindi il fatto che non patchino mi fa sorgere dei dubbi che qs vuln sia"un pacco" come molte già pubblicate.
A supporto invece della validità c'è il fatto che è pubblicato anche sui top advisory site (seclist piuttosto che altri) e anche in giro se ne parla...
detto questo....allora, non è che uno funziona e l'altro no, in fondo sono la stessa cosa. (.. nn vorrei ti offendessi se dico cose che già conosci :) )
la blind (cieca) mi permette di arrivare alla stringa di esploit passo er passo alla cieca appunto; ad ogni mia richiesta errata mi risponde dandomi info per la successiva es: select pippo from topolino >> risposta "non esiste una tabella topolino nel database pluto. (e mi dice il nome del db)
Mano mano che "imbrocco" i valori corretti ottengo risposte sempre più affinate fino a riuscire a comporre la stringa da iniettare.
A dire la verità joomla non è molto propenso a qs tipo di attacco poichè la restituzione degli errori è abbastanza curata anche se ci si può arrivare comunque non è certo la strada migliore, in un cms dove conosci il nome di tutto. Quindi direi che quell'indicazione blind mi fa pensare ad un ragazzino che abbia esploitato con un tool e ricopiato la stringa senza nemmeno sapere cosa ha fatto. ...poi magari la vuln c'è davvero...
direi che la cosa più appropriata è guardare direttamente il codice se quell'id viene usato male, eeee... lo faccio subito.. o quasi :)... adesso lo scarico.
comunque il tool di Marco dovrebbe mettere al sicuro da queste cose poichè per permettere la visualizzazione dei dati esploitati devi rimanere "all'interno" di joomla e non causare errori e quindi passare per il suo filtro.
M.
-
e sì... è vulnerabile, credo però ci siano degli scenari precisi in cui si verifica
... jecko... hai un po' di pvt :) (sorry)
M.
-
e questo mi preoccupa.
Circoscrivere gli scenari sarebbe opportuno, o quantomeno definire delle pratiche per "limitare la superficie di attacco".
Disattivando un'estensione o non pubblicandola il problema rimarrebbe ugualmente in quanto gli attacchi si riferiscono al loro percorso originale.
Faccio un esempio, avevo tempo fa HuruHelpdesk, estensione che ha sofferto da un po' di SQL Injection e pur avendo rimosso tutte le voci di menu, se richiami l'url originario index.php?com_huruhelpdesk ti esce ugualmente il componente.
Dovrebbe essere così anche per ChronoForms e tutto il resto.
Quindi se non esce una patch e vogliamo darci un po' di tempo si deve ricorrere al Marco's SQL Injection - LFI Protection plugin (http://www.mmleoni.net/sql-iniection-lfi-protection-plugin-for-joomla) che consente di restringere il capo d'attacco, per il momento.
Se non verrà patchato, si dovrà passare ad un'altra estensione.
-
Il sito dello sviluppatore sembra dismesso, così come lo sviluppo del componente (spero di sbagliarmi).
Credo ci sarà una rapida migrazione verso qualche altro componente di gestione forms.
Mi sembra di aver trovato indizi che si sta pensando ad una versione per joomla 1.6
http://www.chronoengine.com/forums/viewtopic.php?f=2&t=16315&p=43880&hilit=next+version#p43880
http://www.chronoengine.com/forums/viewtopic.php?f=3&t=15619&p=43980&hilit=next+version#p43980
-
si va bene la nuova versione, ma non si può prendere in giro la gente così... se hanno fatto na scemenza che la mettano a posto.
Ci vuole anche un minimo di responsabilità verso chi l'ha usata fino ad ora.... imo...
Poi è ridicolo che pensino a "qualcosa di più" non riuscendo nemmeno a sistemare il "qualcosa di meno" che hanno già in uso.
M.