Resumo: apagamento de DNS do CMS não reportado com sinal de alerta de transferência de registador WHOIS
- "Pequeno problema de DNS" ou sequestro: Os fornecedores externos adoram a expressão "pequeno problema de DNS", mas um apagamento total de DNS coincidente com uma atualização de registador WHOIS parece, do ponto de vista do cliente, idêntico a um sequestro de domínio ao estilo Polyfill, e só um destes dois cenários termina em notificação ao cliente.
- Retirámo-lo e monitorizámo-lo: A cside retirou o ButterCMS do nosso próprio blog a 9 de setembro, às 08:00 PT, quando o DNS deixou de resolver em simultâneo com uma atualização WHOIS, e o nosso motor já acompanha o histórico de registos DNS, os metadados WHOIS e a deriva comportamental de cada domínio de terceiros em cerca de 1.660 sites potencialmente afetados e 5.800 domínios adicionais.
- Sem post-mortem, sem confiança: Se o teu fornecedor de CMS não consegue publicar uma entrada na página de estado, um número de caso ou um post-mortem depois de uma queda que podia passar por um sequestro de domínio, a questão não é confiar na correção, é decidir se a verificação contínua de cada terceiro dinâmico é indispensável ou apenas um extra.
Sem tempo? Veja o bloqueio in-browser de Magecart e skimmers da cside. Cobre tudo o que se segue numa única implementação.
O ButterCMS é uma ferramenta popular utilizada para gerir conteúdo de blogs. No início desta semana, detetámos um incidente de segurança potencialmente grave que levou a equipa a remover o ButterCMS do nosso site e a iniciar uma investigação aprofundada sobre o que aconteceu. Potencialmente 1.660 sites e mais de 5.800 domínios foram impactados.
O nosso objetivo é partilhar as conclusões da nossa investigação para mostrar o que pode acontecer quando se confia em terceiros dinâmicos sem verificação contínua.
O incidente do ButterCMS
Observámos o incidente a começar às 08:00 (PT) de 9 de setembro, quando detetámos um aumento significativo de erros porque o DNS estava a falhar na resolução do hostname. Isto resultou numa interrupção do blog no nosso site.
Pouco depois, reparámos que o site do ButterCMS estava em baixo porque não estava a ser servido nenhum registo DNS.
Ao investigar mais a fundo, verificámos que o domínio do ButterCMS tinha tido uma atualização de WhoIs precisamente quando os nossos problemas começaram. Uma razão lógica para isto poderia ter sido uma renovação ou uma mudança de propriedade do domínio. Esta última seria altamente preocupante.
Se o domínio tivesse sido "capturado" e tivesse caído em mãos maliciosas, poderia ter representado um sério risco de segurança, semelhante ao incidente do Polyfill, em que uma mudança de propriedade de domínio provocou um grande ataque à cadeia de fornecimento de navegadores em quase 500.000 sites. Isto resultou na injeção de código malicioso nos navegadores de milhões de visitantes, provocando redirecionamentos maliciosos e potencialmente outros ataques furtivos que passaram despercebidos devido à subutilização da monitorização de segurança do lado do cliente.
Nesta altura, desativámos por completo a integração do ButterCMS para evitar que qualquer dado fosse servido a partir do domínio potencialmente comprometido. Desativar o CMS elimina o risco de código malicioso ser injetado no nosso site.
Contactámos via X (Twitter) para notificar a equipa do ButterCMS:
Estamos a ter problemas de DNS com
, parece que o vosso DNS foi completamente apagado em várias redes diferentes.
Como não consigo aceder ao site, não tenho outra forma de contactar a vossa equipa de suporte.- cody (@devlooskie)
Não responderam à nossa mensagem.
Às 08:30, observámos que os registos DNS do ButterCMS estavam a ser restaurados e, importante, apontavam para os mesmos IPs de antes da interrupção. Isto sugere que o problema se deveu provavelmente a uma configuração incorreta ou a uma indisponibilidade no fornecedor de DNS usado para o seu domínio. Durante a interrupção, não vimos nenhum registo presente. Nem para o site, nem para a API.
Assim que confirmámos que o serviço tinha voltado ao normal, revertemos as nossas alterações.
Por fim, contactámos a equipa do ButterCMS através do seu serviço de chat:
Na mensagem completa, a operadora de suporte afirmou que a sua equipa desconhecia o problema, mas que tinha começado a investigar. Não podemos partilhar o histórico completo da mensagem, pois, ao pedirmos um número de caso, responderam que não tinham nenhum. O Intercom deveria atribuir estes números por defeito.
Verificámos a página de estado do ButterCMS, que, até hoje, não mostra qualquer interrupção. Isto levou-nos inicialmente a acreditar que o problema estava do nosso lado, ou que era maior do que na realidade se veio a revelar.
A correspondência falhada com o ButterCMS
Depois de tudo isto, contactámo-los por e-mail. Eis a resposta deles:
Mencionam uma aquisição recente do ButterCMS pela Tiugo Technologies. No entanto, isso foi noticiado no final de 2022, há mais de 1,5 anos. Embora isto explique agora o motivo da transferência de domínio, não fomos informados nem notificados antes das alterações.
Fizemos um seguimento e recebemos a seguinte mensagem:
Um problema de verificação poderia ter sido a causa. Saberemos mais na sua declaração post-mortem, a ser publicada em breve.
Num último e-mail de seguimento, a 12 de setembro, esta foi a resposta deles:
Acreditamos que a comunicação sobre este tipo de alterações é vital. Quando alterações planeadas correm mal, mesmo que ligeiramente, isso coloca os clientes num risco significativo. Um e-mail rápido a notificar os utilizadores faz toda a diferença neste tipo de cenários.
Estas alterações podem até interferir com os requisitos do RGPD, agora que se sabe que a propriedade do domínio mudou após uma aquisição. O RGPD não menciona especificamente transferências de domínio, mas foca-se na transferência do controlo sobre dados pessoais. Se a mudança de propriedade resultar num novo responsável pelo tratamento a gerir dados pessoais, os clientes (titulares dos dados) teriam de ser informados. Isto enquadra-se nos princípios de transparência e equidade do RGPD (Artigos 13 e 14).
Os clientes devem ser notificados sobre a identidade do novo responsável pelo tratamento e sobre quaisquer alterações na forma como os seus dados serão processados. A notificação deve ocorrer num prazo razoável.
Esperámos algum tempo antes de publicar isto, para ver se ainda chegaria alguma comunicação antes do webinar planeado. Até agora, não vimos nenhuma.
ATUALIZAÇÃO: Mesmo depois do webinar, não houve gravação nem qualquer publicação de blog ou declaração.
Mais tarde, tentámos procurar outras empresas a comentar este problema, mas não encontrámos nenhuma. Embora não possamos saber o número exato de clientes afetados, potencialmente 1.660 sites e mais de 5.800 domínios adicionais foram impactados:
O risco de terceiros dinâmicos
Isto é mais grave do que uma simples alteração de registos. Este padrão é exatamente o que acontece quando um domínio muda de propriedade, ou quando detalhes importantes do WhoIs são atualizados.
Embora o problema esteja agora resolvido, esta situação revelou uma potencial vulnerabilidade de segurança.
A lição mais ampla deste incidente é o risco que se assume ao depender de serviços de terceiros que injetam conteúdo dinamicamente nos sites. Um problema que conhecemos bem, e contra o qual protegemos do lado do cliente.
Os domínios usados em integrações podem ser comprados por agentes maliciosos e explorados para ataques. O conteúdo que injetam é dinâmico. Isto significa que o conteúdo pode variar consoante vários fatores, como a hora, a região e outros dados específicos do utilizador, o que facilita aos agentes maliciosos contornar a deteção.
Neste caso, a renovação do domínio do ButterCMS e a falta de clareza em torno da atualização do WhoIs levantaram um sinal de alerta que nos lembrou da necessidade de monitorizar dependências de terceiros.
A forma como um site é construído afeta significativamente a sua vulnerabilidade a este tipo de problema. Idealmente, qualquer input deveria ser devidamente sanitizado. O input do utilizador deve ser limpo para evitar que código malicioso seja injetado no site.
Muitos programadores não implementam uma sanitização adequada, sobretudo quando este aspeto não é explicitamente abordado na documentação.
Se procurares por "dangerouslySetInnerHTML", não há indicações claras sobre como usar esta prop em segurança. Sem uma sanitização adequada, qualquer HTML válido pode ser injetado, o que cria uma vulnerabilidade séria de XSS (Cross-Site Scripting).
Quando o HTML é injetado no cliente, toda a página pode ficar comprometida através de injeções de script. Sem salvaguardas, o HTML injetado pode executar scripts nocivos ou redirecionar utilizadores para sites maliciosos, transformando efetivamente a funcionalidade num portal aberto a riscos de segurança.
Como isto é tratado do lado do cliente
O risco de mudança de domínio não é, obviamente, novidade para nós. É um vetor de ataque comum no mundo da segurança do lado do cliente. A cside já verifica o histórico de registos DNS, informação WhoIs e metadados.
Enquanto o site se mantiver ativo (e, como resultado, a cside também) e ocorrerem alterações ou anomalias, o nosso motor deteta-as. E, depois de verificar outras possíveis atividades maliciosas, alertará e/ou bloqueará o domínio, o script e, assim, um possível ataque.
Podes proteger o teu site de forma rápida e gratuita usando a cside.
