Cosa fare se il tuo Discourse è compromesso

[Discourse]

Abbiamo recentemente ricevuto due segnalazioni di siti Discourse compromessi, probabilmente a causa di password deboli per gli account di amministrazione. Vorremmo quindi documentare:

• cosa fare quando si verifica una compromissione
• cosa possiamo fare per prevenire meglio questo in futuro

Il Database

Si prega di notare che Discourse, da diversi anni, dispone delle seguenti protezioni relative al database del sito:

• I link per il download del backup completo del database vengono inviati solo tramite e-mail valida di un amministratore del sito, quindi non è sufficiente effettuare l’accesso (tramite shoulder surfing o dimenticando di disconnettersi), ma è necessario anche controllare l’indirizzo e-mail di un amministratore del sito. E hai configurato l’autenticazione a due fattori (2FA) per la tua e-mail, vero?

• Per cambiare l’e-mail dello staff, è necessario verificare il controllo di entrambi gli indirizzi e-mail, quello vecchio e quello nuovo, mentre un utente normale deve solo verificare il controllo dell’indirizzo e-mail nuovo. Questo rende molto più difficile cambiare l’indirizzo e-mail di un membro dello staff.

• Supponendo che tu abbia configurato la chiave API del database di geolocalizzazione (è gratuita, richiede la registrazione), ricevi avvisi attivi quando i membri dello staff accedono da posizioni fisicamente distanti da dove hanno effettuato l’ultimo accesso.

• Gli amministratori che non accedono da più di un anno sono tenuti a rivalidare il loro indirizzo e-mail, per ridurre la superficie di attacco. L’impostazione del sito per questo è invalidate inactive admin email after days e il valore predefinito è 365.

Comunque, in caso di compromissione, dovresti sempre presumere che un account amministratore canaglia abbia scaricato una copia completa del database/backup del sito.

Pertanto, dovresti IMMEDIATAMENTE reimpostare tutte le password degli account utilizzando il seguente comando:

./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'

Inoltre devi disconnettere tutti gli utenti

./launcher enter app
rails r 'UserAuthToken.destroy_all'

Infine devi rimuovere tutte le chiavi API

./launcher enter app
rails r 'UserApiKey.destroy_all' 
rails r 'ApiKey.destroy_all'

Password degli account nel Database

Secondo la nostra documentazione sulla sicurezza, Discourse utilizza hash molto forti e lenti da attaccare per le password memorizzate nel database:

Discourse utilizza l’algoritmo PBKDF2 per crittografare le password con sale. Questo algoritmo è approvato dal NIST. Gli esperti di sicurezza sul web tendono a concordare che PBKDF2 sia una scelta sicura.

E la lunghezza minima predefinita della password è 10 per gli utenti e 15 per gli amministratori, il che rende difficile invertire forzatamente gli hash delle password per ottenere l’hash. Ma questo non impedisce agli utenti di impostare una password come password1password1 o qualcos’altro di banale da invertire, anche con un hash forte.

E-mail nel Database

L’attaccante può vedere tutti gli indirizzi e-mail di tutti gli utenti sul tuo sito. Questa è normalmente un’informazione riservata che anche i moderatori devono premere un pulsante per rivelare.

Contenuto dei Messaggi nel Database

Poiché l’attaccante ha una copia del database, può vedere tutte le informazioni memorizzate in tutti i post.

• Se hai inoltrato password o informazioni sull’account esterne nelle tue risposte, private o pubbliche, dovresti cambiare quelle password immediatamente.

• Se hai informazioni sensibili nelle tue risposte, private o pubbliche, sii consapevole che l’attaccante può vedere tali informazioni.

Messaggi crittografati

Se stai utilizzando il plugin Discourse Encrypt, i messaggi crittografati saranno crittografati end-to-end. Ciò significa che se un database viene violato, l’attaccante non sarà in grado di accedere al contenuto dei messaggi crittografati.

Regolamenti

Assicurati di consultare un parere legale professionale riguardo ai tuoi obblighi legali. Determinati regolamenti come il GDPR e il CCPA possono imporre la divulgazione.

In Futuro

Potresti voler richiedere l’autenticazione a due fattori per gli utenti dello staff se hai motivo di credere che il tuo sito sarà sotto attacco. L’impostazione del sito che desideri è “enforce second factor” (forza secondo fattore).

enforce second factor

Forza gli utenti ad abilitare l’autenticazione a due fattori. Seleziona ‘all’ per imporla a tutti gli utenti. Seleziona ‘staff’ per imporla solo agli utenti dello staff.