Novas falhas "LeakyLooker" no Google Looker Studio podem permitir consultas SQL cross-tenant
Aprofundamento CEVIU
Aprofundamento
A Tenable Research batizou de 'LeakyLooker' um conjunto de nove falhas críticas que transformavam o Looker Studio, plataforma de BI usada por milhares de empresas para relatórios em tempo real, em uma porta de entrada cross-tenant para execução remota de SQL. Diferente de injeções clássicas, algumas dessas vulnerabilidades exploravam mecanismos internos do próprio serviço: por exemplo, uma falha de 'Alias Injection' contornava filtros do Google usando comentários SQL (como /* */) para injetar comandos de backend sem precisar de interação da vítima. Em outro cenário, ao copiar um relatório, credenciais armazenadas permaneciam vinculadas, ou seja, quem recebia o relatório podia executar consultas no BigQuery ou Spanner da empresa original, mesmo sem ter acesso direto à conta GCP.
O mais preocupante não foi só o alcance (BigQuery, Spanner, PostgreSQL, MySQL, Sheets e Cloud Storage), mas a forma como as falhas desafiavam pressupostos de segurança do modelo SaaS: o Looker Studio é totalmente gerenciado, mas sua arquitetura de compartilhamento de relatórios e reutilização de conexões de dados criou um novo vetor de ataque, onde o 'relatório' virou um payload executável. Não houve exploração conhecida, mas a correção foi feita silenciosamente pelo Google entre junho de 2025 e março de 2026, sem necessidade de atualização por parte do usuário.
Por que isso importa
Empresas tratam relatórios de BI como objetos estáticos, mas o LeakyLooker mostra que, em ambientes de nuvem, eles são superfícies de ataque dinâmicas, especialmente quando integram diretamente com bancos de dados produtivos. Uma única URL compartilhada com permissão 'editar' podia, antes da correção, permitir exfiltração de dados sensíveis do BigQuery de outra organização, sem autenticação adicional. Isso força uma revisão urgente de políticas de compartilhamento: limitar o uso de conectores não essenciais, revogar credenciais salvas em relatórios compartilhados e auditar quem tem permissão para copiar ou duplicar dashboards. A falha também expõe um risco sistêmico em plataformas de análise que prometem 'isolamento de dados', mas dependem de mecanismos de confiança entre tenants no mesmo backend.
Perguntas frequentes
O Looker Studio ainda é seguro para usar após a correção?
Sim, todas as nove falhas foram corrigidas globalmente pelo Google até março de 2026. Não há ação necessária do usuário, pois o serviço é totalmente gerenciado. Mas é essencial rever configurações de compartilhamento de relatórios e evitar salvar credenciais em dashboards acessíveis por terceiros.
Como saber se meu relatório foi usado como vetor de ataque?
Não há log padrão que registre execução de SQL maliciosa via relatório no Looker Studio. Empresas devem monitorar auditorias do BigQuery (campos like 'query' em logs do Cloud Audit Logs) por consultas incomuns originadas de 'lookerstudio.googleapis.com', além de verificar acessos não autorizados a relatórios compartilhados com permissões elevadas.
Essas falhas afetaram apenas o Looker Studio ou também o Looker (plataforma independente)?
Apenas o Looker Studio (antigo Data Studio). O Looker, plataforma separada com arquitetura distinta e foco em autoatendimento corporativo, não foi impactado. As vulnerabilidades estavam ligadas à forma como o Looker Studio lida com conectores de dados, cache de credenciais e renderização de relatórios compartilháveis.
Por que o Google não divulgou publicamente as falhas antes da correção?
O Google seguiu seu processo padrão de divulgação responsável: recebeu o relatório da Tenable em junho de 2025, corrigiu as falhas internamente e validou a remediação antes de permitir a divulgação pública em março de 2026. Como não houve evidência de exploração ativa, o lançamento coordenado evitou riscos de 'zero-day' em larga escala.
Fontes
- thehackernews.comfonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 13 de março de 2026
- Editoria
- CEVIU Segurança da Informação
