WordPress, l’insuccesso del reparto di IT Security

Wordpress Logo

Nelle ultime due settimane abbiamo visto nella cronaca della Sicurezza Informatica il nome di WordPress per ben due volte, infatti come ha riportato Paolo sul suo blog le ultime versioni di WordPress contenevano una vulnerabilità di tipo XSS Stored (è definita stored una vulnerabilità che viene memorizzata/salvata nel filesystem o nel database della vittima, in questo caso nel database). WordPress è corsa ai ripari aggiornando la sua piattaforma di Blogging con la versione 4.2.1 ma ieri è corsa nuovamente ai riparti rilasciando la versione 4.2.2 poiché sono state trovate altre vulnerabilità XSS come ha riportato The Hacker News.

La vulnerabilità di tipo XSS Stored è stata scoperta da Jouko Pynnönen ed essendo di tipo Stored è indubbiamente la vulnerabilità di tipo XSS più pericolosa, ma non voglio soffermarmi sugli aspetti tecnici perché potete tranquillamente trovare tutti i dettagli sul blog di Jouko compreso di un ottimo video dimostrativo. Quel che mi ha stupito e vorrei condividere con voi, magari per avere un vostro parere, è la seguente dichiarazione rilasciata da Jouko:

WordPress has refused all communication attempts about our ongoing security vulnerability cases since November 2014. We have tried to reach them by email, via the national authority (CERT-FI), and via HackerOne. No answer of any kind has been received since November 20, 2014. According to our knowledge, their security response team have also refused to respond to the Finnish communications regulatory authority who has tried to coordinate resolving the issues we have reported, and to staff of HackerOne, which has tried to clarify the status our open bug tickets.

Il ricercatore avrebbe tentato di comunicare a WordPress la vulnerabilità a Novembre 2014, senza ricevere alcuna risposta Jouko ha poi chiesto al CERT e ad HackerOne di comunicare la gravità della vulnerabilità individuata ma ancora volta non è stata data nessuna risposta. Così lo scorso 26 Aprile 2015 Jouko ha deciso di rendere pubblica la vulnerabilità.

La gravità di questa vicenda è l’assenza di risposte dal Team di IT Security di WordPress per ben 6 mesi, 6 mesi!!! E sempre Paolo Perego mi fa notare che sul sito ufficiale di WP vi è riportato quanto segue:

The WordPress Security Team is made up of approximately 25 experts including lead developers and security researchers — about half are employees of Automattic (makers of WordPress.com, the earliest and largest WordPress hosting platform on the web), and a number work in the web security field. The team consults with well-known and trusted security researchers and hosting companies.

Circa 25 persone lavorano nel reparto di IT Security di WordPress, se fosse un’azienda Italiana diremmo subito che sono dei fannulloni ma è sempre meglio evitare affermazioni affrettate ma quel che è certo che è incomprensibile l’aver ignorato tale vulnerabilità e la relativa comunicazione da parte di Jouko. Capisco che non è sempre possibile individuare le vulnerabilità di un proprio progetto, anche se si è in 25, ma ignorare il lavoro svolto da una terza persone che cortesemente vi sta comunicando un’importante falla di sistema lo trovo veramente sbagliato!

Jouko avrebbe potuto rivendere la vulnerabilità in qualche Black Market vista l’insoddisfazione nel ricevere un ringraziamento ufficiale e sicuramente guadagnare un buon gruzzoletto, visto che WordPress è il primo CMS mondiale con un adozione stimata al 55%.

In sostanza, da WordPress mi aspettavo molto di più!!

  • Andrea, sono confuso anche io. Come sai con Owasp Italia stiamo lanciando un progetto di adozione dei progetti opensource… gli facciamo #appsec pro bono. Io sto adottando wordpress ed al momento non sono ancora riuscito a trovare un riferimento interno della loro security con cui parlare.

    Mi piacerebbe molte persone si volessero unire a noi per adottare WordPress e provare a capire cosa non va…

    C’è un typo: adozzione

    • Paolo,
      mi sono iscritto alla ML di Owaps perché conto in un futuro di potervi affiancare nei progetti e perché no intensificare i traporti tra BackBox e Owaps!
      Ora però ho un progetto più grande che vorrei completare, l’università! 🙂 non voglio mettere troppa carne al fuoco!

  • Federico R

    Sottoscrivo con amarezza, considerando poi l’implentazione futura di nuove api (vedi rest con la 4.3) la superficie di attacco andrà ad aumentare in maniera esponenziale.

    Io sto pensando ad adottare un WAF cloud come la versione business di cloudflare o sucuri (che tra l’altro effettua un ottimo lavoro di informazione), almeno spero di avere un minimo di protezione in più

    • Perché non ci metti davanti un mod_security?

      • Federico R

        Ero rimasto fermo al supporto per Apache ma vedo che è disponibile il modulo per nginx (attualmente uso questo). Inoltre stavo sbriccando un po’ con naxsi

        Quello che è interessante è il virtual patching con regole aggiornate giornalmente, con quella fee annuale vale la pena? Esperienze?

        • No, troppo esose per me 🙂 mi son fermato alle regole di OWASP! Ma dubito che vadano peggio…se son realmente aggiornate periodicamente!

    • Il tutto dipende dal livello di protezione e dal carico che la macchina deve gestire, io con Mod_Security e regole di OWASP sono abbastanza protetto!

      Certo che se vuoi proteggere un sito con tante/troppe visite è meglio affidarsi a un WAF in cloud, anche solo per proteggersi da un DDoS!
      Tanto per fare un esempio recente, expo2015.org ha un WAF interno (mal configurato ma c’è l’ha), ma per la mole di traffico avrei optato per una soluzione esterna! E i risultati si son visti…caduto per mezza giornata!