Rastrear el origen de un script PHP malicioso

2

Estoy viendo un servidor Linux que ejecuta Apache + mod_php. Un script PHP malicioso fue subido durante la noche. Es propiedad del usuario de Apache y creo que es casi seguro que el script fue generado por un exploit en algunos de nuestros códigos PHP existentes.

Busqué en el registro de Apache los resultados del script, y de ahí obtuve la IP del atacante. Entonces busqué otra actividad por esta IP ... nada. También busqué respuestas del mismo Agente de usuario (en caso de que el atacante se conectara a través de proxies). Nada.

Entonces, puse a punto el registro para POST solicitados problemas en los pocos minutos anteriores al primer golpe en el script malicioso, con la esperanza de encontrar qué script legítimo había explotado el agente. Unos cuantos golpes, pero nada de lo que se destacó. Para cada uno de estos scripts, he adjuntado un código en la parte superior para volcar los datos POST en un archivo de registro.

Luego busqué en el registro de Apache en busca de cadenas como 'lynx', 'wget', 'tmp' en caso de que el ataque hubiera sido a través de GET. Nada.

Así que estoy un poco atascado ahora. Me pregunto si alguien puede pensar en alguna forma inteligente de determinar cómo se cargó este script malicioso o en cualquier otro registro adicional que pudiera implementar. (mod_dumpio es una opción)

    
pregunta Joe Guest 27.04.2016 - 11:07
fuente

2 respuestas

2

Déjame contestar con algunas observaciones y comentarios. Comenzaré con el enfoque de "whodunit" de ayudar a determinar quién, qué, cuándo, dónde y cómo.

  • Qué : un archivo que encontraste en tu sistema
  • Cuándo : en qué fecha se encontró
  • Cómo : cómo se cargó
  • Quién : quién lo subió

Ya conoces el archivo porque lo encontraste. Llamemos a este archivo: malware.php. Lo que mencionas haciendo es determinar " quién " accedió a este archivo, pero debes averiguar how que se subió. Mirar a quién accedió a este archivo es el enfoque equivocado. Esto es porque los atacantes usualmente usan múltiples puntos de ataque. Por ejemplo, un sistema puede escanearlo, otro puede comprometerlo, y otro puede acceder al sistema comprometido. Entonces, averigüemos quién primero usa los métodos deductivos:

$ ls -ltha malicious.php 
-rw-r--r-- 1 www-data www-data 0 Mar 27 10:59 malicious.php

En este caso, vemos que el archivo pertenece al usuario www-data en el grupo www-data. Esto no significa que un atacante lo haya cargado a través de http usando post u get. No hay nada que impida que alguien explote, por ejemplo, telnet, cargue un archivo y realice una comprobación en el archivo.

ls -ltha --time=atime malicious.php 
-rw-r--r-- 1 www-data www-data 0 Apr 27 10:09 malicious.php
ls -ltha --time=ctime malicious.php 
-rw-r--r-- 1 www-data www-data 0 Apr 27 11:00 malicious.php

Aquí podemos ver las diferencias en las marcas de tiempo. Si alguien utiliza, digamos timestomp (Metasploit), se pueden cambiar los tiempos de MAC. Entonces, podemos deducir en los datos anteriores, que estamos más o menos dentro del reino de los 50 minutos. Asegurémonos de que este usuario nunca haya iniciado sesión, para eso podemos verificar wtmp, auth, ftp logs, etc. Si este usuario nunca ha iniciado sesión, podemos luego inferir que esto no se cargó en ningún otra moda fuera de via HTTP.

Cuándo : redujimos el período de tiempo a un período de 51 minutos. Los registros que vería serían los registros de error PRIMERO seguidos del registro de acceso. La razón de esto es simple, en ningún momento un atacante sabría exactamente cómo obtener un archivo en su sistema. Esto significa, hubo un reconocimiento de prueba y error. Esto estará en sus registros de error que aparecen como un 404 o 403. Yo buscaría esos primero. Ahora reduzcamos aún más la búsqueda. Un análisis de registro de las visitas mostrará lo que es normal en comparación con lo que puede ser una anomalía. Por ejemplo, si la base de tráfico va a decir index.html, elimine todas esas instancias y observe las anomalías. Una vez que determine esto, habrá determinado el Cómo . Esto es completamente independiente de averiguar cómo compilaron su código, lo cual sería una pregunta completamente diferente.

    
respondido por el munkeyoto 27.04.2016 - 17:13
fuente
1

Felicitaciones por encontrarlo rápidamente, parece que estás haciendo algo bien. Pero también estás haciendo muchas cosas mal. La más obvia es que los directorios dentro de la raíz de su documento se pueden escribir en el UID del servidor web.

Sería útil saber qué está intentando lograr al "rastrear el origen" del script. Ciertamente, deberías estar buscando la vulnerabilidad que fue explotada para poder tapar el agujero, pero cualquier otra cosa es simplemente curiosidad.

  

grepped el registro para POST solicitó problemas en los pocos minutos anteriores al primer golpe en el script malicioso ... ya había visto la marca de tiempo en el archivo

¿Así que usaste el mtime en el archivo para ubicar las entradas del registro y luego trataste de usar las entradas del registro para determinar la hora de creación? Lógica algo circular aquí.

¿Cuántas entradas de registro tiene 1 segundo a cada lado de la hora de modificación del archivo? ¿A cuántos scripts PHP únicos se resuelve eso? Ciertamente, no puede confiar en que mtime sea una representación precisa de la hora de creación, pero es un comienzo.

Como mínimo, debería revisar todos los scripts de PHP por $ _FILES e incluir / include_once / require / require_once / eval con argumentos no literales.

A qué tipo de registro puede agregar ... no dice qué registro que actualmente tiene instalado . Además de evitar que el weserver escriba en cualquier lugar en la raíz del documento, configure inotify para informar cualquier cambio en los archivos. Sin mencionar los pasos habituales para fortalecer un servidor PHP.

    
respondido por el symcbean 27.04.2016 - 13:52
fuente

Lea otras preguntas en las etiquetas