Test penetracyjny przeprowadzony przez firmę Sygnia ujawnił poważny błąd w aplikacji do onboardingu klientów w firmie finansowej zarządzającej aktywami o wartości miliardów dolarów. Aplikacja została zbudowana w dużej części z pomocą modelu Claude i obsługiwała między innymi dokumenty wydawane przez państwo, dane z procesu weryfikacji tożsamości, informacje płatnicze oraz numery Social Security. Według opisu Sygnia problem pozwalał jednemu wnioskodawcy dotrzeć do rekordu innego wnioskodawcy. Najciekawszy element tego przypadku polega na tym, że kod nie był pozbawiony zabezpieczeń. Miał tokeny tymczasowe, terminy wygaśnięcia, ograniczanie liczby żądań i logowanie zdarzeń. Błąd pojawił się wcześniej, przy ustalaniu, komu w ogóle można wydać token.
Problem zaczynał się przed wydaniem tokenu
Aplikacja musiała rozwiązać konkretny problem użytkowy. Osoba rozpoczynająca proces składania wniosku może przerwać go w dowolnym momencie i wrócić później, zanim utworzy konto oraz ustawi hasło. Claude przygotował dla tego scenariusza model tymczasowego dostępu, który miał pozwalać na wznowienie pracy nad wnioskiem. Krytyczna decyzja dotyczyła jednak warunku otrzymania takiego dostępu. Posiadanie globalnie unikalnego identyfikatora wniosku, czyli GUID, uznano za wystarczający dowód do wydania albo odtworzenia tokenu dostępu. W praktyce oznaczało to, że osoba znająca GUID mogła otrzymać token przypisany do danego wnioskodawcy. Nie musiała dodatkowo udowodnić, że kontroluje sesję, urządzenie, tożsamość ani zweryfikowany kanał kontaktu powiązany z wnioskiem.
Identyfikator rekordu nie jest dowodem tożsamości
GUID służy do wskazania konkretnego rekordu. Sam w sobie nie powinien być traktowany jako sekret, którego posiadanie potwierdza uprawnienia do danych. Sygnia opisała ten błąd jako sytuację, w której GUID stał się sekretem typu bearer, czyli wartością dającą dostęp każdemu, kto ją posiada. W efekcie osoba mająca identyfikator innego wnioskodawcy mogła uzyskać dostęp do jego imienia i nazwiska, danych kontaktowych, statusu aplikacji, informacji finansowych, danych z weryfikacji tożsamości, danych płatniczych oraz numeru Social Security. W zasięgu problemu znajdowały się także rekordy współwnioskodawców, czyli osób, których dane znalazły się w systemie dlatego, że wskazał je ktoś inny.
- Aplikacja przyznawała lub przywracała dostęp po przedstawieniu GUID.
- Model obejmował tokeny tymczasowe, ich wygasanie, limity zapytań, logi audytowe i przywracanie sesji.
- Błąd mógł odsłonić dane identyfikacyjne, finansowe, płatnicze i informacje współwnioskodawców.
- Problem znajdował się w architekturze oraz logice biznesowej, a nie w pojedynczym niebezpiecznym wzorcu kodu.
Zabezpieczenia były prawidłowe, ale otaczały złą decyzję
W opisie Sygnia znalazł się plan obejmujący wiele mechanizmów uznawanych za standardowe elementy bezpiecznej aplikacji. System tworzył tymczasowe tokeny, nadawał im termin ważności, ograniczał liczbę żądań, prowadził rejestry audytowe, obsługiwał przywracanie sesji i miał wykrywać podejrzaną aktywność. Każdy z tych mechanizmów może być potrzebny, ale żaden nie odpowiada na podstawowe pytanie: co musi zostać udowodnione, zanim backend wyda wnioskodawcy token dostępu? Jeżeli token trafi do niewłaściwej osoby, jego krótki czas życia nie usuwa problemu. Ograniczanie liczby żądań może utrudnić masowe próby, lecz nie sprawia, że pierwotna decyzja o uprawnieniu staje się prawidłowa. Logi pomagają później odtworzyć zdarzenia i zareagować na incydent, ale same nie zapobiegają błędnemu wydaniu dostępu. Sygnia wskazuje więc, że zabezpieczenia zostały zbudowane wokół niewłaściwej granicy zaufania.
To także wyjaśnia, dlaczego problem nie musiał zostać wykryty przez podstawowe narzędzia do analizy bezpieczeństwa. Statyczne testy bezpieczeństwa aplikacji szukają między innymi niebezpiecznych wzorców kodu oraz ryzykownych przepływów danych. Opisana luka była przede wszystkim błędem architektonicznym i błędem logiki biznesowej. Kod mógł korzystać ze znanych konwencji frameworka, poprawnie się kompilować i przechodzić podstawowe kontrole, a jednocześnie opierać się na fałszywym założeniu dotyczącym własności rekordu oraz prawa do dostępu. Zach Mead, tester penetracyjny Sygnia, podkreśla w tym kontekście, że działający kod nie jest tym samym co bezpieczny kod. Dotyczy to zwłaszcza kodu generowanego przez AI, które może odtworzyć poprawny technicznie schemat bez znajomości modelu ryzyka konkretnej organizacji.
Ten sam model może pomóc obrońcy i napastnikowi
Sygnia twierdzi, że problem został wskazany podczas analizy części kodu przez model językowy, któremu polecono szukać luk na granicach zaufania oraz błędów logiki biznesowej. Nie chodziło więc wyłącznie o ręczne przeglądanie implementacji. Firma opisała ten przypadek jako sytuację, w której kod powstały z pomocą AI został przeanalizowany przy użyciu podobnego podejścia. To pokazuje dwustronny charakter tej technologii. Jeżeli model potrafi wskazać brakującą granicę zaufania na podstawie kodu, podobne pytanie może zadać także osoba mająca dostęp do wykradzionej bazy kodu, dokumentacji technicznej albo notatek opisujących sposób działania aplikacji. Ta sama zdolność może zatem służyć zarówno do szybszego wykrywania błędów, jak i do szybszego przekształcania znanej słabości w ścieżkę ataku.
AI przyspiesza także kolejne etapy ataku
Raport zestawia ten przypadek z innym dochodzeniem Sygnia dotyczącym włamania do środowiska chmurowego. Pierwszym sygnałem nie był tam pojedynczy exploit, lecz tempo działań. Wyszukiwanie poświadczeń, rozpoznanie zasobów chmurowych, przegląd kodu źródłowego, sprawdzanie procesów CI/CD, dostęp do bazy danych i zakłócanie działania systemów odbywały się równocześnie. Aktywność wyglądała tak, jakby prowadziło ją kilku operatorów, choć według opisu działała jedna osoba korzystająca z agentów. Oba przypadki nie są tym samym incydentem, ale razem pokazują szerszy problem. AI może przyspieszać tworzenie kodu, wyszukiwanie błędów oraz wykonywanie kolejnych czynności po znalezieniu słabości. W takiej sytuacji znaczenie ma nie tylko jakość pojedynczego fragmentu programu, lecz także tempo, w jakim organizacja potrafi zweryfikować założenia stojące za tym programem.
Jak ograniczać ryzyko kodu generowanego przez AI
Sygnia nie rekomenduje po prostu zakazu używania narzędzi AI. Jej argument jest praktyczny: całkowity zakaz może przenieść korzystanie z modeli do prywatnych kont i kanałów, w których organizacja nie ma wglądu. Zamiast tego firma sugeruje oznaczanie żądań zmian, które zostały wygenerowane przez AI albo w dużej części zmodyfikowane przez model, oraz zapisywanie informacji o użytym narzędziu. Dodatkowej kontroli powinny podlegać zmiany związane z uwierzytelnianiem, płatnościami, eksportem danych i informacjami regulowanymi. Oznaczenie pochodzenia kodu nie zastępuje przeglądu bezpieczeństwa, ale pozwala skierować uwagę na obszary, w których błędne założenie może mieć największe konsekwencje.
Ważną część zaleceń stanowią również same prompty. Prośba o przygotowanie tymczasowych tokenów dla wnioskodawców nie zawiera wystarczającego opisu wymagań bezpieczeństwa. Bezpieczniejsza instrukcja powinna jasno określać, że identyfikatory wniosków nie są sekretami, a wydanie tokenu musi wymagać niezależnego dowodu kontroli nad wnioskiem lub powiązanym kanałem. Powinna też wymagać testów negatywnych, które sprawdzą, czy jeden wnioskodawca nie może uzyskać dostępu do rekordu innego. Model nie zna samodzielnie instytucjonalnego modelu ryzyka, granic odpowiedzialności ani wrażliwości danych. Jeżeli te założenia nie zostaną zapisane w wymaganiach, AI może wygenerować implementację zgodną z opisem funkcji, ale niezgodną z rzeczywistym poziomem ochrony potrzebnym w danej organizacji.
Opis Sygnia dotyczy anonimowego klienta i pochodzi z raportu firmy, która tego samego dnia uruchomiła usługę AI Cybersecurity Services obejmującą ocenę poziomu ochrony, zarządzanie oraz testy penetracyjne aplikacji AI. Wyników nie można niezależnie zweryfikować na podstawie innych publicznych relacji, a żaden inny podmiot nie opisał tego konkretnego przypadku. Sam mechanizm jest jednak zrozumiały i pokazuje klasę błędu, której nie da się sprowadzić do braku tokenów, logów czy limitów zapytań. Najważniejsza kontrola musi pojawić się przed wydaniem dostępu, przy pytaniu o to, kto i na jakiej podstawie ma prawo otrzymać token. Kod napisany przez człowieka albo przez model powinien być sprawdzany właśnie na tym poziomie.
