LeakyLooker: a falha de cruzamento de inquilinos no Looker Studio que poderia exfiltrar dados do Google Cloud

No início deste ano, pesquisadores de segurança revelaram um conjunto de falhas que afetavam o Looker Studio, a ferramenta do Google para criar relatórios e painéis a partir de fontes de dados diversas. Tenable bautizou esse pacote de defeitos como LeakyLooker e descreveu-o como uma série de fraquezas de “cruce de inquilinos” (cross-tenant) capazes, no pior dos cenários, de permitir que um atacante execute consultas SQL arbitrárias contra bases de dados alheias e extraiga informações sensíveis alojadas em projetos do Google Cloud.

Embora não haja indícios de que estes buracos fossem explorados em ambientes reais, a pesquisa deixou claro que o impacto potencial era sério. Após uma notificação responsável realizada em junho de 2025, o Google aplicou correcções. O relatório público sobre estas investigações está disponível com explicações técnicas detalhadas, por exemplo nesta análise geral publicado pela própria Tenable.

As vulnerabilidades identificadas incluem múltiplos vetores distintos: injeções SQL que não requerem interação do usuário (zero-click), abusos de credenciais armazenadas em conectores JDBC, falhas em funções nativas que permitiam injetar em BigQuery, vazamento de fontes de dados através de links ou renderização de imagens, técnicas de filtragem por temporização e conteo de frames, e até mesmo um caminho para provocar efeitos de recusa de recursos em BigQuery. Tenable documentou cada caso com sua própria ficha técnica, acessível publicamente, por exemplo aqui sobre injeção através de conectores e credenciais armazenadas TRA-2025-28 e TRA-2025-29, ou problemas específicos relacionados com BigQuery e Spanner TRA-2025-27 e TRA-2025-37.

O que torna estas falhas particularmente inquietantes não é apenas a possibilidade de executar sentenças de SQL maliciosas, mas a natureza transversal do problema: muitas organizações conectam Looker Studio com serviços como BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL ou Cloud Storage para construir painéis. Se um atacante conseguir explorar uma dessas cadeias, poderia digitalizar relatórios públicos ou aproveitar um relatório partilhado para alcançar credenciais e, daí, aceder a conjuntos de dados completos dentro de diferentes projetos da GCP.

Um cenário descrito pelos pesquisadores ilustra como um fluxo aparentemente inocente — por exemplo, tornar pública uma visualização ou partilhá-la com um colaborador — pode se transformar em um vetor de ataque. Graças a uma falha na lógica da cópia de relatórios, um adversário poderia clonar um relatório e conservar as credenciais do proprietário original, com a capacidade subsequente de alterar ou apagar tabelas na base de dados vinculada. Em outros casos documentados, bastava que a vítima abrisse ou visualizasse um relatório projetado ad hoc para que seu navegador executasse código que contava com um projeto controlado pelo atacante, facilitando a reconstrução de dados a partir de registros.

Nas palavras da pesquisadora responsável, essas vulnerabilidades quebravam uma das garantias fundamentais do sistema: que um papel de apenas leitura ou de “espectador” não deve poder manipular ou controlar os dados que visualiza. Na verdade, a pesquisa mostrou caminhos pelos quais um usuário com permissões mínimas poderia, indiretamente, provocar exfiltração ou modificação de informações em serviços como BigQuery e Google Sheets.

Desde a perspectiva defensiva, a publicação de Tenable e a resposta do Google sublinham várias lições práticas que qualquer equipe de segurança ou administrador de nuvem deveria considerar. É recomendável rever quais relatórios do Looker Studio estão expostos publicamente, auditar os conectores que armazenam credenciais e aplicar o princípio de menor privilégio em contas de serviço e credenciais ligadas. O Google mantém documentação sobre o Looker Studio que ajuda a entender como os relatórios são partilhados e geridos, por exemplo no centro de ajuda. Looker Studio, e aqueles que usam BigQuery podem repassar as melhores práticas na página BigQuery e guias de segurança do Google Cloud em cloud.google.com/security.

É importante sublinhar que as falhas foram o resultado de combinações lógicas complexas e não de um único erro trivial: o ataque completo exige acorrentar várias condições e apalancar comportamentos inesperados na plataforma. Ainda assim, a existência desses encadeamentos demonstra que as interfaces entre serviços e a gestão de credenciais são áreas críticas que requerem provas rígidas e modelos de ameaça atualizados.

A divulgação responsável foi fundamental para reduzir o risco: Tenable informou o Google em junho de 2025 e, após a colaboração entre ambas as partes, foram implementadas correcções antes de a informação técnica ser amplamente divulgada. Essa coordenação evitou, muito provavelmente, um uso malicioso massivo e deu tempo aos administradores a tomar medidas preventivas.

Para as organizações que dependem de dashboards e dados na nuvem, este episódio deve servir como lembrete de que o conforto de compartilhar e visualizar informações não deve sacrificar controles básicos de segurança. Rotar credenciais após mudanças, limitar o acesso a conectores sensíveis, revisar políticas de partilha e monitorar tentativas incomuns de consulta em serviços como BigQuery são passos práticos que reduzem a superfície de ataque.

No conjunto, LeakyLooker é outro exemplo de como a complexidade das plataformas cloud e a interação entre componentes podem gerar vetores de ataque novos. A boa notícia é que os problemas foram patchados após a notificação, e a publicação técnica de Tenable oferece material para que equipamentos de segurança aprendam e fortalezcan suas defesas. Para aqueles que querem aprofundar os achados, Tenable publicou notas técnicas individuais sobre cada vetor, entre elas as relativas à filtragem por imagens e ligações ( TRA-2025-30), oráculos de temporização ( TRA-2025-31) e rotas específicas para BigQuery e Spanner ( TRA-2025-38).

A moral para responsáveis técnicos e gestores é clara: a segurança em ambientes de dados compartilhados exige vigilância constante, revisões periódicas de licenças e uma política firme sobre o que é publicado e com quem é partilhado. Manter-se informado sobre os avisos de segurança de fornecedores e aproveitar os recursos de investigação - como os que o Tenable oferece - ajuda a colmatar rapidamente as lacunas antes de serem exploradas.