Exploit a causa di BUG nel modulo EMAIL - WebSite X5

[serzio]

Nel caso di form che fa uso di MYSQL e permette l'invio di allegati, è possibile iniettare nel sito codice malevolo a causa della gestione superficiale dei nomi assegnati ai file allegati.

Un esempio su [ link rimosso per ragioni di sicurezza ]

Riporto, di seguito, un esempio di esecuzione del file inserito nel sito web sfruttando il bug, lo script che viene messo in esecuzione (chiamato cmd_xyz.php) ed infine lo script in grado di rilevare il nome completo del file allegato:

[ Guests cannot view attachments ] [ Guests cannot view attachments ] [ Guests cannot view attachments ]

[Giuseppe G.]

il BUG lo dovrebbe correggere ICM..... o se no che alternative abbiamo prima che lo risolvano?

[serzio]

il BUG lo dovrebbe correggere ICM..... o se no che alternative abbiamo prima che lo risolvano?

Non posso certo dire che quel codice sia pieno di bachi come qualcuno mi ha detto in privato, ma devo senz'altro ammettere che quasi ogni volta che ne analizziamo un pezzetto, qualcosa esce fuori. Non è stato testato a dovere, sono almeno 6 mesi che lo sto dicendo.
Questa volta è bastato dare un'occhiata al "dove" vengono memorizzati i files degli allegati per accorgermi che il nome del file è perfettamente rintracciabile e, cosa ben peggiore, mantiene l'estensione originale e quindi la capacità di essere eseguito. E' una bomba a orologeria. Non capisco come si possa non averci pensato.

Ho già fornito sia il problema che la soluzione, mentre per l'applicazione "di massa" della soluzione dovremo aspettare che incomedia si muova, sempre che non sia un comportamento voluto.

[serzio]

Ho ricevuto un messaggio privato, ma come ben risaputo, sono contrario alle risposte personalizzate (che tanto sanno di lavoro su commissione) e pertanto, ma senza svelare chi è l'autore, giro il post nell'area pubblica a beneficio di chi volesse capirci di più:

...
... come fa un utente malintenzionato che carica il file sul server a sapere quale stringa numerica è stata aggiunta al nome del file?
...

Il baco è presente fino alla release odierna, ovvero la 9.0.10.1842.

I file prelevati dal form vengono inseriti nella root del sito web e vengono rinominati utilizzando il nome originale del file seguito da un underscore "_", la data AAAAMMGG, l'ora di invio HHMMSS ed una sequenza di 6 caratteri che nel mio caso erano sempre zeri, ma presumo che vengano utilizzati per la gestione delle eventuali omonimie, non ho fatto ricerche in tal senso, ed infine l'estensione del file (ed è qui, il vero problema).

Immaginiamo di voler replicare l'exploit. Prepariamo un file in php, o in asp .... insomma qualsiasi cosa che sia eseguibile sul lato server, io ho realizzato il file in php ..... che contiene il codice malefico che devo iniettare nel sito web. A tal riguardo c'e' un topic che scrissi tempo fa <QUI> e che spiega come realizzare uno script in grado di eseguire comandi direttamente da sistema operativo del web server.

Successivamente ma molto banalmente si allega il file così realizzato e chiamato cmd.php ad una richiesta di contatto mediante form annotandosi data e ora dell'ora dell'invio. Ci sarebbe da considerare il timezone del server e qualche altro particolare, ma sono solo dettagli non utili al fine della spiegazione.
A questo punto occorre "ritrovare" il file rinominato sul sito web e richiamarlo mediante http_://www.sitoweb.xx/cmd_AAAAMMGGHHMMSS000000.php per ottenere il controllo completo del sito web ed utilizzarlo per farci qualsiasi cosa, eventualmente anche truffe informatiche (fishing) o semplice spam se nel codice si è attivato un sistema di gestione dei contenuti che passerebbe sotto al naso di qualsiasi policy di sicurezza del webserver ed indipendente dai dati dell'ftp.

La difficoltà è ritrovare il file dello script ed il metodo che ho brutalmente utilizzato ha bisogno di un numero massimo di 60 iterazioni. E' migliorabile, ma già così funziona ottimamente. 60 sono i secondi che non riuscirei ad indovinare, mentre ora e minuti è facile facile. Preparo 60 stringhe contenenti il probabile nome e le richiamo mediante curl, ma solo perchè ho scritto in php anche il codice per la ricerca dello script piuttosto che in c++ o in c o in chissa quale altro linguaggio.
Perchè ho usato il php? Facile, se devo sferrare un attacco di questo tipo, sarei un imbecille se lo facessi dal mio pc, mentre invece potrei avere come base di partenza un qualsiasi altro sito web "preparato" per lo scopo e magari che utilizzi un qualsiasi anonymizer proxy.

Sicuramente verrò criticato per aver pubblicato questi dettagli, perchè l'ho fatto? Il primo e più importante motivo è che sono fermamente convinto che il sistema migliore per combattere i cretini che si divertono a compiere questi atti vandalici sia quello di conoscere i metodi usati e quindi prevenirli.
Il secondo motivo è di spingere icm a mettere al più presto una toppa su questa gravissima falla evitando quello che è accaduto in passato per un problema protratto per oltre due mesi.

[marcoboni]

Ho ricevuto un messaggio privato, ma come ben risaputo, sono contrario alle risposte personalizzate (che tanto sanno di lavoro su commissione) e pertanto, ma senza svelare chi è l'autore, giro il post nell'area pubblica a beneficio di chi volesse capirci di più:

...
... come fa un utente malintenzionato che carica il file sul server a sapere quale stringa numerica è stata aggiunta al nome del file?
...

Il baco è presente fino alla release odierna, ovvero la 9.0.10.1842.

I file prelevati dal form vengono inseriti nella root del sito web e vengono rinominati utilizzando il nome originale del file seguito da un underscore "_", la data AAAAMMGG, l'ora di invio HHMMSS ed una sequenza di 6 caratteri che nel mio caso erano sempre zeri, ma presumo che vengano utilizzati per la gestione delle eventuali omonimie, non ho fatto ricerche in tal senso, ed infine l'estensione del file (ed è qui, il vero problema).

Immaginiamo di voler replicare l'exploit. Prepariamo un file in php, o in asp .... insomma qualsiasi cosa che sia eseguibile sul lato server, io ho realizzato il file in php ..... che contiene il codice malefico che devo iniettare nel sito web. A tal riguardo c'e' un topic che scrissi tempo fa <QUI> e che spiega come realizzare uno script in grado di eseguire comandi direttamente da sistema operativo del web server.

Successivamente ma molto banalmente si allega il file così realizzato e chiamato cmd.php ad una richiesta di contatto mediante form annotandosi data e ora dell'ora dell'invio. Ci sarebbe da considerare il timezone del server e qualche altro particolare, ma sono solo dettagli non utili al fine della spiegazione.
A questo punto occorre "ritrovare" il file rinominato sul sito web e richiamarlo mediante http_://www.sitoweb.xx/cmd_AAAAMMGGHHMMSS000000.php per ottenere il controllo completo del sito web ed utilizzarlo per farci qualsiasi cosa, eventualmente anche truffe informatiche (fishing) o semplice spam se nel codice si è attivato un sistema di gestione dei contenuti che passerebbe sotto al naso di qualsiasi policy di sicurezza del webserver ed indipendente dai dati dell'ftp.

La difficoltà è ritrovare il file dello script ed il metodo che ho brutalmente utilizzato ha bisogno di un numero massimo di 60 iterazioni. E' migliorabile, ma già così funziona ottimamente. 60 sono i secondi che non riuscirei ad indovinare, mentre ora e minuti è facile facile. Preparo 60 stringhe contenenti il probabile nome e le richiamo mediante curl, ma solo perchè ho scritto in php anche il codice per la ricerca dello script piuttosto che in c++ o in c o in chissa quale altro linguaggio.
Perchè ho usato il php? Facile, se devo sferrare un attacco di questo tipo, sarei un imbecille se lo facessi dal mio pc, mentre invece potrei avere come base di partenza un qualsiasi altro sito web "preparato" per lo scopo e magari che utilizzi un qualsiasi anonymizer proxy.

Sicuramente verrò criticato per aver pubblicato questi dettagli, perchè l'ho fatto? Il primo e più importante motivo è che sono fermamente convinto che il sistema migliore per combattere i cretini che si divertono a compiere questi atti vandalici sia quello di conoscere i metodi usati e quindi prevenirli.
Il secondo motivo è di spingere icm a mettere al più presto una toppa su questa gravissima falla evitando quello che è accaduto in passato per un problema protratto per oltre due mesi.

Ritengo questo post, ottimo per chi come me intuiva ma non capiva i meccanismi usati dai "cretini", adesso so cosa non devo fare per espormi, bene grazie.

[serzio]

...
Ritengo questo post, ottimo per chi come me intuiva ma non capiva i meccanismi usati dai "cretini", adesso so cosa non devo fare per espormi, bene grazie.

Ti ringrazio per l'apprezzamento. 

Ho constatato con piacere che nessuno ha "osato" fare prove fraudolente e qualcuno si è civilmente limitato ad eseguire il link proposto.

Ad ogni modo, ho rimosso il sito web di test per questioni di sicurezza, oramai si è capito come funziona e non voglio mettere a repentaglio l'enorme quantità di materiale che mantengo sul serzio.it. Tuttavia, nel primo post, ho allegato le jpg per illustrare nei dettagli il metodo utilizzato ed un output in cui si vede chiaramente quello che può accadere.

[milux]

Ringraziando come sempre Serzio per l'ottimo lavoro svolto , mi collego per aggiungere che un eventuale exploit può essere usato per accedere ad esempio al file che contiene le password per l'accesso alle pagine "riservate" create con WSX5 in cui molti utenti riversano documenti, pensando di aver messo il tutto al sicuro..

[serzio]

Ringraziando come sempre Serzio per l'ottimo lavoro svolto , mi collego per aggiungere che un eventuale exploit può essere usato per accedere ad esempio al file che contiene le password per l'accesso alle pagine "riservate" create con WSX5 in cui molti utenti riversano documenti, pensando di aver messo il tutto al sicuro..

Esattamente. Nelle immagini che ho postato c'è un DUMP dell'array degli utenti ed il listato completo del file access.inc.php ... ma ovviamente si può ottenere qualsiasi cosa.