Nove vulnerabilidades corrigidas no Looker Studio podiam quebrar o isolamento entre locatários, reaproveitar credenciais de relatórios e permitir leitura, alteração ou remoção de dados em serviços conectados ao Google Cloud.
| Componente | Google Looker Studio e conectores de dados associados, incluindo BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL, Cloud Storage e outros conectores usados em relatórios. |
| Vetor | Abuso de relatórios públicos ou privados compartilhados, clonagem de relatórios com credenciais preservadas, uso de fontes de dados conectadas por JDBC e relatórios especialmente construídos para acionar vazamento de dados pelo navegador da vítima. |
| Impacto | Execução de consultas SQL arbitrárias em fontes de dados de outro locatário, acesso a conjuntos de dados e projetos, além de possível exfiltração, inserção, modificação ou exclusão de dados nos serviços conectados. |
| Prioridade | Confirmar que as correções do Google estão aplicadas ao ambiente, revisar relatórios compartilhados, reduzir permissões de fontes de dados, auditar credenciais armazenadas e investigar consultas anômalas originadas de relatórios do Looker Studio. |
| Artefatos | O conjunto de nove falhas foi agrupado sob o nome LeakyLooker e inclui caminhos de injeção SQL entre locatários, abuso de credenciais armazenadas, uso indevido de consultas personalizadas, exploração via Linking API e vazamentos por oráculos de tempo e contagem de frames. |
| Exploração | Não há evidência informada de exploração em ambiente real; as falhas foram reportadas de forma responsável em junho de 2025 e corrigidas pelo Google. |
O Google Looker Studio teve nove vulnerabilidades entre locatários corrigidas após uma divulgação responsável realizada em junho de 2025. As falhas, agrupadas sob o nome LeakyLooker, afetavam premissas centrais do modelo de segurança do produto: um usuário com papel de visualizador não deveria conseguir controlar a fonte de dados que apenas está consultando, nem reutilizar credenciais do proprietário do relatório para operar sobre bancos, planilhas, projetos ou conectores associados.
O impacto técnico descrito é relevante para ambientes que usam o Looker Studio como camada de visualização sobre dados corporativos. Em cenários bem-sucedidos, um operador poderia localizar relatórios públicos ou obter acesso a relatórios privados compartilhados e, a partir deles, executar consultas SQL arbitrárias em fontes pertencentes a outro locatário. O efeito não ficava restrito à visualização do painel: o material analisado descreve acesso a conjuntos de dados e projetos, além de caminhos para exfiltrar, inserir, modificar ou excluir dados nos serviços conectados.
As falhas envolviam conectores usados para Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage e outros mecanismos de integração de dados do Looker Studio. A exposição dependia da forma como relatórios e fontes de dados eram compartilhados, de credenciais armazenadas no serviço e de lógicas de cópia, vinculação ou renderização que permitiam atravessar a fronteira esperada entre proprietário, visualizador e projeto de destino.
Um dos caminhos descritos partia de relatórios públicos ou privados que usavam conectores como BigQuery. O atacante precisava encontrar um relatório acessível ou receber acesso a um relatório compartilhado. A partir desse ponto, a falha permitia manipular o relacionamento entre o relatório, a fonte de dados e o projeto associado, abrindo espaço para consultas SQL no escopo do proprietário. O ponto crítico é que a permissão de visualização, que deveria limitar o usuário ao resultado apresentado, podia se transformar em controle indevido sobre a consulta executada contra dados de outro locatário.
Outro caminho envolvia a função de copiar relatórios. Quando uma vítima criava um relatório público ou compartilhava o relatório com um destinatário específico usando uma fonte conectada por JDBC, como PostgreSQL, a lógica de clonagem podia preservar credenciais do proprietário original. Essa condição quebrava a separação esperada entre o objeto copiado e a identidade autorizada a consultar a base. Com as credenciais retidas, o atacante poderia operar sobre tabelas no ambiente conectado, inclusive com possibilidade de modificação ou exclusão quando a permissão da credencial original permitisse esse tipo de ação.
Também foi descrito um fluxo de exfiltração acionado por um relatório especialmente construído. Nesse cenário, o compartilhamento do relatório levava o navegador da vítima a executar uma sequência maliciosa que se comunicava com um projeto controlado pelo atacante. A reconstrução dos dados a partir de logs do projeto atacante tornava a falha particularmente perigosa porque deslocava parte da cadeia para a interação do usuário com o relatório, sem exigir que a vítima executasse comandos fora do navegador ou instalasse componentes adicionais.
Além dos caminhos de injeção SQL, o conjunto inclui vazamentos entre locatários por oráculos de tempo e contagem de frames em fontes arbitrárias. Esses métodos não precisam revelar diretamente o conteúdo completo de uma base em uma única resposta; eles exploram diferenças observáveis no comportamento da interface ou do carregamento para inferir informações. Em sistemas de BI e painéis compartilhados, esse tipo de canal lateral é sensível porque relatórios frequentemente agregam fontes de dados com permissões mais amplas do que as concedidas ao usuário final.
A superfície de risco estava concentrada em organizações que conectavam o Looker Studio a dados corporativos hospedados ou integrados ao Google Cloud. O contexto cita BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL e Cloud Storage, além de quase qualquer outro conector de dados do Looker Studio. Isso inclui ambientes em que dashboards públicos eram usados para divulgação de métricas, relatórios privados eram compartilhados entre equipes e fontes de dados eram configuradas com credenciais capazes de consultar projetos inteiros.
A condição de maior risco ocorria quando a credencial associada ao relatório tinha permissões amplas no projeto, dataset, tabela, planilha ou banco conectado. Mesmo que o usuário malicioso recebesse apenas permissão de visualização sobre o relatório, a falha podia permitir que essa visualização fosse usada como ponte para ações realizadas com o privilégio do proprietário da fonte. A exposição, portanto, não era apenas uma falha de interface; ela afetava o limite de confiança entre identidade, relatório, conector e serviço de dados.
- Relatórios públicos do Looker Studio conectados a BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL, Cloud Storage ou fontes equivalentes.
- Relatórios privados compartilhados com usuários específicos quando a fonte de dados mantinha credenciais do proprietário ou de uma conta com permissões amplas.
- Fontes conectadas por JDBC em que a cópia do relatório podia preservar credenciais originais e permitir operações além da visualização.
- Projetos do Google Cloud e datasets acessíveis por conectores configurados com permissões de leitura, escrita, modificação ou exclusão.
Como não há evidência informada de exploração em ambiente real, a investigação defensiva deve priorizar sinais compatíveis com abuso de relatórios, fontes de dados e credenciais armazenadas. A telemetria útil inclui histórico de compartilhamento de relatórios, criação e clonagem de painéis, mudanças em fontes de dados, consultas inesperadas em BigQuery ou Spanner, operações incomuns em bancos conectados por JDBC e acessos a projetos que tenham relação temporal com visualizações de relatórios do Looker Studio.
Em BigQuery e Spanner, a defesa deve procurar consultas fora do padrão de dashboards conhecidos, especialmente quando executadas com identidade ou credencial associada a relatórios, mas com estrutura incompatível com a consulta esperada do painel. Em bancos PostgreSQL e MySQL conectados por JDBC, logs de auditoria devem ser revisados para operações de alteração, remoção ou consulta volumosa originadas do caminho de integração usado pelo Looker Studio. Em Cloud Storage e Google Sheets, a atenção deve ficar em leituras amplas, enumeração de objetos, acesso a planilhas sensíveis e atividade fora do horário ou do grupo de usuários normalmente associado ao relatório.
A telemetria do navegador e de identidade também pode ajudar nos cenários de relatório especialmente construído. Visualizações de relatório seguidas por chamadas para projetos inesperados, carregamentos anômalos de frames ou diferenças recorrentes de tempo em fontes de dados podem indicar tentativa de vazamento por canal lateral. Esses sinais não confirmam exploração sozinhos, mas ajudam a delimitar períodos, usuários e relatórios que merecem revisão mais profunda.
- Consultas SQL incomuns em BigQuery ou Spanner executadas por credenciais associadas a relatórios do Looker Studio.
- Cópias de relatórios que preservaram vínculos com fontes de dados sensíveis ou credenciais do proprietário original.
- Operações de inserção, modificação ou exclusão em PostgreSQL ou MySQL conectados por JDBC após compartilhamento ou clonagem de relatório.
- Visualizações de relatórios seguidas por atividade em projetos não esperados ou por acessos volumosos a datasets, planilhas ou objetos de armazenamento.
- Mudanças recentes em permissões de relatório, visibilidade pública, destinatários de compartilhamento e configuração de conectores.
A mitigação principal é garantir que as correções disponibilizadas pelo Google estejam efetivamente aplicadas e que os controles de compartilhamento do Looker Studio sejam revisados. Como as falhas já foram endereçadas, o foco operacional passa a ser reduzir dano residual: identificar relatórios expostos, validar se fontes de dados continuam necessárias, remover compartilhamentos excessivos e limitar credenciais usadas por conectores ao menor privilégio necessário para cada painel.
Equipes de segurança devem tratar relatórios de BI como componentes com superfície de ataque própria, não apenas como artefatos de visualização. Fontes de dados conectadas a projetos inteiros ou credenciais com permissão de escrita ampliam o impacto de qualquer bypass de isolamento. O desenho defensivo adequado separa credenciais por relatório ou por domínio de dados, evita que visualizadores herdem capacidades administrativas e mantém auditoria habilitada nos serviços conectados para permitir correlação entre visualização, consulta e alteração de dados.
A resposta também deve incluir uma revisão retrospectiva desde o período anterior à correção, quando houver dados de auditoria disponíveis. A ausência de exploração conhecida não elimina a necessidade de verificar acessos atípicos em relatórios críticos, principalmente em ambientes que tinham dashboards públicos ou compartilhamento amplo com fontes sensíveis. Onde houver suspeita, a contenção deve passar por revogação de compartilhamentos, rotação de credenciais associadas a conectores, revisão de permissões em datasets e validação de integridade de tabelas, planilhas e objetos alteráveis.
- Confirmar que o ambiente está coberto pelas correções do Google para as nove falhas LeakyLooker.
- Inventariar relatórios públicos e privados compartilhados que usam BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL, Cloud Storage ou outros conectores sensíveis.
- Reduzir permissões das credenciais de conectores, separando leitura de escrita e limitando escopo por dataset, tabela, planilha, bucket ou banco.
- Revisar relatórios clonados, fontes de dados copiadas e vínculos que possam manter credenciais do proprietário original.
- Auditar consultas e operações de alteração em serviços conectados, com foco em atividade fora do padrão de dashboards legítimos.
- Rotacionar credenciais de conectores quando houver indício de abuso, compartilhamento excessivo ou impossibilidade de comprovar a cadeia de acesso.
0 Comentários