Determinazione del punto di compromesso su un server Web infetto?

Question

Determinazione del punto di compromesso su un server Web infetto?

#1 da (3 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (1 voti)

3

Recentemente un mio amico ha avuto il suo server Web compromesso - tutti i file PHP sono stati iniettati con codice dannoso, in particolare uno che sembra chiamato "GetMama". Se osservo questo aspetto, sembra che la maggior parte delle persone affermi che si tratta di un malware che si rivolge alle installazioni di WordPress (e non riesco a trovare nulla in contrario). Il suo sito tuttavia non ha alcuna installazione WordPress su di esso. Il server è condiviso per gentile concessione di BlueHost, con accesso SSH / FTP. Se GetMama è pensato per essere un virus automatizzato, mi piacerebbe sapere come ha compromesso il sito senza alcuna installazione di WordPress. Dopo aver pulito GetMama da tutti i file infetti con alcune regex magic, alcuni giorni dopo sarebbe tornato. Ho cercato nel sito qualsiasi segno di compromesso, ma non sono riuscito a trovarne. I registri di accesso sembrano datare solo indietro di 24 ore o meno (non sono sicuro se questa è la politica di BlueHost oi log che vengono cancellati). Altri sintomi includevano una compromissione manuale dell'account dell'amministratore del forum, l'iniezione di codice dannoso nei modelli di vBulletin. Il proprietario del sito ha cambiato le password e non ci sono stati ulteriori compromessi del forum. Dopo aver pensato che il sito era finalmente pulito per un po ', JS malizioso è stato inviato agli utenti da un reindirizzamento 301 in un file .htaccess.

Fondamentalmente, mi piacerebbe sapere come voi ragazzi dovreste affrontare una situazione come questa. Non riesco a capire come trovare il punto di compromesso. Ad esempio, quel file .htaccess è spuntato negli ultimi giorni, ma non ci sono dati registrati su come - solo quando. Lo stesso con l'iniezione di codice PHP dannoso, non vedo alcun dato su cosa ha modificato quei file. Abbiamo cambiato le password, ma anche così, SSH non segnala alcun utente non autorizzato che ha effettuato l'accesso negli ultimi mesi (almeno). Quali metodi posso utilizzare per analizzare le infezioni future e individuare il loro punto di compromesso (tenendo presente che sono in hosting condiviso senza privilegi di root con cui lavorare)?

linux webserver incident-response

posta Moocow 21.06.2012 - 01:02

fonte

4 risposte

Leggi altre domande sui tag linux webserver incident-response

Migliorare la privacy di un utente Web occasionale Utilizzo di Cain e Abel per acquisire il traffico della macchina nella stessa rete

score 3 · Answer 1

Ah, le gioie dell'hosting condiviso. Puoi essere sicuro al 99,9% che in questo incidente, un altro servizio di hosting condiviso sullo stesso server, che esegue WordPress, sia stato violato da questo script automatico. Questo risponderebbe alla prima parte della tua domanda.

La domanda di fondo è "come ha compromesso l'account di qualcun altro sul mio account?". Se questo attacco automatico di GetMama non ha eseguito una sorta di comando PHP exec () per sfruttare una vulnerabilità di Linux, allora c'è un qualche tipo di problema di permessi che BlueHost deve affrontare. Queste cose possono entrare in altri account in molti modi, anche attraverso server di database condivisi con le autorizzazioni utente errate specificate.

(disclaimer - questa è una risposta generale, non ho affatto google "GetMama")

Tutto sommato è un primo esempio dell'importanza di mantenere aggiornate le tue webapp. Pacchetti particolarmente popolari come WordPress o vBulletin come il loro uso diffuso li rende obiettivi ovvi. Mantenere le cose aggiornate aiuta a mantenere il sito più sicuro e aiuta anche a essere un buon vicino riducendo il potenziale di problemi per gli altri utenti. Lo stesso vale per le persone che eseguono i server.

Il modo migliore per proteggersi da questo è non usare l'hosting condiviso. Al giorno d'oggi si può trovare un VPS a bassa specifica per il prezzo dell'host condiviso decente (~ $ 30 / m).

score 2 · Answer 2

Inizia cambiando la password sul tuo server web.
Porta il sito web offline, non vuoi infettare i visitatori con codice malevolo servito dal tuo sito web.

Quindi:

Inizia controllando quando i primi file (o la loro proprietà / permesso) cambiano. Questo può essere fatto facilmente dai backup giornalieri effettuati. Normalmente i file che non cambiano non sono in backup incrementali, quindi se i tuoi log iniziano all'improvviso a mostrare file .php, hai determinato il giorno in cui i file sono stati modificati. Ovviamente anche i file di registro dovrebbero essere nel backup.
Un altro metodo, ma meno affidabile, è il controllo dell'ora / data su vari file sul server. Questo metodo è meno affidabile, perché i timestamp possono essere facilmente modificati in qualsiasi cosa tu voglia.
Ora hai una data, controlla i file di log (apache). Sia l'errore che i log di accesso e vediamo se riesci a trovare l'attacco tra il traffico normale.
Controlla la proprietà e le autorizzazioni sui file. Sei l'unico in grado di scrivere su file e directory? Sei tu e il webserver (apache?) Gli unici con accesso in lettura ai file?

Quindi:

Ripristina tutti i file dal backup e corregge la vulnerabilità prima di tornare online. Se non trovi e correggi la vulnerabilità, verrai nuovamente compromesso in un paio di giorni.

score 2 · Answer 3

Una cosa simile mi è successo nelle mie installazioni MediaWiki e WordPress. Ecco come l'ho affrontato.

Come menzionato in altre risposte, cambia le tue password. Li ho cambiati tutti solo per essere sicuri: amministratore del sito, FTP, SSH, tutte le password degli amministratori delle app, le password MySQL, ecc. Questo dovrebbe essere fatto periodicamente comunque, quindi subito dopo essere stato violato è davvero un buon momento per riprendi la routine.
Ho aggiornato tutte le istanze dell'applicazione alla versione più recente. La mia installazione MediaWiki era un paio di versioni secondarie scadute.
Se la versione di PHP in esecuzione presenta la vulnerabilità php_register_variable_ex , modificala. Il mio ha fatto. link
Lo strumento di pulizia PHP di Ran Paulo. link . Ho dovuto eseguire questo alcune volte per ottenere tutto.
Come accennato, controlla le autorizzazioni per i file e le directory e assicurati di non avere permessi di scrittura aperti su tutto ciò che non vuoi specificamente. Avevo un widget meteo Yahoo su una delle mie installazioni WordPress che aveva 777 su una directory cache. Ci siamo sbarazzati di quello.

Dopo questi 5 passaggi, non ho avuto una ricorrenza di questo attacco su nessuno dei miei siti. Sono puliti da mesi ormai.

L'ho usato come riferimento quando ho ripulito i miei siti: link .

score 1 · Answer 4

Poiché si tratta di un hosting condiviso, è molto probabile che l'account di qualcun altro venga compromesso e utilizzato per leggere / scrivere file degli altri account. È difficile dire come risolverlo senza sapere come è configurato il server. Se gli script php vengono eseguiti come utente dell'account, puoi iniziare a controllare le autorizzazioni dei tuoi file e directory per assicurarti che non abbiano accesso in lettura / scrittura per tutti.