O Varonis Threat Labs encontrou uma vulnerabilidade de injeção de SQL e uma falha de acesso lógico no Zendesk Explore, o serviço de geração de relatórios e análises da popular solução de atendimento ao cliente, Zendesk.
Não há evidências de que as contas de clientes do Zendesk Explore tenham sido invadidas, e a Zendesk começou a trabalhar em uma correção no mesmo dia em que a falha foi relatada. A empresa corrigiu vários bugs em menos de uma semana de trabalho sem exigir nenhuma ação por parte dos clientes.
Antes de ser corrigida, a falha permitia que agentes mal-intencionados acessassem conversas, endereços de e-mail, tíquetes, comentários e outras informações de contas do Zendesk com o Explore ativado.
“A Zendesk começou a trabalhar em uma correção no mesmo dia em que o problema foi relatado. A empresa corrigiu vários bugs em menos de uma semana de trabalho sem exigir nenhuma ação por parte dos clientes.”
Para explorar essa vulnerabilidade, um invasor primeiro se registra no serviço de emissão de tíquetes da conta do Zendesk da vítima como novo usuário externo. O registro é ativado como padrão, já que muitos clientes do Zendesk precisam que os usuários finais enviem tíquetes de suporte diretamente pela web. O Zendesk Explore não está ativado como padrão, mas geralmente é anunciado como necessário para acessar a página de insights analíticos.
Executar, codificações aninhadas e XMLs. Que programa!
A Zendesk usa várias APIs GraphQL em seus produtos, especialmente no console de administração. Como o GraphQL é um formato de API relativamente novo, iniciamos nossa investigação por ele. Encontramos um tipo de objeto particularmente interessante no Zendesk Explore chamado QueryTemplate.
O campo querySchema chamou nossa atenção porque continha um documento XML codificado em Base64 chamado Query dentro de um objeto JSON, e muitos dos atributos no XML eram objetos JSON codificados em Base64. O que isso significa? Que é um objeto JSON codificado em Base64, dentro de um documento XML codificado em Base64, dentro de um objeto JSON. Ufa!
Várias codificações aninhadas sempre chamam nossa atenção porque um grande número de wrappers nos dados geralmente significa que muitos serviços diferentes (que provavelmente foram criados por desenvolvedores ou até mesmo equipes diferentes) são usados para processar esses dados. Mais código em geral significa mais locais com potencial para vulnerabilidades.
É por isso que nos aprofundamos no Zendesk Explore como um usuário de nível de administrador da nossa própria conta de laboratório no Zendesk. Ao visualizar um relatório no Zendesk Explore, encontramos uma API chamada execute-query. Esse método de API aceita um objeto JSON com a Query XML, juntamente com vários outros parâmetros XML, alguns dos quais são codificados em Base64.
Injeção de SQL
Um dos campos passados para a API é extra_param3_value, que inclui um documento XML de texto simples, DesignSchema, não codificado em Base64. Esse documento define a relação entre um AWS RDS (banco de dados relacional gerenciado) e o documento Query XML mencionado anteriormente.
Todos os atributos de nome nesse documento XML, que definem as tabelas e colunas a serem consultadas, foram considerados vulneráveis a um ataque de injeção de SQL. O desafio da nossa equipe era explorar a vulnerabilidade do SQLi para exfiltrar os dados.
O mecanismo de análise XML no back-end estava pronto para aceitar atributos com aspas simples em vez de atributos com aspas duplas como padrão, permitindo-nos evitar as aspas duplas no nome da tabela.
Precisávamos de uma maneira de escrever strings na consulta sem usar aspas simples ou duplas. Felizmente, o PostgreSQL, o banco de dados usado pelo Zendesk Explore, fornece uma maneira conveniente de representar strings: constantes de string entre cifrões. Os caracteres “$$” podem ser usados para definir uma string no lugar das aspas simples padrão em uma instrução SQL.
Usando esse método de representação de strings, conseguimos extrair a lista de tabelas da instância RDS do Zendesk e continuar exfiltrando todas as informações armazenadas no banco de dados, incluindo endereços de e-mail de usuários, leads e negócios do CRM, chats ao vivo de agentes, tíquetes, artigos da Central de Ajuda e muito mais.
A falha de acesso lógico
As injeções de SQL têm suas vantagens, mas a capacidade de exfiltrar dados como administrador não é muito interessante. Estávamos procurando um impacto mais amplo, então decidimos investigar como funciona essa API execute-query.
O método da API execute-query aceita uma carga JSON contendo um objeto “content” com as propriedades “query”, “cubeModels” e “datasources”.
“query” contém um documento Query XML com as colunas, linhas, segmentos, métricas e explosões da consulta, bem como a configuração de visualização no formato JSON. O documento também contém uma referência à propriedade “cubeModels”. “cubeModels” contém um documento XML chamado “OLAPSchema” que define as tabelas que podem ser consultadas na fonte de dados selecionada.
A API execute-query falhou ao executar várias verificações lógicas em solicitações:
- A integridade dos documentos não foi verificada, o que permitiu que nossa equipe os modificasse de forma a revelar o funcionamento interno do sistema.
- Os IDs de “query”, “datasources” e “cubeModels” não foram avaliados para verificar se pertenciam ao usuário atual.
- Por fim, mas não menos importante, o endpoint da API não verificou se o autor da chamada tinha permissão para acessar o banco de dados e executar consultas. Isso significa que um usuário final recém-criado poderia invocar essa API, alterar a consulta e roubar dados de qualquer tabela no RDS da conta do Zendesk de destino, sem SQLi.
Conclusão
A Varonis Threat Labs ajudou a Zendesk a resolver uma vulnerabilidade SQLi e uma falha de controle de acesso no Zendesk Explore que teria permitido que um agente mal-intencionado vazasse dados de contas de clientes do Zendesk com o Explore ativado. O Zendesk resolveu o problema rapidamente e essa falha no Explore foi removida. Nenhuma ação é necessária por parte dos clientes atuais.
