karlemilnikka/cve-2023-1430Divulgazione responsabile di una vulnerabilità non corretta in FluentCRM di WPManageNinja
Aggiornamento 2023-06-12: Non hai più bisogno dello snippet. WPManageNinja ha corretto la vulnerabilità due ore dopo la divulgazione pubblica (93 giorni dopo la segnalazione).
Aggiornamento 2024-01-27: Il problema correlato con i valori hash eterni è ora completamente risolto.
tl;dr Gli aggressori possono visualizzare e modificare i dettagli dei contatti in FluentCRM. WPManageNinja non ha corretto la vulnerabilità entro la finestra di divulgazione responsabile di 90 giorni. Fornisco uno snippet di mitigazione per prevenire lo sfruttamento della vulnerabilità in attesa di una patch ufficiale.
Oggi pubblico informazioni su una vulnerabilità che ho trovato nel popolare plugin WordPress FluentCRM di WPManageNinja. La vulnerabilità, CVE-2023-1430, è causata dall'uso insufficiente di un hash dell'indirizzo email come controllo di autorizzazione da parte di FluentCRM. Ho divulgato responsabilmente la vulnerabilità secondo la politica di divulgazione delle vulnerabilità di Google Zero. WPManageNinja non ha fornito una patch entro la finestra di 90 giorni né ha richiesto una proroga.
In questo rapporto, contact si riferisce a un oggetto contatto di FluentCRM, mentre user si riferisce a un oggetto utente WordPress. Un contatto può essere collegato a un utente, ma non è un requisito. I dettagli sullo sfruttamento della vulnerabilità vengono omessi fino a quando non sarà disponibile una patch ufficiale. I professionisti della sicurezza possono contattarmi per il rapporto completo ([email protected]).
Sui siti che eseguono FluentCRM, un aggressore può visualizzare e modificare il nome, l'indirizzo email e l'impostazione dell'elenco di un contatto conoscendo l'indirizzo email del contatto. Poiché il nome del contatto è spesso incluso nelle newsletter tramite tag di unione, un aggressore può sostituire il nome del contatto con linguaggio volgare, causando l'invio di newsletter volgari da parte del proprietario del sito. Se l'amministratore del sito ha abilitato lo shortcode di FluentCRM per la gestione delle preferenze e lo ha aggiunto a una pagina web pubblica, un aggressore può visualizzare e modificare tutte le informazioni personali esposte, ovvero titolo, numero di telefono, data di nascita e indirizzo (a seconda della configurazione di FluentCRM).
FluentCRM è installato su più di 30.000 siti. Gli amministratori dei siti FluentCRM possono prevenire lo sfruttamento della vulnerabilità aggiungendo il mio snippet di mitigazione al file functions.php del loro tema figlio.
Lo snippet non corregge la vulnerabilità. Sostituisce il contenuto vulnerabile sulla pagina di FluentCRM per l'annullamento dell'iscrizione (unsubscribe.php) e sulla pagina per la gestione delle preferenze (manage_subscription.php) con un messaggio di errore che chiede al contatto di contattare via email. L'indirizzo email nel messaggio di errore è l'indirizzo email dell'amministratore del sito (può essere modificato dallo snippet). Lo snippet di mitigazione garantisce anche che i visitatori non autenticati non possano visualizzare lo shortcode vulnerabile di FluentCRM per la gestione delle preferenze (fluentcrm_pref). Un visitatore non autenticato vedrà invece un messaggio di errore che lo invita ad accedere. Tutte le stringhe sono traducibili con il file POT fornito.
Raccomando ai proprietari dei siti di implementare la mitigazione che fornisco o una mitigazione corrispondente propria. I proprietari dei siti dovrebbero anche verificare l'integrità dei loro dati di contatto FluentCRM e, se possibile, controllare i loro log per potenziali fughe di dati. Controllare i log è particolarmente importante per i seguenti siti:
Il responsabile del trattamento dei dati designato del sito gestirà le potenziali fughe di dati personali secondo le leggi e i regolamenti delle giurisdizioni interessate.
Se FluentCRM è configurato per sincronizzare le impostazioni di un contatto con il suo utente corrispondente, un aggressore può cambiare il nome dell'utente. Fortunatamente, FluentCRM non sincronizza gli indirizzi email dai contatti agli utenti. Se FluentCRM lo facesse, questa vulnerabilità consentirebbe il pieno controllo del sito. Un aggressore avrebbe potuto ottenere accesso privilegiato cambiando l'indirizzo email dell'amministratore del sito e quindi reimpostando la password dell'amministratore.
Tuttavia, altre soluzioni possono sincronizzare tutti i metadati dai contatti agli utenti, ad esempio WP Fusion e l'API di FluentCRM. WP Fusion è probabilmente il plugin di terze parti più popolare per sincronizzare i metadati dei contatti tra un CRM (ad es. FluentCRM) e WordPress. Fortunatamente, la versione corrente di WP Fusion non è collegata alle modifiche dei metadati iniziate dai moduli vulnerabili. Ho informato gli sviluppatori di WP Fusion, e non affronteranno questa limitazione fino a quando WPManageNinja non avrà corretto la vulnerabilità.
L'API di FluentCRM può anche essere utilizzata per aggiornare i dati di contatti e utenti. I proprietari di siti che utilizzano l'API di FluentCRM per aggiornare gli indirizzi email degli utenti devono disabilitare questo aggiornamento quando avviato dalla pagina o dallo shortcode di FluentCRM per la gestione delle preferenze (o aggiungere il mio snippet di mitigazione per garantire che nessuna impostazione possa essere aggiornata dai moduli vulnerabili).
FluentCRM consente ai contatti di annullare l'iscrizione e gestire le preferenze da pagine web pubbliche. I collegamenti a queste pagine sono inclusi in ogni newsletter. Le modifiche apportate su queste pagine sono autorizzate da hash MD5 degli indirizzi email dei contatti, passati come parametri URL. L'hash MD5 di un indirizzo email non è un segreto e può essere calcolato da chiunque. Un aggressore può sfruttare l'uso errato degli hash per annullare l'iscrizione di contatti specifici o annullare l'iscrizione in massa di contatti con indirizzi email noti.
Mentre la pagina di annullamento dell'iscrizione si basa esclusivamente sull'hash MD5 per l'autorizzazione, la pagina per la gestione delle preferenze richiede un parametro URL aggiuntivo chiamato ce_id. In questo caso, ce_id si riferisce all'ID del contatto nella tabella fc_subscribers. Questo ID è un intero incrementale. Il valore di ce_id è quindi facilmente trovabile testando tutti i valori possibili (lo spazio di ricerca è il numero di contatti mai registrati sul sito). Gli utenti amministratori probabilmente hanno valori bassi.
Dalla pagina per la gestione delle preferenze, un aggressore può anche esfiltrare il valore secure_hash del contatto. Aggiornando l'indirizzo email del contatto, il valore "secure_hash" del contatto viene memorizzato in un cookie chiamato fc_hash_secure. Con questo cookie, l'aggressore può visualizzare tutte le informazioni di contatto rese disponibili dallo shortcode del modulo delle preferenze di FluentCRM.
Il "secure_hash" menzionato in precedenza è un valore su cui FluentCRM (in alcune situazioni) fa affidamento invece o in alternativa all'hash MD5 dell'indirizzo email. Dalla versione 2.8.0 di FluentCRM, la pagina di annullamento dell'iscrizione si basa esclusivamente sul valore secure_hash per l'autorizzazione. La pagina per la gestione delle preferenze accetta sia il nuovo valore secure_hash che il vecchio hash MD5 dell'indirizzo email per l'autorizzazione.
Sebbene il valore secure_hash non possa essere derivato dall'indirizzo email, l'uso di FluentCRM non segue buone pratiche di sicurezza. Il valore secure_hash viene generato una volta per contatto. Non viene mai aggiornato e non scade mai. Ciò è problematico poiché il valore secure_hash è incluso in ogni newsletter. Se un aggressore ottiene l'accesso alla casella di posta di un contatto, l'aggressore può modificare le impostazioni del contatto a tempo indeterminato. Se il contatto interessato è collegato a un utente con privilegi di amministratore e le modifiche dell'indirizzo email vengono sincronizzate da FluentCRM a WordPress, ogni singola newsletter inviata a questo contatto conterrà un token che non scade mai per prendere il controllo del sito.
Ho segnalato questo problema correlato a WPManageNinja il 2023-03-15. Due mesi dopo (2023-05-15), WPManageNinja ha risposto che i loro consulenti di sicurezza non consideravano il valore secure_hash statico un problema. I consulenti di sicurezza di WPManageNinja hanno detto che era "ok usare questo tipo di token generati una tantum per identificare il contatto" e che era "simile ai token API dei servizi SaaS che non vengono consegnati ad altri contatti ma solo inviati al contatto effettivo che possiede l'indirizzo email".
WPManageNinja sono stati aperti e mi hanno detto di fargli sapere se pensavo ancora che fosse un problema di sicurezza, cosa che ho fatto. Ho spiegato perché i valori secure_hash non potevano essere paragonati ai token API. (I token API possono essere assicurati di essere inviati solo su connessioni TLS e l'accesso ai token API può essere limitato. Non è il caso dei valori in chiaro nelle email. Ancora più importante, i token API possono essere revocati mentre non c'è modo per un contatto di revocare un valore secure_hash.)
Più tardi quel giorno, WPManageNinja mi ha ringraziato e ha detto che avrebbero preso in considerazione la combinazione dell'ID del record email con l'hash. Questo risolverà il problema se implementato insieme alla revoca automatica di vecchi (scadenza basata sul tempo) o precedenti (scadenza basata sul contatore) valori secure_hash. Questa funzionalità non è ancora stata implementata, ma non considero l'uso di valori hash statici come parte di questo CVE.
Nel primo trimestre 2023, abbiamo iniziato la migrazione dal nostro precedente strumento di newsletter (Sendy) a FluentCRM. Ho trovato la vulnerabilità durante l'integrazione di FluentCRM con Nikka Systems Academy (Project Opal). Poiché abbiamo sostituito il sistema di gestione delle iscrizioni di FluentCRM con il nostro plugin personalizzato, i moduli vulnerabili di FluentCRM non hanno mai interessato il nostro sito o i dati dei nostri clienti.
FluentCRM è un ottimo plugin, ma la gestione della divulgazione della vulnerabilità da parte di WPManageNinja lascia molto a desiderare. L'elenco seguente è il mio suggerimento su come WPManageNinja potrebbe migliorare la situazione.
Detto questo, ho ancora fiducia in WPManageNinja. Ci sono bug in tutti i software, e una singola segnalazione di vulnerabilità gestita male non è un motivo per smettere di usare i loro plugin.
Aggiornamento 2023-06-12: Il fatto che abbiano ancora tentato di nascondere la vulnerabilità nel loro changelog mi preoccupa genuinamente. (Ora hanno aggiunto il CVE.)
