Wojna o dane w erze Open-Source LLM

Fala naruszeń ujawnia luki w zabezpieczeniach

Szybkie wdrażanie otwartych modeli językowych (LLM), takich jak DeepSeek i Ollama, stało się mieczem obosiecznym. Podczas gdy firmy wykorzystują te potężne narzędzia do zwiększania wydajności, sama otwartość, która napędza ich rozwój, powoduje równoległy wzrost zagrożeń dla bezpieczeństwa danych. Niedawny raport opracowany przez NSFOCUS Xingyun Lab kreśli ponury obraz: w ciągu zaledwie pierwszych dwóch miesięcy 2025 roku świat był świadkiem pięciu znaczących naruszeń danych bezpośrednio związanych z LLM. Incydenty te doprowadziły do ujawnienia ogromnych ilości poufnych informacji, od poufnych historii czatów i kluczy API po krytyczne dane uwierzytelniające użytkowników. Te wydarzenia są sygnałem alarmowym, podkreślającym często pomijane luki w zabezpieczeniach, czające się pod powierzchnią najnowocześniejszej technologii AI. Ta analiza rozłoży na czynniki pierwsze te pięć incydentów, analizując metody ataku, mapując je do ustalonej struktury MITRE ATT&CK i ujawniając luki w zabezpieczeniach, którymi organizacje muszą pilnie się zająć.

Incydent 1: Źle skonfigurowana baza danych DeepSeek – okno na prywatne rozmowy

Oś czasu: 29 stycznia 2025 r.

Skala wycieku: Miliony linii danych dziennika, w tym poufne historie czatów i klucze dostępu.

Rozwijanie wydarzeń:

Zespół badawczy ds. bezpieczeństwa w Wiz zainicjował to odkrycie. Zidentyfikowali oni odsłoniętą usługę ClickHouse dostępną w publicznym Internecie. Dalsze dochodzenie potwierdziło, że usługa ta należała do chińskiego startupu AI, DeepSeek. ClickHouse, zaprojektowany do wydajnej obsługi dużych zbiorów danych w przetwarzaniu analitycznym, niestety stał się bramą do wewnętrznych danych DeepSeek. Naukowcy uzyskali dostęp do około miliona linii strumienia dziennika DeepSeek, ujawniając skarbnicę poufnych informacji, w tym historyczne dzienniki czatów i kluczowe klucze dostępu.

Wiz natychmiast powiadomił DeepSeek o luce, co doprowadziło do natychmiastowego działania i bezpiecznego usunięcia odsłoniętej usługi ClickHouse.

Analiza ataku:

Główny problem tkwił w podatności ClickHouse na nieautoryzowany dostęp. ClickHouse, otwarty, kolumnowy system zarządzania bazami danych, przoduje w zapytaniach w czasie rzeczywistym i analizie ogromnych zbiorów danych, często używanych do analizy dzienników i zachowań użytkowników. Jednakże, gdy jest wdrażany bez odpowiednich kontroli dostępu, jego odsłonięty interfejs API pozwala każdemu na wykonywanie poleceń podobnych do SQL.

Podejście zespołu ds. bezpieczeństwa Wiz obejmowało metodyczne skanowanie subdomen DeepSeek dostępnych z Internetu. Początkowo koncentrując się na standardowych portach 80 i 443, znaleźli typowe zasoby internetowe, takie jak interfejsy chatbotów i dokumentacja API. Aby poszerzyć swoje poszukiwania, rozszerzyli je o mniej popularne porty, takie jak 8123 i 9000, ostatecznie odkrywając odsłonięte usługi w wielu subdomenach.

Naruszone dane dziennika, pochodzące z 6 stycznia 2025 r., zawierały bogactwo poufnych informacji: dzienniki połączeń, dzienniki tekstowe dla wewnętrznych punktów końcowych DeepSeek API, szczegółowe historie czatów, klucze API, szczegóły systemu zaplecza i metadane operacyjne.

Klasyfikacja zdarzeń VERIZON: Różne błędy

Mapowanie struktury MITRE ATT&CK:

• T1590.002 (Collect Victim Network Information - Domain Name Resolution): Atakujący prawdopodobnie użyli nazwy domeny podstawowej do wyliczenia subdomen.
• T1046 (Web Service Discovery): Atakujący zidentyfikowali otwarte porty i usługi powiązane z domeną docelową.
• T1106 (Native Interface): Atakujący wykorzystali interfejs API ClickHouse do interakcji z bazą danych.
• T1567 (Data Exfiltration via Web Service): Atakujący użyli interfejsu API ClickHouse do kradzieży danych.

Incydent 2: Atak na łańcuch dostaw DeepSeek – koń trojański w kodzie

Oś czasu: 3 lutego 2025 r.

Skala wycieku: Dane uwierzytelniające użytkownika i zmienne środowiskowe.

Rozwijanie wydarzeń:

Atak rozpoczął się 19 stycznia 2025 r., kiedy złośliwy użytkownik, zidentyfikowany jako ‘bvk’, przesłał dwa złośliwe pakiety Pythona o nazwach ‘deepseek’ i ‘deepseekai’ do popularnego repozytorium PyPI (Python Package Index).

Zespół ds. analizy zagrożeń w Positive Technologies Expert Security Center (PT ESC) wykrył tę podejrzaną aktywność tego samego dnia. Ich analiza potwierdziła złośliwy charakter pakietów i natychmiast powiadomili administratorów PyPI.

Administratorzy PyPI szybko usunęli złośliwe pakiety i poinformowali PT ESC. Pomimo szybkiej reakcji, statystyki ujawniły, że złośliwe oprogramowanie zostało pobrane ponad 200 razy w 17 krajach za pośrednictwem różnych kanałów. Złośliwe pakiety zostały następnie odizolowane.

Analiza ataku:

Złośliwe pakiety przesłane przez ‘bvk’ koncentrowały się na dwóch głównych celach: gromadzeniu informacji i kradzieży zmiennych środowiskowych. Skradzione dane zawierały poufne informacje, takie jak dane uwierzytelniające bazy danych, klucze API i dane uwierzytelniające dostęp do magazynu obiektów S3. Złośliwy ładunek był uruchamiany za każdym razem, gdy użytkownik wykonywał DeepSeek lub Deepseekai z wiersza poleceń.

Atakujący wykorzystał PipeDream jako serwer dowodzenia i kontroli do odbierania skradzionych danych. Incydent uwydatnia kilka czynników przyczyniających się do tego:

• Atak Dependency Confusion: Atakujący wykorzystali różnicę priorytetów między prywatnymi pakietami organizacji a publicznymi pakietami o tej samej nazwie.
• Podszywanie się pod nazwę pakietu: Złośliwe pakiety naśladowały nazwę marki DeepSeek, znanej firmy AI, aby oszukać użytkowników.
• Słabość rejestracji PyPI: Proces rejestracji PyPI nie obejmował skutecznej weryfikacji tożsamości programisty i legalności nazwy pakietu.
• Świadomość bezpieczeństwa programistów: Programiści mogli omyłkowo zainstalować podobnie nazwane złośliwe pakiety.

Klasyfikacja zdarzeń VERIZON: Inżynieria społeczna

Mapowanie struktury MITRE ATT&CK:

• T1593.003 (Search Open Websites/Domains - Search Publicly Available Dependency Repository): Atakujący szukali informacji na PyPI.
• T1195.002 (Supply Chain Compromise - Compromise Software Supply Chain): Atakujący użyli złośliwego oprogramowania przebranego za zależności Pythona i przesłali je do PyPI.
• T1059.006 (Command and Scripting Interpreter - Python): Atakujący wszczepili złośliwy kod do pakietu, który po wykonaniu ujawniał poufne dane.
• T1041 (Exfiltration Over C2 Channel): Atakujący eksfiltrowali poufne informacje za pośrednictwem kanału C2 PipeDream.

Incydent 3: Przejęcie LLM – DeepSeek celem kradzieży zasobów

Oś czasu: 7 lutego 2025 r.

Skala wycieku: Nielegalnie wykorzystano około 2 miliardy tokenów modelu.

Rozwijanie wydarzeń:

Zespół badawczy ds. zagrożeń Sysdig początkowo odkrył nowatorski atak na LLM, nazwany ‘LLM jacking’ lub ‘LLM hijacking’, w maju 2024 roku.

Do września 2024 r. Sysdig zgłosił rosnącą częstotliwość i rozpowszechnienie tych ataków, przy czym DeepSeek coraz częściej stawał się celem.

26 grudnia 2024 r. DeepSeek wydał zaawansowany model, DeepSeek-V3. Wkrótce potem zespół Sysdig stwierdził, że DeepSeek-V3 został zaimplementowany w projekcie OpenAI reverse proxy (ORP) hostowanym na Hugging Face.

20 stycznia 2025 r. DeepSeek wydał model wnioskowania o nazwie DeepSeek-R1. Już następnego dnia pojawił się projekt ORP obsługujący DeepSeek-R1, a atakujący zaczęli go wykorzystywać, zapełniając wiele ORP kluczami API DeepSeek.

Badania Sysdig wykazały, że całkowita liczba dużych tokenów modelu nielegalnie użytych przez ORP przekroczyła 2 miliardy.

Analiza ataku:

Przejęcie LLM polega na tym, że atakujący wykorzystują skradzione dane uwierzytelniające w chmurze do atakowania usług LLM hostowanych w chmurze. Atakujący wykorzystują odwrotne proxy OAI (OpenAI) i skradzione dane uwierzytelniające, aby zasadniczo sprzedawać dostęp do subskrybowanych usług LLM ofiary. Powoduje to znaczne koszty usług w chmurze dla ofiary.

Odwrotne proxy OAI działa jako centralny punkt zarządzania dostępem do wielu kont LLM, maskując podstawowe dane uwierzytelniające i pule zasobów. Atakujący mogą korzystać z drogich LLM, takich jak DeepSeek, bez płacenia za nie, kierując żądania przez odwrotne proxy, zużywając zasoby i omijając uzasadnione opłaty za usługi. Mechanizm proxy ukrywa tożsamość atakującego, umożliwiając mu niezauważone nadużywanie zasobów chmury.

Podczas gdy odwrotne proxy OAI jest niezbędnym elementem do przejęcia LLM, kluczowym elementem jest kradzież danych uwierzytelniających i kluczy do różnych usług LLM. Atakujący często wykorzystują tradycyjne luki w zabezpieczeniach usług internetowych i błędy konfiguracji (takie jak luka CVE-2021-3129 w frameworku Laravel) do kradzieży tych danych uwierzytelniających. Po uzyskaniu te dane uwierzytelniające zapewniają dostęp do usług LLM opartych na chmurze, takich jak Amazon Bedrock, Google Cloud Vertex AI i inne.

Badania Sysdig ujawniły, że atakujący mogą szybko zawyżyć koszty zużycia ofiar do dziesiątek tysięcy dolarów w ciągu kilku godzin, a w niektórych przypadkach nawet do 100 000 dolarów dziennie. Motywacja atakujących wykracza poza pozyskiwanie danych; czerpią również zyski ze sprzedaży praw dostępu.

Klasyfikacja zdarzeń VERIZON: Podstawowe ataki na aplikacje internetowe

Mapowanie struktury MITRE ATT&CK:

• T1593 (Search Open Websites/Domains): Atakujący wykorzystali metody OSINT (Open-Source Intelligence) do zebrania informacji o odsłoniętych usługach.
• T1133 (External Remote Services): Atakujący zidentyfikowali luki w odsłoniętych usługach.
• T1586.003 (Compromise Accounts - Cloud Accounts): Atakujący wykorzystali luki w zabezpieczeniach do kradzieży danych uwierzytelniających usługi LLM lub usługi w chmurze.
• T1588.002 (Obtain Capabilities - Tool): Atakujący wdrożyli otwarte narzędzie odwrotnego proxy OAI.
• T1090.002 (Proxy - External Proxy): Atakujący użyli oprogramowania odwrotnego proxy OAI do zarządzania dostępem do wielu kont LLM.
• T1496 (Resource Hijacking): Atakujący przeprowadzili atak wstrzyknięcia LLM, aby przejąć zasoby LLM.

Incydent 4: Naruszenie danych OmniGPT – dane użytkowników sprzedawane w dark webie

Oś czasu: 12 lutego 2025 r.

Skala wycieku: Dane osobowe ponad 30 000 użytkowników, w tym adresy e-mail, numery telefonów, klucze API, klucze szyfrowania, dane uwierzytelniające i informacje rozliczeniowe.

Rozwijanie wydarzeń:

12 lutego 2025 r. użytkownik o nazwie ‘SyntheticEmotions’ opublikował na BreachForums post, twierdząc, że ukradł poufne dane z platformy OmniGPT i oferując je na sprzedaż. Wyciekłe dane podobno zawierały adresy e-mail, numery telefonów, klucze API, klucze szyfrowania, dane uwierzytelniające i informacje rozliczeniowe dla ponad 30 000 użytkowników OmniGPT, a także ponad 34 miliony linii ich rozmów z chatbotami. Dodatkowo naruszono linki do plików przesłanych na platformę, z których niektóre zawierały poufne informacje, takie jak kupony i dane rozliczeniowe.

Analiza ataku:

Chociaż dokładny wektor ataku pozostaje nieujawniony, rodzaj i zakres wyciekłych danych sugerują kilka możliwości: wstrzyknięcie SQL, nadużycie API lub ataki socjotechniczne mogły dać atakującemu dostęp do bazy danych zaplecza. Możliwe jest również, że platforma OmniGPT miała błędy konfiguracji lub luki, które pozwoliły atakującemu ominąć uwierzytelnianie i uzyskać bezpośredni dostęp do bazy danych zawierającej informacje o użytkownikach.

Plik ‘Messages.txt’ zaangażowany w wtórny wyciek zawierał klucze API, dane uwierzytelniające bazy danych i informacje o kartach płatniczych, potencjalnie umożliwiając dalsze włamanie do innych systemów lub manipulowanie danymi. Niektóre dokumenty przesłane przez użytkowników platformy zawierały poufne tajemnice handlowe i dane projektu, stwarzając ryzyko dla operacji biznesowych w przypadku ich niewłaściwego wykorzystania. Ten incydent jest wyraźnym przypomnieniem o potrzebie wzmocnienia bezpieczeństwa danych i ochrony prywatności w sektorach AI i big data. Użytkownicy powinni zachować szczególną ostrożność podczas korzystania z tych platform, a organizacje muszą ustanowić ścisłe zasady korzystania z danych, wdrażając środki takie jak szyfrowanie, minimalizacja danych i anonimizacja poufnych danych. Niezastosowanie się do tego może prowadzić do poważnych konsekwencji prawnych, reputacyjnych i ekonomicznych.

Klasyfikacja zdarzeń VERIZON: Różne błędy

Mapowanie struktury MITRE ATT&CK:

• T1071.001 (Application Layer Protocol - Web Protocols): Atakujący mogli uzyskać dostęp do wyciekłych informacji o użytkownikach i poufnych danych za pośrednictwem interfejsu internetowego OmniGPT.
• T1071.002 (Application Layer Protocol - Application Programming Interfaces): Wyciekłe klucze API i dane uwierzytelniające bazy danych mogły pozwolić atakującym na dostęp do systemu za pośrednictwem interfejsu API platformy i wykonywanie nieautoryzowanych działań.
• T1071.002 (Application Layer Protocol - Service Execution): Atakujący mogli nadużywać usług systemowych lub demonów do wykonywania poleceń lub programów.
• T1020.003 (Automated Exfiltration - File Transfer): Wyciekłe linki do plików i poufne pliki przesłane przez użytkowników mogły być celem atakujących do pobrania, uzyskując więcej poufnych danych do kolejnych ataków.
• T1083 (File and Directory Discovery): Atakujący mogli wykorzystać wyciekłe informacje do dalszego uzyskania kluczowych informacji biznesowych.

Incydent 5: Dane uwierzytelniające DeepSeek wyciekły w Common Crawl – zagrożenia związane z hard-codingiem

Oś czasu: 28 lutego 2025 r.

Skala wycieku: Około 11 908 ważnych kluczy API DeepSeek, danych uwierzytelniających i tokenów uwierzytelniających.

Rozwijanie wydarzeń:

Zespół ds. bezpieczeństwa Truffle wykorzystał otwarte narzędzie TruffleHog do przeskanowania 400 TB danych z grudnia 2024 r. w Common Crawl, bazie danych przeszukiwarki obejmującej 2,67 miliarda stron internetowych z 47,5 miliona hostów. Skanowanie ujawniło zaskakujące odkrycie: około 11 908 ważnych kluczy API DeepSeek, danych uwierzytelniających i tokenów uwierzytelniających zostało zakodowanych na stałe bezpośrednio w licznych stronach internetowych.

Badanie podkreśliło również wyciek kluczy API Mailchimp, z około 1500 kluczami zakodowanymi na stałe w kodzie JavaScript. Klucze API Mailchimp są często wykorzystywane do ataków phishingowych i kradzieży danych.

Analiza ataku:

Common Crawl, niekomercyjna baza danych przeszukiwarki internetowej, regularnie przechwytuje i publikuje dane ze stron internetowych. Przechowuje te dane w plikach WARC (Web ARChive), zachowując oryginalny kod HTML, JavaScript i odpowiedzi serwera. Te zbiory danych są często używane do trenowania modeli AI. Badania Truffle ujawniają krytyczny problem: trenowanie modeli na korpusach zawierających luki w zabezpieczeniach może prowadzić do dziedziczenia tych luk przez modele. Nawet jeśli LLM, takie jak DeepSeek, stosują dodatkowe środki bezpieczeństwa podczas szkolenia i wdrażania, powszechna obecność zakodowanych na stałe luk w danych szkoleniowych może normalizować takie ‘niebezpieczne’ praktyki dla modeli.

Hard-coding, powszechna, ale niebezpieczna praktyka kodowania, jest wszechobecnym problemem. Chociaż przyczyna jest prosta, ryzyko jest poważne: naruszenia danych, zakłócenia usług, ataki na łańcuch dostaw, a wraz z rozwojem LLM, nowe zagrożenie – przejęcie LLM. Jak wspomniano wcześniej, przejęcie LLM polega na tym, że atakujący używają skradzionych danych uwierzytelniających do wykorzystywania usług LLM hostowanych w chmurze, co powoduje znaczne straty finansowe dla ofiar.

Klasyfikacja zdarzeń VERIZON: Różne błędy

Mapowanie struktury MITRE ATT&CK:

• T1596.005 (Search Open Technical Database - Scan Databases): Atakujący zebrali informacje z publicznej bazy danych przeszukiwarki.
• T1588.002 (Obtain Capabilities - Tool): Atakujący wdrożyli narzędzie do wykrywania poufnych informacji.
• T1586.003 (Compromise Accounts - Cloud Accounts): Atakujący użyli narzędzi do wykrywania poufnych informacji, aby znaleźć poufne dane uwierzytelniające w publicznych bazach danych.
• T1090.002 (Proxy - External Proxy): Atakujący użyli oprogramowania odwrotnego proxy OAI do zarządzania dostępem do wielu kont LLM.
• T1496 (Resource Hijacking): Atakujący przeprowadzili atak wstrzyknięcia LLM, aby przejąć zasoby LLM.

Zapobieganie wyciekom danych LLM: wieloaspektowe podejście

Przeanalizowane incydenty podkreślają pilną potrzebę solidnych środków bezpieczeństwa w celu ochrony przed naruszeniami danych związanymi z LLM. Oto zestawienie strategii zapobiegawczych, podzielonych na kategorie według odpowiednich incydentów:

Wzmocnienie łańcucha dostaw:

Dotyczy Incydentu II (atak złośliwego pakietu zależności) i Incydentu V (naruszenie danych publicznych):

1. Zaufana weryfikacja pakietów zależności:

   • Używaj narzędzi takich jak PyPI/Sonatype Nexus Firewall do przechwytywania niepodpisanych lub podejrzanie pozyskanych pakietów zależności.
   • Zabroń bezpośredniego pobierania zależności z publicznych repozytoriów w środowiskach programistycznych. Wymagaj użycia korporacyjnych serwerów proxy prywatnych repozytoriów (np. Artifactory).

2. Monitorowanie zagrożeń łańcucha dostaw:

   • Zintegruj narzędzia takie jak Dependabot/Snyk, aby automatycznie skanować w poszukiwaniu luk w zależnościach i blokować wprowadzanie komponentów wysokiego ryzyka.
   • Zweryfikuj podpis kodu pakietów open-source, aby upewnić się, że wartość skrótu jest zgodna z oficjalną.

3. Czyszczenie źródła danych:

   • Podczas zbierania danych szkoleniowych filtruj poufne informacje z publicznych zbiorów danych (takich jak Common Crawl) za pomocą wyrażeń regularnych i narzędzi do redagowania opartych na sztucznej inteligencji w celu podwójnej weryfikacji.

Wdrażanie zasady najmniejszych uprawnień i kontroli dostępu:

Dotyczy Incydentu I (błąd konfiguracji bazy danych) i Incydentu IV (naruszenie danych narzędzia innej firmy):

• Włącz domyślnie dwukierunkowe uwierzytelnianie TLS dla baz danych (takich jak ClickHouse) i zapobiegaj ujawnianiu portów zarządzania w sieciach publicznych.
• Wykorzystuj rozwiązania takie jak Vault/Boundary do dynamicznego dystrybuowania tymczasowych danych uwierzytelniających, unikając długoterminowego przechowywania kluczy statycznych.
• Przestrzegaj zasady najmniejszych uprawnień, ograniczając dostęp użytkowników tylko do niezbędnych zasobów za pomocą RBAC (Role-Based Access Control).
• Wdrażaj białą listę adresów IP i ograniczanie szybkości dla wywołań API do narzędzi innych firm (takich jak OmniGPT).

Zapewnienie ochrony poufnych danych w całym cyklu życia:

Dotyczy Incydentu III (przejęcie LLM):

• Redagowanie i szyfrowanie danych: Wymuszaj szyfrowanie na poziomie pola (np. AES-GCM) dla danych wejściowych i wyjściowych użytkownika. Maskuj poufne pola w dziennikach.
• Włącz redagowanie w czasie rzeczywistym dla interaktywnych treści LLM (np. zastępowanie numerów kart kredytowych i numerów telefonów symbolami zastępczymi).

Te środki zapobiegawcze, w połączeniu z ciągłym monitorowaniem bezpieczeństwa i planowaniem reagowania na incydenty, są niezbędne do łagodzenia zagrożeń związanych z rosnącym wykorzystaniem LLM. ‘Niewidzialne pole bitwy’ bezpieczeństwa LLM wymaga stałej czujności i proaktywnego podejścia do ochrony poufnych danych w tym szybko rozwijającym się krajobrazie technologicznym.