Support 24/7: +48 61 646 07 77
Z tego artykułu dowiesz się:
W pierwszej części artykułu zajmiemy się zagrożeniami – a tych niestety wcale nie brakuje. Sztuczna inteligencja nie tylko dostarcza multum wyspecjalizowanych narzędzi, które pozwalają przestępcom na praktycznie bezobsługowy phishing w dowolnym języku, ukrywanie malware’u w mailach bez załączników i zatruwanie szeroko wykorzystywanych modeli LLM. Najpowszechniejszym zagrożeniem okazują się być sami użytkownicy narzędzi takich jak ChatGPT. Nierzadko dość bezrefleksyjnie wpisują oni swoje (ale i cudze) dane osobowe, hasła, a nawet klucze API i tokeny aplikacji w okna chatów, aby w ten sposób uzyskać pomoc sztucznej inteligencji. Niestety to dowodzi, że najsłabszym ogniwem cyberbezpieczeństwa niezmiennie pozostaje człowiek.
Przez ostatnie kilkanaście miesięcy przyglądałam się doniesieniom o różnych formach złośliwego wykorzystania AI, śledziłam raporty o wyciekach związanych z narzędziami opartymi o sztuczną inteligencję i przekopywałam się przez newsy branżowe, żeby dziś móc podzielić się z Tobą, jak najbardziej kompleksową wiedzą w tym zakresie. Oczywiście nie śmiem twierdzić, że poniższy katalog zagrożeń jest w jakimkolwiek stopniu wyczerpujący, ale chciałabym, żeby stał się swego rodzaju wprowadzeniem do tej tematyki oraz by uczulił Cię na niebezpieczeństwa czyhające za (cyber)rogiem. Starałam się też, by artykuł był napisany na tyle prosto, by bez problemu zrozumiały go osoby niezwiązane z IT – jeśli uważasz, że jest wartościowy, to śmiało podsyłaj go znajomym.
Zachłystując się nową wspaniałą technologią wiele osób zapomina, że po drugiej stronie ekranu nie siedzi dobra wróżka, tylko w najlepszym wypadku – nastawiona na zysk korporacja, a w najgorszym – cyberprzestępca. Dlatego podawanie LLMowym asystentom danych, które nie są publicznie dostępne, zawsze jest ryzykowne. Wprawdzie protonowe Lumo nęci tym, że nie przechowuje konwersacji, a jedyny sposób na zachowanie rozmowy to pobranie jej na dysk… Ale wątpliwości badaczy bezpieczeństwa budzi faktyczny poziom szyfrowania end‑to‑end czatu Protona. O ile w przypadku wcześniejszych produktów tej firmy poziom prywatności od lat nie ma sobie równych, to Lumo – będące w końcu chatbotem – musi mieć dostęp do rozmowy w trybie otwartego tekstu (eng. plain text), a to najzwyczajniej wyklucza jego szyfrowanie na poziomie konwersacji.
Pozostałe narzędzia AI nawet nie usiłują ukryć faktu, że uczą swoje modele na danych użytkowników. Antrophic szczyci się tym, że ich Claude jest „wytrenowany do bycia bezpiecznym i trafnym”, ale jeśli zagłębimy się w politykę prywatności firmy, to szybko odkryjemy, że Claude zbiera o użytkownikach całkiem sporo informacji, z ich promptami włącznie. Co to oznacza? Dopóki twórcy czatów nie wymyślą w jaki sposób zabezpieczyć LLMy przed atakami typu prompt injection, musimy mieć świadomość, że wszystko co wrzucamy do czatu może zostać odzyskane i wykorzystane przez hakerów. Niestety na razie rozwiązanie tego problemu jest tylko jedno: odcięcie modelu od pełnego dostępu do Internetu, co siłą rzeczy ogranicza jego funkcjonalność.
Ale to tylko jedna z form tzw. Secret Leaking w kontekście agentów AI. Jakiś czas temu na użytkowników ChataGPT padł blady strach, gdy okazało się, że ich bardzo prywatne konwersacje były indeksowane przez Google. Co istotne, opcja dzielenia się linkami działa podobnie również w przypadku pozostałych czatów – oznacza to, że w momencie, w którym decydujesz się na udostępnienie treści rozmowy innej osobie, naturalnym następstwem będzie zapisanie tej konwersacji pod adresem URL. Ten z kolei, nawet jeśli nie zostanie zindeksowany przez wyszukiwarki, automatycznie stanie się zasobem internetowym i w dotarciu do jego zawartości pomoże np. Wayback Machine.
Po aferze z ChatemGPT opcje dzielenia się linkami zostały nieco zmodyfikowane i w tym momencie Google nie pokazuje już udostępnianych rozmów. Ale podstawowa znajomość pisania skryptów wystarczy, by przeszukać konwersacje, które trafiły do archiwum Internetu i w ten sposób poznać ich tajemnice – od tych technicznych, jak klucze API i hasła, po te bardzo prywatne, związane np. ze zdrowiem psychicznym… (I tu jeszcze słowo komentarza: napisałam „znajomość pisania skryptów”, ale taki skrypt może przecież napisać samo AI.)
Oczywiście warto pamiętać, że nie tylko cyberprzestępcy i mniej lub bardziej świadomie udostępniane linki są odpowiedzialne za wycieki danych z LLMów. Stosunkowo często winna jest niewłaściwa konfiguracja infrastruktury i jej zabezpieczeń. Pamiętaj, że żaden system, choćby i dogłębnie przemyślany pod kątem prywatności i bezpieczeństwa danych, nie będzie w 100% wyciekoodporny, jeśli infrastruktura, w ramach której funkcjonuje, nie zostanie odpowiednio zabezpieczona. I dotyczy to w takim samym stopniu sklepów internetowych, jak i wielkich modeli językowych. Parafrazując klasyka, infrastruktura jest królową(cyberbezpieczeństwa).
Tyle tytułem wstępu, a teraz przyjrzyjmy się po kolei zagrożeniom, które wprowadziła lub wzmocniła sztuczna inteligencja.
Koncepcja wirusa komputerowego jest z nami prawie tak długo, jak sam komputer. W 1949 roku John von Neumann opisał samoreprodukujący się program komputerowy i został teoretycznym ojcem malware’u. Niemniej, wykorzystanie koncepcji von Neumanna w praktyce zabrało jeszcze ponad dwie dekady. Pierwszy wirus został bowiem napisany w latach 70‑tych i wciąż był to eksperyment badawczy, a nie realne zagrożenie. Natomiast ze złośliwym oprogramowaniem wykorzystywanym dla celów przestępczych mamy do czynienia w zasadzie dopiero od połowy lat 90‑tych i jeszcze do niedawna tworzenie takich programów wymagało dość solidnej wiedzy i umiejętności technicznych. Zmieniła to sztuczna inteligencja i szybko zyskujący na popularności vibe coding oraz jego nikczemny brat bliźniak – vibe hacking.
Do vibe codingu jeszcze wrócimy, ale najprościej mówiąc – jest to sposób tworzenia oprogramowania oparty o prompty pisane językiem naturalnym i nie wymagający żadnej wiedzy technicznej. Jak możesz się domyślić, w przypadku vibe hackingu założenie jest podobne, z tym, że efektem jest tu znacznie obniżony próg wejścia do społeczności cyberprzestępców. To, co kiedyś zajmowało grupie utalentowanych hakerów całe miesiące, dzięki AI da się osiągnąć jednoosobowo w ciągu tygodni, i to bez choćby podstawowych umiejętności programowania.
Mało tego, jeśli model zostanie nakarmiony dobrze napisanym promptem, będzie w stanie samodzielnie przeprowadzić pełny cyberatak. Dowiedli tego badacze z NYU, którzy zaprogramowali złośliwe AI (obecnie znane jako PromptLock) zdolne do przeprowadzenia kompletnego ataku ransomware – od zinfiltrowania systemu i wytypowania wartościowych danych, poprzez ich kradzież lub szyfrowanie, po samodzielne napisanie żądania okupu. Symulację przeprowadzono zarówno na prywatnych komputerach oraz serwerach firmowych, jak i na przemysłowych systemach sterowania. Warto też zaznaczyć, że rozwój w tym zakresie postępuje na tyle szybko, że pomiędzy napisaniem tego akapitu a momentem, w którym go czytasz, samodzielne ataki AI mogły wyjść już dawno poza ośrodki badawcze.
W przypadku popularnych LLMów, takich jak Claude, ChatGPT, czy Gemini, vibe hacking wymaga przynajmniej podstawowej wiedzy o promptowaniu i metodach prompt injection, która pozwalają na złamanie zabezpieczeń modelu (choć podobno wystarczy też bardzo długie i niegramatyczne zdanie oraz wytrwałość – czyli przynajmniej 20 prób). Lecz wykorzystanie komercyjnych LLMów to tylko jedna z możliwych dróg użycia AI do celów przestępczych.
Prawie równie szybko, jak produkty korporacji w „normalnym” Internecie, w Dark Webie pojawiły się dedykowane modele AI dla hakerów – kilka najbardziej znanych to WormGPT 4, FraudGPT i PoisonGPT. W zasadzie same ich nazwy tłumaczą cele, do których zostały stworzone, ale najważniejsze co trzeba o nich wiedzieć, to że dzięki takim narzędziom nietechniczni przestępcy mają możliwość partycypowania w cyberatakach praktycznie na równi z doświadczonymi Black Hat’ami. Owszem, ich malware nie będzie idealny i raczej nie zastosują w nim celowego zatruwania skryptów, żeby utrudnić pracę badaczom, chcącym przeanalizować kod programu. Ale to nie powstrzyma ich przed przeczesywaniem sieci w poszukiwaniu nieaktualizowanych systemów i niezałatanych podatności. Dlatego powiedzmy sobie wprost – to w zasadzie ostatni dzwonek na inwestycję w cyberbezpieczeństwo firmy, bo dzięki AI cyberataki stały się tak demokratyczne, jak jeszcze nigdy dotąd.
Osobnym problemem z malwarem dzisiejszych czasów jest to, że odpowiednio zaprogramowany wirus może w czasie rzeczywistym wykorzystywać AI, by dynamicznie dopasowywać się do atakowanego systemu. Badacze odkryli między innymi tzw. dropper (czyli typ wirusa, który sam w sobie nie jest groźny, za to wykorzystuje się go do pobierania i instalacji tego „właściwego” malware’u), który przepisywał swój własny kod przy pomocy modelu LLM, unikając w ten sposób wykrycia w systemie ofiary.
Na koniec tej części zostawiłam sobie jeszcze komentarz o sposobie rozprzestrzeniania malware’u, którego popularność (i skuteczność) nie słabnie od dekad. Mowa oczywiście o podkładaniu złośliwych plików instalacyjnych udających programy, które w danym czasie cieszą się ogromnym zainteresowaniem użytkowników. A że obecnie prawie wszystkich interesuje AI to… no właśnie. Pamiętaj, że w czasach powszechnego zatruwania SEO, nawet pierwszy wynik w wyszukiwarce nie gwarantuje, że plik, który pobierasz jest w 100% bezpieczny.
Można by pomyśleć, że skoro to vibe hacking jest tym złośliwym bratem bliźniakiem, to vibe coding nie powinien trafić do zestawienia zagrożeń. Niestety źle napisany i jeszcze gorzej zabezpieczony kod aplikacji może okazać się równie niebezpieczny, co przestępcy z hakerskimi ambicjami.
Same narzędzia, które wspomagają programistów nie są oczywiście niczym złym. Dla osoby, która wie, co robi i oprócz napisania promptu potrafi też sprawdzić efekty pracy asystenta AI, korzystanie z Cursora lub Github Copilot to doskonała metoda przyspieszenia najbardziej mechanicznej części programowania. Poza tym, doświadczony developer wie, że napisanie kodu to wcale nie koniec „kodowania”, bo równie ważne jak zaplanowanie logiki aplikacji jest jej późniejsze przetestowanie, również na tzw. przypadkach brzegowych (eng. edge cases). A że pisanie testów należy do zajęć żmudnych i powtarzalnych, to i w tym może oczywiście dopomóc AI.
Natomiast problem z vibe codingiem leży zupełnie gdzie indziej. Odkąd wiedza techniczna przestała być elementem niezbędnym do napisania działającego kodu, do grona podwykonawców oferujących usługi programistyczne dołączyły osoby, którym Java kojarzyła się dotychczas jedynie z indonezyjską wyspą. Samo zainteresowanie programowaniem, nawet jeśli nagłe i niespodziewane, to oczywiście nic zdrożnego, ale obniżony próg wejścia oznacza w tym przypadku nieuchronne zalanie Internetu falą stron i sklepów spod znaku AI slop.
I tu dochodzimy do słynnych halucynacji AI. Zacznijmy może od tego, że jako ludzie mamy tendencję do antropomorfizowania – nadajemy cechy ludzkie zwierzętom, żywiołom i… narzędziom AI. Te ostatnie przecież nawet “mówią” do nas językiem naturalnym! Zapominamy jednak, że LLMy to modele oparte o predykcję tekstu, czyli przewidywanie sekwencji wyrazów na podstawie statystyki. Dodatkowo, AI w trakcie treningów uczy się, że brak odpowiedzi jest odbierany negatywnie. A to oczywiście, prowadzi do sytuacji, w której gdy asystentowi zabraknie danych lub odpowiedniego kontekstu, otrzymamy od niego najbardziej prawdopodobną gramatycznie “halucynację”.
Ale czemu tłumaczę to wszystko we fragmencie poświęconym vibe codingowi? Odpowiedzią jest slopsquatting, czyli cyberatak opierający się o wykorzystanie halucynacji asystentów kodowania do podkładania złośliwych bibliotek. Bazując na tendencji modeli LLM do proponowania programistom wiarygodnych, acz nieistniejących nazw dependencji, hakerzy dodają w publicznych repozytoriach złośliwe pakiety pod takimi właśnie wyhalucynowanymi nazwami.
Wielu doświadczonych developerów może nie ustrzec się przed tym zagrożeniem, odruchowo wpisując komendę instalacji biblioteki podpowiedzianej im przez AI, a co dopiero osoby, które tworzą swoje aplikacje zdając się całkowicie na instrukcie otrzymane od asystenta. I to jest kolejny powód, dla którego vibe coding wylądował w części artykułu o zagrożeniach związanych z AI.
Przy okazji jest to dobre miejsce, żeby wspomnieć o Human‑in‑the‑Loop (HITL) – kluczowej zasadzie, której pominięcie w kontaktach ze sztuczną inteligencją praktycznie gwarantuje, że coś pójdzie nie tak. Nawet zlecając AI zrobienie prostego researchu i wymagając od asystenta trzymania się wiedzy z wskazanych mu źródeł, warto sprawdzić wyniki jego pracy. Natomiast w przypadku zadań, których efekty mają mieć realny wpływ na rzeczywistość, utrzymanie roli człowieka w procesie jest absolutnie nieodzowne.
Wraz z popularyzacją użycia AI reguła Human‑in‑the‑Loop doczekała się nawet wyższego poziomu: Human‑in‑the‑Lead(HITLd). O ile wdrożenie pierwszej z nich spokojnie wystarcza w kontekście prostych zadań, z których zaplanowaniem sztuczna inteligencja bez problemu sobie poradzi, to jeśli proces wymaga precyzyjnej strategii i osiągnięcia konkretnych celów, to człowiek powinien nie tylko być jego częścią, ale przede wszystkim nim kierować.
Wspomniałam już kilkukrotnie o prompt injection, więc czas w końcu wyjaśnić, co to takiego. Zwykle, kiedy myślimy o ataku hakerskim, jawi się on jako coś dynamicznego i pełnego zwrotów akcji. Tymczasem wiele (a wręcz: większość) cyberataków przeprowadza się w ukryciu i bez presji czasu. Prompt injection, czyli „wstrzyknięcie (złośliwego) promptu”, samo w sobie jest mało widowiskowe, ale za to jego skutki mogą być dość katastrofalne. W systemach, w których AI zintegrowano z zewnętrznymi interfejsami API, udany atak prompt injection może doprowadzić do eskalacji uprawnień, kradzieży danych uwierzytelniających, a nawet przeprowadzenia nieautoryzowanych transakcji finansowych lub operacji na bazach danych.
Problem prompt injection wynika bezpośrednio z architektury modeli językowych, które nie posiadają mechanizmu, który mógłby oddzielić instrukcje systemowe (wpisane przez twórców aplikacji) od zewnętrznych danych dostarczanych przez użytkownika. W efekcie hakerzy mogą manipulować procesem wnioskowania modelu poprzez podanie mu odpowiednio spreparowanych i sformatowanych danych.
I tak, ze względu na źródło złośliwej komendy, ataki typu prompt injection możemy podzielić na bezpośrednie i pośrednie, przy czym efekt w obu przypadkach jest ten sam – wymuszenie jakiejś akcji na zaatakowanym modelu LLM. W przypadku pierwszego wariantu, wstrzykiwane polecenie wpisywane jest bezpośrednio w okienko czatu przez użytkownika, który przekleja tekst z innego miejsca i jest nieświadomy zagrożenia, albo też celowo chce ominąć zabezpieczenia modelu (czyli wykonuje tzw. jailbreaking). Z kolei opcja druga opiera się o funkcjonalność agentów AI pozwalającą im na samodzielne przeszukiwanie i przetwarzanie danych na stronach internetowych, a także w wiadomościach i dokumentach, do których mają dostęp. O pośrednim ataku mówimy też w przypadku, gdy dwa modele komunikują się ze sobą nawzajem.
W celu ukrycia komend przed użytkownikiem lub nawet przed twórcami strony, która została przez przestępców wytypowana jako nośnik prompt injection, wykorzystywane są metody takie jak:
Analiza ruchu sieciowego prowadzona przez badaczy bezpieczeństwa (między innymi przez laboratoria Google) ujawniła, że Internet stał się obecnie poligonem doświadczalnym dla wstrzykiwania promptów na strony internetowe. Obok przypadków nieszkodliwych (np. próby optymalizacji SEO za pomocą prompt injection), nie zabrakło też na przykład komend polecających usunięcie plików systemowych.
I to jest krajobraz, w który wkraczają przeglądarki z wbudowanym agentem AI, który mając ogromne uprawnienia w środowisku użytkownika i nieograniczony dostęp do Internetu, z cudu technologii zmienia się w jeźdźca cybernetycznej apokalipsy. Nawet jeśli założymy, że agent nie dostaje uprawnień do przeglądania zawartości dysków, to wciąż zachowuje on dostępy do aktywnych sesji przeglądarki. A to oznacza: formularze w sklepach internetowych (wraz z danymi osobowymi i szczegółami transakcji płatniczych), konta mailowe i wszystkie inne strony, na których użytkownik jest zalogowany.
A teraz przypomnij sobie, co napisałam nieco wyżej o vibe codingu, jego szalonej popularności i fakcie, że kod produkowany w ten sposób często nie jest ani testowany, ani odpowiednio zabezpieczany. W czasach przed AI, kiepsko napisana witryna również stanowiła zagrożenie, bo mogła serwować gościom złośliwe skrypty, ale skala takiego ataku była znacznie mniejsza.
W przypadku prompt injection osoby odwiedzające stronę przez klasyczne przeglądarki nie są zagrożone (oczywiście tak długo, jak nie kopiują treści i nie wklejają ich ręcznie do narzędzi AI), ale za to agenty zczytujące witrynę mogą w ten sposób dostać polecenie przesłania danych lub zrzutów ekranu prosto na serwery hakerów. Taka aktywność nie zostanie zidentyfikowana jako podejrzana przez komercyjne firewalle, ani nawet przez systemy DLP skonfigurowane do wyłapywania anomalii w ruchu – w końcu wszystko odbywa się w ramach standardów ruchu sieciowego przeglądarki i z wykorzystaniem zaufanego API agenta.
Na koniec tej sekcji chcę jeszcze pokazać Ci kilka oryginalnych “twarzy” prompt injection. Zwróć uwagę na to, jak pomysłowe są niektóre z nich:
Metoda “na babcię” to chyba najciekawszy (a przy tym najprostszy) z ataków typu Jailbreaking. Przy okazji świetnie pokazuje, dlaczego sztuczna inteligencja z inteligencją ma naprawdę niewiele wspólnego. Modele językowe szkoli się na gigantycznych zbiorach danych, ale same te dane nie mają większego znaczenia, dopóki nie zostaną przypisane do określonego kontekstu. Dlatego dość szybko okazało się, że jeśli opakujemy prompt w łzawą opowieść o nieżyjącej babuni, to asystent obejdzie własne zabezpieczenia, żeby ukoić naszą żałobę po śmierci ukochanej seniorki. A przy okazji podzieli się informacjami o budowie bomby albo składzie niebezpiecznej substancji.
HashJack to sposób na ukrycie promptu w linku bez zmiany adresu, do którego prowadzi odnośnik. Dodatkową komendę umieszcza się po symbolu “#”, który do tej pory był wykorzystywany np. do śledzenia skuteczności kampanii marketingowych (#utm). Człowiek taki dopisany prompt po prostu zignoruje, a asystent AI – cóż, on go wykona.
Odkąd firmy zachłysnęły się bezobsługowym supportem Internet stał się naprawdę frustrującym miejscem. Ale nie dla hakerów. Okazuje się bowiem, że taki czat obsługiwany przez AI jest doskonałym punktem wejścia do firmowej infrastruktury.
Grupa ataków kryjąca się pod nazwą Tool Poisoning szczególnie dobrze sprawdza się w przypadku całych ekosystemów MCP, w których centralnym punkcie znajduje się model LLM z szerokimi uprawnieniami. W ten sposób podmiana pojedynczego elementu (a nawet samej jego dokumentacji!) na złośliwy wystarczy, żeby wykraść dane, lub nawet zdalnie przejąć cały system.
Przestępcom nie zawsze chodzi o przejęcie finansów ofiary. Denial of Wallet to rodzaj prompt injection, który naraża ofiary na straty finansowe i mimo że powstał jeszcze przed popularyzacją AI, to coraz częściej właśnie w tym zakresie jest wykorzystywany. Atak bazuje na systemie przeliczania promptów i odpowiedzi na tokeny – jeśli instrukcja jest skomplikowana i wymaga równie kompleksowej odpowiedzi, a do tego zapytanie zostanie zapętlone, taki prompt może sporo kosztować niczego nieświadomego użytkownika. Dlatego warto ustawiać limity wykorzystania tokenów, a zamiast kart kredytowych, do narzędzi AI podpinać karty pre‑paid.
Model Context Protocol, czyli standard komunikacyjny pozwalający na współpracę modeli LLM z zewnętrznymi narzędziami, przebojem wdarł się na technologiczne salony, obiecując rzeczywistość z filmów science fiction. Niestety pierwsi użytkownicy – o ile sami nie zadbali o odpowiednie zabezpieczenia – mogli się przekonać, że autonomiczne połączenie „wszystkiego ze wszystkim” wpisuje się w nieco inny gatunek kinowy, a mianowicie thriller.
Podstawowy problem tkwi w samej koncepcji MCP, a także w szybkości, z jaką standard został przyjęty w środowiskach produkcyjnych – protokół nie został bowiem wyposażony w żadną domyślną warstwę zabezpieczeń. Implementacja uwierzytelniania zależała wyłącznie od osoby tworzącej dany system, a to dość często prowadziło do braku jakiejkolwiek autentykacji między modelem i skomunikowanymi z nim zewnętrznymi aplikacjami.
Obecnie świadomość zagrożeń jest już znacznie większa, powstały też tzw. wrappery, które „opakowują” LLM najbardziej podstawową warstwą zabezpieczeń. Ale tu znów wracamy do szerokiej dostępności technologii, z której nagle korzystać mogą osoby, które niekoniecznie znają się na zapewnieniu odpowiedniego poziomu bezpieczeństwa swoim integracjom.
Lista zagrożeń dla systemów agentowych wykorzystujących MCP obejmuje zarówno prompt injection, jak i masę dedykowanych ataków (na szczególną wzmiankę zasługuje User Consent Fatigue, czyli seria próśb o zgodę na automatyzację zupełnie nieszkodliwych akcji, która wyrabia w użytkowniku nawyk klikania „zezwól” w każdym kolejnym oknie dialogowym). Dla zobrazowania powagi sytuacji opowiem Ci o doświadczeniu, jakie jeden z badaczy przeprowadził na asystencie AI pokazując, że nawet jeśli zadbasz o bezpieczeństwo poszczególnych komponentów, cały ekosystem MCP nie będzie chroniony sumą tych zabezpieczeń.
Efekt wspomnianego doświadczenia to Claude, który zhakował sam siebie. Nie, nie przy pierwszym podejściu i nie z wykorzystaniem żadnej znanej podatności. Ale asystent sam pomógł badaczowi dopracować atak oparty o wykonanie kodu z wiadomości email i dzielnie iterował jej treść. Po każdej próbie Claude analizował, co poszło nie tak i dzielił się wnioskami. Aż w końcu się udało – asystent AI odpalił okno kalkulatora na podstawie komendy wyciągniętej z odpowiednio spreparowanego maila. A co, gdyby to nie był kalkulator?
Jeszcze przed złotym wiekiem AI, phishing odpowiadał za ponad połowę incydentów bezpieczeństwa na świecie (wg danych za 2022 rok). To sporo jak na atak, który opierał się o wiadomości z błędami (szczególnie w krajach nieanglojęzycznych), rozsyłane masowo i bez dopasowywania treści do ofiar (oczywiście oprócz spear‑phishingu i whalingu, w przypadku których przestępcy dużo bardziej się starają). Jeśli chcesz dowiedzieć się więcej o phishingu w ogóle, to zachęcam do przeczytania mojego artykułu o atakach socjotechnicznych, tu natomiast skupię się na pokazaniu, jak na jego rozwój wpłynęła sztuczna inteligencja.
Dzięki AI, phishing stał się bardziej – bardziej dopracowany, bardziej skuteczny i bardziej dostępny. Pierwsze, co wydarzyło się po wejściu ChataGPT na rynek komercyjny to globalizacja ataków phishingowych. Przestępców przestała bowiem ograniczać znajomość języka ich ofiar – używając odpowiednio skonstruowanego promptu, przetłumaczenie wiadomości na dowolny język z zachowaniem odpowiednich struktur gramatycznych i zwrotów właściwych dla danego regionu stało się kwestią sekund. Nagle obudziliśmy się w świecie, w którym mail od scamera brzmi lepiej, niż większość tych prawdziwych.
I nie pomogły ograniczenia i zabezpieczenia nakładane na popularne modele – wszak dotychczas nie powstał system, który skutecznie blokowałby złośliwe instrukcje. W dodatku przestępcy wykazują się w tym względzie szaloną wręcz pomysłowością. Ale nawet, gdyby udało się skutecznie uniemożliwić oszustom korzystanie z ChataGPT, Claude’a, Gemini i innych komercyjnych asystentów, to przecież powstały już (wspomniane przeze mnie w części na temat malware) dedykowane narzędzia AI, których modele znacznie lepiej odpowiadają na potrzeby przestępczego cyberświata.
Dodatkowo, wyrastające jak grzyby po deszczu narzędzia do budowy stron oparte o AI pozwalają przestępcom na szybkie stawianie witryn i sklepów, które wzmacniają w ofiarach przekonanie, że otrzymana przez nich wiadomość nie jest oszustwem (np. imitacje stron kancelarii prawnych uwiarygadniają „oficjalne” pisma otrzymane drogą mailową).
Co gorsza, narzędzia te poszerzają również potencjalną pulę osób narażonych na phishing – najlepszym przykładem była masowa kampania zamykających się sklepów. Nierealnie niskie ceny wsparte łzawą historią o bankrutującym butiku lub – w innym wariancie – o właścicielu porzucającym życie biznesmena, żeby poświęcić czas rodzinie, trafiały w serca i portfele ogromnej rzeszy osób, które potem przekonywały się, że nigdy nie otrzymają zakupionych w nieprzyzwoicie niskich cenach produktów.
Z drugiej strony, lokalizowane tłumaczenia, generowanie bezbłędnych tekstów, które prześlizgują się przez filtry antyspamowe oraz fałszywe sklepy to dziś już tylko część problemu. Tekst ma w końcu to do siebie, że można przeczytać go ponownie i wyłapać drobne niuanse, które umknęły nam za pierwszym razem. Z kolei w przypadku sklepów – można poszukać opinii od użytkowników lub po prostu sprawdzić od kiedy witryna istnieje.
Znacznie trudniej, usłyszawszy znany sobie głos w słuchawce, wykazać się taką przytomnością umysłu, by nie dać się podejść za pomocą vishingu (czyli voice phishingu), który dzięki AI zyskał potencjał zupełnie nowej jakości. Choć w tym miejscu warto też zaznaczyć, że rozmowy telefoniczne z wykorzystaniem klonowania głosu to w dalszym ciągu rzadkość i mimo że ofiary phishingu głosowego są przekonane, że słyszały przez telefon szefa lub członka rodziny, to najczęściej przekonanie to wynika z kombinacji stresu i socjotechnik stosowanych przez oszusta.
No chyba, że w akcji biorą udział Koreańczycy z Północy – wtedy już sprawa może wyglądać zgoła odmiennie. Bo nikt chyba nie doprowadził wykorzystania generatywnej sztucznej inteligencji do takiej maestrii, jak hakerzy na usługach Koreańskiej Republiki Ludowo‑Demokratycznej. Ich działania ciężko zakwalifikować jako tylkophishing, ale na potrzeby tego artykułu pozwolę sobie pominąć kontekst geopolityczny i spojrzeć na koreańską kampanię pracy zdalnej jako na oszustwo polegające na podszyciu się pod kogoś w celu pozyskania środków finansowych.
Scam północno‑koreański (znany także pod jakże romantyczną nazwą “Operacja Dream Job”) zaczął się jeszcze zanim wkroczyliśmy w erę generatywnej AI, ale w 2024 roku wszedł on na zupełnie nowy poziom skuteczności. Dość powiedzieć, że od tego czasu problem dotknął wiele firm zaliczanych do grona Fortune 100, a Koreańscy „pracownicy” IT rozpoczęli ekspansję na rynek europejski.
Dawniej oszustwo opierało się po prostu o kradzież tożsamości i istniało stosunkowo wysokie prawdopodobieństwo, że przekręt zostanie wykryty najdalej na etapie rozmowy z kandydatem. Zmieniła to sztuczna inteligencja, pozwalając nie tylko na zwielokrotnienie profili obsługiwanych przez pojedynczą osobę i automatyzację niemal całości procesu, ale także na przejście etapu rozmowy za pomocą deepfake’ów tak dobrych, że rekruterzy muszą uciekać się do bardzo pomysłowych rozwiązań, żeby „kandydat” sam się odsłonił.
A jaki jest spodziewany rezultat tego scamu? Z jednej strony – oczywiście zdobycie środków finansowych na wspieranie reżimu. Natomiast z punktu widzenia cyberbezpieczeństwa, znacznie gorsze od nieświadomego dorzucania się do północnokoreańskiej skarbonki jest narażanie systemów firmy na zainfekowanie malwarem. Pracownicy IT, nawet ci pracujący zdalnie, mają zwykle dość szeroki dostęp do infrastruktury, z którą łączą się po firmowym VPNie. To niestety oznacza, że atak przeprowadzony w taki sposób może w krótkim czasie położyć całą infrastrukturę ofiary. Dlatego też jednym z filarów bezpieczeństwa w każdej firmie powinno być dostosowanie poziomu uprawnień stricte do wymagań stanowiska. I warto o tym pamiętać nawet, jeśli cały personel pracuje z biura i nie ma nawet cienia szans na zatrudnienie w firmie Koreańczyka.
Na koniec pozwolę sobie wspomnieć o jeszcze jednym zagrożeniu. AI crawlery nie są wprawdzie z założenia złośliwe, ale w obliczu generowanych przez nie kosztów (szczególnie dla projektów open‑source) oraz notorycznego wysycania przepustowości łącz, możemy je jako takie potraktować.
W odróżnieniu od tradycyjnych botów wyszukiwarkowych, które kierują ruch na oryginalną stronę odpowiadającą na zapytanie użytkownika, AI crawlery zasysają całą zawartość witryny i dostarczają ją prosto do okienka czatu. W teorii plik robots.txt powinien ograniczać ich aktywność, ale to niestety jest… teoria. W praktyce, wielu twórców musi korzystać z dodatkowych zabezpieczeń, które nierzadko powodują utrudnienia w dostępie do witryny dla prawdziwych użytkowników.
Oprócz AI crawlerów odpowiadających na konkretne zapytania, możemy spotkać jeszcze dwa inne typy: boty treningowe (tych jest najwięcej, bo aż około 80%) i indeksujące. Te pierwsze służą oczywiście do zczytywania ogromnych baz danych, na których trenuje się wielkie modele językowe. Z kolei te drugie indeksują zawartość Internetu na podobnej zasadzie, jak robi to Googlebot, tyle że z efektów ich pracy korzystają narzędzia AI.
Możemy oczywiście pomstować na kradzież treści i pogwałcenie praw autorskich, ale jest to temat na nieco inny artykuł. Z punktu widzenia cyberbezpieczeństwa, crawlery AI to przede wszystkim groźba przestoju serwisu. Wprawdzie koncepcja Martwego Internetu nie jest niczym nowym i wciąż postrzegana jest w kategorii teorii spiskowych, ale z danych niektórych projektów open‑source’owych wynika, że nawet aż 97% ich ruchu generują boty. I są to niestety boty inteligentne, które wyrzucone drzwiami, wejdą oknem – bez problemu podszyją się pod prawdziwych użytkowników albo ukryją za adresami IP osiedli mieszkaniowych.
W takim kontekście o „przypadkowy” DDoS już naprawdę nietrudno. Wystarczy, że do botów dołączy nieco wzmożony ruch pochodzący od prawdziwych użytkowników i serwis może nie być w stanie obsłużyć takiej ilości zapytań. No a konsekwencji downtime’u raczej nikomu tłumaczyć nie trzeba.
Czy to już wszystkie zagrożenia dla cyberbezpieczeństwa ze strony sztucznej inteligencji? Na pewno nie, bo hakerzy nie próżnują i wciąż wymyślają nowe. Osobną kwestią jest też to, jak operują poszczególne modele, szczególnie w kontekście geopolitycznym. Na przykład Deep Seek został napisany w taki sposób, by jego odpowiedzi były zgodne z chińską racją stanu. W prostym eksperymencie wykazano, że kod generowany dla regionów politycznie wykluczanych przez Chiny, takich jak Tybet czy Tajwan, był pełen poważnych luk bezpieczeństwa. A i to tylko, jeśli asystent w ogóle zgodził się pomóc mieszkańcom tych krajów.
Jednym zagrożeniem, którym na razie nie musimy się martwić jest to, że AI przewyższy ludzi pod względem, cóż, inteligencji. Tak, ChatGPT‑4.5 zdał tzw. Test Touringa na ponad 70%, co niektórzy przyjmują za niezbity dowód na „inteligencję maszyny”. Ale prawda jest znacznie bardziej nieoczywista. Test w gruncie rzeczy sprawdza, czy na podstawie odpowiedzi na te same pytania da się pomylić człowieka z AI. Przy czym warto pamiętać, że to, co nazywamy sztuczną inteligencją to model językowy wytrenowany na petabajtach danych stworzonych przez ludzi. A wobec tego zdanie testu Touringa wcale nie dowodzi, że AI staje się coraz bardziej myślące, a jedynie, że coraz lepiej dopasowuje się do ludzkiego sposobu komunikacji, czyli odtwarza to, co przyswoiło z danych treningowych i rozmów z użytkownikami.
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
