I plugin mantenuti dovrebbero essere sospesi dal repository di WordPress in caso di problemi di sicurezza?

Il 27 febbraio 2020, alle 21:34 (CET), abbiamo ricevuto un'e-mail che ci informava che il nostro plugin WP Activity Log era stato " temporaneamente ritirato dalla directory dei plugin di WordPress.org a causa di un exploit" .

Abbiamo inviato una correzione venerdì 28 febbraio 2020 alle 16:08. Ci sono volute solo 16,5 ore per rilasciare la correzione. Avremmo risolto il problema molto prima se ciò fosse accaduto durante il nostro normale orario di lavoro (la nostra sede è in Europa), perché abbiamo un ottimo tempo di risposta del supporto (riferimento).

Il nostro plugin è stato ripristinato lunedì 2 marzo 2020 alle 13:00. Sono 69 ore dopo che abbiamo inviato la correzione. È importante notare che il team ha impiegato così tanto tempo per ripristinare il plug-in a causa del fine settimana.

Perché scrivo questo?

Vorrei sottolineare che credo che i plugin non mantenuti che presentano problemi di sicurezza dovrebbero essere sospesi dal repository di WordPress. Inoltre, ho un enorme rispetto per il lavoro svolto dai volontari del team di revisione dei plug-in e mi assumo anche la piena responsabilità per il problema di sicurezza segnalato.

Tuttavia, credo che i problemi di sicurezza segnalati nei plugin mantenuti potrebbero essere gestiti meglio. A causa del modo in cui vengono gestiti in questo momento, la reputazione del plug-in subisce un grosso colpo negativo e i suoi utenti e i loro siti Web sono messi a rischio. Pertanto, alla fine di questo post, evidenzierò alcuni possibili miglioramenti che potrebbero aiutare, e penso che dovrebbero essere presi in considerazione. L'idea è quella di mettere sempre meno utenti a rischio e di ridurre l'impatto sul plugin e sugli sviluppatori.

In questo post, documento anche tutti i dettagli di ciò che è accaduto e spiego la vulnerabilità del caso limite a bassa gravità segnalata nel nostro plug-in.

Qual è la procedura per segnalare un problema di sicurezza del plugin di WordPress?

Dalle linee guida ufficiali nel Plugin Handbook:

Ogni tentativo di contattare direttamente lo sviluppatore deve essere effettuato prima di segnalarci il plug-in (anche se capiamo che può essere difficile: controlla prima il codice sorgente del plug-in, molti sviluppatori elencano le loro e-mail). Se non riesci a contattarli in privato, ti preghiamo di contattarci direttamente e ti aiuteremo.

Cosa è successo nel nostro caso?

Chiariamo molto chiaramente nel plugin chi sviluppa il plugin. Basta guardare la pagina del plugin nel repository e ti farai un'idea! Semplifichiamo anche il contatto con noi.

Tuttavia, nessuno ci ha segnalato il problema di sicurezza prima che il plug-in venisse temporaneamente ritirato dal repository dei plug-in. Quindi qualcuno ha segnalato il problema al team di revisione dei plugin di WordPress e ha temporaneamente ritirato il nostro plugin dal repository senza alcuna notifica preventiva.

Prima di approfondire i perché e cosa è, e cosa è buono, cattivo e cosa può essere migliorato, diamo un'occhiata alla vulnerabilità del plugin e una breve spiegazione di chi siamo.

Qual era la vulnerabilità del plugin?

Abbiamo una procedura guidata di installazione in WP Activity Log per aiutare gli utenti a configurare il plugin. Una delle impostazioni della procedura guidata consente agli utenti non amministratori di leggere i registri delle attività.

Tuttavia, abbiamo commesso un errore; non abbiamo verificato se l'utente che esegue la procedura guidata è stato autenticato. Pertanto gli utenti non autenticati possono eseguire la procedura guidata e consentire a un altro utente o ruolo di accedere alle impostazioni del plug-in. Tuttavia, questo è un problema di bassa gravità del caso limite.

Perché si tratta di un problema di sicurezza del caso limite di bassa gravità?

Gli aggressori potrebbero sfruttarlo solo se:

• l'installazione guidata non è mai stata completata dall'installatore,
• gli aggressori avevano già un utente/hanno avuto accesso a un utente sul sito web,
• Gli aggressori possono accedere solo alle impostazioni del plug-in e al registro delle attività.

Sfruttando questi problemi di sicurezza, gli aggressori non ottengono l'accesso ad altri privilegi sul sito Web di WordPress. Pertanto questo exploit non ha alcun effetto negativo sul comportamento e sulla funzionalità del sito web stesso.

Verifica teorica

Il POC è molto semplice. Visita questa pagina come utente non autenticato:

http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access

Questo è il passaggio della procedura guidata che consente di specificare chi può vedere i log. Cerca il nonce '_wpnonce' nel sorgente della pagina HTML, copialo e inseriscilo nel seguente comando curl:

$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D= abbonato&save_step=Avanti'

Una volta effettuato l'accesso come abbonato e avrai pieno accesso alle impostazioni del plug-in.

Perché pensiamo che questo caso sia stato gestito male?

Nell'e-mail che ci è stata inviata, c'era quanto segue:

Non chiudiamo i plug-in alla leggera e, quando si tratta di problemi di sicurezza, cerchiamo di bilanciare il volume degli utenti e la cronologia degli sviluppatori con la gravità e il potenziale danno del rapporto.

Tuttavia, penso che il nostro plugin sia stato ritirato troppo presto. Finora;

1. Quando abbiamo avuto problemi in passato, li abbiamo sempre affrontati entro poche ore. Abbiamo fatto lo stesso questa volta.
2. Abbiamo sempre risposto in tempo quando il team di revisione dei plugin si è messo in contatto.
3. Il problema di sicurezza ha interessato solo il nostro plug-in (bassa gravità) ed è stato un caso limite.
4. Il problema di sicurezza non può essere sfruttato automaticamente.
5. L'unico danno che l'attaccante poteva fare era modificare le impostazioni del plug-in, leggere i registri delle attività o eliminarli.

Cosa pensano gli altri sviluppatori di tali situazioni?

La maggior parte di noi ha già letto un articolo, un tweet o un messaggio sui social media su problemi simili. Tuttavia, volevo scoprire di persona cosa ne pensano gli altri, in particolare gli sviluppatori. Penso che questo sia importante perché potrebbero esserci delle cose che non vedo.

Per cominciare, ho inviato un'e-mail alla persona che ha identificato il problema, ringraziandolo per la divulgazione responsabile. La sua risposta è stata:

“Sono felice di vedere che hai risolto rapidamente il problema nel plugin. A proposito, ho notato che le persone di wordpress.org l'hanno chiuso per alcuni giorni, è stato un po' duro e non era davvero necessario. "- Jerome Bruandet.

Ho anche fatto un piccolo sondaggio sul gruppo Facebook Vendita di prodotti WordPress. Sebbene questo gruppo sia piccolo, la maggior parte dei suoi membri sono sviluppatori di plugin e temi. Dal sondaggio possiamo vedere che gli sviluppatori concordano all'unanimità sul fatto che in caso di problemi di gravità medio-bassa, gli sviluppatori dovrebbero essere contattati e data la possibilità di fornire una soluzione e non ritirare il plug-in:

Come possono essere migliorate queste procedure?

Per quanto ne so, non esistono procedure documentate per quando qualcuno segnala un problema di sicurezza in un plug-in. In tal caso, procedure come quelle riportate di seguito potrebbero aiutare gli sviluppatori e anche mettere meno persone a rischio.

Contatta gli sviluppatori e concorda un piano d'azione prima di chiudere il plugin

Il team di revisione dei plugin può provare a contattare gli sviluppatori e confermare la vulnerabilità prima di chiudere il plugin. Gli sviluppatori dovrebbero rispondere con un piano d'azione, inclusa una data ragionevole per la correzione.

Se necessario, il team di revisione dei plugin può fissare una scadenza. Ad esempio, gli sviluppatori dovrebbero avere tra le 12 e le 24 ore per risolvere il problema. Tuttavia, in alcuni casi potrebbero aver bisogno di più tempo, a seconda del fuso orario in cui si trovano, ecc. Se gli sviluppatori non rispondono, il plugin dovrebbe essere ritirato dal repository.

Determinare la gravità e il tipo del problema di sicurezza

Questo potrebbe essere aperto al dibattito. Tuttavia, qualcuno con un po' di esperienza di sicurezza può facilmente dire se un problema di sicurezza segnalato può essere sfruttato automaticamente, se si tratta di un caso limite o meno, e qual è il suo impatto dalla prova di concetto segnalata (POC).

Verifica che gli sviluppatori si attengano al piano d'azione

Dovrebbe esserci una sorta di controllo in atto per confermare che gli sviluppatori inviino la correzione in tempo e si attengono a qualsiasi altra attività inclusa nel piano d'azione.

Il ritiro dei plugin gestiti dal repository non aiuta

Nel caso di plugin mantenuti, ritirarli dal repository fa più male che bene. Per esempio;

1. Rendi pubblico che il plugin ha un problema, molto probabilmente un problema di sicurezza. Ciò solleva molti allarmi e mette in luce il plugin. Questo è anche come invitare gli aggressori, dicendo loro che qualcosa nel plugin può essere sfruttato.
2. Espone l'attuale base di utenti del plug-in perché all'improvviso i loro siti Web sono diventati un bersaglio. La maggior parte degli utenti non ha idea di cosa dovrebbe fare, soprattutto se la funzionalità del plug-in è fondamentale per il proprio sito Web e la propria attività.
3. Aumenta le possibilità di ritardare la correzione. Ciò è in genere causato dalla mancanza di comunicazione o da festività e fine settimana.

Si potrebbe obiettare che ritirando un plugin dal repository si impedisce la propagazione dell'infezione . Tuttavia, se il problema di sicurezza è di bassa gravità, lo sfruttamento non può essere automatizzato e la divulgazione è responsabile, non ci sono rischi coinvolti o i rischi sono estremamente bassi.

Disclaimer: questo non è un attacco

Vorrei sottolineare che questo non è un attacco contro il team di revisione dei plugin di WordPress o chiunque sia coinvolto in questi processi. Sinceramente rispetto il loro lavoro e so che quello che fanno è fatto in buona fede. Tuttavia, c'è sicuramente un margine di miglioramento, come in ogni altro sistema e processo.

Molti probabilmente mi diranno che se voglio un cambiamento dovrei fare volontariato invece di scrivere questo post.

Ho cercato di unirmi per un po' di tempo; Ho parlato con diverse persone in diversi WordCamp per essere coinvolto e ho anche monitorato la pagina Crea plugin per WordPress per le chiamate per i volontari. Tuttavia, negli ultimi anni non avevano posti vacanti. Quando avevano bisogno di aiuto, aggiungevano nuovi membri solo su invito.