Recentemente, tivemos dois relatos de sites Discourse que foram comprometidos, provavelmente devido a senhas fracas de contas de administrador. Portanto, gostaríamos de documentar:
- o que fazer quando ocorre um comprometimento
- o que podemos fazer para prevenir melhor isso no futuro
O Banco de Dados
Observe que o Discourse, há vários anos, tem as seguintes proteções em vigor em relação ao banco de dados do site:
-
Os links para download de backup completo do banco de dados só serão enviados por meio de e-mail válido de um administrador do site, então você não pode simplesmente fazer login (por meio de “shoulder surfing” ou esquecer de sair), você também deve controlar o endereço de e-mail de um administrador do site. E você tem o 2FA configurado para seu e-mail, certo?
-
Para alterar o e-mail da equipe, você deve verificar o controle de ambos os endereços de e-mail, o antigo e o novo — enquanto um usuário normal só precisa verificar o controle do endereço de e-mail novo. Isso torna muito mais difícil alterar o endereço de e-mail de um membro da equipe.
-
Assumindo que você configurou a chave de API do banco de dados de geolocalização (é grátis, requer um cadastro), você será ativamente avisado quando membros da equipe fizerem login de locais fisicamente distantes de onde fizeram login pela última vez.
-
Administradores que não fazem login há mais de um ano são obrigados a revalidar seu endereço de e-mail, para reduzir a superfície de ataque. A configuração do site para isso é
invalidate inactive admin email after days(invalidar e-mail de administrador inativo após dias) e o padrão é 365.
Ainda assim, em caso de comprometimento, você deve sempre presumir que uma conta de administrador mal-intencionada baixou uma cópia completa do banco de dados/backup do site.
Portanto, você deve IMEDIATAMENTE redefinir todas as senhas de contas usando o seguinte comando:
./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'
Além disso, você deve desconectar todos os usuários
./launcher enter app
rails r 'UserAuthToken.destroy_all'
Finalmente, você deve remover todas as chaves de API
./launcher enter app
rails r 'UserApiKey.destroy_all'
rails r 'ApiKey.destroy_all'
Senhas de Conta no Banco de Dados
De acordo com nossa documentação de segurança, o Discourse usa hashes muito fortes e lentos para atacar as senhas armazenadas no banco de dados:
O Discourse usa o algoritmo PBKDF2 para criptografar senhas com sal. Este algoritmo é abençoado pelo NIST. Especialistas em segurança na web tendem a concordar que o PBKDF2 é uma escolha segura.
E o comprimento mínimo padrão da senha é 10 para usuários e 15 para administradores — então isso torna difícil reverter por força bruta os hashes de senha para obter o hash. Mas isso não impede que os usuários definam uma senha como senha1senha1 ou algo trivial de reverter, mesmo com um hash forte.
E-mails no Banco de Dados
O invasor pode ver todos os endereços de e-mail de todos os usuários no seu site. Esta é normalmente uma informação privilegiada que até moderadores precisam clicar em um botão para revelar.
Conteúdo da Mensagem no Banco de Dados
Como o invasor tem uma cópia do banco de dados, ele pode ver todas as informações armazenadas em todas as postagens.
-
Se você tem senhas externas ou informações de conta retransmitidas em suas respostas, privadas ou públicas, você deve alterar essas senhas imediatamente.
-
Se você tem informações confidenciais em suas respostas, privadas ou públicas, esteja ciente de que o invasor pode ver essas informações.
Mensagens Criptografadas
Se você estiver usando o plugin Discourse Encrypt, as mensagens criptografadas serão criptografadas de ponta a ponta. Isso significa que, se o banco de dados vazar, o invasor não poderá obter acesso ao conteúdo em mensagens criptografadas.
Regulamentações
Certifique-se de buscar aconselhamento jurídico profissional sobre sua obrigação legal. Certos regulamentos, como GDPR e CCPA, podem exigir divulgação.
No Futuro
Você pode querer exigir autenticação de dois fatores para usuários da equipe se tiver motivos para acreditar que seu site estará sob ataque. A configuração do site que você deseja é “enforce second factor” (forçar segundo fator)
enforce second factor (forçar segundo fator)
Força os usuários a habilitar a autenticação de dois fatores. Selecione ‘all’ (todos) para forçar a todos os usuários. Selecione ‘staff’ (equipe) para forçar apenas aos usuários da equipe.