Tag: AI

Wprowadzenie do problemu / definicja luki

10 grudnia 2025 r. ujawniono wyniki badania zespołu Flare: w samym listopadzie 2025 r. 10 456 obrazów na Docker Hub zawierało wrażliwe „sekrety” — od kluczy API i tokenów chmurowych, po poświadczenia baz danych i klucze do modeli LLM. Część z nich należała do ponad 100 organizacji, w tym do spółki z listy Fortune 500 oraz dużego banku. Co gorsza, aż 42% z tych obrazów miało ≥5 sekretów jednocześnie. Źródłem wielu wycieków były konta „shadow IT” — prywatne lub kontraktorskie, poza korporacyjnym nadzorem.

Serwis BleepingComputer podkreśla także, że ~25% deweloperów usuwało przypadkowo ujawnione dane z obrazów w ciągu 48 godzin, ale w 75% przypadków klucze nie były rotowane — więc nadal mogły być nadużywane. Najczęściej wyciekały klucze do usług AI (OpenAI, Hugging Face, Anthropic, Gemini, Groq) — ok. 4000 kluczy.

W skrócie

• Skala: 10 k+ obrazów z sekretami w 1 miesiąc skanowania.
• Ofiary: 100+ firm (SMB + kilka dużych), w tym bank, Fortune 500.
• Rodzaje sekretów: AI/LLM API, klucze chmurowe (AWS/Azure/GCP), tokeny CI/CD, DB creds, SSH.
• Główne przyczyny: pliki .env, twardo zakodowane tokeny w kodzie/konfigach, manifesty obrazów, „shadow IT”.
• Błąd naprawczy: usunięcie z obrazu ≠ unieważnienie klucza; rotacja kluczy krytyczna.

Kontekst / historia / powiązania

Problem nie jest nowy. Badanie akademickie z 2023 r. pokazało, że ~8,5% z 337 171 obrazów Docker Hub zawierało sekrety (m.in. 52 107 kluczy prywatnych), a tysiące hostów faktycznie używało wyciekłych kluczy TLS/SSH — czyli nie chodzi tylko o „ryzyko teoretyczne”.

W 2025 r. GitGuardian raportował 100 000 ważnych sekretów w 15 mln obrazów — potwierdzając, że skala „secret sprawl” w konteneryzacji rośnie szybciej niż praktyki higieny kluczy.

Analiza techniczna / szczegóły luki

Główne wektory ujawnienia:

• Pliki .env kopiowane do obrazu (często z danymi do DB/chmury).
• Twarde zakodowanie tokenów w plikach źródłowych, config.json, YAML (np. pipeline’y), a nawet manifesty obrazów.
• Konta „shadow IT” (osobiste/kontraktorskie), które omijają polityki skanowania i DLP.

Kategorie sekretów najczęściej spotykane w listopadzie 2025:

• AI/LLM (OpenAI/HF/Anthropic/Gemini/Groq) — prawie 4000 kluczy,
• Chmura (AWS/Azure/GCP),
• Bazy danych (Mongo/Postgres/…),
• SCM/CI (GitHub/NPM/Docker),
• Płatności/komunikacja (Stripe/SMTP/Slack/Telegram).

Dlaczego to groźne technicznie? Sekrety w obrazie propagują się do każdego środowiska, do którego obraz trafi (dev/test/prod). Ich użycie często omija MFA i klasyczne kontrole perymetrowe — atakujący „autentykuje się” zamiast „hakować”.

Praktyczne konsekwencje / ryzyko

• Natychmiastowy dostęp do chmury/CI/CD/DB przy pobraniu obrazu (lub przez scraperów skanujących rejestry).
• Łańcuch dostaw: przejęte tokeny CI/CD → modyfikacja artefaktów → eskalacja u klientów.
• Ominięcie detekcji: legalny ruch z ważnymi kluczami trudniej odróżnić od działań uprawnionych.
• Dług żywotności kluczy: brak rotacji po „wyczyszczeniu” obrazu = trwała ekspozycja.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast: reagowanie na incydent

1. Zidentyfikuj wszystkie publiczne obrazy i ich warstwy (w tym manifesty). Skanuj pod kątem sekretów: trivy, gitleaks, ggshield, dockle (zautomatyzuj w CI).
2. Wycofaj/rotuj każdy znaleziony sekret (klucze API, tokeny, hasła), unieważnij sesje i odwołaj tokeny OIDC/PAT.
3. Audyt aktywności dla kont chmurowych/SCM (CloudTrail, GitHub Audit, CI logs) — szukaj nadużyć po dacie publikacji obrazu.
4. Zmień wszystkie obrazy-bazy na obrazy bez sekretów, wypchnij nowe tagi i odwołaj stare z rejestru (policy + retention).

Na stałe: higiena sekretów

• Nie umieszczaj sekretów w obrazie (ani w ENV, ani w warstwach). Używaj BuildKit secrets / --secret, multi-stage builds, .dockerignore.
• Sejf na sekrety: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault; krótkoterminowe i scopowane poświadczenia (STS/OIDC).
• „Shift-left” skanowanie: commit → PR → build → image → rejestr (policy: „no secret, no merge/push”).
• Kontrola „shadow IT”: obowiązkowe konta organizacyjne, SSO, discovery kont deweloperskich, monitorowanie namespace’ów.
• SBOM + podpisywanie (Sigstore/cosign) i atestacje: potwierdzaj pochodzenie i polityki builda.
• Rotacja okresowa i least privilege dla wszystkich tokenów (GitHub PAT, chmura, dostawcy).
  Rekomendacje powyżej wynikają bezpośrednio z analizy Flare i obserwacji, że samo usunięcie sekretu z obrazu nie wystarcza — rotacja jest kluczowa.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W odróżnieniu od wcześniejszych badań akademickich (2023), które pokazały problem strukturalny i jego zasięg historyczny, obecne wnioski Flare dotyczą świeżych, miesięcznych danych i wskazują silny wzrost udziału kluczy AI/LLM jako najczęściej ujawnianych sekretów — co koreluje z gwałtowną adopcją AI w SDLC w 2024–2025.

Raport GitGuardian z 2025 r. (100 000 ważnych sekretów w 15 mln obrazów) dodatkowo unaocznia, że problem nie ogranicza się do pojedynczego miesiąca czy rejestru — to systemowy „secret sprawl” w całym ekosystemie kontenerów.

Podsumowanie / kluczowe wnioski

• Sekrety w obrazach to nie błąd kosmetyczny, lecz gotowa ścieżka ataku („authenticate-in”).
• Czas reakcji bez rotacji kluczy jest złudny — wyciekłe, ale nadal ważne tokeny mogą krążyć miesiącami.
• Najczęstszy grzech: pliki .env i twarde tokeny w kodzie/konfigach + brak polityk dla kont osobistych.
• Plan minimum: pełna automatyzacja skanowania + sejf na sekrety + krótkoterminowe, ograniczone uprawnienia + stała rotacja.

Źródła / bibliografia

• Flare — Thousands of Exposed Secrets Found on Docker Hub (10.12.2025). Dane źródłowe, metodologia, statystyki listopad 2025. (flare.io)
• BleepingComputer — Over 10,000 Docker Hub images found leaking credentials, auth keys (10.12.2025). Artykuł przeglądowy z dodatkowymi przykładami i liczbami. (BleepingComputer)
• GitGuardian — Uncovering 100,000 Valid Secrets in DockerHub (15.05.2025). Kontekst i skala problemu w 2025 r. (GitGuardian Blog)
• ArXiv — Secrets Revealed in Container Images: An Internet-wide Study on Occurrence and Impact (07.2023). Badanie akademickie, dane historyczne o sekrecie w obrazach. (arXiv)

Wprowadzenie do problemu / definicja luki

Google załatało krytyczną podatność w Gemini Enterprise nazwaną „GeminiJack”. To zero-clickowa, pośrednia injekcja promptów (indirect prompt injection), która umożliwiała atakującym bez udziału użytkownika wykradanie wrażliwych danych z usług Google Workspace (Gmail, Docs, Calendar i inne) — wystarczył udostępniony dokument, zaproszenie kalendarza albo e-mail zawierający ukryte instrukcje dla agenta AI. Google potwierdziło wdrożenie mitigacji po zgłoszeniu przez Noma Security.

---

W skrócie

• Wejście: Udostępniony artefakt (Docs/Calendar/Gmail) z ukrytymi instrukcjami.
• Wyzwalacz: Zwykłe zapytanie pracownika do Gemini Enterprise (np. „pokaż nasze budżety”).
• Działanie: RAG pobiera „zatruty” artefakt, LLM traktuje ukryty tekst jak polecenia i agreguje dane z wielu źródeł, następnie osadza je w zewnętrznym znaczniku obrazu, co skutkuje cichą eksfiltracją podczas ładowania obrazka.
• Interakcja użytkownika: 0 kliknięć, brak ostrzeżeń i typowych alarmów DLP/AV.
• Status: Google wdrożyło zmiany architektoniczne ograniczające wektor — m.in. separację Vertex AI Search od Gemini Enterprise i RAG.

---

Kontekst / historia / powiązania

Badanie opublikowało Noma Security, które wykazało, że problem dotyczył Gemini Enterprise, a wcześniej Vertex AI Search. Media branżowe (SecurityWeek, Dark Reading, ISMG) potwierdziły szczegóły i informację o poprawkach Google. Podatność wpisuje się w szerszą klasę AI-native zagrożeń dla platform z federowanym dostępem i RAG.

---

Analiza techniczna / szczegóły luki

1. Zatrucie treści (content poisoning):
   Atakujący tworzy wiarygodny artefakt (np. Q4 Budget Planning) z niewidocznymi instrukcjami (HTML/CSS, minimalny font, biały na białym itp.) nakazującymi agentowi m.in. wyszukiwać frazy typu „confidential”, „API key”, „salary”, „acquisition”. Artefakt trafia do indeksu wiedzy organizacji.
2. Normalne użycie AI przez pracownika:
   Użytkownik zadaje rutynowe pytanie Gemini Enterprise. Silnik RAG pobiera kontekst, w tym „zatruty” dokument. LLM nie odróżnia instrukcji od dowodu/treści i wykonuje polecenia.
3. Eksfiltracja przez znacznik obrazu:
   Wynik zawiera zewnętrzny <img> z parametrami niosącymi zebrane dane. Podczas renderowania przeglądarka wykonuje żądanie HTTP do serwera napastnika — to boczne wyprowadzenie danych poza kontrolowane kanały. Tradycyjne narzędzia nie podnoszą alertów, bo ruch wygląda „normalnie”.
4. Zmiany po stronie Google:
   Po zgłoszeniu Google przebudowało interakcję między Gemini Enterprise, Vertex AI Search i RAG — separując komponenty, aby ograniczyć możliwość wciągania niezaufanej treści jako instrukcji.

---

Praktyczne konsekwencje / ryzyko

• Szeroki zasięg eksfiltracji: potencjalnie lata korespondencji e-mail, kompletne historie kalendarza, całe repozytoria dokumentów — wszystko, do czego ma dostęp agent.
• Brak sygnałów ostrzegawczych: brak kliknięć, brak typowych IOC, brak alarmów DLP. Ryzyko „cichej porażki”.
• Nowa powierzchnia ataku: AI z uprawnieniami do danych staje się wysokowartościowym pojedynczym punktem awarii.

---

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (0–7 dni):

1. Przegląd integracji i uprawnień Gemini Enterprise/Workspace: minimalne zakresy, ograniczenie źródeł RAG do zaufanych repozytoriów.
2. Wymuś blokadę zewnętrznych połączeń w wynikach AI (np. filtrowanie/stripowanie <img>/zewn. URL) na warstwie proxy/CSP; rozważ blokadę zdalnego ładowania obrazów w interfejsach, które renderują odpowiedzi AI. (Wnioski z wektora <img>).
3. Higiena treści: oznaczanie i kwarantanna artefaktów zewnętrznych (Docs/Calendar/Email) zanim trafią do indeksu AI; automatyczne reguły flagujące „niewidzialny” tekst/HTML. (Wynika z mechaniki ataku).
4. Rotacja sekretów (API keys/hasła) i przegląd logów pod kątem anomalii żądań HTTP do nieznanych domen po akcjach AI.

Krótkoterminowo (1–4 tygodnie):

1. Segmentacja dostępu AI („blast radius mapping”) i least privilege dla konektorów; osobne projekty/tenants dla działów o podwyższonej wrażliwości.
2. Separacja instrukcji od dowodów w pipeline RAG (policy: „instructions-vs-evidence”); walidacja/trust score każdej pozycji kontekstu (proweniencja).
3. Monitoring runtime pod kątem prompt-injection/exfiltracji (wzorce <img>, dane w query stringach, nienaturalne zapytania typu „confidential”, „API key”, itp.).
4. „Human-in-the-loop” dla akcji o skutkach zewnętrznych (wysyłka wiadomości, modyfikacja danych, dostępy).

Średnioterminowo:

1. Red teaming AI (scenariusze e-mail/chat z ukrytym HTML/CSS), testy odporności RAG i zasilanych konektorów.
2. Polityki CSP/egress control dedykowane dla komponentów renderujących odpowiedzi AI (whitelisting domen obrazów, blokada data exfil via URL). (Wynika z wektora eksfiltracji).
3. Rejestry proweniencji treści oraz etykietowanie zaufania (content provenance) przed włączeniem do indeksu „organizational knowledge”.

---

Różnice / porównania z innymi przypadkami

• GeminiJack vs. klasyczne prompt-injection: tu użytkownik niczego nie klika i nawet nie widzi złośliwego polecenia; triggerem jest standardowe wyszukiwanie w RAG.
• Na tle wcześniejszych odkryć (np. „Gemini Trifecta” Tenable): wspólnym mianownikiem jest możliwość przekształcenia AI w wektor ataku oraz wycieki danych wskutek błędów separacji kontekstu i uprawnień; jednak GeminiJack jest bardziej „bezklikowy” i architektoniczny, bo opiera się na federacji danych i renderowaniu odpowiedzi.

---

Podsumowanie / kluczowe wnioski

• AI z dostępem do danych = nowa brama dostępu. Jeśli AI „czyta” treści, musi odróżniać instrukcje od dowodów/treści i nie wolno jej bezkrytycznie wykonywać ukrytych poleceń z artefaktów.
• Eksfiltracja może wyglądać jak zwykłe ładowanie obrazka. Kontroluj egress i sanitację HTML w odpowiedziach AI.
• Google zareagowało i przebudowało architekturę po zgłoszeniu (separacja VAIS od Gemini Enterprise/RAG), ale klasa ryzyka pozostaje dla wszystkich środowisk RAG/agentów.

---

Źródła / bibliografia

• SecurityWeek: „Google Patches Gemini Enterprise Vulnerability Exposing Corporate Data” (10 grudnia 2025) — potwierdzenie mitigacji po stronie Google. (SecurityWeek)
• Noma Security (Noma Labs): „Hacking Google Gemini Enterprise with an Indirect Prompt Injection / GeminiJack FAQ” — szczegóły techniczne i zalecenia. (noma.security)
• Dark Reading: „Gemini Enterprise No-Click Flaw Exposes Sensitive Data” (9 grudnia 2025) — opis wektora i zmian architektonicznych. (Dark Reading)
• ISMG / BankInfoSecurity: „Google Patches AI Flaw That Turned Gemini Into a Spy” (9 grudnia 2025) — mechanizm <img> i brak sygnałów w DLP. (bankinfosecurity.com)
• (Kontekst porównawczy) Tenable Research: „The Trifecta: three new Gemini vulnerabilities…” (wrzesień 2025). (Tenable®)