AI pomogło znaleźć błędy warte 500 tys. dolarów

Haker znany jako Brutecat udowodnił, że sztuczna inteligencja może być skutecznym narzędziem w rękach specjalisty od bezpieczeństwa. W ciągu trzech miesięcy automatycznego fuzzowania API Google znalazł luki warte ponad 500 000 dolarów. Jak to zrobił? Postawił na połączenie modelu Claude z własną infrastrukturą do analizy interfejsów Google.

Punktem wyjścia było zaproszenie na bugSWAT Mexico w październiku 2025 roku, które ponownie skierowało uwagę badacza na wewnętrzne API Google. Wcześniejsze projekty z wykorzystaniem Claude pokazały mu, że potencjał AI w automatyzacji testów jest ogromny. Postanowił wykorzystać go do masowego skanowania API w poszukiwaniu błędów kontroli dostępu.

Jak zdobyto mapę ataku

Podstawą całej operacji były dokumenty Discovery – odpowiedniki Swagger docs dla API Google. Zawierają one listę wszystkich dostępnych endpointów, parametrów i metod. Problem w tym, że dostęp do większości z nich wymaga ważnych kluczy API (API keys). Klucze są osadzone w praktycznie każdej aplikacji Google, dlatego pierwszym krokiem było zebranie ich jak najwięcej.

Zbieranie kluczy API na masową skalę

Razem z przyjacielem Michaelem przeczesali ponad 60 000 plików APK – każdą wersję każdej aplikacji Google, jaka kiedykolwiek została wydana. Rozpakowali je i wyszukali klucze API. Nie poprzestali jednak na tym. Stworzyli również rozszerzenie do Chrome, które przechwytywało ruch sieciowy, systematycznie odwiedzali znane domeny Google (ponad 2,8 tysiąca) i korzystali ze wszystkich możliwych funkcji aplikacji webowych, aby złapać klucze z aktywnych żądań.

Aby odsiać klucze nienależące do Google, wykorzystali interesujący endpoint w Cloud Marketplace API. Zwraca on informacje o projekcie GCP powiązanym z danym kluczem. Pozwoliło to odrzucić wszystkie klucze z projektów, które nie należały do domen google.com, nest.com, fitbit.com czy wing.com.

Mapowanie żywych API

Mając klucze, potrzebowali jeszcze listy aktywnych domen API Google. Wykorzystali do tego kombinację domen zarejestrowanych przez rozszerzenie Chrome, nazw wygenerowanych metodą brute-force z użyciem słów kluczowych oraz logów certyfikatów (certificate transparency). Aby potwierdzić, że dana domena to działające API Google, wysyłali proste żądanie GET i sprawdzali nagłówek odpowiedzi Server. Obecność nagłówków takich jak ESF, GSE lub scaffolding oznaczała, że usługa jest żywa.

Budowa własnego narzędzia z AI

Google ma narzędzie o nazwie API Explorer, które pozwala testować publiczne endpointy. Działa ono jednak tylko z publicznymi API i generuje strony po stronie serwera, co uniemożliwia podmianę dokumentu Discovery na prywatny. Brutecat postanowił więc zbudować własny eksplorator API. Zajęło mu to około tygodnia, ale efektem było narzędzie, które potrafiło parsować każdy dokument Discovery po stronie klienta i wykonywać żądania z własną biblioteką do obsługi autoryzacji First Party Authentication (FPA).

Początkowe podejście i jego wady

Na początku model AI dostał tylko dwa narzędzia: probe_api do testowania endpointów i report_vulnerability do zgłaszania błędów. Szybko okazało się, że AI nie testuje wszystkiego dokładnie – kończyło pracę po kilku próbach. Rozwiązaniem było wymuszenie na modelu wywołania funkcji confirm_testing_complete dopiero po przetestowaniu każdego endpointu. Mimo to AI nadal nie było wystarczająco dokładne, a dostarczanie ogromnej ilości danych JSON w kontekście początkowym szybko wyczerpywało dostępny kontekst.

Klasyfikacja na grupy i usprawnienia

Strategia zmieniła się na grupowanie endpointów według logicznych kategorii, takich jak „Analiza metadanych APK” czy „Uprawnienia”. Każda grupa była testowana osobno, a wyniki z poprzednich grup udostępniano kolejnym. AI mogło również wywoływać endpointy spoza zakresu, ale dopiero po pobraniu ich schematu za pomocą funkcji get_endpoint_context. Dodatkowo uproszczono wywołanie probe_api, usuwając zbędne pola, które model mógł pomylić.

Kluczowym usprawnieniem było automatyczne testowanie każdego endpointu przy użyciu wszystkich znanych kluczy API. Backend sam dodawał odpowiednie nagłówki i obsługiwał logikę dopasowania origin/referer. Odpowiedzi grupowano według hash-a, co pozwalało szybko wychwycić różnice między kluczami.

Najciekawsze znalezione luki

Po dopracowaniu systemu AI zaczęło znajdować błędy z ponad 50-procentową dokładnością. Weryfikacja stała się prosta – kliknięcie „Play” i sprawdzenie, czy podatność nadal działa. Oto kilka najbardziej spektakularnych przykładów.

Przejęcie konta Google Voice

Endpoint gfibervoice-pa.googleapis.com nie miał żadnych kontroli dostępu. Wystarczyło jedno polecenie curl z kluczem API i identyfikatorem Gaia ofiary, aby odczytać jej prywatne dane: numer telefonu Google Voice, adres e-mail do powiadomień, a nawet numer telefonu odzyskiwania konta. Co więcej, istniał endpoint umożliwiający przypisanie dowolnego numeru Google Voice do konta ofiary, bez żadnej walidacji. Google uznało to za krytyczny błąd (P0/S0) i wypłaciło 20 000 dolarów.

Dostęp do kont AdExchange

AI odkryło, że endpoint zwracający listę wszystkich kont AdExchange był ukryty za etykietą widoczności, do której dostęp miała tylko grupa google.com:ad-exchange-buyer-fe. Jeszcze ciekawsze okazało się to, że środowisko stagingowe (test-adexchangebuyer-googleapis.sandbox.google.com) wskazywało na produkcyjne dane. Dzięki temu możliwe było odczytanie danych dowolnego konta, włącznie z listą użytkowników i dodaniem siebie jako administratora. Łączna nagroda za te błędy wyniosła 30 000 dolarów.

Wyciek niepublicznych filmów z YouTube

Okazało się, że dla każdego niepublicznego (unlisted) filmu wideo przesłanego przez twórcę będącego w YouTube Partner Program, tworzony był zasób (asset) w systemie Content ID. Nazwa zasobu zawierała identyfikator wideo w formacie „Auto generated asset – <video_id>”. Wystarczyło przeszukać zasoby według tego wzorca, aby uzyskać dostęp do filmów, które nie były jeszcze publicznie dostępne. Praktyczne zastosowanie? Można było śledzić przedpremierowe wgrania filmów o nowych produktach i wykorzystać tę wiedzę na rynkach predykcyjnych. Nagroda wyniosła 12 000 dolarów.

Pełny dostęp do systemu Widevine

Widevine to system DRM używany przez Netflix, Disney i inne serwisy do ochrony treści. Portal zarządzania kluczami Widevine okazał się publicznie dostępny. AI odkryło, że można odczytać listę wszystkich organizacji, ich klucze szyfrowania, a nawet dodać siebie do dowolnej organizacji, w tym do organizacji „google”. Oznaczało to potencjalny dostęp do zarządzania urządzeniami i kluczami DRM. Nagroda: 16 004,40 dolarów.

Wnioski z trzech miesięcy automatycznych testów

Sukces Brutecata pokazuje, że AI może być niezwykle skuteczne w automatyzacji testów bezpieczeństwa, ale wymaga odpowiedniego przygotowania infrastruktury. Kluczowe elementy to: system operacji-id umożliwiający błyskawiczne odtworzenie i weryfikację każdego żądania, abstrakcja złożoności autoryzacji (jak FPA Google) od modelu oraz staranne dostrojenie promptu systemowego, aby AI wiedziało, co jest realną podatnością, a co jedynie szumem.

Jak podsumowuje sam badacz, większość błędów Google nie wymaga skomplikowanej eksploatacji – wystarczy cierpliwość. Te same wzorce powtarzały się w wielu miejscach: brak sprawdzania IAM w zasobach cross-tenantowych, schematy GraphQL bez autoryzacji, endpointy debugowe w produkcji i środowiska stagingowe wskazujące na produkcyjne dane. Rola AI nie polegała na byciu odkrywczym, ale na niestrudzonym testowaniu tego, co oczywiste, na powierzchni zbyt dużej dla człowieka.

Czy to oznacza, że wkrótce wszystkie testy bezpieczeństwa będą wykonywane przez AI? Raczej nie – model wciąż potrzebuje człowieka do nadzoru, interpretacji wyników i decydowania o eskalacji. Jedno jest jednak pewne: połączenie wiedzy eksperckiej z automatyzacją AI daje przewagę, którą trudno przecenić.