ButterCMS é uma ferramenta popular usada para gerenciar conteúdo de blogs. No início desta semana, notamos um incidente de segurança potencialmente grave que levou a equipe a remover o ButterCMS do nosso site, e iniciar uma investigação aprofundada sobre o que aconteceu. Potencialmente 1.660 sites e mais de 5.800 domínios foram impactados.
Nosso objetivo é compartilhar as descobertas de nossa investigação para mostrar o que pode acontecer quando você confia em terceiros dinâmicos sem verificação contínua.
O incidente do ButterCMS
Observamos o incidente começando às 08:00 (PT) de 9 de setembro, quando notamos um aumento significativo de erros porque o DNS estava falhando ao resolver o hostname. Isso resultou em uma interrupção do blog em nosso site.
Logo depois, notamos que o site do ButterCMS estava fora do ar porque nenhum registro DNS estava sendo servido.
Quando investigamos mais a fundo, notamos que o domínio do ButterCMS teve uma atualização de WhoIs ao mesmo tempo em que nossos problemas começaram. Uma razão lógica para isso poderia ter sido uma renovação ou uma mudança de propriedade do domínio. Esta última seria altamente preocupante.
Se o domínio foi "capturado" e caiu em mãos maliciosas, poderia ter representado um sério risco de segurança, semelhante ao incidente do Polyfill, onde uma mudança de propriedade de domínio causou um grande ataque à cadeia de suprimentos de navegadores em quase 500.000 sites. Isso resultou em código malicioso sendo injetado nos navegadores de milhões de visitantes, resultando em redirecionamentos maliciosos e potencialmente outros ataques furtivos que não foram notados devido ao monitoramento de segurança do lado do cliente ser subutilizado.
Neste momento, desabilitamos a integração do ButterCMS inteiramente para evitar que quaisquer dados fossem servidos do domínio potencialmente comprometido. Desabilitar o CMS remove o risco de código malicioso ser injetado em nosso site.
Entramos em contato via X (Twitter) para notificar a equipe do ButterCMS:
Estamos enfrentando problemas de DNS com
, parece que seu DNS foi totalmente apagado em várias redes diferentes.
Como não consigo acessar o site, não tenho outra forma de contatar sua equipe de suporte.— cody (@devlooskie)
Eles não responderam à nossa mensagem.
Às 08:30, observamos que os registros DNS do ButterCMS estavam sendo restaurados e, importante, apontavam para os mesmos IPs de antes do tempo de inatividade. Sugerindo que o problema provavelmente foi devido a uma configuração incorreta ou tempo de inatividade com o provedor de DNS usado para seu domínio. Durante o tempo de inatividade, não vimos nenhum registro presente. Nem para o site, nem para a API.
Uma vez que confirmamos que o serviço estava de volta ao normal, revertemos nossas alterações.
Finalmente entramos em contato com a equipe do ButterCMS via seu serviço de chat:
Na mensagem completa, a operadora de suporte alegou que sua equipe não estava ciente do problema, mas começou a investigar. Não podemos compartilhar o histórico completo da mensagem, pois depois de pedir um número de caso, eles responderam que não tinham um. O Intercom deveria ter esses por padrão.
Verificamos a página de status do ButterCMS, que até hoje não mostra nenhum tempo de inatividade. Isso inicialmente nos fez acreditar que o problema estava do nosso lado, ou era maior do que acabou sendo.
A correspondência falha com o ButterCMS
Depois de tudo isso, entramos em contato com eles por e-mail. Aqui está a resposta deles:
Eles mencionam uma aquisição recente do ButterCMS pela Tiugo Technologies. No entanto, isso foi reportado no final de 2022, há mais de 1,5 anos. Embora isso agora mostre o motivo da transferência de domínio, não fomos informados ou notificados antes das mudanças.
Fizemos um acompanhamento e recebemos a seguinte mensagem:
Um problema de verificação poderia ter sido o problema. Saberemos mais em sua declaração post-mortem a ser publicada em breve.
Em um e-mail de acompanhamento final em 12 de setembro, esta foi a resposta deles:
Acreditamos que a comunicação sobre esses tipos de mudanças é vital. Quando mudanças planejadas dão errado, mesmo que ligeiramente, isso coloca os clientes em risco significativo. Um e-mail rápido para notificar os usuários faz muita diferença nesses tipos de cenários.
Essas mudanças podem até interferir com os requisitos do GDPR, agora sabendo que a propriedade do domínio mudou após uma aquisição. O GDPR não menciona especificamente transferências de domínio, mas se concentra na transferência de controle sobre dados pessoais. Se a mudança de propriedade levar a um novo controlador de dados gerenciando dados pessoais, os clientes (titulares dos dados) precisariam ser informados. Isso se enquadra nos princípios de transparência e equidade do GDPR (Artigos 13, 14).
Os clientes devem ser notificados sobre a identidade do novo controlador e quaisquer mudanças em como seus dados serão processados. A notificação deve ocorrer dentro de um prazo razoável.
Esperamos para publicar isso por algum tempo para ver se alguma comunicação ainda poderia vir antes do webinar planejado. Até agora, não vimos nenhuma.
ATUALIZAÇÃO: Mesmo após o webinar, nenhuma gravação e nenhuma postagem de blog ou declaração.
Mais tarde tentamos procurar outras empresas comentando sobre esse problema, mas não encontramos nenhuma. Embora não possamos saber seus números exatos de clientes, potencialmente 1.660 sites e mais de 5.800 domínios adicionais foram impactados:
O risco com terceiros dinâmicos
Isso é mais sério do que simplesmente registros mudando. Este padrão é exatamente o que acontece quando o domínio muda de propriedade, ou detalhes importantes do WhoIs são atualizados.
Embora o problema esteja agora resolvido, esta situação mostrou uma vulnerabilidade de segurança potencial.
A lição mais ampla deste incidente é o risco que você assume ao depender de serviços de terceiros que injetam conteúdo dinamicamente em sites. Um problema que conhecemos bem e contra o qual protegemos no lado do cliente.
Domínios usados em integrações podem ser comprados por atores maliciosos e explorados para ataques. O conteúdo que eles injetam é dinâmico. Isso significa que o conteúdo pode mudar com base em vários fatores como tempo, região e outros dados específicos do usuário, tornando fácil para atores mal-intencionados contornar a detecção.
Neste caso, a renovação do domínio do ButterCMS e a falta de clareza em torno da atualização do WhoIs levantaram uma bandeira vermelha para nos lembrar de monitorar dependências de terceiros.
Como um site é construído afeta significativamente sua vulnerabilidade a esse tipo de problema. Idealmente, qualquer entrada deve ser devidamente sanitizada. A entrada do usuário deve ser limpa para evitar que código malicioso seja injetado no site.
Muitos desenvolvedores não implementam sanitização adequada, especialmente quando isso não é explicitamente abordado na documentação.
Se você pesquisar por "dangerouslySetInnerHTML," não há orientação clara sobre como usar essa prop com segurança. Sem sanitização adequada, qualquer HTML válido pode ser injetado, o que cria uma vulnerabilidade séria de XSS (Cross-Site Scripting).
Quando HTML é injetado no cliente, toda a página da web pode ficar comprometida através de injeções de script. Sem salvaguardas, o HTML injetado poderia executar scripts prejudiciais ou redirecionar usuários para sites maliciosos, efetivamente transformando o recurso em um portal aberto para riscos de segurança.
Como isso é tratado no lado do cliente
Claro que o risco de mudança de domínio não é novo para nós. É um vetor de ataque comum no mundo da segurança do lado do cliente. cside já verifica histórico de registros DNS, informações de WhoIs e metadados.
Enquanto o site permanecer ativo (e como resultado, nosso proxy também) e quaisquer mudanças ou anomalias ocorrerem, nosso mecanismo detecta isso. E, após verificar outras possíveis atividades maliciosas, alertará e/ou bloqueará o domínio, o script e, portanto, um possível ataque.
Você pode proteger seu site rapidamente e gratuitamente usando cside.
