You are here

Drupageddon: ma Drupal è sicuro ?

Inviato da giovanninews on Ven, 21/11/2014 - 19:55

Drupal piange dopo DrupageddonDrupageddon, o Drupalgeddon se si preferisce chiamarla così ma il termine non è importante, è un termine che si riferisce ad una grave vulnerabilità dei siti web basati sul cms Drupal dalla versione 7.0 alla versione 7.31. La versione Drupal 7.32 corregge la vulnerabilità.

Sono sicuro con Drupal ?

Dal sito web ufficiale Drupal.org, si è sicuri se il sito web parte con Drupal 7.32 o superiore, si è sicuri se è stata applicata la patch relativa alle versioni Drupal 7 inferiori alla 7.32 entro le prime ore dall' annuncio sulla sicurezza o se entro le prime ore è stato effettuato l' update a Drupal 7.32, si è sicuri se è stato fatto l' upgrade da Drupal 6.33 direttamente a Drupal 7.32 (o versioni superiori).

La stessa vulnerabilità è valida per i pochi che stanno utilizzando la versione di sviluppo Drupal 8 e non hanno applicato la patch o fatto l' update a Drupal 8.0.0 beta2. Si è sicuri con Drupal 6 se non si usa il modulo DBTNG o se è stato effettuato l' update del modulo con la stessa tempistica.

La sicurezza è un processo, non uno stato di fatto

Dopo la versione Drupal 7.32 che corregge la vulnerabilità, esce anche la 7.33 che contiene miglioramenti, ma, il 19/11/2014, esce anche la versione Dupal 7.34 e anche questa volta vi sono correzioni relative a bug di sicurezza, anche se di entità minori rispetto a prima.

Quindi la sicurezza è un processo, non un dato di fatto; ciò che fino al giorno prima poteva essere considerato sicuro, oggi non lo è più se nuove vulnerabilità vengono scoperte.

Anche se sono state prese tutte le misure sulla sicurezza, in fondo nessuno può dire di essere al sicuro.

Wordpress o Joomla sono più sicuri di Drupal ? Se andiamo a verificare i diversi CMS sui problemi di sicurezza avuti, vediamo che nessuno ne è immune.

E' certo che la vulnerabilità di Drupal chiamata Drupageddon è particolarmente grave perchè non era su un modulo, ma su una API del Core di Drupal; ha quindi coinvolto migliaia o forse centinaia di migliaia di siti web.

Tanti utenti piangono per questo ma piange anche lo staff dei partner e degli sponsor Drupal che, seppure probabilmente informati in anticipo, invece che pensare solo a mettere in sicurezza i loro clienti avessero pensato di più anche alla community, fatta di tanti sviluppatori e semplici utenti, un clima di sfiducia non si sarebbe creato.

Sicuramente gestire la comunicazione una volta scoperta la vulnerabilità, non era semplice, ma la vulnerabilità è stata scoperta/notificata allo staff Drupal il 16/09/2014 da SektionEins; il bug è presente in tutte le versioni Drupal 7 fin dalla sua uscita fino a Drupal 7.31, quindi dal 05/01/2011 al 15/10/2014.

Il fix è stato rilasciato pubblicamente il 15/10/2014, un mese dopo la scoperta; il pubblico rilascio della vulnerabilità e della relativa soluzione, oltre che permettere di risolvere il problema, naturalmente scatena anche i crackers e quindi la lotta è per chi arriva prima: faranno in tempo i nostri a mettersi in sicurezza ?

Ma per fare una patch ci volevano 5 minuti, quindi qualcosa in un mese è stato fatto: ma cosa ?

Da quel che ho letto sono stati messi in sicurezza i siti web hostati sulle piattaforme dei partner (Acquia e Pantheon): decine di migliaia di siti web.

Sicuramente sono stati avvisati i siti web istituzionali e ce ne sono tanti. Per questi ultimi bisogna calcolare il tempo burocratico per dare il via ad un aggiornamento, sicuramente nell' ordine di settimane, ma passa un mese.

Per la community non altolocata 7 ore di tempo; il 15/10 è pubblicata la vulnerabilità con relativa patch o update. Già dopo alcune ore dalla pubblicazione si cominciano a vedere i primi siti web compromessi.

La vastità e la tipologia degli attacchi hacker può essere compresa in un articolo del blog di Acquia del 24/10/2014 dove ne è stato osservato il comportamento su decine di migliaia di siti web.

In Drupal come funzionano le notifiche degli aggiornamenti ?

E' possibile impostare il sistema delle notifiche automatiche per gli aggiornamenti settimanalmente o giornalmente. Per avere prima la notifica è necessario entrare nei reports e cliccare su un link per il controllo manuale; quindi, se non si usa il controllo manuale, si ha la notizia dell' aggiornamento più o meno con 24 ore di ritardo (sempre se si ha l' accortezza di verificare il report).

Con Drupal è possibile fare qualcosa in più: iscriversi alla mailing list per gli aggiornamenti di sicurezza che produce l' invio di una mail entro qualche minuto dalla pubblicazione dell' aggiornamento: mi sono iscritto dopo questo fatto (ma anche i crackers potrebbero farlo).

In Wordpress esiste da ottobre 2013 l' aggiornamento automatico e l' ultima vulnerabilità ne rilancia il progetto anche per Drupal, ma che dubito verrà preso in considerazione; potrebbe esserci per gli aggiornamenti di sicurezza relativi al core di Drupal, ma non per gli aggiornamenti di sicurezza dei moduli, che, se implementato, porterebbe ad un alto rischio di rottura dei siti web.

La frase "la sicurezza è un processo, non uno stato di fatto" non è mia, ma di Bevan che ha anche pubblicato un flowchart di comportamento dopo Dupageddon e pressato il team Drupal a pubblicare la PSA del 29/10/2014 e che il team di Drupal non poteva ignorare al fine di non tradire lo spirito dell' Open Source.

Per tornare al tema " la sicurezza è un processo, non uno stato di fatto " è possibile fare un paragone con la sicurezza delle nostre case.

Quotidianamente ci sono furti nelle case, ma cosa è possibile fare per aumentarne la sicurezza ?

Innanzitutto la sicurezza è una questione sociale e dovrebbe essere lo stato ad occuparsene per prima; ma se in un paese vi è solo una pattuglia di polizia, potremmo allora istituire delle ronde (il team sulla sicurezza).

Se abbiamo una casa al primo piano, dobbiamo cercare di salire al secondo, o al terzo (dal piccolo servizio di hosting a quello medio o a quello più grande).

Se al terzo piano entrano dalla porta, bisogna mettere almeno una cassaforte (password più complesse, sistemi più affidabili).

Se aprono anche la cassaforte è necessario mettere un guardiano per la sicurezza (se non si è specializzati, delegare la sicurezza, gli aggiornamenti, a qualcuno che può seguirne meglio lo sviluppo).

Ma qual' è la situazione di Drupal ?

Il team di Drupal, forse troppo impegnato con lo sviluppo di Drupal 8, si è lasciato un pò andare.

Dal sito ufficiale Drupal.org, di circa 942.000 siti web con Drupal 7 (e sembra che la conta sia difficile anche per Drupal.org), xxx siti web sono con Drupal 7.34, 111.000 siti web sono con Drupal 7.33 e 252.000 sono con Drupal 7.32. Abbiamo quindi oltre 600.000 siti web che sono potenzialmente già compromessi ed a questi bisogna aggiungere quelli che pensano di essere puliti (quelli che hanno applicato la patch o fatto l' upgrade oltre il tempo limite).

Il totale generale dei siti web con Drupal, dal 12/10 è già sceso di circa 40.000 unità (circa 20.000 per Drupal 7) e la cifra è purtroppo destinata ad aumentare.

Nel team Drupal ci sono già stati cambiamenti al vertice della sicurezza, con il risultato che la sicurezza, già molto avanzata allo stadio precedente, diventa ora l' obiettivo primario.

Avremo un Drupal 7 che sarà sempre più simile a Fort Knox ed un molto più promettente Drupal 8, che faticherà ancora molto ad uscire ed ancora più ad essere produttivo. Il 2018 per Drupal 9 diventerà probabilmente 2020.

Il morale della favola è che, di questi tempi, se si pensa di lavorare con il web, è necessario investire facendosi aiutare da qualcuno attento alle novità.