Archiwa: AI - Strona 137 z 183

HackerOne wstrzymuje Internet Bug Bounty. AI ujawnia kryzys po stronie remediacji

Wprowadzenie do problemu / definicja

HackerOne wstrzymał przyjmowanie nowych zgłoszeń do programu Internet Bug Bounty, jednego z najbardziej rozpoznawalnych mechanizmów wspierających odpowiedzialne ujawnianie podatności w projektach open source. Decyzja ta pokazuje rosnące napięcie między gwałtownie rosnącą zdolnością do wykrywania luk a ograniczonymi możliwościami ich weryfikacji, priorytetyzacji i usuwania.

W praktyce oznacza to zmianę głównego wąskiego gardła w cyberbezpieczeństwie. Jeszcze niedawno największym wyzwaniem było samo znalezienie podatności. Dziś coraz częściej problemem staje się obsługa napływających raportów oraz skuteczna remediacja potwierdzonych błędów.

W skrócie

Internet Bug Bounty działał od 2013 roku jako inicjatywa wspierająca bezpieczeństwo kluczowych komponentów internetu i ekosystemu open source. Od 27 marca 2026 roku program przestał przyjmować nowe zgłoszenia, ponieważ liczba odkrywanych podatności zaczęła przewyższać możliwości ich skutecznej obsługi.

wykrywanie podatności stało się szybsze i tańsze dzięki automatyzacji oraz AI,
triage i remediacja nadal wymagają czasu, kompetencji i zasobów ludzkich,
część projektów zależnych od finansowania bounty, w tym Node.js, również zawiesiła wypłaty nagród,
sam proces zgłaszania problemów bezpieczeństwa nie został jednak całkowicie zatrzymany.

Kontekst / historia

Model bug bounty przez lata opierał się na prostym założeniu: najtrudniejsze jest znalezienie podatności, dlatego warto finansowo motywować badaczy do odpowiedzialnego zgłaszania błędów. Podejście to dobrze sprawdzało się w czasach, gdy większość analiz była wykonywana ręcznie, a wolumen zgłoszeń pozostawał relatywnie ograniczony.

Sytuacja zmieniła się wraz z rozwojem narzędzi automatyzujących analizę bezpieczeństwa. Następnym etapem było pojawienie się rozwiązań AI wspierających analizę kodu, generowanie hipotez o podatnościach, tworzenie proof-of-conceptów i przeszukiwanie dużych powierzchni ataku. W efekcie liczba potencjalnych ustaleń zaczęła rosnąć szybciej niż zdolność zespołów do ich praktycznego potwierdzania i naprawiania.

Problem szczególnie mocno dotyka projekty open source, które często są utrzymywane przez niewielkie zespoły lub wolontariuszy. Dla takich projektów nawet wartościowe zgłoszenia mogą stanowić duże obciążenie operacyjne, jeśli brakuje czasu, budżetu i osób odpowiedzialnych za proces bezpieczeństwa.

Analiza techniczna

Z technicznego punktu widzenia kryzys nie sprowadza się wyłącznie do większej liczby raportów. Kluczowe znaczenie ma pogorszenie relacji sygnału do szumu. Narzędzia AI potrafią przyspieszyć identyfikację potencjalnych słabości, ale nie gwarantują, że każda wskazana ścieżka prowadzi do realnej, eksploatowalnej podatności.

Wiele zgłoszeń wymaga kosztownej walidacji, ponieważ może opierać się na niepełnym kontekście, błędnych założeniach lub scenariuszach, które brzmią wiarygodnie, lecz nie przekładają się na praktyczne ryzyko. To oznacza, że zespoły triage muszą poświęcać coraz więcej czasu na ręczne odsiewanie raportów o niskiej jakości.

W konsekwencji maintainers i zespoły bezpieczeństwa tracą zasoby nie tylko na analizę prawdziwych problemów, ale również na obalanie błędnych hipotez. Jeśli dodatkowo program nagradza przede wszystkim sam fakt zgłoszenia, może to wzmacniać presję na ilość zamiast na jakość technicznej analizy.

Warto też podkreślić, że znalezienie podatności i usunięcie jej to dwa różne etapy. O ile AI może pomóc wykrywać wzorce błędów, o tyle przygotowanie bezpiecznej poprawki, testów regresyjnych, planu wydania i komunikacji do użytkowników wciąż wymaga wiedzy domenowej, doświadczenia i czasu. To właśnie na tym etapie kumulują się dziś największe koszty operacyjne.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem jest przeciążenie procesów bezpieczeństwa. Gdy liczba zgłoszeń rośnie szybciej niż zdolność do ich oceny, wydłuża się czas potwierdzenia, priorytetyzacji i wdrożenia poprawek. To automatycznie zwiększa okno ekspozycji na atak.

Drugim ryzykiem jest pogorszenie jakości samych programów bounty. Jeśli fundusze są konsumowane szybciej, niż organizacje są w stanie przekształcić raporty w realne poprawki bezpieczeństwa, cały model zaczyna tracić efektywność ekonomiczną.

Szczególnie narażony jest łańcuch dostaw oprogramowania. Wiele krytycznych bibliotek i frameworków stanowi fundament dla tysięcy produktów komercyjnych, a jednocześnie jest utrzymywanych przez niewielkie zespoły. Zalew zgłoszeń, zwłaszcza tych wspomaganych przez AI, może utrudnić odróżnienie problemów naprawdę krytycznych od automatycznie wygenerowanego szumu.

Na poziomie strategicznym branża staje przed niebezpieczną asymetrią: finansowany i skalowany jest etap wykrywania, natomiast etap usuwania błędów pozostaje chronicznie niedoinwestowany. Z perspektywy redukcji ryzyka jest to problem fundamentalny, ponieważ bezpieczeństwo poprawia się dopiero wtedy, gdy luka zostanie skutecznie załatana.

Rekomendacje

Organizacje prowadzące programy bug bounty powinny dostosować swoje modele operacyjne do realiów epoki AI. Kluczowe znaczenie mają mocniejsze mechanizmy filtrowania zgłoszeń, wielopoziomowy triage, ograniczanie duplikatów oraz lepsza ocena jakości raportów.

premiowanie raportów zawierających wiarygodny wpływ, warunki eksploatacji i pełną reprodukcję,
wprowadzenie scoringu jakości zgłoszeń i mechanizmów ograniczających spam,
budowa dedykowanych kompetencji po stronie security triage i PSIRT,
inwestowanie w automatyzację testów oraz procesy szybkiego wydawania poprawek,
większe wsparcie finansowe dla remediacji, a nie wyłącznie dla discovery.

Projekty open source i dostawcy oprogramowania powinni rozwijać zdolności remediacyjne równie intensywnie jak kanały przyjmowania zgłoszeń. Obejmuje to zarówno procedury bezpieczeństwa, jak i realne finansowanie osób odpowiedzialnych za analizę, naprawę i komunikację incydentów.

Po stronie odbiorców biznesowych potrzebne jest bardziej aktywne podejście do bezpieczeństwa łańcucha dostaw. Organizacje nie powinny zakładać, że społeczność samodzielnie zapewni pełną ochronę komponentów open source. Konieczne są własne procesy monitorowania podatności, priorytetyzacji krytycznych zależności oraz wsparcia dla projektów, od których biznes faktycznie zależy.

Podsumowanie

Wstrzymanie Internet Bug Bounty to ważny sygnał ostrzegawczy dla całej branży cyberbezpieczeństwa. Rozwój AI przyspieszył wykrywanie podatności, ale jednocześnie obnażył słabość procesów walidacji i remediacji, zwłaszcza w ekosystemie open source.

Najważniejszy wniosek jest prosty: większa liczba wykrytych luk nie oznacza automatycznie większego bezpieczeństwa. Bez odpowiednich zasobów do triage, potwierdzania i usuwania błędów nawet dojrzałe programy zgłaszania podatności mogą zacząć generować przeciążenie zamiast realnej redukcji ryzyka.

Źródła

Apple Intelligence: nowe obejście zabezpieczeń AI ujawnia ryzyko prompt injection na urządzeniach Apple

Wprowadzenie do problemu / definicja

Bezpieczeństwo systemów generatywnej sztucznej inteligencji zależy dziś nie tylko od jakości modeli, ale również od skuteczności mechanizmów ochronnych ograniczających niepożądane zachowania. Najnowsze ustalenia dotyczące Apple Intelligence pokazują, że nawet rozbudowane warstwy zabezpieczeń mogą zostać ominięte przez odpowiednio przygotowane dane wejściowe.

W opisywanym scenariuszu badacze połączyli adversarial prompt injection z manipulacją znakami Unicode. Taki atak może prowadzić nie tylko do wygenerowania niedozwolonych odpowiedzi, ale również do wpływania na sposób, w jaki model interpretuje polecenia, kontekst i dane dostępne w ramach integracji z systemem lub aplikacją.

W skrócie

Badania wskazują, że lokalne mechanizmy bezpieczeństwa Apple Intelligence mogły zostać ominięte z wysoką skutecznością. Atak łączy technikę Neural Execs, wykorzystującą nietypowe i pozornie bezsensowne ciągi znaków jako wyzwalacze określonych zachowań modelu, z manipulacją renderowaniem tekstu przy użyciu Unicode.

celem było obejście filtrów wejścia i wyjścia oraz wewnętrznych guardrails,
w testach uzyskano skuteczność na poziomie 76% dla 100 losowych promptów,
największe ryzyko dotyczy aplikacji zintegrowanych z Apple Intelligence i operujących na wrażliwym kontekście użytkownika.

Kontekst / historia

Apple Intelligence to zestaw funkcji AI zintegrowanych z iOS, iPadOS i macOS, łączący lokalne modele uruchamiane na urządzeniu z dodatkowymi mechanizmami obsługi bardziej złożonych zadań. Taka architektura jest promowana jako rozwiązanie wspierające prywatność, jednak lokalne przetwarzanie samo w sobie nie eliminuje ryzyka manipulacji modelem.

Nowoczesne systemy AI są zwykle chronione wielowarstwowo. Obejmuje to filtrowanie promptów wejściowych, kontrolę odpowiedzi, klasyfikację treści oraz dodatkowe polityki bezpieczeństwa narzucone przez producenta platformy. Problem polega na tym, że atakujący coraz częściej nie próbują łamać pojedynczego filtra wprost, lecz szukają sposobów na wywołanie rozjazdu między treścią widoczną dla człowieka, reprezentacją przetwarzaną przez model i logiką warstw ochronnych.

W tym przypadku badacze mieli zgłosić problem producentowi już w 2025 roku, a następnie wskazano, że odpowiednie zabezpieczenia zostały wdrożone w nowszych wersjach systemów. Nie ma publicznie potwierdzonych informacji o aktywnym wykorzystaniu tej techniki w realnych kampaniach, ale sam wektor ataku ma istotne znaczenie dla oceny odporności ekosystemów AI.

Analiza techniczna

Sednem ataku jest połączenie dwóch technik ofensywnych. Pierwsza z nich, określana jako Neural Execs, wykorzystuje semantycznie nieczytelne lub trudne do interpretacji ciągi wejściowe, które mogą działać jak uniwersalne wyzwalacze określonych reakcji modelu. To szczególnie problematyczne z punktu widzenia detekcji, ponieważ analiza oparta wyłącznie na jawnej treści promptu może nie rozpoznać złośliwej intencji.

Drugim elementem jest manipulacja Unicode, w tym użycie mechanizmów wpływających na kierunek renderowania tekstu, takich jak right-to-left override. Pozwala to zmienić sposób prezentacji treści bez zmiany jej logicznej struktury. W praktyce oznacza to możliwość ukrycia znaczenia danych wejściowych lub wyjściowych przed częścią filtrów bezpieczeństwa.

Połączenie tych metod tworzy atak wieloetapowy:

model otrzymuje nietypowe wejście, które nie wygląda jak klasyczny złośliwy prompt,
warstwa ochronna nie wykrywa zagrożenia na etapie analizy,
model wykonuje zachowanie zgodne z intencją atakującego,
wynik może zostać dodatkowo zakodowany w sposób utrudniający jego blokadę przez filtry wyjściowe,
ostatecznie treść lub polecenie może wpłynąć na funkcje aplikacyjne albo dane dostępne przez integrację.

Najważniejsze jest to, że problem nie ogranicza się do generowania zabronionych treści. Jeżeli model ma dostęp do wiadomości, zdjęć, kalendarza, danych zdrowotnych lub funkcji aplikacji trzecich, prompt injection staje się potencjalnym wektorem naruszenia poufności i integralności danych.

Konsekwencje / ryzyko

Ryzyko należy rozpatrywać na kilku poziomach. Po pierwsze, obejście guardrails podważa zaufanie do ochrony wdrażanej w systemach AI. Po drugie, zagrożenie rośnie wraz z zakresem uprawnień nadawanych komponentom AI przez aplikacje i system operacyjny.

Potencjalne konsekwencje obejmują:

generowanie niedozwolonych odpowiedzi mimo aktywnych filtrów,
obchodzenie polityk bezpieczeństwa opartych na klasyfikacji treści,
wpływ na logikę aplikacji zintegrowanych z AI,
ryzyko ekspozycji danych osobowych i innych informacji wrażliwych,
wykorzystanie modelu jako pośrednika do inicjowania działań, których użytkownik nie zamierzał wykonać.

Dla organizacji budujących rozwiązania oparte na systemowym AI kluczowe jest zrozumienie, że zagrożenie nie musi wynikać z klasycznych błędów, takich jak memory corruption czy zdalne wykonanie kodu. Coraz częściej problemem są błędne założenia dotyczące bezpieczeństwa warstwy semantycznej oraz zaufania do danych przetwarzanych przez model.

Rekomendacje

Deweloperzy i zespoły bezpieczeństwa powinni traktować modele AI jako komponenty nieufne, nawet jeśli działają lokalnie i pochodzą od renomowanego dostawcy. Oznacza to konieczność wdrożenia dodatkowych zabezpieczeń na poziomie aplikacji, logiki biznesowej i kontroli dostępu.

stosowanie zasady minimalnych uprawnień dla integracji AI,
oddzielanie instrukcji systemowych, danych użytkownika i kontekstu aplikacyjnego,
normalizacja oraz filtrowanie Unicode przed i po przetworzeniu przez model,
blokowanie automatycznego wykonywania wrażliwych działań wyłącznie na podstawie odpowiedzi modelu,
prowadzenie testów red team obejmujących prompt injection, output smuggling i manipulację kodowaniem znaków,
monitorowanie nietypowych wzorców wejść i wyjść, w tym sekwencji kontrolnych oraz pozornie losowych ciągów znaków.

Szczególne znaczenie ma również wdrożenie jawnej autoryzacji dla operacji na danych wrażliwych oraz niezależnych polityk decyzyjnych dla akcji inicjowanych przez komponenty AI. Tylko takie podejście ogranicza ryzyko nadużyć wynikających z błędnej interpretacji promptu lub zmanipulowanego kontekstu.

Podsumowanie

Nowe ustalenia dotyczące Apple Intelligence pokazują, że bezpieczeństwo AI nie kończy się na lokalnym przetwarzaniu danych i filtrach treści. Połączenie adversarial prompt injection z manipulacją Unicode umożliwiło obejście mechanizmów ochronnych z istotną skutecznością, a największe ryzyko dotyczy scenariuszy, w których model ma dostęp do danych użytkownika i funkcji aplikacyjnych.

Dla branży cybersecurity to kolejny dowód, że systemy AI należy projektować zgodnie z zasadą zero trust. Ochrona powinna obejmować walidację wejścia, ograniczanie uprawnień, kontrolę działań wykonywanych przez model oraz ciągłe testowanie odporności na nowe klasy ataków semantycznych.

Źródła

Apple Intelligence AI Guardrails Bypassed in New Attack — https://www.securityweek.com/apple-intelligence-ai-guardrails-bypassed-in-new-attack/
Neural Exec: Learning to Jailbreak LLMs with Adversarial Prompts — https://arxiv.org/abs/2407.11969
Unicode Standard Annex #9: Unicode Bidirectional Algorithm — https://www.unicode.org/reports/tr9/

Klucze Google API w aplikacjach Android mogą otwierać nieautoryzowany dostęp do Gemini

Wprowadzenie do problemu / definicja

Twardo zakodowane klucze Google API w aplikacjach Android od lat były postrzegane jako element o ograniczonej wrażliwości, zwłaszcza gdy służyły głównie do identyfikacji projektu. Najnowsze ustalenia pokazują jednak, że w określonych konfiguracjach te same klucze mogą zapewniać dostęp do usług Gemini, czyli środowiska generatywnej AI Google. W praktyce oznacza to, że dane osadzone w publicznie dostępnych pakietach APK mogą zostać użyte do nieautoryzowanych wywołań API, dostępu do zasobów oraz nadużyć kosztowych.

Problem jest szczególnie istotny dla twórców aplikacji mobilnych, ponieważ każde publicznie opublikowane APK może zostać poddane analizie statycznej. Jeśli klucz API pozostaje w kodzie lub plikach konfiguracyjnych, jego pozyskanie przez osobę trzecią jest zazwyczaj kwestią czasu, a nie zaawansowanych umiejętności.

W skrócie

Badacze wykazali, że klucze Google API osadzone w aplikacjach Android można łatwo wyodrębnić z pakietów APK.
W części przypadków te same klucze pozwalały na wywoływanie endpointów Gemini.
Problem objął dziesiątki kluczy znalezionych w popularnych aplikacjach o łącznej bazie użytkowników przekraczającej setki milionów.
Ryzyko obejmuje dostęp do plików, danych cache, wyczerpanie limitów API oraz generowanie kosztów po stronie właściciela projektu.
Zagrożenie wynika nie tylko z obecności klucza w aplikacji, ale także z konfiguracji usług aktywowanych później w tym samym projekcie chmurowym.

Kontekst / historia

Środowisko bezpieczeństwa od dawna podkreśla, że aplikacje Android są podatne na analizę reverse engineering. Po rozpakowaniu pakietu APK można przeszukiwać zasoby, manifest, ciągi znaków, pliki konfiguracyjne i zdekompilowany kod w poszukiwaniu sekretów lub tokenów. Dotąd część zespołów deweloperskich traktowała jednak klucze Google API jako identyfikatory techniczne, a nie pełnoprawne sekrety.

Sytuacja zmieniła się wraz z rozwojem usług AI i rosnącą integracją Gemini z projektami korzystającymi z ekosystemu Google. Klucz, który wcześniej miał ograniczone znaczenie bezpieczeństwa, może po aktywacji nowych usług zyskać realną wartość ofensywną. To właśnie ta zmiana kontekstu sprawia, że starsze praktyki projektowe przestają być wystarczające.

Nowe ustalenia pokazują, że zagrożenie nie ma charakteru czysto teoretycznego. W wielu przypadkach możliwe było przełożenie prostego pozyskania klucza z aplikacji na dostęp do zasobów Gemini powiązanych z tym samym projektem.

Analiza techniczna

Techniczny mechanizm zagrożenia opiera się na relacji między kluczem Google API a projektem, w którym aktywowano usługi Gemini. Jeżeli deweloper osadził klucz w aplikacji mobilnej, a następnie w tym samym projekcie uruchomił funkcje AI, klucz może zacząć działać jako ważny element umożliwiający komunikację z endpointami Gemini.

Typowy scenariusz ataku jest stosunkowo prosty. Napastnik pobiera publicznie dostępną aplikację Android, analizuje pakiet APK, wyodrębnia klucz rozpoznawalny po prefiksie „AIza”, a następnie wykorzystuje go do wywołań API związanych z Gemini. Jeśli po stronie projektu nie wdrożono dodatkowych ograniczeń, możliwe staje się wykonywanie operacji w imieniu cudzego środowiska.

Istotnym aspektem jest tu retroaktywna zmiana znaczenia klucza. Nie chodzi o klasyczne przejęcie uprawnień w urządzeniu użytkownika, lecz o sytuację, w której wcześniej osadzony i publicznie dostępny klucz zyskuje nowe możliwości po zmianie konfiguracji usług chmurowych. Deweloper może nie zauważyć, że wraz z aktywacją AI dotychczasowy model bezpieczeństwa przestał działać zgodnie z założeniami.

Z perspektywy atakującego najbardziej atrakcyjne są następujące możliwości:

wywoływanie modeli Gemini z wykorzystaniem cudzego projektu,
dostęp do przesłanych plików i danych pomocniczych,
odczyt zawartości cache powiązanej z operacjami AI,
generowanie kosztów rozliczeniowych,
wyczerpywanie quota i zakłócanie działania legalnej aplikacji.

Konsekwencje / ryzyko

Pierwszym obszarem ryzyka jest poufność danych. Jeśli aplikacja mobilna przesyła do usług AI treści użytkowników, dokumenty, obrazy lub inne pliki, nieautoryzowany dostęp do zasobów Gemini może prowadzić do ujawnienia części tych informacji. Nawet ograniczony dostęp do danych roboczych lub plików tymczasowych może oznaczać istotny incydent bezpieczeństwa.

Drugim wymiarem jest dostępność i integralność usług. Osoba nieuprawniona może generować arbitralne żądania do API, zużywać limity i powodować przeciążenie projektu. W praktyce skutkiem mogą być błędy po stronie legalnych użytkowników, opóźnienia działania funkcji AI lub czasowa niedostępność wybranych funkcji aplikacji.

Trzecie ryzyko ma charakter finansowy. Nadużycia związane z modelami generatywnej AI mogą bezpośrednio przekładać się na koszty, zwłaszcza przy intensywnym użyciu API lub przetwarzaniu dużych wolumenów danych. Organizacja może wykryć problem dopiero po analizie rachunków lub anomalii w logach wykorzystania.

Nie można też pominąć aspektu zgodności i odpowiedzialności. Jeżeli słabo zabezpieczone klucze doprowadzą do ekspozycji danych użytkowników, firma może stanąć przed koniecznością przeprowadzenia analizy naruszenia, zgłoszenia incydentu oraz aktualizacji procedur bezpiecznego wytwarzania oprogramowania.

Rekomendacje

Podstawową zasadą powinno być traktowanie każdego klucza osadzanego w aplikacji mobilnej jako potencjalnie publicznego. Oznacza to, że nie należy przypisywać takim kluczom uprawnień umożliwiających dostęp do danych, funkcji AI ani usług, które mogą generować koszty.

W praktyce organizacje powinny wdrożyć następujące działania:

usunąć klucze API z kodu aplikacji wszędzie tam, gdzie jest to możliwe,
przenieść wywołania wrażliwych usług AI do backendu kontrolowanego przez organizację,
stosować warstwę pośredniczącą z autoryzacją użytkownika i kontrolą dostępu,
rotować klucze, które były obecne w publicznych wersjach aplikacji,
ograniczać klucze do konkretnych API, aplikacji, sygnatur i scenariuszy użycia,
monitorować billing, quota oraz anomalie w wykorzystaniu usług AI,
skanować kod i artefakty CI/CD pod kątem sekretów i identyfikatorów,
regularnie przeglądać konfigurację projektów chmurowych po aktywacji nowych usług,
prowadzić testy reverse engineering jako element oceny bezpieczeństwa aplikacji mobilnych,
rozdzielać projekty i klucze pomiędzy różne środowiska oraz różne funkcje biznesowe.

Dobrym kierunkiem jest także segmentacja architektury. Jeżeli aplikacja wymaga publicznego identyfikatora dla jednej usługi, nie powinna współdzielić tego samego kontekstu projektowego z komponentami AI operującymi na danych użytkowników. Takie rozdzielenie zmniejsza promień rażenia w razie wycieku klucza.

Podsumowanie

Przypadek kluczy Google API w aplikacjach Android pokazuje, jak szybko zmienia się model zagrożeń w ekosystemie AI. Elementy wcześniej uznawane za niskiego ryzyka mogą wraz ze zmianą konfiguracji chmurowej zyskać nowe znaczenie bezpieczeństwa i stać się punktem wejścia do nadużyć.

Dla deweloperów i zespołów bezpieczeństwa to wyraźny sygnał, że integracje z generatywną AI wymagają innego podejścia niż tradycyjne użycie publicznych usług API. Ochrona powinna opierać się na backendzie, ścisłej kontroli dostępu, segmentacji projektów, monitoringu nadużyć oraz regularnym przeglądzie konfiguracji usług chmurowych.

Źródła

Kampania VENOM atakuje kadrę zarządzającą i przejmuje konta Microsoft 365 mimo MFA

Wprowadzenie do problemu / definicja

Na początku kwietnia 2026 roku opisano kampanię phishingową wykorzystującą nową platformę phishing-as-a-service o nazwie VENOM. Operacja jest wymierzona przede wszystkim w członków zarządów, dyrektorów finansowych oraz menedżerów wysokiego szczebla korzystających z Microsoft 365, a jej celem jest nie tylko kradzież poświadczeń, lecz także przejęcie sesji i utrzymanie dostępu do środowiska tożsamości ofiary.

To istotna zmiana w charakterze współczesnych ataków. W praktyce napastnicy nie muszą już ograniczać się do wyłudzenia hasła, ponieważ coraz częściej próbują przechwycić zaufaną sesję lub uzyskać tokeny pozwalające działać w ramach legalnego procesu uwierzytelniania.

W skrócie

VENOM to zamknięta platforma PhaaS używana do precyzyjnych kampanii przeciwko kadrze kierowniczej.
Ataki podszywają się pod powiadomienia SharePoint i wykorzystują kody QR zapisane znakami Unicode.
Mechanizm przenosi ofiarę na urządzenie mobilne, co pomaga ominąć część zabezpieczeń stacji roboczej.
Po wejściu w łańcuch ataku użytkownik może trafić do scenariusza AiTM albo phishingu opartego na device code.
Celem jest przejęcie sesji, tokenów oraz ustanowienie trwałego dostępu do konta Microsoft 365.

Kontekst / historia

Phishing ukierunkowany na środowiska Microsoft 365 od lat pozostaje jednym z głównych wektorów przejęcia tożsamości w firmach. W ostatnich latach obserwujemy przejście od prostych stron wyłudzających hasła do bardziej zaawansowanych zestawów adversary-in-the-middle, które pośredniczą w czasie rzeczywistym podczas logowania i przechwytują tokeny sesyjne.

Równolegle rośnie skala nadużyć związanych z mechanizmem device code. Ten model bazuje na legalnym procesie autoryzacji urządzenia, dlatego bywa trudniejszy do wykrycia niż klasyczny phishing formularzowy. VENOM wpisuje się w ten trend, ale wyróżnia się wysokim poziomem organizacji operacyjnej, własnym panelem zarządzania kampaniami oraz kontrolowanym, ograniczonym sposobem dystrybucji.

Analiza techniczna

Łańcuch ataku rozpoczyna się od wiadomości e-mail imitującej wewnętrzne powiadomienie SharePoint. Wiadomości są silnie spersonalizowane i skonstruowane tak, aby wyglądały jak realna korespondencja biznesowa. Dodatkowe elementy HTML, sztuczne klasy CSS, komentarze i rozbudowane wątki wiadomości mają utrudniać analizę treści oraz omijać mechanizmy detekcji oparte na sygnaturach.

Jednym z najbardziej charakterystycznych elementów kampanii jest użycie kodów QR zapisanych jako układ znaków Unicode osadzonych bezpośrednio w HTML. Taka technika zmniejsza skuteczność części rozwiązań skanujących obrazy i załączniki, a jednocześnie zachęca odbiorcę do zeskanowania kodu telefonem i kontynuowania interakcji poza firmowym endpointem.

Adres ofiary bywa ukrywany w fragmencie adresu URL zakodowanym podwójnym Base64. Ponieważ część po znaku kratki nie jest standardowo przesyłana do serwera w żądaniu HTTP, analiza i reputacyjne wykrywanie takich linków stają się trudniejsze. Po wejściu na stronę użytkownik trafia do warstwy filtrującej, która ma oddzielić realne cele od badaczy, automatycznych skanerów, sandboxów i systemów analitycznych.

Mechanizmy filtrujące wykorzystują między innymi ocenę User-Agent, reputację adresu IP, elementy honeypot i dodatkowe kontrole wskazujące na środowisko analityczne. Osoby lub systemy, które nie spełniają kryteriów, są przekierowywane do legalnych serwisów, co ogranicza ryzyko wzbudzenia podejrzeń.

Po przejściu przez filtr ofiara trafia do jednego z dwóch scenariuszy. W modelu AiTM fałszywa strona pośredniczy w prawdziwym logowaniu do Microsoft. Użytkownik widzi wiarygodny ekran logowania, często z poprawnym brandingiem organizacji i wstępnie uzupełnionym adresem e-mail, a operator ataku przechwytuje dane logowania, kody MFA i finalnie sesję.

Drugi wariant opiera się na device code phishing. W tym przypadku użytkownik otrzymuje instrukcję wprowadzenia kodu na legalnej stronie logowania urządzenia i zatwierdzenia dostępu. Ofiara nie wpisuje hasła w fałszywym formularzu, co znacząco utrudnia wykrycie ataku przez klasyczne zabezpieczenia antyphishingowe, ale skutkiem nadal jest wydanie tokenów napastnikowi.

Kluczowym etapem jest utrzymanie dostępu. W scenariuszu AiTM platforma może doprowadzić do zarejestrowania nowego urządzenia lub dodatkowej metody MFA na koncie ofiary jeszcze w trakcie aktywnej sesji. W wariancie device code trwałość zapewnia przejęty refresh token, dlatego sama zmiana hasła może nie wystarczyć do pełnego usunięcia dostępu intruza.

Konsekwencje / ryzyko

Ryzyko związane z kampanią VENOM jest szczególnie wysokie, ponieważ celem są osoby posiadające szerokie uprawnienia, dostęp do danych finansowych i strategicznych oraz możliwość autoryzowania wrażliwych działań biznesowych. Przejęcie konta członka zarządu lub dyrektora finansowego może prowadzić do oszustw BEC, wyłudzeń płatności, kradzieży dokumentów poufnych i dalszej kompromitacji organizacji.

Dodatkowym problemem jest skuteczność zastosowanych technik omijania zabezpieczeń. Unicode QR, ukrywanie danych w fragmencie URL oraz przekierowania do legalnych stron dla niepożądanych odwiedzających tworzą wielowarstwowy model utrudniający wykrywanie i analizę incydentu.

Kampania podważa również założenie, że samo MFA jest wystarczającą ochroną. Jeśli napastnik przejmie tokeny sesyjne lub skłoni ofiarę do zatwierdzenia legalnie wyglądającego procesu device code, może uzyskać dostęp bez klasycznego obchodzenia kontroli wieloskładnikowej. Z perspektywy obrońcy oznacza to konieczność ochrony nie tylko haseł, ale całego procesu tożsamości i sesji.

Rekomendacje

Organizacje powinny traktować tego typu kampanie jako atak na warstwę tożsamości. Priorytetem jest wdrożenie metod uwierzytelniania odpornych na phishing, takich jak FIDO2 i passkeys, zwłaszcza dla kadry kierowniczej, administratorów oraz kont uprzywilejowanych.

Warto przeanalizować, czy przepływ device code jest rzeczywiście potrzebny biznesowo. Jeśli nie, należy go ograniczyć lub wyłączyć. Jeżeli pozostaje wymagany, powinien zostać objęty ścisłym monitoringiem, politykami dostępu warunkowego i dodatkowymi kontrolami ryzyka.

Monitorować rejestrację nowych urządzeń i metod MFA.
Analizować nietypowe logowania do Entra ID oraz anomalie związane z tokenami odświeżania.
Wdrożyć alerty dla nietypowych lokalizacji, urządzeń i przepływów autoryzacyjnych.
Uwzględnić w procedurach IR unieważnianie aktywnych sesji oraz cofanie tokenów.
Regularnie przeglądać zarejestrowane metody MFA i listę zaufanych urządzeń.
Szkolić kadrę zarządzającą z rozpoznawania wiadomości z kodami QR i nietypowych żądań logowania na telefonie.

W reagowaniu na incydenty trzeba założyć, że reset hasła może być niewystarczający. W przypadku podejrzenia kompromitacji konieczne może być unieważnienie wszystkich aktywnych sesji, cofnięcie zgód tokenowych, przegląd metod MFA, usunięcie nieautoryzowanych urządzeń i szczegółowa analiza historii logowań oraz działań administracyjnych.

Podsumowanie

VENOM pokazuje, że współczesny phishing coraz częściej koncentruje się na przejęciu zaufanej tożsamości, a nie wyłącznie na kradzieży hasła. Połączenie personalizacji, technik unikania analizy, przeniesienia interakcji na urządzenia mobilne oraz nadużycia legalnych mechanizmów uwierzytelniania sprawia, że atak jest szczególnie groźny dla organizacji korzystających z Microsoft 365.

Dla firm oznacza to potrzebę przesunięcia strategii obrony z tradycyjnego antyphishingu na ochronę warstwy tożsamości, tokenów i sesji. Bez takiej zmiany nawet dobrze wdrożone MFA może nie zapewnić oczekiwanego poziomu odporności.

Źródła

Project Glasswing (Anthropic): AI, Które Znajduje I Exploituje Podatności Szybciej Niż Człowiek

Nie chodzi o model. Chodzi o zmianę zasad gry

Jeśli spojrzysz na Project Glasswing jak na kolejny launch modelu AI, przeoczysz sedno. Anthropic nie zrobiło publicznej premiery „nowego Claude’a do cybera”. Zrobiło coś dużo ciekawszego: zamknęło dostęp do modelu, uruchomiło program defensywny z udziałem AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA i Palo Alto Networks, rozszerzyło dostęp na ponad 40 kolejnych organizacji utrzymujących krytyczne oprogramowanie, dorzuciło do 100 mln USD kredytów oraz zapowiedziało publiczny raport z wnioskami i poprawkami w ciągu 90 dni. To nie wygląda jak marketing produktu. To wygląda jak zarządzanie ryzykiem wokół capability, które zaczynają mieć znaczenie systemowe dla bezpieczeństwa software’u.

Czytaj dalej

Grafana łata podatność „GrafanaGhost”. Błąd AI mógł prowadzić do wycieku danych użytkowników

Wprowadzenie do problemu / definicja

Grafana usunęła podatność określaną jako „GrafanaGhost”, związaną z komponentami AI wykorzystywanymi w platformie observability. Problem dotyczył klasy pośrednich ataków prompt injection, w których złośliwe instrukcje są ukrywane w treściach przetwarzanych później przez model i mogą wpływać na jego działanie bez klasycznego, bezpośredniego polecenia wydanego w interfejsie czatu.

W praktyce oznaczało to ryzyko, że asystent AI obsługujący dane w Grafanie potraktuje spreparowaną treść jako wiarygodny kontekst roboczy. W rezultacie mogło dojść do nieautoryzowanego ujawnienia informacji lub przesłania danych do zasobu kontrolowanego przez napastnika.

W skrócie

Podatność została ujawniona 7 kwietnia 2026 roku i dotyczyła sposobu interpretacji zewnętrznych treści przez komponenty AI w Grafanie. Badacze wskazali, że odpowiednio przygotowane znaczniki obrazów oraz ukryte instrukcje mogły posłużyć do obejścia części zabezpieczeń i uruchomienia scenariusza eksfiltracji danych.

Grafana potwierdziła problem oraz wdrożyła poprawkę, jednocześnie podkreślając, że skuteczne wykorzystanie błędu nie miało charakteru całkowicie bezobsługowego i wymagało interakcji użytkownika. Niezależnie od tej różnicy interpretacyjnej incydent pokazuje, jak wrażliwe na manipulację mogą być systemy GenAI osadzone w narzędziach operacyjnych.

Kontekst / historia

Grafana jest szeroko stosowana do wizualizacji logów, metryk, zdarzeń i danych operacyjnych, często w środowiskach o znaczeniu krytycznym dla biznesu. Z tego powodu każda podatność dotycząca mechanizmów renderowania treści lub warstwy AI ma podwyższoną wagę, ponieważ platforma bywa zintegrowana z wartościowymi źródłami informacji o infrastrukturze, użytkownikach i procesach.

Problem opisała firma Noma Security, która przedstawiła scenariusz pośredniego prompt injection prowadzącego do wycieku danych przedsiębiorstwa. Według badaczy złośliwy ładunek mógł zostać osadzony w treści, którą system później pobierał i analizował podczas zwykłej pracy użytkownika, na przykład przy przeglądaniu logów lub innych danych zawierających elementy zewnętrzne.

Istotą sporu między badaczami a dostawcą była skala automatyzacji ataku. Badacze akcentowali możliwość uruchomienia niebezpiecznego przepływu przy minimalnej świadomości ofiary, natomiast Grafana zaznaczyła, że nie był to scenariusz całkowicie „zero-click” i nie ma dowodów na aktywne wykorzystanie luki w realnych incydentach.

Analiza techniczna

Od strony technicznej problem znajdował się na styku przetwarzania kontekstu przez AI, renderowania Markdown oraz obsługi obrazów. Badacze wskazali, że mechanizmy ograniczające nadużycia związane z zewnętrznymi obrazami mogły zostać obejście poprzez odpowiednio przygotowane odwołania oraz instrukcje zakamuflowane jako pozornie bezpieczna treść.

To klasyczny przykład pośredniego prompt injection. Napastnik nie komunikuje się bezpośrednio z modelem, lecz umieszcza instrukcje w danych, które system uznaje za część kontekstu roboczego. Gdy komponent AI pobiera i analizuje taką treść, może nadać jej wysoki priorytet semantyczny i wykonać działania niezgodne z intencją operatora systemu.

W tego typu scenariuszu tradycyjne zabezpieczenia aplikacyjne nie zawsze są wystarczające. Nawet jeśli aplikacja ogranicza dostęp do niektórych zasobów lub filtruje określone wejścia, model AI może stać się warstwą interpretacyjną, która odczyta złośliwe instrukcje z nieufnych danych i potraktuje je jak legalne polecenie operacyjne.

Grafana poinformowała, że podatny element związany z rendererem obrazów w module Markdown został poprawiony. Wskazuje to, że źródłem problemu było połączenie logiki renderowania treści, walidacji zewnętrznych zasobów oraz sposobu, w jaki asystent AI budował i przetwarzał kontekst.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiej podatności jest możliwość eksfiltracji danych z platformy, która często agreguje informacje o wysokiej wartości biznesowej. W zależności od wdrożenia mogą to być logi aplikacyjne, metryki infrastruktury, wskaźniki operacyjne, dane klientów lub szczegóły środowisk produkcyjnych.

Ryzyko jest szczególnie istotne tam, gdzie funkcje GenAI uzyskały szeroki dostęp do źródeł danych i mogą inicjować operacje na podstawie analizowanego kontekstu. Tego rodzaju ataki są trudniejsze do wykrycia, ponieważ nie przypominają klasycznego przejęcia konta czy uruchomienia złośliwego kodu, lecz wykorzystują sam mechanizm rozumienia treści przez model.

Dodatkowym zagrożeniem jest ograniczona widoczność dla użytkownika końcowego. Osoba korzystająca z systemu może wykonać zwykłą, rutynową czynność, nie mając świadomości, że uruchamia łańcuch zdarzeń prowadzący do ujawnienia informacji poza organizację.

Rekomendacje

Organizacje korzystające z Grafany powinny w pierwszej kolejności upewnić się, że wdrożyły najnowsze poprawki bezpieczeństwa oraz przeanalizowały konfigurację komponentów AI i mechanizmów renderowania treści. Szczególne znaczenie ma ograniczenie relacji między nieufnymi danymi wejściowymi a zasobami, do których model ma dostęp.

zaktualizować instancje Grafany oraz powiązane komponenty AI do wersji zawierających poprawki,
ograniczyć pobieranie i renderowanie treści z niezaufanych źródeł,
wdrożyć segmentację dostępu między asystentem AI a wrażliwymi źródłami danych,
monitorować nietypowe połączenia wychodzące, zwłaszcza do nieznanych hostów,
rejestrować operacje wykonywane przez funkcje AI i audytować kontekst przekazywany do modeli,
stosować allowlisty dla domen i zasobów osadzanych w treści,
testować rozwiązania GenAI pod kątem pośrednich ataków prompt injection, a nie wyłącznie klasycznych podatności webowych.

Dobrą praktyką pozostaje traktowanie wszystkich danych wejściowych dla modeli jako potencjalnie nieufnych, nawet jeśli pochodzą z logów, dashboardów lub innych rutynowo wykorzystywanych źródeł wewnętrznych. W architekturach z AI izolacja uprawnień i kontrola semantyczna stają się równie ważne jak tradycyjna walidacja danych.

Podsumowanie

Przypadek „GrafanaGhost” pokazuje, że integracja AI w platformach observability otwiera nową powierzchnię ataku, w której prompt injection może prowadzić do realnego ryzyka wycieku danych. Nawet jeśli szczegóły dotyczące poziomu interakcji użytkownika pozostają przedmiotem dyskusji, sam incydent potwierdza potrzebę projektowania funkcji GenAI zgodnie z zasadą nieufnego kontekstu wejściowego.

Dla zespołów bezpieczeństwa to kolejny sygnał, że modelowanie zagrożeń dla systemów AI musi wykraczać poza klasyczne podatności aplikacyjne i API. Ochrona narzędzi takich jak Grafana wymaga dziś jednoczesnego spojrzenia na warstwę aplikacyjną, logikę renderowania oraz semantyczne zachowanie modeli.

Źródła

Dark Reading – https://www.darkreading.com/application-security/grafana-patches-ai-bug-leaked-user-data
Noma Security – https://noma.security/blog/grafana-ghost/
SecurityWeek – https://www.securityweek.com/grafanaghost-attackers-can-abuse-grafana-to-leak-enterprise-data/
Grafana Labs – https://grafana.com/docs/grafana/latest/panels-visualizations/visualizations/text/

HackerOne wstrzymuje Internet Bug Bounty. AI ujawnia kryzys remediacji w open source

Wprowadzenie do problemu

Automatyzacja wykrywania podatności z użyciem narzędzi AI zmienia sposób działania programów bug bounty oraz ekonomię bezpieczeństwa w projektach open source. Przez lata największym wyzwaniem było samo znalezienie błędu, jednak dziś coraz częściej problemem staje się jego weryfikacja, priorytetyzacja i skuteczna naprawa. Decyzja o wstrzymaniu nowych zgłoszeń do Internet Bug Bounty pokazuje, że sektor otwartego oprogramowania wchodzi w etap przeciążenia procesów remediacji.

W skrócie

HackerOne wstrzymał przyjmowanie nowych zgłoszeń do programu Internet Bug Bounty od 27 marca 2026 roku. Powodem jest rosnąca nierównowaga między tempem odkrywania podatności a możliwościami zespołów utrzymaniowych, które muszą je analizować i usuwać. Skutki tej decyzji odczuły również projekty korzystające z finansowania tego modelu, w tym Node.js, który zawiesił własny program nagród po utracie zewnętrznego wsparcia.

Kontekst i historia

Internet Bug Bounty przez lata należał do najbardziej rozpoznawalnych inicjatyw wspierających odpowiedzialne ujawnianie podatności w oprogramowaniu o kluczowym znaczeniu dla infrastruktury internetu. Program zapewniał badaczom finansową motywację do zgłaszania błędów, a projektom open source dawał dodatkowy mechanizm wzmacniający bezpieczeństwo.

Sytuacja zaczęła się zmieniać wraz z popularyzacją narzędzi AI wspierających analizę kodu, fuzzing oraz generowanie hipotez o podatnościach. W praktyce doprowadziło to do gwałtownego wzrostu liczby zgłoszeń, bez analogicznego wzrostu zasobów po stronie maintainerów. W projektach rozwijanych przez małe zespoły lub wolontariuszy nawet wartościowe raporty mogą przekraczać realne możliwości obsługi.

Dodatkowym sygnałem zmiany była decyzja projektu Node.js o wstrzymaniu programu bug bounty finansowanego wcześniej przez Internet Bug Bounty. Sam proces zgłaszania luk pozostał aktywny, ale zniknęły wypłaty nagród, co unaoczniło zależność części ekosystemu od zewnętrznego finansowania bezpieczeństwa.

Analiza techniczna

Kluczowym problemem nie jest wyłącznie większa liczba potencjalnych błędów, lecz pogarszająca się relacja między sygnałem a szumem. Narzędzia AI potrafią tworzyć raporty, które wyglądają wiarygodnie technicznie, lecz po dokładnej analizie okazują się mało istotne, nieeksploatowalne albo oparte na błędnych założeniach. To powoduje przesunięcie kosztów z etapu discovery na triage, walidację i remediację.

Każde zgłoszenie bezpieczeństwa wymaga odtworzenia warunków, potwierdzenia wpływu, oceny zasięgu, ustalenia priorytetu, przygotowania poprawki, wykonania testów regresyjnych oraz zaplanowania publikacji. Jeśli liczba raportów rośnie szybciej niż zdolność ludzi do ich obsługi, cały pipeline staje się niewydolny.

zgłoszenia niskiej jakości, ale technicznie przekonujące,
duplikaty i różne warianty tej samej klasy błędu,
raporty wymagające długiej analizy mimo braku realnego scenariusza ataku,
przeciążenie maintainerów łączących rozwój, utrzymanie i bezpieczeństwo projektu.

W efekcie pojawia się zjawisko triage fatigue, czyli zmęczenia procesem weryfikacji. Zespół traci czas na ocenę zgłoszeń o niskiej wartości zamiast skupiać się na usuwaniu podatności o rzeczywistym znaczeniu. To podważa klasyczny model bug bounty, który nagradza znalezienie problemu, ale nie zawsze finansuje najdroższy etap, czyli skuteczną naprawę.

Konsekwencje i ryzyko

Najpoważniejsze ryzyko ma charakter operacyjny. Gdy liczba zgłoszeń przekracza zdolność ich obsługi, wydłuża się czas potrzebny na weryfikację i usunięcie błędów. W rezultacie zwiększa się okno ekspozycji, nawet jeśli organizacja formalnie otrzymuje więcej informacji o zagrożeniach.

Dla ekosystemu open source oznacza to kilka istotnych konsekwencji:

spadek efektywności programów bug bounty,
wzrost obciążenia po stronie wolontariackich maintainerów,
ryzyko ograniczania lub zamykania programów nagród,
przesunięcie uwagi z jakości badań na skalę generowanych zgłoszeń,
opóźnienia we wdrażaniu poprawek dla krytycznych komponentów.

Z perspektywy bezpieczeństwa łańcucha dostaw jest to szczególnie ważne. Lepsza wykrywalność nie gwarantuje wzrostu bezpieczeństwa, jeśli projekty nie mają środków ani ludzi do szybkiej remediacji. Może więc powstać paradoks: rośnie liczba zidentyfikowanych problemów, ale maleje zdolność do ich praktycznego usunięcia.

Rekomendacje

Organizacje prowadzące programy bug bounty oraz zespoły rozwijające oprogramowanie open source powinny dostosować swoje modele operacyjne do nowej skali zgłoszeń.

Zaostrzyć kryteria przyjmowania raportów i wymagać pełnych kroków reprodukcji oraz dowodów eksploatowalności.
Inwestować nie tylko w discovery, ale również w triage, deduplikację i finansowanie remediacji.
Silniej premiować jakość raportu niż sam wolumen zgłoszeń.
Wprowadzać filtry wejściowe dla raportów niskiej jakości oraz szybsze ścieżki obsługi dla błędów krytycznych.
Zwiększyć udział użytkowników komercyjnych open source w finansowaniu bezpieczeństwa kluczowych komponentów.

W praktyce oznacza to odejście od modelu, w którym nagradzane jest przede wszystkim znalezienie symptomu. Coraz większe znaczenie powinny mieć raporty zawierające realny scenariusz ataku, ocenę wpływu, a najlepiej także propozycję poprawki lub test regresyjny.

Podsumowanie

Wstrzymanie nowych zgłoszeń do Internet Bug Bounty to nie tylko decyzja organizacyjna jednego programu, ale wyraźny sygnał szerszej zmiany w branży. AI przyspieszyła wykrywanie podatności szybciej, niż ekosystem open source zdołał rozwinąć zdolności ich obsługi i naprawy. W nowej rzeczywistości kluczowe staje się nie samo znalezienie luki, lecz utrzymanie wydajnego procesu triage, finansowania i remediacji.

Dla rynku cybersecurity to ważna lekcja: skuteczność ujawniania podatności nie zależy wyłącznie od liczby raportów, ale od tego, czy istnieje realna możliwość przełożenia ich na trwałą poprawę bezpieczeństwa.

Źródła

Dark Reading — AI-Led Remediation Crisis Prompts HackerOne to Pause Bug Bounties — https://www.darkreading.com/application-security/ai-led-remediation-crisis-prompts-hackerone-pause-bug-bounties
Node.js — Security Bug Bounty Program Paused Due to Loss of Funding — https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties
HackerOne — Internet Bug Bounty policy versions — https://hackerone.com/ibb/policy_versions?change=3771829&type=team