Prawdopodobnie DeepSeek zna Wasze sekrety oraz klucze API ;)

Przeszukiwanie zasobów w poszukiwaniu kluczy API nie jest nowatorską praktyką i bywa bardzo często wykorzystywane przez atakujących na etapie rekonesansu. Powstały liczne narzędzia, które potrafią przeszukiwać np. repozytoria kodu (np. na GitHubie). Sytuacje, w których produkcyjne poświadczenia trafiają do publicznych baz danych nie są wyjątkiem, dlatego nic dziwnego, że badacze z Truffle Security Co. znaleźli klucze, które zostały zarchiwizowane w zbiorze Common Crawl. 

TLDR:

• Badacze z Truffle Security wrzucili na warsztat zbiór Common Crawl, zawierający dane zebrane z sieci. Zbiór ten służy do uczenia dużych modeli językowych jak DeepSeek
• Wewnątrz znaleziono liczne klucze API i hasła, które wciąż działały ;)

Ten olbrzymi zbiór danych zawiera ponad 400TB skompresowanych danych (w formacie WARC). To prawie 50 milionów hostów “uwiecznionych” w zapytaniach HTTP. 

Pliki zbioru Common Crawl to tzw. Web ARChive, format danych służący do archiwizowania zasobów webowych podczas procesu crawlowania (zautomatyzowanego odwiedzania i archiwizowania treści stron internetowych). Specyfikacja formatu jest otwarta, a korzysta z niej między innymi web.archive.org. Oprócz samego zapytania i odpowiedzi, pliki WARC przechowują dodatkowe metadane jak np. referer (pole “via”), który mówi przez jaki adres crawler trafił na zarchiwizowaną stronę. 

Wykrywanie sekretów nie jest zadaniem trudnym, zwłaszcza że istnieją do tego naprawdę dobrze zoptymalizowane narzędzia, jak trufflehog, o którym już nieraz wspominaliśmy. Jednak nawet pojedynczej instancji najszybszego grepa, przemielenie 400TB danych “chwilę” zajmie. Specjaliści od bezpieczeństwa słyną z improwizacji i budowania narzędzi ad hoc (jeśli jesteś młodym adeptem bezpieczeństwa – ucz się skryptować i pisać narzędzia “na kolanie” – nigdy nie wiadomo co przyniesie dzień – ta porada jest na serio). Dlatego też Truffle Security zbudowało zestaw kolejek i skryptów, które pobierały pojedyncze fragmenty zbioru danych, rozpakowywały je, dzieliły i skanowały z wykorzystaniem trufflehoga. Proste, prawda? Otóż tak, wystarczy taką operację powtórzyć dziewięćdziesiąt tysięcy razy – umiejętność jakiegokolwiek load balancingu i przede wszystkim automatyzacji była niezbędna. A ponieważ urwanie nawet sekundy z dowolnego kroku tej sekwencji daje zauważalne rezultaty, to całe przetwarzanie zostało uruchomione na AWS (prędkość transferu wzrosła 5-6 razy wedle doniesień badaczy). 

No dobrze, ale po co to wszystko? Przede wszystkim odpowiada to na pytanie postawione w innym badaniu, które również opisywaliśmy – dlaczego LLMy popełniają błędy przy generowaniu kodu? Dzieje się tak, ponieważ na etapie uczenia są wystawione na tysiące przykładów błędów. Błędy te potwierdzone są dodatkowo przykładami z dokumentacji, których model nie ma jak odróżnić od rzeczywistości. 

Bardzo interesującym zagadnieniem jest problem zgłoszenia 12000 poświadczeń tak, aby nie trafić na listę spamerów. Truffle Security, zamiast kontaktować się z każdym z użytkowników, sklasyfikowało poświadczenia na podstawie systemu, do którego należą. Następnie skontaktowało się z dostawcami usług, prosząc o ich unieważnienie. To chyba najsensowniejsze co da się zrobić w takiej sytuacji. 

Jak zwykle zachęcamy do zadbania o poprawną obsługę sekretów, poświadczeń, certyfikatów i haseł. Jeśli już informacje takie muszą trafić do repozytorium (nawet prywatnego), to zalecamy zadbać o ich odpowiednie zabezpieczenie na przykład przy pomocy frameworka agebox. Oczywiście optymalnym rozwiązaniem będzie wykorzystanie odpowiedniego vaulta (np. https://www.vaultproject.io/) umożliwiającego sprawną rotację sekretów, lub HSM (hardware security module – np. https://www.yubico.com/products/hardware-security-module/), który utrudni ekstrakcję sekretów niepowołanym aktorom. 

~callsign.chaos && evilcat