Специалисты компании Tenable обнаружили девять серьёзных уязвимостей в Google Looker Studio, которые получили общее название LeakyLooker. Речь идёт о так называемых cross-tenant уязвимостях — то есть дефектах, позволяющих одному пользователю облачной платформы проникнуть в данные другого, совершенно постороннего арендатора той же инфраструктуры Google Cloud Platform.
Суть проблемы сводилась к грубому нарушению базового принципа разграничения прав. Пользователь с ролью «Viewer» (зритель), который по замыслу архитектуры должен лишь просматривать отчёты, получал возможность управлять данными и запускать произвольные SQL-запросы. Это нарушение фундаментального обещания безопасности: тот, кто смотрит — не должен иметь возможности что-либо менять. LeakyLooker это обещание полностью разрушал.
Под угрозой оказался практически весь спектр коннекторов Looker Studio. Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage и источники данных, подключённые через JDBC — все эти сервисы потенциально могли быть затронуты. Масштаб впечатляет, учитывая, что Looker Studio активно используется для бизнес-аналитики в тысячах компаний по всему миру.
Исследователь, упоминаемый под именем Matan, и его команда из Tenable описали три конкретных сценария атак. Первый — сканирование публичных отчётов Looker Studio, использующих, например, BigQuery. Атакующий находит такой отчёт (или получает доступ к закрытому), а затем перехватывает контроль над базой данных и выполняет произвольные SQL-запросы в рамках всего GCP-проекта владельца отчёта. Фактически чужой проект становится открытой книгой.
Второй вектор атаки эксплуатировал логическую ошибку в функции копирования отчётов. Жертва создаёт публичный отчёт или делится им с конкретным получателем — скажем, подключённый к PostgreSQL или любому JDBC-источнику. Злоумышленник копирует этот отчёт через встроенную функцию, но при клонировании в копию незаметно «утекают» учётные данные оригинального владельца. После чего атакующий может удалять и модифицировать таблицы в чужой базе данных, пользуясь украденными кредами.
Третий сценарий выглядит ещё элегантнее и опаснее. Атакующий создаёт специально сконструированный вредоносный отчёт и отправляет его жертве. Достаточно одного клика — открытия этого отчёта — чтобы браузер жертвы начал исполнять вредоносный код. Код связывается с проектом, который контролирует атакующий, и через логи позволяет реконструировать и выгрузить целые базы данных. Один клик — и вся информация утекает.
При успешной эксплуатации любого из этих путей злоумышленники могли получить доступ к целым датасетам и проектам в Google Cloud. Похищение, модификация, удаление конфиденциальных данных — всё это становилось возможным сразу в нескольких сервисах GCP одновременно. И всё через инструмент визуализации, который большинство пользователей воспринимает как безобидную «рисовалку графиков».
По данным Tenable, доказательств того, что уязвимости LeakyLooker были использованы в реальных атаках, нет. Это несколько успокаивает, но не снимает вопросов. Девять уязвимостей в одном продукте, каждая из которых ломает межтенантную изоляцию — это системная проблема в архитектуре, а не случайный баг.
Обнаруженные дефекты заставляют по-новому взглянуть на безопасность облачных аналитических инструментов. Когда отчёт в Looker Studio может стать оружием для кражи баз данных, привычное представление о том, что аналитика — это «только чтение», перестаёт работать. Любой публичный отчёт, любая ссылка, отправленная коллеге, потенциально могла стать точкой входа для атаки на всю облачную инфраструктуру организации.
Изображение носит иллюстративный характер
Суть проблемы сводилась к грубому нарушению базового принципа разграничения прав. Пользователь с ролью «Viewer» (зритель), который по замыслу архитектуры должен лишь просматривать отчёты, получал возможность управлять данными и запускать произвольные SQL-запросы. Это нарушение фундаментального обещания безопасности: тот, кто смотрит — не должен иметь возможности что-либо менять. LeakyLooker это обещание полностью разрушал.
Под угрозой оказался практически весь спектр коннекторов Looker Studio. Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage и источники данных, подключённые через JDBC — все эти сервисы потенциально могли быть затронуты. Масштаб впечатляет, учитывая, что Looker Studio активно используется для бизнес-аналитики в тысячах компаний по всему миру.
Исследователь, упоминаемый под именем Matan, и его команда из Tenable описали три конкретных сценария атак. Первый — сканирование публичных отчётов Looker Studio, использующих, например, BigQuery. Атакующий находит такой отчёт (или получает доступ к закрытому), а затем перехватывает контроль над базой данных и выполняет произвольные SQL-запросы в рамках всего GCP-проекта владельца отчёта. Фактически чужой проект становится открытой книгой.
Второй вектор атаки эксплуатировал логическую ошибку в функции копирования отчётов. Жертва создаёт публичный отчёт или делится им с конкретным получателем — скажем, подключённый к PostgreSQL или любому JDBC-источнику. Злоумышленник копирует этот отчёт через встроенную функцию, но при клонировании в копию незаметно «утекают» учётные данные оригинального владельца. После чего атакующий может удалять и модифицировать таблицы в чужой базе данных, пользуясь украденными кредами.
Третий сценарий выглядит ещё элегантнее и опаснее. Атакующий создаёт специально сконструированный вредоносный отчёт и отправляет его жертве. Достаточно одного клика — открытия этого отчёта — чтобы браузер жертвы начал исполнять вредоносный код. Код связывается с проектом, который контролирует атакующий, и через логи позволяет реконструировать и выгрузить целые базы данных. Один клик — и вся информация утекает.
При успешной эксплуатации любого из этих путей злоумышленники могли получить доступ к целым датасетам и проектам в Google Cloud. Похищение, модификация, удаление конфиденциальных данных — всё это становилось возможным сразу в нескольких сервисах GCP одновременно. И всё через инструмент визуализации, который большинство пользователей воспринимает как безобидную «рисовалку графиков».
По данным Tenable, доказательств того, что уязвимости LeakyLooker были использованы в реальных атаках, нет. Это несколько успокаивает, но не снимает вопросов. Девять уязвимостей в одном продукте, каждая из которых ломает межтенантную изоляцию — это системная проблема в архитектуре, а не случайный баг.
Обнаруженные дефекты заставляют по-новому взглянуть на безопасность облачных аналитических инструментов. Когда отчёт в Looker Studio может стать оружием для кражи баз данных, привычное представление о том, что аналитика — это «только чтение», перестаёт работать. Любой публичный отчёт, любая ссылка, отправленная коллеге, потенциально могла стать точкой входа для атаки на всю облачную инфраструктуру организации.
