Fue manipulado. ¿Quieres entender cómo

40

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),

Lothar_Grimpsenbacher
fuente
66
No sé, ¿le diste tu contraseña a alguien?
44
Si sabe cuándo sucede exactamente esto, busque en su access_log todo lo inusual en este momento. Especialmente tome nota de todas las solicitudes POST: a dónde van, qué hicieron.
sanmai
3
Thx WhirlWind ... muy útil.
Lothar_Grimpsenbacher
2
En realidad, si los conoce, ¿por qué no pegar los detalles de su dirección en un sitio antispam? Deje que la red les "hable" y les dé una probada de su propia medicina. :-)
44
@ gaoshan88: más útil de lo que piensas. Un vector de ataque es un troyano que detecta las contraseñas de los clientes ftp de los desarrolladores.
Quentin

Respuestas:

9

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.

Torre
fuente
66
+1, evita FTP como una plaga. Un troyano rastreador de contraseñas puede infectar su computadora y usar sus credenciales para cambiar archivos. O puede infectar su enrutador. O la computadora de su vecino en el netcafe con la red wifi no segura. Enviar la contraseña en texto claro es una mala, mala idea.
Tgr
1
FTP no vienen con SSL, ya sabes.
Grawity
1
@grawity la mayoría de la gente no usa "ftps", pero eso evitará que te hackeen. sftp es más popular.
Torre de
2
El www-data NO debe poseer archivos en su directorio web. Cualquier cosa que www-data pueda actualizarse mediante un script mal escrito en el servidor.
Zoredache
9

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).

typeoneerror
fuente
jaja. mis sitios gs están todos caídos en este momento. sin correo electrónico. weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror
2

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)?

abarax
fuente
renombrar es una buena idea. Lo intentaré una vez que vea qué efectos tendrá en el sitio. Crontab tenía una cosa un poco extraña, hay una entrada para el momento en que se cambiaron los archivos, pero es el administrador de copias de seguridad de Plesk ... una aplicación compilada. Si eso se ve comprometido, Media Temple tiene un gran problema en sus manos.
Lothar_Grimpsenbacher
1

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!


fuente
1

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.

editor
fuente
Los registros muestran el tráfico en el momento en que se modificaron estos archivos, pero es algo inocuo como: 207.46.13.43 - - [05 / mayo / 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 & page = 4 HTTP / 1.1 "404 257" - "" msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher
¿Sabes cómo funcionó ese truco de Wordpress? Podría decirme cómo solucionar mi propio problema.
Lothar_Grimpsenbacher
2
Sí, se trataba de malos permisos en cajas compartidas, posiblemente causadas por malas configuraciones predeterminadas por parte de Network Solutions. La solución recomendada era bloquear los permisos como 755 en carpetas y 644 en archivos.
1

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.

webbiedave
fuente
Supongo que puede ser que el código de un tercero tenga un exploit. Está en un servidor compartido, pero habría encontrado los scripts cargados (a menos que lo hayan subido, lo haya usado y luego lo haya eliminado, pero incluso así habría encontrado algo en los archivos de registro que muestra su conexión ftp)
Lothar_Grimpsenbacher
1
Si el servidor web puede escribir sus archivos, es posible que hayan cargado el script en cualquier sitio web del servidor y hayan sobrescrito sus archivos. Pero también miraría de cerca esa aplicación de terceros.
El código de terceros ... ¿es un script ejecutable o simplemente un fragmento de JavaScript? JavaScript no puede modificar archivos en el servidor.
Salman A
@Salman A: es una colección de scripts PHP que gestionan la publicidad.
Lothar_Grimpsenbacher
Bien, entonces espero que hayas investigado ese código.
Salman A
1

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.

outis
fuente
1

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.

Salman A
fuente
1

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.

BillThor
fuente
Las secuencias de comandos que no son CGI a menudo pueden tener el modo 600 o 640 (dependiendo del propietario y grupo del archivo y del usuario con el que se ejecuta el servidor web), ya que muchas secuencias de comandos se pasan a un intérprete.
outis
0

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.

Tgr
fuente
0

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

Joe Phillips
fuente
No hay Wordpress involucrado aquí.
Lothar_Grimpsenbacher