PHP shellcode dentro de / tmp. ¿Está el servidor comprometido?

Question

PHP shellcode dentro de / tmp. ¿Está el servidor comprometido?

#1 de David (2 votos)
#2 de Valmiky Arquissandas (1 votos)

2

Tengo un Debian 7 VPS que ejecuta Nginx, PHP5-FPM y MariaDB. Este servidor ejecuta un par de instalaciones de WordPress, phpMyAdmin y Roundcube Webmail. Uno es mi blog personal que ejecuta WP 3.9.1 y otro ejecuta la última versión troncal WP 4.0-beta1 con fines de desarrollo.

Soy la única persona que tiene acceso a SSH y también a wp-admin. El inicio de sesión de raíz a través de SSH está deshabilitado y también lo es el inicio de sesión utilizando contraseñas.

Hoy encontré los siguientes archivos dentro de /tmp .

# ls -l /tmp
total 8
-rw------- 1 www-data www-data 1551 Jul  9 03:22 php9Lg8Js
-rw------- 1 www-data www-data 1551 Jul  9 03:23 phpQNsW36

stat output para los archivos

# stat /tmp/phpQNsW36
  File: '/tmp/phpQNsW36'
  Size: 1551            Blocks: 8          IO Block: 4096   regular file
Device: ca01h/51713d    Inode: 337356      Links: 1
Access: (0600/-rw-------)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2014-07-09 03:23:03.000000000 +0530
Modify: 2014-07-09 03:23:03.000000000 +0530
Change: 2014-07-09 03:23:03.000000000 +0530
 Birth: -

# stat /tmp/php9Lg8Js
  File: '/tmp/php9Lg8Js'
  Size: 1551            Blocks: 8          IO Block: 4096   regular file
Device: ca01h/51713d    Inode: 337355      Links: 1
Access: (0600/-rw-------)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2014-07-09 03:22:27.000000000 +0530
Modify: 2014-07-09 03:22:27.000000000 +0530
Change: 2014-07-09 03:22:27.000000000 +0530
 Birth: -

Ambos archivos contienen el mismo código PHP codificado en base64. Reemplacé eval() con print() para encontrar que era un shellcode PHP que envía por correo electrónico HTTP_HOST y REQUEST_URI a dos direcciones de Gmail, además de imprimir un cuadro de entrada para que el explotador ejecute comandos de shell y cargue archivos.

Puedo publicar este código aquí si es necesario para el análisis y si se me permite hacerlo.

Buscando en el registro de acceso Nginx basado en la marca de tiempo, solo pude encontrar las siguientes solicitudes POST.

121.97.137.10 - - [09/Jul/2014:03:22:27 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"
121.97.137.10 - - [09/Jul/2014:03:23:03 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"

Este servidor NO ejecuta Joomla

Tengo entendido que un BOT estaba explorando aleatoriamente la web en busca de instalaciones de Joomla con el exploit de JCE. PUBLICÓ algún contenido de archivo y cerró la solicitud (estado 499 de Nginx - Solicitud de cliente cerrado). Este contenido PUBLICADO terminó con un tmp_name en el directorio /tmp porque la solicitud no se completó.

¿Esto es correcto?

¿Qué más debo verificar para ver si esto fue solo un intento fallido o algo más que eso?

Avísame si se necesita más información.

linux php nginx shellcode

pregunta A.Jesin 12.07.2014 - 22:16

fuente

2 respuestas

Lea otras preguntas en las etiquetas linux php nginx shellcode

¿El monitoreo de las colmenas del registro es suficiente para detectar una nueva instalación de malware? ¿Alguna vez un paquete IP a la propia dirección IP saldrá de la computadora? [duplicar]

score 2 · Answer 1

Su evaluación suena correcta. Es imposible, por supuesto, decir que su servidor no ha sido comprometido, pero de manera predeterminada, PHP recibe todos los datos antes de ejecutar el script, por lo que escribe las cargas de archivos en / tmp y proporciona ese nombre de archivo al script en ejecución.

Si su /tmp está montado con atime habilitado, el hecho de que atime == mtime sea tranquilizador. Si el atacante encontró una forma de ejecutar esos scripts después de su carga (vulnerabilidad de LFI, por ejemplo), eso cambiaría el atime , por lo que el hecho de que no se haya actualizado indica que no se ejecutaron (nuevamente, si% co_de El% de soporte está habilitado en atime ).

score 1 · Answer 2

¿Dijiste algo sobre la ejecución de phpMyAdmin? ¿Es su directorio estándar y / o está disponible públicamente? (incluso si [usted piensa] nadie tiene la contraseña).

phpMyAdmin suele ser un vector de ataque en servidores web y de bases de datos, y su existencia se busca ampliamente en rastreadores automáticos.

¿Está el servidor comprometido? Como dijo David, no podemos saber si lo fue o no, pero en una buena configuración, el usuario que ejecuta nginx no debería tener acceso a más de lo que realmente necesita ( Principio de privilegio mínimo ), y los permisos se deberían haber configurado en consecuencia, que deberían contener la mayoría de los daños, en caso de que su servidor ejecute código PHP arbitrario.

Probablemente desee considerar que las contraseñas configuradas en los archivos de configuración están en peligro.

Las marcas de tiempo son fáciles de cambiar. Si bien es probable que sean un buen indicador, no confíes demasiado en ellos. Siempre busca los registros a fondo.