PHP malware / shell sigue resucitando [duplicado]

Permitiría que auditd monitoree los cambios en los archivos que espera que estén bloqueados. Podrá determinar qué cuenta y proceso es responsable de realizar estos cambios.

Después de instalar auditd (no instalado pr predeterminado en todos los sistemas), puede comenzar a monitorear los cambios en los archivos. Para hacer esto, simplemente ejecute el comando:

auditctl -w /var/www -p wa

Este comando registrará todos los cambios de archivo en el archivo de registro de auditd. Generalmente lo encontrará en / var / log / audit /, pero depende del sistema.

Si le preocupa que el atacante pueda notar esto (y tal vez eliminar la regla), puede bloquearlo ejecutando el comando:

auditctl -e 2

No se pueden realizar más cambios en las reglas de auditoría hasta que se reinicie el sistema. Antes de hacer esto, asegúrese de que la regla de auditoría anterior no genere una cantidad insana de registros.

Por último, los registros de auditoría son un poco crípticos. Una vez que haya encontrado que el sistema está en la puerta trasera nuevamente, puede buscar la pista de auditoría, usando el comando:

ausearch -f /var/www/backdoored_file.php

Espero que esto te proporcione las pistas sobre lo que está sucediendo. Buena suerte!

Adicional:

Para hacer que las reglas de auditoría sobrevivan al reinicio, debe definirlas en /etc/audit/audit.rules

Originalmente publiqué esto como un comentario, pero creo que esto podría hacer con una pequeña explicación.

Desde mi experiencia con los escenarios de toma de control de sitios web, cuando se carga un shell en un sitio web, el pirata informático se las arregla para explotar una vulnerabilidad en el servidor, obtener acceso de root, proteger su SSH y comprometer a todos los demás sitios del servidor, o Simplemente no logra esto y se conforma con un shell simple. Creo que, en su caso, es el segundo escenario, dado que usted dice que solo un sitio web en el VPS estaba infectado.

Ahora, ¿cómo hace el shell "resucitar". Si su servidor no estaba "rooteado", eso deja solo otras cuatro opciones que se me ocurren:

1. un "bindport" backdoor
2. un "backconnect" backdoor (raro)
3. un backdoor personalizado o un "descargador" en uno de tus archivos PHP
4. una cuenta MySQL comprometida con acceso a archivos y privilegios de inicio de sesión remoto.

Hablemos de los primeros dos y de cómo tratarlos primero. "bindport" y "backconnect" son dos pequeños programas, generalmente scripts de Perl, que tradicionalmente se envían con shells web. Por lo general, se crean en (y se ejecutan desde) la carpeta /tmp , que se puede escribir en todo. Para encontrarlos, puedes monitorear todos tus procesos en busca de scripts o programas extraños y tener un buen aspecto en la carpeta /tmp . Además, es aconsejable configurar un firewall.

"Bindport" abre un nuevo puerto para las conexiones entrantes y proporciona acceso de shell de Unix a cualquiera que llame (generalmente está protegido por contraseña). Para encontrarlo, busque puertos abiertos raros (muchos hackers solo lo tienen abierto port 31337 o algo así).

"Backconnect" hace exactamente lo que se llama: abre una conexión a un servidor remoto y también le otorga acceso a la shell. Se usa más raramente que "bindport", principalmente porque la mayoría de los hackers son demasiado perezosos para molestarse en usarlo. Normalmente recurren a este método solo si "bindport" falla por algún motivo (como la configuración del firewall).

Ahora, sobre puertas traseras personalizadas y "descargadores" . Rara vez se usan, porque el atacante necesita saber PHP al menos un poco para usarlo (y la mayoría de los usuarios de sitios no son más que skriptkiddies o bots mal hechos). En su mayoría son archivos independientes, como shells simplistas, o un par de líneas adicionales de código inyectadas en uno de sus scripts. O bien ejecutan los comandos que se les dan (código PHP, comandos de shell) o hacen una simple escritura de archivos con los datos que se les han pegado (lo que puede ser otra puerta trasera). Puede intentar buscar archivos que tengan código PHP como eval , preg_replace con el modificador e , exec , system , fopen / fwrite y otras funciones de archivo, etc. Sin embargo, la mejor y la forma más segura de lidiar con esto es simplemente restaurar todo el sitio web desde una copia de seguridad . Si decides hacer esto, asegúrate de borrar de antemano todos los demás archivos del sitio del servidor, en caso de que te hayas perdido un shell independiente o una puerta trasera.

Y el último caso altamente improbable, pero todavía posible. Si ha estado ejecutando WordPress con el usuario root de MySQL (o simplemente un usuario con derechos de escritura de archivo), o simplemente con un usuario que tenía suficientes derechos para ver el hash de contraseña de otro usuario con derechos de escritura de archivo, y ese usuario con archivo Los derechos de escritura tienen el privilegio de conectarse a la base de datos desde cualquier lugar, bueno ... lo consigues. Recomiendo cambiar todas tus contraseñas de MySQL.

Ahora a por qué solo un determinado conjunto de directorios se infecta . Hay dos casos posibles: el pirata informático, al no haber "rooteado" el servidor, arreglárselas con la cantidad limitada de directorios disponibles (probablemente todos los directorios de su sitio web), o tienen acceso a otros directorios, pero simplemente no lo hacen. t utilizarlos.

Si es el último caso, apostaría a que, o bien estás tratando con un idiota, o alguien extremadamente perezoso. O con un bot. Sí, esto puede decepcionarlo, pero dudo que su sitio sea lo suficientemente importante para un pirata informático con experiencia: podría ser usado para captar algunos clics de sus usuarios, alojar malware o simplemente generar una tonelada métrica de spam en un par de veces. O estás tratando con un scriptkiddie, o con un tonto inexperto que intenta eliminar un par de centavos del intercambio de clics y el spam, o con un bot. Sin embargo, creo que es más probable que sea una persona viva: eso explicaría la irregularidad de las "resurecciones" de la concha.

Me ha pasado algo muy similar a un sitio que administro. Después de mucha frustración de eliminar el código malicioso y luego de aparecer 2 semanas después, descubrí esto:

Tomé nota de la marca de fecha de cuando todos los archivos se modificaron, luego busqué el registro de acceso para ese minuto. Vi que se solicitó cierta página que parecía sospechosa, ya que era un tema de 404 ppp de wordpress que no estaba activo. Revisé esa página y vi una línea que estaba básicamente codificada por eval($_POST['php']) en base64.

Así que no eliminé el código, en lugar de eso lo cambié, guardé un registro de todo lo que se envió a la publicación de esa página. 2 semanas después, mi sitio permaneció seguro, pero un archivo de registro registró un código interesante que se le envió.

Parece que los atacantes han instalado un rootkit en su servidor. Un rootkit puede proporcionar una puerta trasera incluso si todo parece limpio.

El mejor enfoque ahora en mi opinión sería limpiar el servidor y reinstalarlo desde cero. Parche los sitios web para eliminar la vulnerabilidad. Si necesita restaurar desde una copia de seguridad (tiene copias de seguridad, ¿verdad? :)) asegúrese de que esté limpia.

Configure una secuencia de comandos para buscar los rastros de infección (por ejemplo, el usuario del ID 10001) en caso de que existan otras vulnerabilidades además del problema de MailPoet.

Si no sabes cómo te infectaste en primer lugar, entonces supongo que la resurrección proviene de que te golpee el mismo escáner de vulnerabilidades que te golpeó la primera vez, si este es el caso, Siguiendo el consejo de @ scrollup para comparar las marcas de tiempo de los archivos con el tráfico web, debería encontrar el script vulnerable, además de proporcionarle algunas buenas direcciones IP para bloquear desde su sitio.

En mi experiencia, al menos cuando se dirige a Apache, los scripts de modificación de página se dirigirán a un subconjunto muy específico de las carpetas en su máquina: las que pueden encontrar en su carpeta /etc/httpd/conf/httpd.conf. Tenía otras carpetas web definidas en los archivos incluidos, pero la secuencia de comandos que buscaba las carpetas para inyectar estaba claramente interesada en grepping las carpetas de un solo archivo.

Entonces, vea si hay algo significativamente diferente en su configuración de Apache entre los sitios que se vieron afectados y los que no lo fueron. Es posible que le brinde un buen enfoque para proteger la mayoría de sus sitios de él en el futuro, mientras deja un sitio "canary" o "honeypot" que puede supervisar en caso de recurrencia.

Esto puede parecer una pregunta simple, pero ¿has comprobado algo sospechoso en tu directorio /tmp ? Si bien hay diferentes variantes de malware por todas partes, muchos se aprovechan de los errores de acceso al sistema, como el error bash shellshock, para plantar código ejecutable en el directorio /tmp .

Si no está seguro de lo que debería / no debería estar en /tmp/ , hay una cosa fácil, pero extrema, que puede hacer para eliminar las cosas malas. Simplemente ejecute esto en línea en la línea de comando:

rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp

O ejecuta cada comando individualmente de esta manera:

sudo rm -rf /tmp 
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp

Luego reinicia el servidor para ver si eso aclara las cosas. Si lo hace, felicidades! Pero todavía no está fuera de peligro, ya que lo que causó la infección del sistema original aún podría penetrar en su sistema, es solo cuestión de tiempo antes de que vuelvan a infectarse. Lo que significa que, con suerte, esto solucionará el desorden causado por una debilidad en su sistema que esperamos que ya se haya conectado. Pero debe asegurarse de averiguar cuál pudo haber sido ese punto débil y de endurecerlo.

También recomendaría verificar las entradas de crontab para el usuario raíz a través de un simple crontab -l como este:

sudo crontab -l

Y tal vez incluso ejecutando el script de bash tomado de esta respuesta en Stack Overflow , que le proporcionará un buen informe general de todos Crontabs instalados en el sistema:

#!/bin/bash

# System-wide crontab file and cron job directory. Change these for your system.
CRONTAB='/etc/crontab'
CRONDIR='/etc/cron.d'

# Single tab character. Annoyingly necessary.
tab=$(echo -en "\t")

# Given a stream of crontab lines, exclude non-cron job lines, replace
# whitespace characters with a single space, and remove any spaces from the
# beginning of each line.
function clean_cron_lines() {
    while read line ; do
        echo "${line}" |
            egrep --invert-match '^($|\s*#|\s*[[:alnum:]_]+=)' |
            sed --regexp-extended "s/\s+/ /g" |
            sed --regexp-extended "s/^ //"
    done;
}

# Given a stream of cleaned crontab lines, echo any that don't include the
# run-parts command, and for those that do, show each job file in the run-parts
# directory as if it were scheduled explicitly.
function lookup_run_parts() {
    while read line ; do
        match=$(echo "${line}" | egrep -o 'run-parts (-{1,2}\S+ )*\S+')

        if [[ -z "${match}" ]] ; then
            echo "${line}"
        else
            cron_fields=$(echo "${line}" | cut -f1-6 -d' ')
            cron_job_dir=$(echo  "${match}" | awk '{print $NF}')

            if [[ -d "${cron_job_dir}" ]] ; then
                for cron_job_file in "${cron_job_dir}"/* ; do  # */ <not a comment>
                    [[ -f "${cron_job_file}" ]] && echo "${cron_fields} ${cron_job_file}"
                done
            fi
        fi
    done;
}

# Temporary file for crontab lines.
temp=$(mktemp) || exit 1

# Add all of the jobs from the system-wide crontab file.
cat "${CRONTAB}" | clean_cron_lines | lookup_run_parts >"${temp}" 

# Add all of the jobs from the system-wide cron directory.
cat "${CRONDIR}"/* | clean_cron_lines >>"${temp}"  # */ <not a comment>

# Add each user's crontab (if it exists). Insert the user's name between the
# five time fields and the command.
while read user ; do
    crontab -l -u "${user}" 2>/dev/null |
        clean_cron_lines |
        sed --regexp-extended "s/^((\S+ +){5})(.+)$/${user} /" >>"${temp}"
done < <(cut --fields=1 --delimiter=: /etc/passwd)

# Output the collected crontab lines. Replace the single spaces between the
# fields with tab characters, sort the lines by hour and minute, insert the
# header line, and format the results as a table.
cat "${temp}" |
    sed --regexp-extended "s/^(\S+) +(\S+) +(\S+) +(\S+) +(\S+) +(\S+) +(.*)$/\t\t\t\t\t\t/" |
    sort --numeric-sort --field-separator="${tab}" --key=2,1 |
    sed "1i\mi\th\td\tm\tw\tuser\tcommand" |
    column -s"${tab}" -t

rm --force "${temp}"

Tan complejo como pueden parecer las infecciones de malware, una vez que sepa dónde están los puntos de estrangulamiento comunes, puede enfocar sus esfuerzos para purgar su sistema de esa basura de una vez por todas.

No hay suficiente información en tu publicación para determinar la causa de esto. Tendrás que hacer un poco de investigación. Lo primero que debe verificar es la hora de creación / modificación de los archivos y luego compararlos con sus registros de acceso y FTP aproximadamente al mismo tiempo para determinar cómo se modificaron los archivos. Esperamos que esto lo lleve a algún archivo /plugin/.shell.php que quede fuera de la puerta trasera de la infección inicial. Si sus registros no parecen contener nada útil, es posible que se haya creado una cuenta de puerta trasera en su instalación de WP y lo que está viendo es el resultado de "operaciones normales" por parte de un usuario malintencionado.

¿Por qué no configurar un reloj en la creación del nuevo usuario? Y una vez que eso sucede, envías un correo externo para informarte de la creación.