LeakyLooker w Google Looker Studio: dziewięć luk mogło umożliwić międzytenantowe zapytania SQL

securitybeztabu.pl 8 godzin temu

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili zestaw dziewięciu podatności określonych zbiorczo jako „LeakyLooker”, które dotyczyły Google Looker Studio. Problem dotyczył naruszenia granic izolacji pomiędzy tenantami oraz podważał podstawowy model zaufania platformy analitycznej, w którym użytkownik z uprawnieniami podglądu nie powinien wpływać na wykonywane zapytania ani korzystać z poświadczeń właściciela źródła danych.

W praktyce opisane błędy mogły prowadzić do wykonywania dowolnych zapytań SQL, eksfiltracji danych, a w wybranych scenariuszach również do modyfikacji zasobów w środowiskach Google Cloud. To stawia incydent w gronie najpoważniejszych klas ryzyka dla nowoczesnych platform BI działających jako pośrednik między użytkownikiem a systemami danych.

W skrócie

Zidentyfikowano dziewięć podatności cross-tenant w Google Looker Studio.
Najgroźniejsze scenariusze obejmowały zero-click SQL injection oraz nadużycie zapisanych poświadczeń.
Ryzyko dotyczyło m.in. BigQuery, Spanner, PostgreSQL, MySQL, Google Sheets i Cloud Storage.
Nie ma publicznych dowodów na aktywne wykorzystanie luk w środowisku produkcyjnym.
Problemy zostały usunięte po odpowiedzialnym zgłoszeniu.

Kontekst / historia

Looker Studio pełni rolę warstwy wizualizacyjnej i raportowej, która łączy użytkowników z wieloma źródłami danych. Tego typu platformy są szczególnie wrażliwe na błędy logiczne, ponieważ operują jednocześnie na uprawnieniach użytkownika końcowego, właściciela raportu, konektorów danych i usług backendowych.

W opublikowanych materiałach wskazano, iż podatności zostały zgłoszone w czerwcu 2025 roku, a następnie naprawione przez Google. Istotne jest jednak to, iż nie chodziło o pojedynczy błąd implementacyjny, ale o całą klasę problemów architektonicznych związanych z kopiowaniem raportów, zaufaniem do danych wejściowych i pośredniczeniem w dostępie do danych „na żywo”.

Analiza techniczna

Najpoważniejsze scenariusze dotyczyły podatności typu zero-click. W jednym z nich manipulacja kontrolowanym przez użytkownika aliasem kolumny prowadziła do zbudowania niebezpiecznego zapytania SQL po stronie backendu. Mechanizm generowania zapytań dla źródeł takich jak BigQuery okazywał się podatny na wstrzyknięcie, gdy odpowiednio spreparowane dane wejściowe były łączone z instrukcją SQL.

Badacze opisali również obejścia filtrów znaków, w tym wykorzystanie komentarzy SQL zamiast spacji oraz funkcji skryptowych do odtwarzania znaków specjalnych w trakcie wykonywania zapytania. To pokazuje, iż choćby częściowa walidacja danych wejściowych nie była wystarczająca, jeżeli logika budowania zapytań pozostawała podatna na manipulację.

Druga ważna ścieżka ataku wiązała się z funkcją kopiowania raportu. W przypadku niektórych źródeł JDBC, takich jak PostgreSQL czy MySQL, sklonowany raport mógł zachowywać zapisane poświadczenia oryginalnego właściciela. Oznaczało to, iż użytkownik z samym prawem podglądu, po utworzeniu kopii, stawał się właścicielem nowego raportu, ale przez cały czas korzystał z cudzego kontekstu uwierzytelnienia do źródła danych.

Opisano także scenariusze jednoklikowe, w których odpowiednio przygotowany raport mógł skłonić przeglądarkę ofiary do wykonania działań w jej własnym kontekście dostępowym. W połączeniu z natywnymi funkcjami platformy otwierało to drogę do eksfiltracji danych, wycieków przez hiperłącza i renderowanie obrazów, a także do technik XS-Leak opartych na obserwacji zachowania interfejsu.

Technicznie przypadek ten jest szczególnie interesujący, ponieważ źródłem ryzyka nie był wyłącznie klasyczny błąd walidacji wejścia. Problem wynikał z tego, iż platforma BI działała jako zaufany broker pomiędzy różnymi granicami bezpieczeństwa: przeglądarką użytkownika, raportem, backendem usługi i docelową bazą danych. Gdy ta warstwa błędnie łączyła uprawnienia właściciela, widza i mechanizmy kopiowania obiektów, izolacja między tenantami przestawała działać zgodnie z założeniami.

Konsekwencje / ryzyko

Wpływ biznesowy takich podatności jest bardzo wysoki. W scenariuszu skutecznego ataku możliwe było odczytywanie danych z baz i zbiorów analitycznych, wykonywanie arbitralnych zapytań SQL, a w części przypadków również modyfikowanie lub usuwanie danych. To oznacza realne zagrożenie dla poufności, integralności i dostępności informacji.

Dla organizacji korzystających z Looker Studio jako wspólnej warstwy raportowej problem był szczególnie groźny. Raporty bywają bowiem udostępniane szeroko wewnątrz firm, partnerom biznesowym, a czasem choćby publicznie. o ile jednocześnie konektory do systemów produkcyjnych działają na uprzywilejowanych kontach lub zapisanych poświadczeniach właściciela, kompromitacja jednego raportu może otworzyć drogę do znacznie większego obszaru środowiska.

Na uwagę zasługuje również ryzyko finansowe określane jako „denial of wallet”. W usługach rozliczanych za wykonane zapytania, takich jak BigQuery, wymuszenie kosztownych operacji analitycznych może prowadzić do wymiernych strat finansowych choćby wtedy, gdy atakujący nie doprowadzi do klasycznej kradzieży danych.

Rekomendacje

Organizacje korzystające z platform BI i konektorów do danych chmurowych powinny traktować warstwę raportową jako element podwyższonego ryzyka, a nie wyłącznie neutralny interfejs wizualizacyjny. najważniejsze działania obronne obejmują zarówno kontrolę dostępu, jak i monitorowanie aktywności na poziomie usług danych.

Przeprowadzić przegląd wszystkich raportów publicznych i współdzielonych oraz ograniczyć ich ekspozycję do minimum.
Zweryfikować, które źródła danych działają na poświadczeniach właściciela, a gdzie można przejść na model uprawnień użytkownika.
Rotować zapisane poświadczenia dla krytycznych źródeł danych i stosować konta o najmniejszych możliwych uprawnieniach.
Ograniczyć możliwość wykonywania niestandardowych zapytań SQL i funkcji natywnych tam, gdzie nie są niezbędne.
Segmentować projekty analityczne i oddzielać je od systemów produkcyjnych.
Monitorować nietypowe zapytania, wzrost kosztów przetwarzania i anomalie w logach usług danych.
Regularnie przeglądać uprawnienia współdzielenia raportów, źródeł danych i kopiowanych obiektów.
Uwzględniać w testach bezpieczeństwa błędy logiczne i architektoniczne, a nie tylko klasyczne podatności wejścia/wyjścia.

Z perspektywy zespołów SOC i cloud security szczególnie ważne jest korelowanie zdarzeń z kilku warstw jednocześnie: działań użytkownika w raporcie, operacji backendowych usługi BI oraz wykonania zapytań po stronie docelowych baz danych. Tylko taka telemetria pozwala zauważyć nadużycia, które formalnie mogą wyglądać jak legalne działania zaufanego komponentu.

Podsumowanie

LeakyLooker pokazuje, iż nowoczesne platformy analityczne mogą stać się wektorem ataku o szerokim zasięgu, jeżeli łączą dane wielu tenantów, dynamiczne zapytania i złożony model współdzielenia. W tym przypadku szczególnie niebezpieczne okazało się połączenie błędów logicznych, niewłaściwego zarządzania poświadczeniami oraz niewystarczającej izolacji pomiędzy rolą widza i właściciela.

Choć opisane luki zostały już naprawione, sprawa stanowi ważne ostrzeżenie dla organizacji budujących analitykę w chmurze. Bezpieczna architektura BI wymaga nie tylko szybkiego łatania podatności, ale również ścisłej kontroli modeli zaufania, poświadczeń, współdzielenia raportów oraz zakresu uprawnień przypisanych konektorom danych.

Źródła

Idź do oryginalnego materiału