Al Wp Meetup Milano, il 13 Giugno 2017, Nicola Laserra, sviluppatore PHP, ha tenuto un talk sull’argomento, snocciolando dati e leggendoli in modo corretto per capire come stanno davvero le cose, oltre all’eccessiva pubblicità negativa fatta a WordPress. Inoltre ha spiegato come si muove il Security team per garantire la sicurezza e le ultime iniziative intraprese.
Il 13 Giugno 2017 al WordPress Meetup di Milano si è parlato della sicurezza di WordPress, vista la non ottima fama che questo CMS gode in materia. Nicola Laserra, PHP developer e dipendente della MotorK, ha cercato di fare chiarezza sulla questione andando ad analizzare una serie di dati e riportando dei casi storici di attacchi rivolti a WordPress.
Leggere bene i dati e andare oltre le apparenze
Facendo ricerche su Google emergono numeri impressionanti: sembrerebbe che 1,5 milioni di siti fatti con WordPress abbiano subito attacchi deface, dove un attore esterno è riuscito ad accedere all’amministrazione e a cambiare il layout delle pagine.
Sembrerebbe che WordPress c’entri in qualche modo con lo scandalo Panama Paper, l’attacco informatico più grande della storia recente, con ben 2,6TB di dati riservati esposti pubblicamente. Leggendo i dati si potrebbe pensare che WordPress abbia un grosso baco dato che ha “permesso” un attacco di questa entità.
Approfondendo bene la questione, però, si scopre che sono state coinvolte anche altre piattaforme e strumenti, le cui tecnologie erano obsolete a causa delle “cattivi abitudini” degli utilizzatori, prima fra tutte di non aggiornare le tecnologie in uso.
Quanto a WordPress il baco non stava nel core ma in un plugin molto usato, Revolution Slider.
La morale di questa storia è che quando siamo sotto attacco non bisogna farsi prendere dal panico, collezionare il maggior numero di informazioni possibili e analizzare bene la situazione.
Non esiste software che sia privo di problematiche, comprese quelle relative alla sicurezza; in generale un programma tanto più è usato tanto più è esposto ad attacchi informatici. Laserra, a questo proposito, ha esposto dei dati relativi al livello di sicurezza WordPress e di altre piattaforme: WordPress non è l’unica ad avere questo tipo di problemi.
La valutazione si esprime con l’indice CVSS (Common Vulnerability Scoring System), che va da 1 a 10, ricavato considerando tre fattori:
- l’esistenza della vulnerabilità;
- quanto sia facile per l’hacker arrivare a quel difetto;
- quanto sia difficile esporlo alla comunità.
Tanti bachi di sicurezza non corrispondono per forza a tanti problemi: 10 bachi di minore entità possono essere molto meno gravi di uno solo che compromette seriamente la sicurezza della piattaforma.
Al CMS analizzato viene assegnato questo indice su ciascun aspetto e, riassumendo, possiamo ricavare questi dati:
- WordPress ha un punteggio che va da 6 a 6.99 (statistiche WordPress);
- Drupal viaggia tra 3.5 e 6 (statistiche Drupal);
- Joomla va da 4.3 a 7.5 (statistiche Joomla).
Per proteggere il proprio sito esistono però degli strumenti di monitoring, uno dei più famosi è WordFence.
Sul blog di WordFence sono pubblicati una serie di dati relativi ad attacchi a siti monitorati da questo strumento. Il dato più impressionante è rappresentato dai 45000 attacchi giornalieri brute force a una singola pagina (tentativi ripetuti di accedere all’area di amministrazione).
La formula di wp e le misure per la sicurezza
Gli attori principali di WordPress sono
- il core;
- plugin e temi del repository;
- plugin e temi di librerie esterne;
- un ingrediente magico, la comunità.
Il Core Development Team è composto da una cerchia ristretta di sviluppatori che definisce le linee guida da seguire e da una squadra di sviluppatori che hanno accesso permanentemente al core.
Potenzialmente tutti possono far parte del team, nel senso che la comunità di WordPress è aperta e chiunque può farne parte. Chi entra non inizierà aderendo al Core Development Team ma gradualmente può arrivare a raggiungere questo traguardo.
All’interno del Core Development Team troviamo il Security Team, deputato a tracciare e rispondere ai difetti di sicurezza, sia di wordpress.com che del software liberamente installabile.
Il team di sicurezza si occupa anche di revisionare temi e plugin scritti da altri per quello che concerne l’aderenza a certi standard.
Il principio che si applica, nel trattare i problemi di sicurezza, è quello del Responsive Disclosure: quando viene scoperto un baco lo si comunica direttamente a chi ha scritto il tema o il plugin e non lo si rende pubblico, almeno fino a quando non è stata prodotta la fix. In questo modo si evita che potenziali hacker vengano a conoscenza del problema e lo sfruttino a loro vantaggio.
Il Core Team interviene quando il baco è relativo al core oppure qualora sia impossibile contattare il vendor del pacchetto in questione.
Un caso storico
Nel Dicembre 2016 esce WordPress 4.7 e una delle novità principali introdotte furono le REST API. Da questa versione nacque la 4.7.1 uscita all’inizio di Gennaio.
Un ricercatore della Sucuri, uno dei principali attori coinvolti nella sicurezza di WordPress, scoprì che questa nuova funzionalità presentava un grosso baco che permetteva a un potenziale hacker di accedere all’amministrazione e sferrare attacchi deface alle singole pagine.
Seguendo il principio del Responsive Disclosure l’azienda contattò il team di sicurezza di WordPress per segnalare il problema. Fu prodotta la fix, inglobata all’interno di altre fix, contenuta nella versione 4.7.2, uscita a fine Gennaio, ma venne tenuta segreta affinché gli hacker non sfruttassero il bug, sapendo che non tutti i gestori di siti sarebbero passati alla 4.7.2.
Una settimana dopo fu pubblicata la fix. Sfruttando la cattiva abitudine di molti gestori di non aggiornare WordPress, 4 gruppi di hacker attaccarono ben 67000 pagine con attacchi deface e in poco tempo 20 gruppi di hacker attaccarono 1,5 milioni di pagine (dato citato all’inizio).
In tutto ciò molti proprietari di siti ricevettero una comunicazione da Google search Console dove si diceva che WordPress andava aggiornato in quanto il sito era potenzialmente esposto ad attacchi pesanti. Il problema fu che la comunicazione arrivò pure a chi aveva già fatto l’aggiornamento, i quali andarono nel panico senza motivo.
Le iniziative del security team
Il Security Team, per garantire la sicurezza di WordPress, ha messo in campo due inziative:
- un sistema per coordinare la reportistica e le comunicazioni delle vulnerabilità di WordPress;
- reclutamento di una serie di “hacker”, ossia di sviluppatori, che vanno a caccia di problemi di sicurezza; se presentano un buon report vengono remunerati. Già sono stati elargiti parecchi soldi in tal senso.
Ciò che potenzia WordPress è la comunità e il suo carattere accogliente, dove tutti possono entrare a patto di aderire a certi principi. La comunità è fatta di meetup, riunioni su Slack, WordCamp e quant’altro.
Un progetto Open-Source sicuro
WordPress è un software open-source, a sorgente aperta, dove il codice è visibile a tutti e, per tale, ragione, chiunque può segnalare bachi al Securty Team.
Un progetto open-source, per funzionare bene, deve:
- rispettare certi standard;
- prevedere solide procedure di testing;
- avere dietro sé una comunità aperta e vista come una risorsa.
WordPress è sicuro?
Da tutto ciò possiamo dire:
- il core di WordPress è sicuro; la sicurezza è garantita da un buon Security Team che in poco tempo risolve il baco;
- le maggiori falle di sicurezza possono averle temi e plugin che vengono scritti da sviluppatori esterni al core development team. Il team in questione fa solo delle revisioni di questi pacchetti.
La regola d’oro è sempre quella di aggiornare WordPress, temi e plugin così da avere sempre le fix su eventuali bachi che inevitabilmente, ci sono in tutti i software.
Le domande del pubblico
Il talk ha suscitato domande da parte di partecipanti che hanno avuto problemi di sicurezza e di aggiornamenti di WordPress.
Quanto conta il server
Un partecipante ha riportato la sua esperienza dove un sito di un cliente era costantemente sotto attacco, pur avendo tutto quanto aggiornato. La soluzione scelta fu quella di spostare il sito su un altro server, e quindi presso un altro servizio di hosting, e in questo modo il problema fu risolto.
Laserra ha risposto che la sicurezza del sito dipende anche dal server. Se l’installazione di WordPress è sicura ma il server non dispone di adeguate protezioni il sito è attaccabile. Allo stesso tempo se il servizio di hosting predispone il server di buoni firewall ma l’installazione non è sicura il sito è ugualmente esposto. Pertanto la sicurezza di un sito dipende 50% dal server e 50% dall’installazione di WordPress.
Citando ancora Panama Papers Laserra ha aggiunto che in quel caso, oltre al problema del plugin citato, c’era un server mail antiquato.
Dalla platea uno degli organizzatori del wp meetup ha aggiunto che generalmente le grandi aziende di hosting offrono dei livelli di sicurezza più elevati rispetto ad altre più piccole.
Rimanendo in tema di server un giovanissimo partecipante ha raccontato di essere stato hackerato su altervista e ha chiesto se fosse possibile capire da cosa è dipeso tale attacco.
Laserra ha consigliato di utilizzare uno strumento di monitoring per verificare che l’installazione si safe. Il passo successivo sarà contattare il servizio di hosting.
Problemi derivanti dagli aggiornamenti coi compositori visivi
Un altro partecipante ha ammesso che l’azienda per cui lavora è una di quelle che non aggiorna WordPress, almeno fino a quando non esce la versione successiva del compositore visivo delle pagine poiché altrimenti quest’ultimo crasha. Pertanto, prima di aggiornare WordPress, deve aspettare che esca la versione successiva del plugin. La domanda è stata se esiste un modo per mettere una pezza a questa situazione.
Laserra ha risposto che non esistono grandi soluzioni a questo problema, l’unica cosa su cui contare è che il server abbia elevati livelli di protezione che compensino, almeno nel breve periodo, la falla causata dall’installazione non aggiornata.