O Instituto Holandês para Divulgação de Vulnerabilidades (DIVD) afirma que a violação da sua própria rede foi possível porque os atacantes exploraram uma cadeia de duas vulnerabilidades zero-day no Zammad, o sistema de tickets de código aberto. A violação do DIVD por zero-day no Zammad é um lembrete contundente de que mesmo organizações cuja função é encontrar e reportar falhas de segurança podem ser surpreendidas por falhas que ninguém conhecia ainda.

As informações disponíveis até agora são breves, por isso este artigo mantém-se ao que foi declarado e explica porque é que isso importa.

Como a cadeia zero-day do Zammad violou o DIVD

De acordo com o DIVD, a intrusão na sua rede foi possível através da combinação de duas vulnerabilidades zero-day separadas no Zammad. Um zero-day é uma falha desconhecida pelo fornecedor ou sem patch disponível quando é explorada, o que deixa os defensores sem correção pronta.

A combinação é importante. Uma vulnerabilidade pode dar ao atacante um ponto de apoio ou acesso limitado, enquanto uma segunda permite-lhe ir mais longe, por exemplo, elevando privilégios ou alcançando sistemas que deveriam estar fora de alcance. Combinados, dois bugs moderados podem resultar numa comprometimento grave.

O Zammad é uma plataforma de help desk e tickets de código aberto, comummente auto-hospedada por organizações para gerir pedidos de suporte. O resumo da fonte não detalha a natureza técnica das duas falhas, e não vamos especular sobre elas. Os leitores devem estar atentos a avisos oficiais e patches do projeto Zammad e do DIVD.

O que o ataque impulsionado por IA muda para os defensores

O título descreve a violação como impulsionada por IA, e a abordagem sugerida nota que ferramentas de IA alegadamente aceleraram o ataque. Os detalhes exatos de como a IA foi usada não constam no material que temos, por isso seria um erro exagerá-lo.

A preocupação geral continua a ser válida. A automação pode encurtar o tempo entre encontrar uma fraqueza e explorá-la. Se as ferramentas ajudam um atacante a descobrir, testar e encadear vulnerabilidades mais rapidamente, a janela que os defensores têm para reagir torna-se menor. Isso dá mais peso a:

  • Aplicação rápida de patches assim que as correções são lançadas
  • Limitar o que uma aplicação exposta à internet pode alcançar dentro da rede
  • Monitorização que deteta comportamentos invulgares precocemente, em vez de depender de assinaturas conhecidas

Nada disto é motivo para pânico. É motivo para tratar a gestão de exposição como um processo contínuo em vez de uma auditoria ocasional.

Porque os sistemas de tickets contêm mais dados sensíveis do que pensa

Um sistema de tickets parece uma ferramenta banal, mas frequentemente recolhe uma quantidade surpreendente de informação. As pessoas descrevem os seus problemas em texto livre, anexam capturas de ecrã e registos, e incluem nomes, endereços de email, detalhes de contas e, por vezes, credenciais ou informação de sistemas internos. Para uma organização de divulgação de vulnerabilidades, os tickets podem também estar relacionados com questões de segurança ainda não corrigidas.

Isso torna estas plataformas alvos atrativos. Ficam entre o público e as equipas internas, são frequentemente acessíveis a partir da internet e contêm um longo histórico de conversas que poucos se lembram de limpar.

O mesmo padrão aparece noutros casos. Na violação da Adidas envolvendo um fornecedor terceiro, dados de contacto de clientes foram obtidos através de um prestador de serviços ao cliente comprometido. A lição é semelhante: a infraestrutura de suporte pode tornar-se o ponto fraco mesmo quando os sistemas centrais do negócio estão melhor protegidos. A exposição de dados também pode acontecer de formas menos diretas, como no caso em que agentes da OpenAI publicaram 53 imagens do ChatGPT em sites públicos sem autorização, um lembrete de que a informação partilhada com um serviço pode viajar para além do que os utilizadores esperam.

O que isto significa para si

Se contactou o DIVD ou reportou uma vulnerabilidade a eles, esteja atento a comunicações oficiais da organização sobre se a sua informação foi afetada. Não temos confirmação da fonte sobre que dados foram acedidos, por isso evite assumir o pior, mas mantenha-se alerta a avisos de seguimento.

Se utiliza o Zammad ou uma ferramenta de tickets auto-hospedada semelhante, este é um bom momento para verificar a sua exposição. Para todos os outros, a conclusão é sobre hábitos: os detalhes que entrega aos serviços de suporte podem viver num sistema que desconhece completamente, gerido por um fornecedor que não escolheu.

O que as organizações e utilizadores devem verificar agora

Para organizações que usam Zammad:

  • Verifique o projeto Zammad e o DIVD para avisos de segurança e aplique quaisquer patches prontamente.
  • Reveja se a sua instância precisa de estar exposta diretamente à internet e coloque-a atrás de controlos de acesso onde possível.
  • Segmente o servidor dos sistemas internos para que um comprometimento não se torne um problema à escala da rede.
  • Reveja os registos para atividade invulgar e rode credenciais que possam aparecer em tickets antigos.
  • Defina regras de retenção para que tickets antigos com conteúdo sensível não sejam mantidos indefinidamente.

Para indivíduos:

  • Partilhe o mínimo necessário com as equipas de suporte e evite enviar palavras-passe, documentos de identidade completos ou detalhes de pagamento em tickets.
  • Use palavras-passe únicas para cada serviço para que um ticket divulgado não possa desbloquear outras contas.
  • Seja cauteloso com emails inesperados que referenciem um pedido de suporte anterior, pois os atacantes podem usar detalhes de tickets divulgados para parecerem convincentes. O caso Mayer Brown Luna Moth mostra como a personificação pode funcionar mesmo sem um comprometimento genuíno de sistema.

A conclusão

A violação do DIVD por zero-day no Zammad mostra que as plataformas de suporte e tickets merecem o mesmo escrutínio que qualquer outro sistema crítico. Aplique patches rapidamente, limite a exposição e elimine dados que já não precisa. Como leitor, reserve alguns minutos para rever que informação pessoal partilhou com serviços de suporte e fornecedores, e considere como uma violação num deles pode afetá-lo. Para um exemplo paralelo de sistemas de apoio ao cliente a tornarem-se o ponto fraco, leia a nossa cobertura da violação do fornecedor terceiro da Adidas.