Bug desagradável de injeção de SQL no Zendesk coloca em risco dados confidenciais do cliente

0 0
Read Time:5 Minute, 19 Second

Várias vulnerabilidades de segurança na plataforma de gerenciamento de relacionamento com o cliente (CRM) baseada na Web do Zendesk poderiam ter permitido que invasores acessassem informações confidenciais de qualquer conta de cliente, uma descoberta que mostra os pontos fracos da interface de programação de aplicativos (API) no software corporativo como solução (SaaS) aplicativos .

Pesquisadores do Varonis Threat Labs descobriram os problemas – especificamente uma vulnerabilidade de injeção de SQL e uma falha de acesso lógico – no Zendesk Explore, um componente da plataforma do Zendesk, disseram eles em uma postagem de blog publicada em 15 de novembro.

Mais de 100.000 clientes atualmente usam o Zendesk para sua solução de experiência do cliente, de acordo com o site da empresa. O Zendesk Explore é o aspecto do pacote destinado a ajudar esses clientes a analisar, entender e compartilhar dados sobre seus respectivos negócios.

Os pesquisadores descobriram que poderiam usar as falhas para extrair dados do Zendesk Explore, incluindo a lista de tabelas da instância do serviço de banco de dados relacional (RDS) do Zendesk, bem como todas as informações armazenadas no banco de dados. Essas informações incluíam endereços de e-mail de usuários, leads de vendas, negócios do CRM, conversas de agentes ao vivo, tíquetes, artigos da central de ajuda e muito mais, disseram eles.

Para uma exploração bem-sucedida, uma vítima em potencial teria que ter o Zendesk Explore ativado, e um invasor primeiro teria que se registrar no serviço de emissão de tíquetes da conta do Zendesk da vítima como um novo usuário externo, explicaram os pesquisadores.

No entanto, “o registro é ativado por padrão porque muitos clientes do Zendesk dependem de usuários finais que enviam tickets de suporte diretamente pela Web”, escreveram eles no post. O Zendesk Explore, por outro lado, não é ativado por padrão, mas é “fortemente anunciado como um requisito para a página de insights analíticos”, observaram os pesquisadores.

Varonis trabalhou com a Zendesk para corrigir as falhas, o que a empresa conseguiu fazer rapidamente, lançando um patch que não exigia nenhuma ação do cliente “em menos de uma semana de trabalho”, disseram os pesquisadores. Não há evidências de que as vulnerabilidades tenham sido exploradas antes da emissão da correção, acrescentaram.

No entanto, uma olhada nos detalhes técnicos mostra como é fácil introduzir falhas de segurança em aplicativos empresariais baseados em nuvem.

Falha Comum, Codificação Exclusiva

Embora as falhas de injeção de SQL (SQLi) sejam um dos tipos mais comuns de vulnerabilidades encontradas em aplicativos da Web, o problema do Zendesk foi exclusivo por alguns motivos, disse Michael Buckbee, engenheiro de segurança da Varonis, ao Dark Reading.

“O que tornou esse ataque específico inovador foi como o aplicativo Zendesk estava construindo suas consultas SQL – como objetos aninhados em uma mensagem GraphQL maior – e o uso do recurso constante de string entre aspas do banco de dados Postgres para ignorar o filtro de injeção SQL existente do aplicativo”, Buckbee diz.

A Zendesk usa várias APIs GraphQL em seus produtos, especialmente no console de administração, explicaram os pesquisadores no post. GraphQL é um formato de API relativamente novo e, após a investigação de sua implementação no Zendesk, eles encontraram um tipo de objeto particularmente interessante no Zendesk Explore, chamado QueryTemplate, que apontava para um possível problema.

“O campo querySchema se destacou porque contém um documento XML codificado em Base64 chamado Query dentro de um objeto JSON, e muitos dos atributos no XML eram os próprios objetos JSON codificados em Base64”, escreveram os pesquisadores.

Isso representou uma codificação aninhada múltipla, um cenário de código que sempre chama a atenção dos pesquisadores de ameaças, “porque um grande número de wrappers em torno dos dados geralmente significa que muitos serviços diferentes (que provavelmente foram criados por desenvolvedores separados ou até equipes) são usados para processar esses dados”, disseram eles.

Em suma, quanto mais código houver em um aplicativo, mais locais potenciais haverá para vulnerabilidades ocultas, disseram os pesquisadores.

Os pesquisadores aproveitaram o usuário administrador da própria conta Zendesk de seu laboratório para explorar o aplicativo ainda mais, visualizando um relatório no Zendesk Explore, onde encontraram uma API chamada execute-query que acabou levando-os a descobrir as falhas.

Descompactando os problemas

Algumas pesquisas levaram os pesquisadores a um documento XML no qual todos os atributos de nome eram vulneráveis ​​a um ataque de injeção SQL, disseram eles. Os atributos de nome definem as tabelas e colunas a serem consultadas em um documento XML.

Uma exploração mais aprofundada da API de consulta de execução descobriu que ela não realizava várias verificações lógicas sob solicitação, representando outra vulnerabilidade no aplicativo.

“A integridade dos documentos não foi verificada, permitindo que nossa equipe os modificasse de forma a expor o funcionamento interno do sistema”, disseram os pesquisadores.

Além disso, os IDs “query”, “datasources” e “cubeModels” não foram avaliados para verificar se pertenciam ao usuário atual. E, finalmente, e “o mais crítico”, o ponto de extremidade da API não verificou se o chamador tinha permissão para acessar o banco de dados e executar consultas, observaram os pesquisadores

“Isso significava 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 a necessidade de SQLi”, disseram eles.

Risco de Mitigação

Com o Zendesk corrigindo a falha rapidamente antes que afetasse qualquer cliente, as empresas que usam a solução de CRM não precisam tomar mais medidas para mitigar o problema, diz Buckbee. No entanto, com os problemas do SQLi sendo um problema tão comum, a Zendesk e outras empresas que oferecem conjuntos de aplicativos hospedados na Web devem ser mais proativas, adotando medidas preventivas para monitorar seus ambientes para evitar cenários semelhantes no futuro, diz ele.

A situação é real: as empresas americanas enfrentarão perdas combinadas de US$ 12 bilhões a US$ 23 bilhões em 2022 devido a compromissos vinculados a APIs da Web, que proliferaram com o aumento da adoção de SaaS e serviços em nuvem e metodologias de desenvolvimento no estilo DevOps, de acordo com uma pesquisa recente . análise de dados de violação.

“Os fornecedores de SaaS corporativos devem testar rigorosamente seus terminais de API para novos ataques de injeção de SQL”, diz Buckbee, “como aqueles que envolvem métodos desenvolvidos internamente para gerar instruções SQL dinâmicas, para evitar expor os clientes a riscos semelhantes”.

FONTE: DARK READING

POSTS RELACIONADOS