shellcode PHP dentro / tmp. Il server è compromesso?

Question

shellcode PHP dentro / tmp. Il server è compromesso?

#1 da (2 voti)
#2 da (1 voti)

2

Ho un Debian 7 VPS che esegue Nginx, PHP5-FPM e MariaDB. Questo server esegue un paio di installazioni WordPress, phpMyAdmin e Roundcube Webmail. Uno è il mio blog personale che esegue WP 3.9.1 e un altro esegue l'ultima versione del trunk WP 4.0-beta1 a scopo di sviluppo.

Sono l'unica persona ad avere accesso SSH e accesso a wp-admin. L'accesso root tramite SSH è disabilitato e quindi è necessario accedere utilizzando le password.

Oggi ho trovato i seguenti file all'interno di /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 per i file

# 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: -

Entrambi questi file contengono lo stesso codice PHP codificato in base 64. Ho sostituito eval() con print() per scoprire che si trattava di uno shellcode PHP che inviava email a HTTP_HOST e REQUEST_URI a due indirizzi Gmail oltre a stampare una casella di input per lo sfruttatore per eseguire comandi shell e caricare file.

Posso inserire questo codice qui se è necessario per l'analisi e se sono autorizzato a farlo.

Cercando il log di accesso di Nginx in base al timestamp, ho potuto trovare solo le seguenti richieste 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)"

Questo server NON esegue Joomla

La mia comprensione è che un BOT ha analizzato casualmente il web per le installazioni di Joomla con l'exploit JCE. Ha inviato il contenuto di alcuni file e ha chiuso la richiesta (stato Nginx 499 - Richiesta chiusa client). Questo contenuto POST ha finito con un tmp_name nella directory /tmp quando la richiesta non è stata completata.

È corretto?

Che altro dovrei controllare per vedere se questo era solo un tentativo fallito o qualcosa di più?

Fammi sapere se sono necessarie ulteriori informazioni.

linux php nginx shellcode

posta A.Jesin 12.07.2014 - 22:16

fonte

2 risposte

Leggi altre domande sui tag linux php nginx shellcode

Come mantenere aggiornati i programmi Controllo registri eventi di un sistema

score 2 · Answer 1

La tua valutazione sembra corretta. È impossibile, ovviamente, dire che il tuo server non è stato compromesso, ma per impostazione predefinita, PHP riceve tutti i dati prima di eseguire lo script, quindi scrive upload di file in / tmp e fornisce quel nome di file allo script in esecuzione.

Se la tua /tmp è montata con atime abilitata, il fatto che atime == mtime è rassicurante. Se l'autore dell'attacco ha trovato un modo per eseguire quegli script dopo il loro caricamento (vulnerabilità LFI, ad esempio), ciò cambierebbe il atime , quindi il fatto che non fosse aggiornato indicava che non erano stati eseguiti (di nuovo, se atime support è abilitato su /tmp ).

score 1 · Answer 2

Hai detto qualcosa sull'esecuzione di phpMyAdmin? La sua directory è standard e / o pubblicamente disponibile? (anche se [tu pensi] nessuno ha la password).

phpMyAdmin è solitamente un vettore di attacco su server Web e database e la sua esistenza è ampiamente ricercata su crawler automatizzati.

Il server è stato compromesso? Come ha detto David, non possiamo dire se fosse o meno, ma in una buona configurazione, l'utente che esegue nginx non dovrebbe avere accesso a più di quello che ha realmente bisogno (il Principle of least privilege ), e le autorizzazioni dovrebbero essere state impostate di conseguenza - che dovrebbe contenere la maggior parte dei danni, nel caso in cui il server esegua codice PHP arbitrario.

Probabilmente vorrai considerare compromesse tutte le password impostate nei file di configurazione.

I timestamp sono facili da cambiare. Mentre sono probabilmente un buon indicatore, non fare troppo affidamento su di essi. Cerca sempre accuratamente i log.