Исследователи обнаружили сразу две серьёзные уязвимости в аналитической платформе Google Looker, которые могли позволить злоумышленникам получить доступ к важным внутренним данным, выполнить произвольный код на серверах и даже, в облачных развёртываниях, перейти к ресурсам других клиентов.
Looker - это мощная корпоративная платформа бизнес-аналитики, которую используют десятки тысяч компаний по всему миру для моделирования данных, построения дашбордов и визуализаций. В крупных организациях она часто выступает центральным компонентом работы с данными, объединяя десятки источников, включая хранилища вроде BigQuery и базы данных PostgreSQL или MySQL.
Уязвимость 1: атака на внутреннюю базу данных
Первая проблема связана с внутренней базой данных Looker, где хранятся пользовательские настройки, списки ролей, секреты и конфигурации. Эта база изначально не должна быть доступна конечным пользователям, но исследователи заметили имя её подключения в логах и решили воспользоваться этим.
Они создали новый проект, перехватили HTTP-запрос и изменили параметр так, чтобы он указывал не на внешнюю базу данных, а на скрытую внутреннюю. Это дало им техническую возможность подключиться к ней, но всё ещё без прямого способа прочитать данные.
Чтобы обойти это ограничение, злоумышленники применили error-based SQL-инъекцию: они специально запускали запросы, которые должны были вызвать ошибку, и в тексте сообщения об ошибке появлялась искомая конфиденциальная информация. Повторяя такие операции, теоретически можно было выкачать всю внутреннюю базу.
Эта уязвимость получила идентификатор CVE-2025-12743 и оценку 6,0 по шкале CVSS, что означает средний уровень риска, но с реальной возможностью компрометации конфиденциальных данных.
Уязвимость 2: удалённое выполнение кода и межтенантная атака
Гораздо более серьёзной стала вторая уязвимость, позволяющая удалённо выполнить произвольный код на сервере Looker.
Looker хранит проекты как Git-репозитории. Исследователи нашли способ воспользоваться уязвимостью типа прохождение по пути (path traversal), чтобы заставить систему искать Git-хуки (специальные скрипты, запускаемые Git) не по стандартному пути, а там, где они управляются злоумышленником.
Скрипты-хуки могли бы содержать вредоносный код и запускать удалённую оболочку, но по умолчанию Looker использует облегчённую Java-реализацию Git (JGit), которая хуки не поддерживает. Матем и его команда нашли способ заставить Looker использовать полноценный Git через специально подобранные параметры HTTP-запроса при создании репозитория.
Кроме того, Looker перед выполнением любых команд Git перезаписывает файл конфигурации, сбрасывая путь хуков в безопасное состояние. Чтобы обойти это, исследователи инициировали состояние гонки (race condition), многократно отправляя запросы, и в одном из моментов внедрили вредоносную конфигурацию между перезаписью и запуском хуков.
В результате они смогли выполнить код на сервере. Это давало доступ к чувствительным данным и возможность двигаться по инфраструктуре с повышенными правами.
Но куда более опасной оказалась возможность межтенантного доступа в облаке. В Google Cloud Platform клиенты могут использовать общую инфраструктуру и общие каталоги с учётными данными сервис-аккаунтов. Оказавшись на уровне сервера Looker, злоумышленник мог потенциально получить доступ к аккаунтам и данным других клиентов Google Cloud.
Трудности с обновлением и рекомендации
Google оперативно выпустил исправления для обеих уязвимостей после их отчёта компанией Tenable. Для облачных экземпляров Looker обновление было применено автоматически, но самостоятельно размещённые (self-hosted) установки должны обновиться вручную до версии, указанной в официальном бюллетене безопасности GCP-2025-052.
Однако обновление может быть сложным. Как отмечает один из исследователей, Looker часто глубоко интегрирован в бизнес-процессы и связан со множеством источников данных. Это может вызвать опасения у ИТ-команд относительно возможного простоя или сбоев после обновления.
Другие препятствия включают строгие графики обновлений и необходимость тестировать совместимость с кастомными подключениями и сторонними инструментами. Также отсутствие чёткого учёта всех экземпляров Looker в инфраструктуре может привести к тому, что некоторые из них останутся незапатчеными.
Помимо обновлений, эксперты рекомендуют использовать принцип наименьших привилегий и сегментировать сеть так, чтобы потенциально скомпрометированный экземпляр Looker не имел прямого доступа к критичным системам.
Источник: DarkReading