¿Determinar el punto de compromiso en un servidor web infectado?

Question

¿Determinar el punto de compromiso en un servidor web infectado?

#1 de Beeblebrox (3 votos)
#2 de jippie (2 votos)
#3 de Todd Dill (2 votos)
#4 de Zzz (1 votos)

3

Recientemente, un amigo mío ha visto comprometido su servidor web: todos los archivos PHP fueron inyectados con código malicioso, en particular uno que parece llamarse "GetMama". Si observo esto, parece que la mayoría de la gente dice que es un malware que se dirige a las instalaciones de WordPress (y no puedo encontrar nada al contrario). Su sitio, sin embargo, no tiene ninguna instalación de WordPress en él. El servidor es hosting compartido cortesía de BlueHost, con acceso SSH / FTP. Si GetMama está destinado a ser un virus automatizado, me encantaría saber cómo comprometió el sitio sin ninguna instalación de WordPress. Después de limpiar GetMama de todos los archivos infectados con un poco de magia regex, unos días más tarde estaría de vuelta. Busqué en el sitio alguna señal de compromiso, pero no pude encontrar ninguna. Los registros de acceso solo se remontan a 24 horas o menos (no estoy seguro de si se trata de una política de BlueHost o de que se eliminen los registros). Otros síntomas incluyen un compromiso manual de la cuenta del administrador del foro, que inyecta código malicioso en las plantillas de vBulletin. El propietario del sitio cambió las contraseñas y no hubo más compromisos en el foro. Después de pensar que el sitio finalmente estuvo limpio por un tiempo, se envió un JS malicioso a los usuarios mediante un redireccionamiento 301 en un archivo .htaccess.

Básicamente, agradecería saber cómo lidiarían con una situación como esta. No puedo averiguar cómo encontrar el punto de compromiso. Por ejemplo, ese archivo .htaccess apareció en los últimos días, pero no hay datos registrados sobre cómo, solo cuándo. Al igual que con la inyección maliciosa de código PHP, no veo ningún dato sobre qué modificó esos archivos. Cambiamos las contraseñas, pero aún así, SSH no informa a ningún usuario no autorizado que haya iniciado sesión en los últimos meses (al menos). ¿Qué métodos podría usar para analizar infecciones futuras y ubicar su punto de compromiso (teniendo en cuenta que estoy en un alojamiento compartido sin privilegios de root para trabajar)?

webserver linux incident-response

pregunta Moocow 21.06.2012 - 01:02

fuente

4 respuestas

Lea otras preguntas en las etiquetas webserver linux incident-response

¿Las cookies flash son todavía una amenaza y son persistentes? Accedí de forma fortuita a la configuración de un enrutador desconocido: ¿por qué y ahora qué?

score 3 · Answer 1

Ah, las alegrías del hosting compartido. Puede estar seguro al 99.9% de que en este incidente, este script automatizado piratea otro servicio de alojamiento compartido en el mismo servidor, que ejecuta WordPress. Esto respondería a la primera parte de tu pregunta.

La pregunta subyacente es "¿cómo afectó la cuenta de otra persona a mi cuenta?". Si este ataque automático GetMama no ejecutó algún tipo de comando exec () de PHP para explotar una vulnerabilidad de Linux, entonces hay algún tipo de problema de permisos que BlueHost debe abordar. Estas cosas pueden ingresar a otras cuentas de muchas maneras, incluso a través de servidores de bases de datos compartidas con permisos de usuario incorrectos especificados.

(descargo de responsabilidad: esta es una respuesta general, no busqué en Google 'GetMama' en absoluto)

En general, es un excelente ejemplo de la importancia de mantener sus aplicaciones web actualizadas. Los paquetes especialmente populares, como WordPress o vBulletin, por su amplio uso los convierten en objetivos obvios. Mantener las cosas actualizadas ayuda a mantener su sitio más seguro y también lo ayuda a ser un buen vecino al reducir el potencial de problemas para otros usuarios. Lo mismo ocurre con las personas que ejecutan los servidores.

La mejor manera de protegerse contra esto es no usar el alojamiento compartido. En estos días se puede encontrar un VPS de baja especificación por el precio del alojamiento compartido decente (~ $ 30 / m).

score 2 · Answer 2

Comience por cambiar la contraseña de su servidor web.
Desconecte el sitio web, no desea infectar a los visitantes con el código malicioso que proporciona su sitio web.

Entonces:

Comience por verificar cuándo cambian los primeros archivos (o su propiedad / permiso). Esto se puede hacer fácilmente desde las copias de seguridad diarias que realice. Normalmente, los archivos que no cambian no se encuentran en copias de seguridad incrementales, por lo que si sus registros inician repentinamente para mostrar los archivos .php, determinará el día en que se cambiaron los archivos. Por supuesto, los archivos de registro también deben estar en la copia de seguridad.
Otro método, pero menos confiable, es verificar la marca de fecha / hora en varios archivos en el servidor. Este método es menos confiable, porque las marcas de tiempo se pueden cambiar fácilmente a cualquier cosa que desee.
Ahora que tiene una fecha, verifique los archivos de registro (apache). Tanto los registros de error como los de acceso, y ver si puede encontrar el ataque entre el tráfico normal.
Compruebe la propiedad y los permisos en los archivos. ¿Eres el único que puede escribir en los archivos y directorios? ¿Es usted y el servidor web (apache?) Los únicos con acceso de lectura a los archivos?

Entonces:

Restaure todos los archivos desde la copia de seguridad y arregle la vulnerabilidad antes de volver a conectarse. Si no encuentra y corrige la vulnerabilidad, será hackeado nuevamente en un par de días.

score 2 · Answer 3

Algo similar me sucedió en mis instalaciones de MediaWiki y WordPress. Aquí es cómo lo traté.

Como se mencionó en otras respuestas, cambie sus contraseñas. Los cambié a todos solo para estar seguros: administrador del sitio, FTP, SSH, todas las contraseñas de administrador de la aplicación, las contraseñas de MySQL, etc. Esto debería hacerse periódicamente de todos modos, por lo que, justo después de que haya sido hackeado, es probablemente un buen momento para volver a la rutina.
Actualicé todas las instancias de mi aplicación a la última versión. Mi instalación de MediaWiki fue un par de versiones menores desactualizadas.
Si la versión de PHP que está ejecutando tiene la vulnerabilidad php_register_variable_ex , cámbiela. El mio lo hizo enlace
La herramienta de limpieza de PHP de Ran Paulo. enlace . Tuve que ejecutar esto varias veces para obtener todo.
Como también se mencionó, verifique los permisos de su archivo y directorio y asegúrese de que no tenga permiso de escritura abierta para nada en lo que no desee específicamente. Tuve algún widget del tiempo de Yahoo en una de mis instalaciones de WordPress que tenía 777 en un directorio de caché. Se deshizo de eso.

Después de estos 5 pasos, no he tenido una recurrencia de este ataque en ninguno de mis sitios. Han estado limpios por meses ahora.

Usé esto como referencia cuando limpié mis sitios: enlace .

score 1 · Answer 4

Ya que es un alojamiento compartido, es bastante probable que la cuenta de otra persona esté comprometida y se use para leer / escribir archivos de otras cuentas. Es difícil decir cómo resolverlo sin saber cómo está configurado el servidor. Si los scripts php se ejecutan como usuario de su cuenta, puede comenzar a verificar los permisos de sus archivos y directorios para asegurarse de que no tengan acceso de lectura / escritura para todos.