Один SQL-запрос и вы в чужом облаке. Что известно об атаке LeakyLooker на инфраструктуру Google
NewsMakerНелепый архитектурный изъян поставил под удар тысячи крупных компаний.
Специалисты компании Tenable обнаружили в сервисе аналитики Google Looker Studio сразу девять уязвимостей, способных открыть доступ к данным разных облачных клиентов и выполнять произвольные SQL-запросы в чужих базах. Проблемы затрагивают соединения с различными источниками данных и потенциально дают злоумышленнику контроль над информацией внутри проектов Google Cloud .
Все найденные уязвимости исследователи Tenable сгруппировали и обозначили кодовым названием LeakyLooker. О находке было сообщено Google ещё в июне 2025 года, после чего компания устранила проблемы. Следов реальных атак на момент публикации отчёта обнаружено не было.
Недочёты нарушали базовые принципы работы сервиса. Архитектура Looker Studio предполагает, что пользователь с ролью «просмотр» лишь видит отчёт и не влияет на источник данных. Однако обнаруженные ошибки позволяли обойти ограничения и запускать SQL-запросы от имени владельца отчёта. Такой сценарий открывал доступ к чтению, изменению или удалению информации в инфраструктуре Google Cloud.
По оценке Tenable, потенциальный риск затрагивал широкий круг организаций, использующих коннекторы Looker Studio. Среди источников данных — Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage и другие облачные сервисы . При успешной атаке злоумышленник мог получить доступ к наборам данных и проектам разных облачных арендаторов.
Один из сценариев начинался с поиска публичных отчётов Looker Studio или получения доступа к закрытому отчёту с подключённой базой данных, например, BigQuery . После этого злоумышленник мог перехватить управление соединением и выполнять произвольные запросы к базе. Другой вариант связан с логической ошибкой функции копирования отчётов. Копия сохраняла учётные данные владельца исходного отчёта, что позволяло изменять или удалять таблицы в подключённой базе.
Отдельный метод позволял извлечь данные всего одним действием пользователя. Специально подготовленный отчёт заставлял браузер жертвы выполнить вредоносный код и связаться с проектом злоумышленника. Через журналы операций можно было восстановить структуру и содержимое баз данных, что фактически означало утечку данных облачного проекта.
По словам автора исследования Лив Матан, обнаруженные проблемы фактически создавали новый класс атак на облачные аналитические сервисы и ставили под угрозу данные, связанные с продуктами Google, включая BigQuery и Google Sheets .
Эта история наглядно демонстрирует уязвимость сложных облачных сервисов перед ошибками проектирования: даже роль с минимальными правами может превратиться в точку входа к критически важным данным, если архитектура системы допускает скрытые логические обходы.
Специалисты компании Tenable обнаружили в сервисе аналитики Google Looker Studio сразу девять уязвимостей, способных открыть доступ к данным разных облачных клиентов и выполнять произвольные SQL-запросы в чужих базах. Проблемы затрагивают соединения с различными источниками данных и потенциально дают злоумышленнику контроль над информацией внутри проектов Google Cloud .
Все найденные уязвимости исследователи Tenable сгруппировали и обозначили кодовым названием LeakyLooker. О находке было сообщено Google ещё в июне 2025 года, после чего компания устранила проблемы. Следов реальных атак на момент публикации отчёта обнаружено не было.
Недочёты нарушали базовые принципы работы сервиса. Архитектура Looker Studio предполагает, что пользователь с ролью «просмотр» лишь видит отчёт и не влияет на источник данных. Однако обнаруженные ошибки позволяли обойти ограничения и запускать SQL-запросы от имени владельца отчёта. Такой сценарий открывал доступ к чтению, изменению или удалению информации в инфраструктуре Google Cloud.
По оценке Tenable, потенциальный риск затрагивал широкий круг организаций, использующих коннекторы Looker Studio. Среди источников данных — Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage и другие облачные сервисы . При успешной атаке злоумышленник мог получить доступ к наборам данных и проектам разных облачных арендаторов.
Один из сценариев начинался с поиска публичных отчётов Looker Studio или получения доступа к закрытому отчёту с подключённой базой данных, например, BigQuery . После этого злоумышленник мог перехватить управление соединением и выполнять произвольные запросы к базе. Другой вариант связан с логической ошибкой функции копирования отчётов. Копия сохраняла учётные данные владельца исходного отчёта, что позволяло изменять или удалять таблицы в подключённой базе.
Отдельный метод позволял извлечь данные всего одним действием пользователя. Специально подготовленный отчёт заставлял браузер жертвы выполнить вредоносный код и связаться с проектом злоумышленника. Через журналы операций можно было восстановить структуру и содержимое баз данных, что фактически означало утечку данных облачного проекта.
По словам автора исследования Лив Матан, обнаруженные проблемы фактически создавали новый класс атак на облачные аналитические сервисы и ставили под угрозу данные, связанные с продуктами Google, включая BigQuery и Google Sheets .
Эта история наглядно демонстрирует уязвимость сложных облачных сервисов перед ошибками проектирования: даже роль с минимальными правами может превратиться в точку входа к критически важным данным, если архитектура системы допускает скрытые логические обходы.