Fue manipulado. ¿Quieres entender cómo

Alguien, por segunda vez, ha agregado una porción de javascript a un sitio que ayudo a ejecutar. Este javascript secuestra Google Adsense, inserta su propio número de cuenta y pega anuncios por todas partes.

El código siempre se agrega, siempre en un directorio específico (uno utilizado por un programa de publicidad de terceros), afecta a una cantidad de archivos en una cantidad de directorios dentro de este directorio de anuncios (más o menos 20) y se inserta aproximadamente durante la misma noche hora. La cuenta de Adsense pertenece a un sitio web chino (ubicado en una ciudad a una hora de donde estaré en China el próximo mes. Tal vez debería ir a la cabeza ... broma, más o menos), por cierto ... aquí está la información sobre el sitio: http://serversiders.com/fhr.com.cn

Entonces, ¿cómo podrían agregar texto a estos archivos? ¿Está relacionado con los permisos establecidos en los archivos (que van desde 755 a 644)? Para el usuario del servidor web (está en MediaTemple, por lo que debería ser seguro, ¿sí?) Quiero decir, si tiene un archivo que tiene permisos establecidos en 777, todavía no puedo agregarle código a voluntad ... ¿cómo podrían estar haciendo esto?

Aquí hay una muestra del código real para su placer visual (y como puede ver ... no mucho. El verdadero truco es cómo lo obtuvieron allí):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Dado que varias personas lo han mencionado, esto es lo que he comprobado (y al comprobarlo quiero decir que busqué alrededor del momento en que los archivos se modificaron por cualquier rareza y agarré los archivos para ver las declaraciones POST y los recorridos de directorio:

• access_log (nada alrededor del tiempo excepto tráfico normal (es decir, excesivo) de bots de msn)
• error_log (nada más que el archivo habitual no existe errores para archivos de aspecto inocuo)
• ssl_log (nada más que lo habitual)
• messages_log (no hay acceso FTP aquí excepto yo)

* ACTUALIZACIÓN: ** OK, lo resolvió. Los hackers de China colocaron físicamente un archivo en nuestro sitio que les permite hacer todo tipo de tareas administrativas (acceso a la base de datos, eliminar y crear archivos y directorios, lo que sea, tenían acceso). Tuvimos suerte de que no hicieran algo más destructivo. No había nada en los archivos de registro de Apache normales, pero encontré un conjunto diferente de archivos de registro en un analizador de registro del servidor web y la evidencia estaba allí. Accedían a este archivo con su propio nombre de usuario y contraseña de administrador y luego editaban lo que necesitaban allí mismo en el servidor. Su archivo tiene "apache" establecido como el usuario, mientras que todos los demás archivos en nuestro sitio tienen un nombre de usuario diferente. Ahora necesito descubrir cómo físicamente obtuvieron este archivo en nuestro sistema. Sospecho que la culpa de esto finalmente recaerá en nuestro proveedor de alojamiento web (Media Temple),

Primero de todo, chmod 744NO es lo que quieres. El objetivo de chmod es revocar el acceso a otras cuentas en el sistema. Chmod 700es mucho más seguro que chmod 744. Sin embargo, Apache solo necesita el bit de ejecución para ejecutar su aplicación php.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data se usa comúnmente como la cuenta de Apache que se usa para ejecutar el php. También puede ejecutar este comando para ver la cuenta de usuario:

`<?php
print system("whoami");
?>`

FTP es terriblemente inseguro y es muy probable que haya sido pirateado con este método. Con FTP, puede hacer que los archivos se puedan escribir y luego infectarlos nuevamente. Asegúrese de ejecutar un antivirus en todas las máquinas con acceso FTP. Hay virus que detectan el tráfico local para nombres de usuario y contraseñas FTP y luego inician sesión e infectan los archivos. Si le preocupa la seguridad, usará SFTP, que cifra todo. Enviar código fuente y contraseñas por cable en texto claro es una locura total.

Otra posibilidad es que esté utilizando una biblioteca o aplicación antigua. Visite el sitio del proveedor de software y asegúrese de ejecutar la última versión.

Mis cuentas de Servidor de cuadrícula de Media Temple han sido "pirateadas" de esta manera varias veces. Su seguridad es muy pobre ... comenzó con CONTRASEÑAS DE TEXTO SENCILLO el año pasado y continúa hasta el día de hoy (puede llamar a soporte técnico y dicen "¿cuál es su contraseña?"). Lo sé porque recibo correos electrónicos mensuales sobre cómo han cambiado todas las contraseñas de mi cuenta y realmente entran y cambian las contraseñas de la base de datos cada vez que son pirateadas. Esa compañía parece brillante como el infierno en la superficie, pero el servidor de la red es un desastre. Recomiendo cambiar de inmediato .

Consulte esta publicación del año pasado sobre el fiasco original (advertencia, lo molestará). Se ha ido cuesta abajo desde allí. El año pasado pasé el día de acción de gracias lejos de mi familia y eliminando enlaces porno de mis sitios web. Encantador.

Mantenga un registro de la diversión en su página de estado : le informará sobre los últimos exploits (y, sí, de hecho, hay un "posible exploit" en este momento).

Según la falta de actividad en los registros de acceso, etc., y el hecho de que está ocurriendo aproximadamente al mismo tiempo, parece que han comprometido el servidor y tienen un script de shell de algún tipo ejecutándose para ejecutar el anexo.

¿Has revisado crontab por algo extraño?

¿Has intentado cambiar el nombre del directorio y las referencias a él (esto puede romper el script de shell)?

Sí, definitivamente podría estar relacionado con los permisos de archivo. Al tener archivos que el proceso web puede escribir, está abierto a cualquier vulnerabilidad de seguridad en las aplicaciones web que está ejecutando. Bloquee todo para que el proceso web no pueda leer ni escribir nada más de lo necesario.

El otro componente está rastreando exactamente cómo están modificando sus archivos. Verificar los registros de acceso del servidor web es un buen lugar para comenzar. Verifique los últimos tiempos de inicio de sesión para varios usuarios. ¡También podría configurar un script que supervise los archivos para su modificación y le notifique para que pueda intentar atrapar a los delincuentes con las manos en la masa!

Esto suena terriblemente familiar para los hacks de Wordpress que golpearon una gran cantidad de sitios de Network Solutions últimamente. Como estás en Media Temple, es posible que dejes algunos archivos visibles para otros usuarios que comparten tu máquina. Eso explicaría la falta de POST o los rastros de registro de Apache. Si ese es el caso, sería mortal simplemente inyectar código en la línea de comando.

El código siempre se agrega, siempre en un directorio específico

¿Está relacionado con los permisos establecidos en los archivos (que van desde 755 a 644)? Para el usuario del servidor web

¿Estás en un servidor compartido? Si es así (o incluso si no), alguien puede haber forzado una contraseña FTP y haber subido un script que adjunta cualquier archivo que pueda tener en sus manos.

uno utilizado por un programa publicitario de terceros

O tal vez este programa tiene una hazaña.

Si tiene acceso apropiado (y soporte de kernel), podría intentar crear un demonio de monitoreo basado en inotify o dnotify para observar los cambios en sus archivos, luego (rápidamente) use "lsof" para ver qué proceso tiene abierto el archivo con acceso de escritura También podría usar strace para el monitoreo. Eso debería proporcionar una pista sobre qué ejecutable se está explotando.

FTP inspeccionar registros es el primer lugar para comenzar. El registro debe contener la mayoría, si no toda la actividad, junto con las marcas de tiempo, por lo que si sabe a qué hora se modificaron sus archivos, puede determinar si su cuenta FTP está comprometida o no.

A continuación, podría ser un script en su servidor web que está inyectando ese código. En un escenario de alojamiento compartido, creo que es posible hacer un cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Esto podría funcionar bajo ciertas condiciones, como que el comando ejecutado por el usuario httpd y el archivo index.php también sea propiedad / escribible por ese usuario. En ese caso, debe tener su proveedor de alojamiento para rastrear la cuenta que se utiliza para inyectar los scripts.

La mayoría de los archivos del sitio deben ser legibles por el servidor web. En un sitio de solo lectura, el servidor web solo debe poder escribir los registros. configura el propietario a alguien que no sea el utilizado por el servidor web. Establezca la protección 640 en todos los archivos, excepto los scripts. Establecer scripts y directorios 750. Para los archivos o directorios que deben ser escritos por el servidor web, puede cambiar el propietario al servidor web o configurar el chmod g + 2 para los archivos o directorios relevantes.

Hay muchísimas formas posibles de descifrar un sitio. Podrían haber utilizado una vulnerabilidad en su script, robar su contraseña, usar una vulnerabilidad de un sitio cohospedado (si se encuentra en un host barato), usar una vulnerabilidad de algún servicio no relacionado con la web en la máquina del servidor. .

Como primer paso, verifique la fecha de modificación del archivo y verifique los registros de acceso, error y ftp para detectar cualquier actividad sospechosa en ese momento.

Lo mismo me sucedió hace un tiempo. Wordpress fue el único software que habría causado algo como esto hasta donde yo sé.