Allarme Virus! Cambiate subito le password FTP!
Sono un po’ di giorni che mi stanno contattando tutti i miei clienti perchè il loro sito viene considerato “malevolo“.
All’inizio pensavo fosse una coincidenza ma ho notato che il fenome è più diffuso di quanto immaginassi e sta prendendo di mira un po’ tutti.
Cosa sta succedendo? Un altro odiosissimo VIRUS.
Non so come facciano… all’interno della root FTP viene inserito un file chiamato mailcheck.php, inoltre nella index viene inserito un Javascript lunghissimo (e facile da individuare).
All’inizio avevo paura di aprire i files sospetti per la possibilità che il mio computer ne venisse infettato, ma purtroppo chi dovrebbe fornire questo genere di servizi si dimostra più incompetente di un web designer che di nozioni sicurezza di certo non è un maestro.
Quindi ho preferito rischiare … meglio fare da soli!
Consiglio a tutti di controllare la propria cartella di files sul server, se trovate il file mailcheck.php eliminatelo.
Ripulite la vostra index di tutti gli script che non avete inserito personalmente e cambiate subito le password del vostro spazio FTP.
Se il vostro sito è iscritto nel programma “Google Webmaster Tool” (www.google.it/webmasters) avrete di sicuro ricevuto un avviso, tramite il vostro pannello di controllo una volta ripuliti i files potrete inviare una segnalazione a Google per far si che il vostro sito non appaia più come malevolo.
In 48 ore torna tutto come prima 
Puoi trovare interessante anche:
- Lively riposa in pace.. seguirà Second Life.
- Sorridi! Sei su Google Street View
- Google migliora la ricerca immagini
- Novità in Google Analytics
- SEO & Web Marketing: Posizionamento sponsorizzato
Esprimi un giudizio sul post!
(+1 rating, 1 voti)
Loading ...24 commenti
-
-
23 marzo 2010 alle 16:37
Bisognerebbe fare un test antihacker al sito, ad esempio per il codice javascript sono sicuro si tratti di XSS…
Mentre per il file che trovi nella root, è molto difficile scoprire la password ftp visto che gli hoster bloccano gli attacchi in brute-force, quindi dovresti controllare che non ci siano bug RFI (Remote File Inclusion) negli script php… Grazie a questo exploit, un hacker può benissimo avviarti una shell e prendere il controllo del host…
Se usi script gia fatti, aggiornarli o controlla manualmente la presenza dei bug prima citati.
-
23 marzo 2010 alle 16:40
Grazie per l’avviso!Ultimamente specie nella posta stò avendo molto più spam del solito!
-
23 marzo 2010 alle 16:52
@ale: credo tu stia facendo un po’ di confusione fra virus e spam
-
23 marzo 2010 alle 17:12
[...] Virus! Cambiate subito le password FTP! Fonte: http://www.web-magazine.it/2010/03/allarme-virus-cambiate-subito-le-password-ftp/ Sono un po’ di giorni che mi stanno contattando tutti i miei clienti perchè il loro sito [...]
-
23 marzo 2010 alle 17:46
dal momento che non avevo capito nulla del commento di stefano (che comunque ringrazio per la sua competenza in materia..) ho letto questo: http://www.notrace.it/cross-site-scripting-xss.htm, inizio a capirne un po’ di più.
Ma come fare per prevenire???
-
23 marzo 2010 alle 18:03
Scusami Lauraaaaa!!
Allora ti spiego:
Tramite XSS (Cross-Site Scripting) un malintenzionato pò iniettare codice javascript.
Per evitare dovresti usare sempre il comando strip_tags di php negli output di dati immessi dall’utente (ad esempio una ricerca, se tu dopo scrivi ecco i risultati del testo: …..TESTO-RICERCATO-PASSATO-IN-FORM senza uno strip_tags ottieni un bel XSS).Io per sicurezza aggiungo anche un htmlentities (che trasforma i tag nelle relative entità html, cosi da rendere innoquo tutto ciò ke viene passato)
Per il RFI invece accade spesso che ci sono siti che passano in querystring o via form il file da includere in php, ad esempio:
http://www.miosito.php?includi=../file
In questo caso basta cambiare ../file con l’indirizzo di una shell e addio sito, per ovviare al problema bisogna controllare l’input ottenuto con degli “if”, e magari se possibile disabilitare il parametro allow_url_include dalle direttive di php…
Il codice vulnerabile di esempio potrebbe essere questo:
include $_GET['includi'].”.php”;
da cambiare con:
if($_GET['includi'] == ‘file’)
{
include ‘file.php’;
} -
23 marzo 2010 alle 18:05
Salve anche a me è successo. Il mio sito risiede nei server di Aruba ed ho avuto lo stesso problema due volte negli ultimi 50 giorni. Fortunatamente nel giro di 2-3 giorni mi hanno risolto tutto quelli di Aruba… questa cosa cmq non mi fa dormire sonni tranquilli.
-
23 marzo 2010 alle 18:14
Altra cosa siccome Daniele ha parlato di ARUBA, vi informo (per chi non lo sa) che le direttive “register_globals” di PHP sono settate su ON, il che compromette molto la sicurezza del sito web se non si è esperti.
Vi spiego meglio:Tutte le variabili passate nei vari modi(get, post, cookie, session, ecc..) se aventi lo stesso nome, vengono trattate come se fossero uguali se register_globals è su ON, perciò con un login per esempio cosi:
if($registrato == 1) { echo “sei registrato”; }
Ad un malintenzionato basta scrivere: login.php?registrato=1
e in questo modo $_GET['registrato'] grazie a register_globals attivo, diventa $registrato e viene settato ad 1 dalla querystring…(spero di essere stato chiaro, sono sottoscritot ai commenti se vi serve una mano
) -
23 marzo 2010 alle 19:17
Parlo da inesperto totale di sicurezza: sarà un caso che per Joomla non sento mai parlare di queste cose, ma negli ultimi tempi per wordpress ne ho sentite parecchie?
-
23 marzo 2010 alle 19:19
@francesco: non credo che il sito di laura fosse in wordpress, o sì?
-
23 marzo 2010 alle 20:06
grazie 1000 per la segnalazione!
-
23 marzo 2010 alle 21:24
no nessun wordpress, tutti cms creati ad hoc. Grazie della spiegazione. Quindi se aruba o chi altro consiglia al mio cliente semplicemente di cambiare la pasword, io dovrei consigliargli invece di cambiare provider?
-
23 marzo 2010 alle 22:04
No non provider Laura, consiglierei di controllare gli script prima di tutto specie nel caso si stia su aruba… Per il resto cambiare le pwd non è sbagliato come consiglio.
@francesco: gli exploit esistono per wordpress come esistono per joomla, uno dei vantaggi di creare un cms ad hoc personale è appunto che gli hacker non avranno vita facile perchè non hanno i sorgenti quindi non potranno trovare i bug facilmente a meno che non usino qualche dork di google…
-
23 marzo 2010 alle 22:19
heheh grazie stefano! mi sa che sono la prima ad avere un blog dal quale impara invece di “insegnare” e informare
! -
23 marzo 2010 alle 22:27
No dai, nessuno nasce insegnato!!
Felice di essere stato d’aiuto in qualche modo. -
24 marzo 2010 alle 12:47
@ StefanoV
grazie mille io come credo tutti quanti qui sono un web designer e non un developer. sapresti consigliarmi un server “più sicuro” a pari prezzo o poco piu costoso? -
24 marzo 2010 alle 13:42
Io attualmente oltre aruba ho provato Tophost e netsons solamente.
Tophost per un lavoretto medio-piccolo è perfetto, mentre su netsons ci ho messo l’ira di dio e gira perfettamente veloce in più su netsons come pannello di controllo c’è cpanel, e in caso di errori php viene creato automaticamente un file di log nell’ftp.Ci saranno sicuramente molti altri host nettamente superiori, ma a quasi-parità di prezzo questi sono favolosi.
-
26 marzo 2010 alle 0:38
ciao, ho passato l’ultime 2 settimane a lavorarci.
non infetta solo il file index.php .. date un’occhiata anche agli altri file php. anche nelle sottocartelle. in particolare fate attenzione alla data dell’ultima modifica così subito individuerete i file infetti e potrete correggerli. come detto cancellate il file mailcheck.php.
lo script si trova semrpe all’inizio del php.
usa un for con sostituzioni di carattere Z->% in modo che si codifica la stringa gigantesca nella variabile $a.
In questo modo potrete vedere cosa fa lo script.
In poche parole agisce sui cookie creando dei cookie malevoli e memorizzandoli sul vostro pc. Oltre che inserire dei link al php a siti malevoli in modo da farlo bloccare da google..
Quindi ripulite tutto, cambiate password ftp. e cancellate tutti i cookie e la cache.
Ciaoo
Alex
-
31 marzo 2010 alle 14:13
ti avverto che visitando questo sito con safari per mac mi da l’avviso: la visita del sito può danneggiare il computer…
-
7 aprile 2010 alle 10:44
finalmente siamo tornati!!!
-
8 aprile 2010 alle 12:09
Ultimamente è capitato ad un mio grosso cliente,
addirittura il suo sito appariva “malevolo” nell’indice di google, purtroppo chi si occupava di marketing non ha saputo monitorare a dovere il sito segnalando tempestivamente il problema e il sito ha perso posizioni su posizioni nelle Serp di Google.
Il problema era ben più ampio e forse relativo alla gestione del server da parte della società che ospitava il progetto, poichè dopo una prima pulizia / cambio dati FTP dopo qualche settimana il server è staro ri-bucato.
Abbiamo risolto spostando la piattaforma su un nuovo fornitore, ma il cliente per ora ha subito un bel danno in termini di immagine e anche in termini di affidabilità agli occhi di google. -
29 ottobre 2010 alle 9:51
A me è successo su moltissimi siti che usavano tecnologie diverse (anche html puro quindi niente xxs) e CMS diversi.
Il problema è che bucano il servizio di ftp, c’è un software che gira sul server e consente l’accesso ftp, quello presenta un bug usato per poi in maniera ricorsiva bucare tutti i siti cercando ad esempio nomi noti di file index.php, index.html ecc o anche js come in alcuni casi.
Il problema non è di chi ha fatto il sito ma di chi lo “hosta”, su Aruba è successo più volte ma anche su un provider locale che spesso uso….per ora mai su register.
-
2 dicembre 2010 alle 0:27
Caspita…assurdo! bè almeno ora lo sappiamo e possiamo difenderci!!
Web magazine è il blog personale di 
I contenuti di questo blog sono pubblicati sotto licenza
Lauryn scrive:
23 marzo 2010 alle 16:23
‘orca miseria! urge un check, grazie, diffondo!