Niebezpieczeństwo związane z kluczami API Google Cloud: Ryzyko kradzieży i nadużyć danych
Nowe badania ujawniają, że klucze API Google Cloud, zazwyczaj używane jako identyfikatory projektów do celów rozliczeniowych, mogą być nadużywane do autoryzacji w wrażliwych punktach końcowych Gemini oraz uzyskania dostępu do prywatnych danych.
Odkrycia te pochodzą od Truffle Security, która zidentyfikowała niemal 3000 kluczy API Google (oznaczonych prefiksem „AIza”) osadzonych w kodzie klienckim, używanym do dostarczania usług związanych z Google, takich jak osadzone mapy na stronach internetowych.
„Dzięki ważnemu kluczowi, atakujący może uzyskać dostęp do przesłanych plików, zbuforowanych danych i obciążyć Twoje konto wydatkami na użycie LLM” – powiedział badacz ds. bezpieczeństwa, Joe Leon, dodając, że klucze te „autoryzują teraz również dostęp do Gemini, mimo że nigdy nie były do tego przeznaczone”.
Jak doszło do nadużyć?
Problem pojawia się, gdy użytkownicy włączają API Gemini w projekcie Google Cloud (tj. Generative Language API). Wówczas istniejące klucze API w tym projekcie, w tym te dostępne poprzez kod JavaScript na stronie, zyskują nieautoryzowany dostęp do punktów końcowych Gemini bez żadnego ostrzeżenia.
W efekcie, każdy atakujący, który przeszukuje strony internetowe, może zdobyć takie klucze API i wykorzystać je w niecny sposób, na przykład do kradzieży kwoty, uzyskując dostęp do wrażliwych plików poprzez punkty końcowe /files i /cachedContents, a także wykonując wywołania API Gemini, co może generować ogromne rachunki dla ofiar.
Niebezpieczeństwa związane z nowymi kluczami API
Truffle Security zauważyła również, że tworzenie nowego klucza API w Google Cloud domyślnie ustawione jest na „Nieograniczone”, co oznacza, że jest on stosowany do każdego włączonego API w projekcie, w tym Gemini.
„Efekt? Tysiące kluczy API, które zostały wdrożone jako niewinne tokeny rozliczeniowe, to teraz aktywne dane uwierzytelniające Gemini dostępne w Internecie” – skomentował Leon. W sumie firma odnalazła 2863 aktywne klucze dostępne w publicznym Internecie, w tym na stronie związanej z Google.
Raport Quokka i szersze problemy z bezpieczeństwem
Ujawniło się to w momencie, gdy firma Quokka opublikowała podobny raport, w którym odkryto ponad 35 000 unikalnych kluczy API Google osadzonych w skanowaniu 250 000 aplikacji na Androida.
„Oprócz potencjalnych nadużyć kosztowych związanych z automatycznymi żądaniami LLM, organizacje muszą także rozważyć, jak punkty końcowe z użyciem AI mogą oddziaływać z danymi wyjściowymi, generowaną zawartością, czy połączonymi usługami w chmurze w sposób, który rozszerza krąg ryzyka związany z skompromitowanym kluczem” – zwróciła uwagę firma zajmująca się bezpieczeństwem mobilnym.
„Nawet jeśli żadne bezpośrednie dane klientów nie są dostępne, połączenie dostępu do wniosków, zużycia limitów oraz możliwe integracje z szerszymi zasobami Google Cloud tworzy profil ryzyka, który znacznie różni się od pierwotnego modelu identyfikatora płatności, na którym polegali programiści.”
Reakcja Google oraz zalecenia dla użytkowników
Mimo że początkowo uważano, że takie zachowanie jest zamierzone, Google podjęło kroki w celu rozwiązania problemu.
„Jesteśmy świadomi tego raportu i współpracowaliśmy z badaczami, aby zaradzić temu problemowi” – poinformował przedstawiciel Google w komentarzu do The Hacker News. „Ochrona danych i infrastruktury naszych użytkowników jest naszym najwyższym priorytetem. Już wdrożyliśmy proaktywne środki mające na celu wykrywanie i blokowanie wycieków kluczy API, które próbują uzyskać dostęp do API Gemini.”
W chwili obecnej nie wiadomo, czy problem ten kiedykolwiek był wykorzystywany w praktyce. Niemniej jednak, w poście na Reddit, użytkownik twierdził, że „skradziony” klucz API Google Cloud doprowadził do naliczenia opłat w wysokości $82,314.44 między 11 a 12 lutego 2026 roku, w porównaniu z regularnymi wydatkami na poziomie $180 miesięcznie.
Zwróciliśmy się do Google o dodatkowe komentarze i zaktualizujemy tę wiadomość, gdy otrzymamy odpowiedź.
Użytkownicy, którzy skonfigurowali projekty Google Cloud, są zachęcani do sprawdzenia swoich API i usług oraz weryfikacji, czy API związane z sztuczną inteligencją są włączone. Jeśli są włączone i publicznie dostępne (czy to w kodzie JavaScript klienckim, czy opatrywane w publicznym repozytorium), należy upewnić się, że klucze zostały obrócone.
„Zacznij od najstarszych kluczy” – radzi Truffle Security. „Są one najbardziej prawdopodobne do publicznego wdrożenia zgodnie z wcześniejszymi wytycznymi, że klucze API są bezpieczne do udostępniania, a następnie retroaktywnie zyskują uprawnienia do Gemini, gdy ktoś w Twoim zespole włączył API.”
„To świetny przykład dynamicznego ryzyka oraz tego, jak API mogą być nadmiernie uprawnione po fakcie” – powiedział Tim Erlin, strateg bezpieczeństwa w Wallarm. „Testowanie bezpieczeństwa, skanowanie luk i inne oceny muszą być ciągłe.”
„API są szczególnie trudne, ponieważ zmiany w ich działaniu lub danych, do których mogą uzyskać dostęp, niekoniecznie są lukami, ale mogą bezpośrednio zwiększać ryzyko. Wdrożenie AI opierającej się na tych API i korzystającej z nich tylko przyspiesza problem. Odkrywanie luk to nie wystarczy dla API. Organizacje muszą profilować zachowanie i dostęp do danych, identyfikując anomalia i aktywnie blokując złośliwą działalność.”
