Página infectada de Drupal 6 con un shell php

0

Tengo un servidor con Drupal 6 que fue hackeado y ahora accediendo a la página principal puedo ver el shell de php. El problema es que no pude encontrar el shell. Los archivos del sitio no están infectados porque copié todos los datos del sitio web en otro servidor y funciona y no se ha cambiado ningún archivo en la última semana. ¿Podría ser el httpd que se empeñó? Si es así, ¿cómo puedo ver porque los registros no ofrecen ninguna pista o información? Descubrí que el shell php se llama FilesMan pero no puedo encontrarlo en ningún archivo con el comando:  %código% Veo un archivo extraño en / tmp llamado trolled ... el contenido del archivo se puede descargar desde aquí

    
pregunta calculataur 11.11.2014 - 11:14
fuente

2 respuestas

2

Su servidor en sí mismo (no Drupal) se vio comprometido por un exploit local de Linux (root). Aunque Drupal pudo haber ayudado a obtener el exploit en su máquina, su máquina fue explotada con CVE- 2013-2094 , el " semtex.c exploit "

$ md5 fileshare.ro_trolled
MD5 (fileshare.ro_trolled) = ff1e9d1fc459dd83333fd94dbe36229a

$ strings fileshare.ro_trolled | grep -i @fu
[email protected] 2010

La limpieza de Drupal no hará nada por ti, yo ampliando lo que hace el exploit sería reinventar la rueda, puedes leer sobre lo que hace el exploit (desde entonces se ha portado a perf) here

Mi sugerencia es comenzar desde cero con una instalación limpia. El único mecanismo para garantizar que nada más esté en la puerta trasera (top, netstat, etc.) sería haber estado ejecutando Tripwire o algo similar, donde puede regresar y comparar sumas de comprobación a fuentes confiables.

    
respondido por el munkeyoto 11.11.2014 - 14:16
fuente
0

Usted preguntó cómo encontrar el software malicioso en un servidor comprometido. La respuesta corta es que no puedes. Es posible que pueda encontrar algunos de los componentes instalados por el compromiso, pero para estar seguro, debe estar seguro de que lo ha encontrado todo y no puede hacerlo. (Con los sistemas operativos modernos y complejos, equivale a ser negativo).

Una vez que una máquina se ha visto comprometida, lo más seguro solo es borrarla y reconstruirla, porque de lo contrario nunca podrá estar seguro de haber eliminado todo el código malicioso.

Para su caso particular, Drupal tiene algunos consejos sobre la recuperación aquí: enlace No podrá volver a instalar el Código de Drupal que tienes. La máquina reconstruida debe tener solo un código nuevo y limpio, además de los datos de limpiar del sitio anterior. Un ejemplo de datos que podrían no estar limpios es una tabla de contraseñas. Los atacantes pueden haber creado nuevas entradas de usuario o cambiar las contraseñas de las entradas existentes. Por lo tanto, deberá restaurar la tabla de contraseñas a partir de una copia de seguridad realizada antes del compromiso.

    
respondido por el Bob Brown 11.11.2014 - 13:17
fuente

Lea otras preguntas en las etiquetas