karlemilnikka/cve-2023-1430Divulgação responsável de vulnerabilidade não corrigida no FluentCRM por WPManageNinja
Atualização 2023-06-12: Você não precisa mais do trecho. A WPManageNinja corrigiu a vulnerabilidade duas horas após a divulgação pública (93 dias após o relato).
Atualização 2024-01-27: O problema relacionado com com valores de hash eternos está agora totalmente resolvido.
tl;dr Atacantes podem visualizar e editar detalhes de contatos no FluentCRM. A WPManageNinja não corrigiu a vulnerabilidade dentro do prazo de 90 dias de divulgação responsável. Forneço um trecho de mitigação para evitar a exploração da vulnerabilidade enquanto se aguarda uma correção oficial.
Hoje, estou publicando informações sobre uma vulnerabilidade que encontrei no popular plugin WordPress FluentCRM da WPManageNinja. A vulnerabilidade, CVE-2023-1430, é causada pelo uso insuficiente de um hash de endereço de email como controle de autorização pelo FluentCRM. Divulguei a vulnerabilidade de forma responsável de acordo com a política de divulgação de vulnerabilidades do Google Zero. A WPManageNinja não forneceu uma correção dentro do prazo de 90 dias nem solicitou uma extensão de prazo.
Neste relatório, contact refere-se a um objeto de contato do FluentCRM, enquanto user refere-se a um objeto de usuário do WordPress. Um contato pode estar vinculado a um usuário, mas não é um requisito. Detalhes sobre a exploração da vulnerabilidade são omitidos até que uma correção oficial esteja disponível. Profissionais de segurança podem entrar em contato comigo para o relatório completo ([email protected]).
Em sites que executam o FluentCRM, um atacante pode visualizar e editar o nome, endereço de email e configuração de lista de um contato ao saber o endereço de email do contato. Como o nome do contato é frequentemente incluído em newsletters através de merge tags, um atacante pode substituir o nome do contato por linguagem obscena, fazendo com que o proprietário do site envie newsletters vulgares. Se o administrador do site ativou o shortcode do FluentCRM para gerenciar preferências e o adicionou a uma página web pública, um atacante pode visualizar e editar todas as informações pessoais expostas, ou seja, título, número de telefone, data de nascimento e endereço (dependendo da configuração do FluentCRM).
O FluentCRM está instalado em mais de 30.000 sites. Administradores de sites com FluentCRM podem evitar a exploração da vulnerabilidade adicionando meu trecho de mitigação ao arquivo functions.php do tema filho.
O trecho não corrige a vulnerabilidade. Ele substitui o conteúdo vulnerável na página de cancelamento de inscrição do FluentCRM (unsubscribe.php) e na página de gerenciamento de preferências (manage_subscription.php) por uma mensagem de erro informando ao contato para entrar em contato por email. O endereço de email na mensagem de erro é o endereço de email do administrador do site (pode ser alterado no trecho). O trecho de mitigação também garante que visitantes não logados não possam renderizar o shortcode vulnerável do FluentCRM para gerenciar preferências (fluentcrm_pref). Um visitante não logado verá uma mensagem de erro informando para fazer login. Todas as strings são traduzíveis com o arquivo POT fornecido.
Recomendo que os proprietários de sites implementem a mitigação que forneço ou sua própria mitigação correspondente. Os proprietários de sites também devem verificar a integridade de seus dados de contato do FluentCRM e, se possível, verificar seus logs em busca de possíveis vazamentos de dados. Verificar os logs é especialmente importante para os seguintes sites:
O controlador de dados designado do site deve lidar com possíveis vazamentos de dados de informações pessoais de acordo com as leis e regulamentos nas jurisdições afetadas.
Se o FluentCRM estiver configurado para sincronizar as configurações de um contato com seu usuário correspondente, um atacante pode alterar o nome do usuário. Felizmente, o FluentCRM não sincroniza endereços de email de contatos para usuários. Se o fizesse, essa vulnerabilidade permitiria a tomada total do site. Um atacante poderia obter acesso privilegiado alterando o endereço de email do administrador do site e depois redefinindo a senha do administrador.
No entanto, outras soluções podem sincronizar todos os metadados de contatos para usuários, por exemplo, WP Fusion e a API do FluentCRM. O WP Fusion é provavelmente o plugin de terceiros mais popular para sincronizar metadados de contatos entre um CRM (por exemplo, FluentCRM) e o WordPress. Felizmente, a versão atual do WP Fusion não está conectada a alterações de metadados iniciadas a partir dos formulários vulneráveis. Informei os desenvolvedores do WP Fusion, e eles não abordarão essa limitação até que a WPManageNinja tenha corrigido a vulnerabilidade.
A API do FluentCRM também pode ser usada para atualizar dados de contato e usuário. Proprietários de sites que usam a API do FluentCRM para atualizar endereços de email de usuários devem desabilitar essa atualização quando iniciada a partir da página ou shortcode do FluentCRM para gerenciar preferências (ou adicionar meu trecho de mitigação para garantir que nenhuma configuração possa ser atualizada a partir dos formulários vulneráveis).
O FluentCRM permite que contatos cancelem a inscrição e gerenciem preferências a partir de páginas web públicas. Links para essas páginas são incluídos em cada newsletter. As alterações feitas nessas páginas são autorizadas por hashes MD5 dos endereços de email dos contatos, passados como parâmetros de URL. O hash MD5 de um endereço de email não é um segredo e pode ser calculado por qualquer pessoa. Um atacante pode explorar o uso incorreto de hashes para cancelar a inscrição de contatos específicos ou cancelar a inscrição de contatos com endereços de email conhecidos em massa.
Enquanto a página de cancelamento de inscrição depende exclusivamente do hash MD5 para autorização, a página de gerenciamento de preferências requer um parâmetro de URL adicional chamado ce_id. Neste caso, o ce_id refere-se ao ID do contato na tabela fc_subscribers. Este ID é um inteiro incremental. O valor do ce_id é, portanto, facilmente encontrado testando todos os valores possíveis (o espaço de busca é o número de contatos já registrados no site). Os usuários administradores provavelmente têm valores baixos.
A partir da página de gerenciamento de preferências, um atacante também pode exfiltrar o valor secure_hash do contato. Ao atualizar o endereço de email do contato, o valor “secure_hash” do contato é armazenado em um cookie chamado fc_hash_secure. Com esse cookie em vigor, o atacante pode exibir todas as informações de contato disponibilizadas pelo shortcode do formulário de preferências do FluentCRM.
O “secure_hash” mencionado anteriormente é um valor no qual o FluentCRM (em algumas situações) depende em vez do hash MD5 do endereço de email ou como alternativa a ele. Desde o lançamento do FluentCRM 2.8.0, a página de cancelamento de inscrição depende exclusivamente do valor secure_hash para autorização. A página de gerenciamento de preferências aceita tanto o novo valor secure_hash quanto o antigo hash MD5 do endereço de email para autorização.
Embora o valor secure_hash não possa ser derivado do endereço de email, o uso do FluentCRM não segue boas práticas de segurança. O valor secure_hash é gerado uma vez por contato. Nunca é atualizado e nunca expira. Isso é problemático, pois o valor secure_hash é incluído em cada newsletter. Se um atacante obtiver acesso à caixa de entrada de um contato, o atacante pode alterar as configurações do contato indefinidamente. Se o contato afetado estiver vinculado a um usuário com privilégios de administrador, e as alterações de endereço de email forem sincronizadas do FluentCRM para o WordPress, cada newsletter enviada a esse contato conterá um token que nunca expira para assumir o controle do site.
Relatei esse problema relacionado à WPManageNinja em 15/03/2023. Dois meses depois (15/05/2023), a WPManageNinja respondeu que seus consultores de segurança não consideravam o valor estático secure_hash um problema. Os consultores de segurança da WPManageNinja disseram que “está tudo bem usar esse tipo de token gerado uma vez para identificar o contato” e que era “semelhante a tokens de API de serviços SaaS que não são entregues a nenhum outro contato, mas apenas enviados ao contato real que possui o endereço de email”.
A WPManageNinja estava aberta a sugestões e me disse para avisá-los se ainda achasse que era uma preocupação de segurança, o que fiz. Expliquei por que os valores secure_hash não poderiam ser comparados a tokens de API. (Os tokens de API podem ser garantidos de serem enviados apenas por conexões TLS, e o acesso a tokens de API pode ser restrito. Esse não é o caso de valores em texto claro em emails. Mais importante, tokens de API podem ser revogados, enquanto não há maneira de um contato revogar um valor secure_hash.)
No mesmo dia, a WPManageNinja me agradeceu e disse que consideraram combinar o ID do registro de email com o hash. Isso resolverá o problema se implementado em conjunto com a revogação automática de valores secure_hash antigos (expiração baseada em tempo) ou anteriores (expiração baseada em contador). Esse recurso ainda não foi implementado, mas não considero o uso de valores de hash estáticos como parte deste CVE.
No primeiro trimestre de 2023, começamos a migrar de nossa ferramenta de newsletter anterior (Sendy) para o FluentCRM. Encontrei a vulnerabilidade ao integrar o FluentCRM com a Nikka Systems Academy (Project Opal). Como substituímos o sistema de gerenciamento de inscrições do FluentCRM pelo nosso plugin personalizado, os formulários vulneráveis do FluentCRM nunca afetaram nosso site ou os dados de nossos clientes.
O FluentCRM é um ótimo plugin, mas o tratamento da divulgação de vulnerabilidades pela WPManageNinja deixa muito a desejar. A lista a seguir é minha sugestão de como a WPManageNinja poderia melhorar a situação.
Dito isso, ainda confio na WPManageNinja. Existem bugs em todos os softwares, e um único relato de vulnerabilidade mal gerenciado não é motivo para parar de usar seus plugins.
Atualização 2023-06-12: O fato de ainda tentarem esconder a vulnerabilidade no changelog me preocupa genuinamente. (Eles agora adicionaram o CVE.)
