Emergenza virus !!! (in cartelle html non joomla)

[mau_develop]

mmhhh no, hai letto qualcosa che non centra, guarda quello sulle iniezioni di codice.

M.

[andrea]

Ho letto anche quel topic aperto da te. Nella nottata hanno ripetuto l'attacco. Sto andato step by step, ora mi trovo sotto attacco con Jomfish,Joomla,JoomlaFap alle ultime versioni. Ogni volta dopo l'attacco ripulisco il file index.php ma non ho chiaro se ci possa essere altro di infetto nel joomla. Ho controllato tutti gli index.htm,index.php mi sembrano apposto, del resto sono quelli per evitare che inserita una path venga listato il contenuto, e la loro dimensione è circa 40B e dentro nulla di pericoloso.

Ora ho provato modificato parte del Js presente nel template JoomlaFAP, eliminandolo proprio e attendo la nottata. Penso che l'attacco avvenga ad orari fissi, circa mezza notte ora IT. Index.php del template ha diritti 555 eppure viene scritto....

L' hoster mi ha detto che non sembra mysqlinjection e che con i loro controlli non hanno rilevato accessi indesiderati, la cosa avviene sicuramente per XSS in un qualche modo, ripeto almeno nel mio caso.

[mmleoni]

ciao a tutti!

..Ho controllato tutti gli index.htm,index.php mi sembrano apposto

non basta, devi verificare anche:
1.
che non siano stati modificati altri files
2.
che non vi siano file estranei alla installazione di joomla e delle estensioni che possano agire da cavalli di troia

btw: difficilmente potranno fare danni con i files html

... Index.php del template ha diritti 555 eppure viene scritto....

555 non vuol dire dire niente se non conosci le ownerships ed i ruoli dei diversi programmi: non farci affidamento

L' hoster mi ha detto che non sembra mysqlinjection

ad ogni buon conto non lasciare il prefisso delle tabelle a jos_ (sempre un pessima scelta...)

... la cosa avviene sicuramente per XSS in un qualche modo, ripeto almeno nel mio caso.

xss fa danni ai navigatori, non al sito.


ciao,
marco

[andrea]

Ho trovato un file che da antivir viene rilevato infetto durante il backup dell FTP del sito in questione, si chiama phpmailer.php è un falso positivo o potrebbe essere veramente uno script estraneo?

Per quanto riguarda l XSS esistono anche attacchi volti a modificare pagine del sito in modo definitivo: http://it.wikipedia.org/wiki/Cross-site_scripting

Ora ho provato ad eliminare parte del template JoomlaFAP in js che permetteva lo zoom dei caratteri della pagina. Questa notte non è stato fatto l'attacco, quindi tutto mi farebbe pensare che fosse partito proprio da li l'attacco. Prima di cantare vittoria vi tengo aggiornati se l'evento si ripete anche dopo la modifica.

[mmleoni]

ciao,

...si chiama phpmailer.php è un falso positivo...

esiste un file di tale nome nella installazione di joomla in /libraries/phpmailer/phpmailer.php, ma non posso dirti se sia stato modificato. tieni presente che molto difficilmente (ie: praticamente mai) un antivirus potrebbe rilevare un virus diretto o proveniente da xss in un sorgente php. devi comparare contenuto e date con gli originali: non puoi fare affidamento su un antivirus.

Per quanto riguarda l XSS esistono anche attacchi volti a modificare pagine del sito in modo definitivo: http://it.wikipedia.org/wiki/Cross-site_scripting

temo tu non abbia capito l'articolo: si fa riferimento all'output prodotto a causa di inserimenti malevoli nel contenuto (dbase) della pagina generata. non viene modificato il codice di generazione, ma solo l'output generato a causa dei contenuti inclusi.(capisco sia difficile comprendere la differenza se non sei un programmatore od un sistemista: nel dubbio continua a chiedere)

... Ora ho provato ad eliminare parte del template JoomlaFAP ...

non penso sia questo il problema. comunque ti auguro di aver risolto (buona parte di questi attaccanti desistono presto: paradossalmente è una questione di affari, non di principio)

ciao,
marco

[mau_develop]

le index le modificano con permessi di root, gli stessi che hai tu quando li setti a 555.

L'attacco xss è sempre rivolto al visitatore, e viene considerato visitatore anche l'admin che accede.
Non è nulla di strano, due tag script e un alert con document.cookies e hai il tuo grabbatore... joomla è andata un po' più avanti, serve un token da abbinare ai cookie.

Un'xss di per se è solo un indice di un input non controllato ma non è nulla, la vedi tu che la lanci e basta però può diventare 2 cose:
un xss permanente, ovvero tu riesci a scrivere l'xss in un articolo, in un commento, in un qualunque campo di input non controllato conduca ad una scrittura all'interno del sito.
A questo punto chiunque visiterà la pagina eseguirà lo script che opportunamente modificato invierà dei dati appartenenti al client del visitatore all'attaccante.

Oppure, la seconda via è che possa diventare una sqlinj, ovvero ciò che tu inserisci, oltre a non essere filtrato viene infilato diretto in una query.

M.

[andrea]

Quotando la risposta di mau, guardando l'index che ho allegato in un precedente post, secondo me è XSS permanente. La differenza penso di capirla anche se sono al secondo anno di informatica e le esperienze relativamente ristrette. Secondo me hanno utilizzato un document.write o qualcosa del genere nel JS del template o di qualche modulo che lo genera (BriasKISS, ma punterei più sul FAP), in questo modo hanno gli stessi permessi dell'eseguibile sul file.

Fatto questo scrivono sul template il pezzo di js (e link spam) volto ad attaccare chiunque visiti il sito web, e torna pure l'intento del XSS.

Fila?

[mau_develop]

e no, è js, quindi con document.write non fai altro che stampare a video qualcosa. Javascript esiste solo lato client, per far comunicare il client con il server ha bisogno del php o cmq di ajax.

Per iniettare del codice in mezzo ad altro codice che non fa parte di un contenuto l'unico modo è farti capitare su un link che sfrutta una richiesta forgiata ad una vulnerabilità sul tuo sito, in pratica farlo fare a te oppure avere accesso ftp.

M.

[andrea]

Ma hai presente lo script per cambiare la grandezza del font dei siti accessibili? Quello và a scrivere in un qualche modo nel DOM del documento, ma a questo punto mi fai venire davvero il dubbio che non abbia modulo ajax allegato, devo controllare.

[mmleoni]

stai confondendo l'effetto (il js e xss) con la causa (il modo in cui sono entrati).

consiglio: concentrati su quest'ultimo aspetto e lascia stare js/dom/xss che non c'entrano niente...

ciao,
marco

[mau_develop]

Quello và a scrivere in un qualche modo nel DOM del documento.
--------------------------------------------------------------
infatti, è corretto.

La request che effettuo al server mi ritorna dei valori che verranno rappresentati graficamente dal browser, come oggetti.
Essendo oggetti e dovendo modellarli runtime per adattarli al mio browser ricorrerò al js ad ajax e ai css... ma sono tutte cose mie, del mio browser, non del sito.

Infatti, se apri firebug, hai una rappresentazione grafica della modellazione. Il tuo sito potrei vederlo completamente diverso da come tu lo hai fatto agendo sul mio dom; posso eliminare contenuti, cambiare colori etc.. nn sono bug, sono funzionalità.

Il bug sopraggiunge quando il mio browser non riesce a rimanere nella "sandbox" dove gira e inizia a restituire cose non previste e volute.

Le cose si sono complicate col cosiddetto web 2.0, che non vuol dire nulla, se non un ulteriore livello di request: Ajax, richieste asincrone e silenzione che possono avvenire a livello di dom intriducendo ulteriori punti di vulnerabilità.

Quello che potrebbe essere successo a te è che sei capitato in una csrf. Ti faccio un esempio grossolano:

- sei loggato e stai scrivendo un'articolo ( scrivere un articolo significa mettere del testo in un form e spedirlo )

- il form che spedirà il tuo articolo controllerà che tu abbia l'autorizzazione per farlo prima di eseguire la richiesta controllando i tuoi cookies (browser), ma non controlla da dove gli viene la richiesta.

- Io so il tuo nick e alcuni tuoi dati, guardo su facebook il nome e il nick di una tua amica e ti mando una fake mail con un link ad una finta pagina di Picasa: Ciao Andrea, ero indecisa se farti vedere questa foto...

- Clicchi e finisci in una pagina che spedisce un form replicato da quello joomla che spedisce l'articolo e con dentro il contenuto che voglio io, ovviamente con tutte le path per il tuo sito.

- Dopo la spedizione del form lo script finisce in un'altra finta pagina con scritto: L'utente ha rimosso l'immagine.

Il gioco è fatto.

Joomla è sempre stato abbastanza sicuro da qs punto di vista, ha dei csrf ma sono su form mail, puoi fare spam ma non buchi nulla.

Il problema sono sempre gli sviluppatori. Per sviluppare basta conoscere php ma a volte non basta ormai... perchè rinunciare ad Ajax, alle jquery a tutto quel mondo invisibile che crea effetti particolari semplicemente copiando il codice e inserendolo nel sito?

Non consideri però che quello non è un'effetto a se stante, è una parte molto attiva del tuo sito e bastarda, perchè invisibile.

M.