O czym jest ten film
- Autor podsumowowa najburzliwszy tydzień w cyberbezpieczeństwie od lat — branża ochrzciła go mianem „Blocktober”, czyli czarnego października — i pokazuje obie strony nowej wojny: atakujących i obrońców.
- 21 października PHP opublikowało poprawki dwóch krytycznych luk: w konfiguracji Apache z mod_php intruz mógł uruchomić swój kod na cudzej stronie jeszcze przed startem jej własnej aplikacji i przejąć w ten sposób całą platformę.
- Brytyjskie i unijne agencje bezpieczeństwa zaleciły organizacjom odizolowanie lub całkowite odłączenie systemów, których nie da się szybko załatać — rząd wprost każe przerywać działalność, bo warstwa pod aplikacją jest niebezpieczna.
- U wystawcy certyfikatów eMudhra osiem kluczy prywatnych okazało się rażąco słabych — jeden „tajny” klucz miał wartość 4; badacz Scott Helme odzyskał je w mniej niż sekundę, podobno jednym promptem do Claude’a.
- Mozilla, Cloudflare i Vercel w kilka godzin rozstawiły ochronę dla stron, których właściciele nie zdążyli się zabezpieczyć — wielcy gracze działają jak tarcza przed resztą internetu.
- Microsoft udokumentował grupę powiązaną z Chinami, która przy pomocy frameworka agentów AI o nazwie Artek atakowała setki organizacji; część ataków zdobyła uprzywilejowany dostęp do chmury w kilka godzin.
- Agenci AI są „natywni” dla systemów komputerowych: czytają kod, piszą testy i iterują bez zmęczenia — dokładnie te same czynności służą atakowi i obronie, a filtry modeli blokujące ataki zatrzymują też obrońców.
- LiteLLM, narzędzie łączące aplikacje z modelami, rozprowadziło wersję z malwarem kradnącym poświadczenia; założyciel startupu Post wyłączył całą usługę po ostrzeżeniach o przejęciu kluczy Anthropic i Stripe.
- Klucze API zachowują się jak gotówka — ukradzione pozwalają pracować na cudzy koszt; Anthropic zgłosiło 29 tysięcy kandydujących luk z zaledwie pół roku skanowania kluczowego oprogramowania.
- Materiał kończy się konkretną listą działań dla użytkowników (aktualizacje, przegląd uprawnień, menedżer haseł, MFA) i propozycją przetestowania modeli obronnych na scenariuszu incydentu LiteLLM.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Klucz API zachowuje się jak gotówka — chroń go i pilnuj rachunków
Na czym polega: Skradziony klucz API pozwala obcej osobie uruchamiać modele i obciążać twoje konto. Może z niego korzystać sama albo odsprzedać dostęp dalej — rachunek zawsze trafia do ciebie. W tym tygodniu klucze kradziono między innymi przez zainfekowaną paczkę LiteLLM.
Jak stosować: Przy najmniejszym podejrzeniu, że klucz mógł wyciec, wygeneruj nowy i unieważnij stary. W panelu rozliczeń dostawcy sprawdź, czy zużycie nie zawiera niczego, czego nie rozpoznajesz.
Na co uważać: Kradzież bywa cicha — zużycie tokenów rośnie, zanim ktokolwiek zauważy. Samo „klucz dalej działa” nie jest dowodem bezpieczeństwa; dowodem jest historia rozliczeń.
2.Czyste repozytorium to nie to samo co czysta instalacja
Na czym polega: W przypadku LiteLLM oficjalny tag w repozytorium był nieskażony, ale paczka dystrybuowana do użytkowników zawierała złośliwe pliki. Przeczytanie kodu źródłowego nic nie mówi o tym, co faktycznie uruchomiła twoja maszyna.
Jak stosować: W każdym śledztwie zadawaj pytanie: „co się faktycznie wykonało?”. Przejrzyj historię wdrożeń i zadań budowania, sprawdź, jakie uprawnienia miały konta usłużne i procesy automatyczne oraz do czego mogły sięgnąć.
Na co uważać: Zadanie, które już się zakończyło, nadal mogło wykraść dane — brak działającego procesu nie oznacza braku szkód.
3.Do cyberobrony bierz najsilniejszy model — i przetestuj go zawczasu
Na czym polega: Atak i obrona wymagają tych samych czynności (czytanie kodu, pisanie testów, weryfikacja hipotez), więc filtry mające powstrzymywać ataki potrafią blokować obrońców. Przeciwnik użyje najsilniejszego modelu, jaki znajdzie — ty też powinieneś.
Jak stosować: Przygotuj bezpieczną replikę znanego ci incydentu (np. scenariusza LiteLLM) i porównuj modele: czy zatrzymują się na czystym repozytorium, czy drążą aż do rekordu budowania i łączą go z poświadczeniami? Mierz czas i koszt dojścia do odpowiedzi, którą znasz.
Na co uważać: Oszczędność na inferencji słabszym modelem może się zemścić kompletnie błędną diagnozą pod presją czasu.
4.Zrób przegląd połączonych aplikacji na ważnych kontach
Na czym polega: Każde autoryzowane połączenie — do plików, kalendarza, profilu — powiększa powierzchnię ataku, a aplikacje zależą z kolei od dostawców i bibliotek, których nawet nie znamy.
Jak stosować: Zacznij od poczty i plików. W ustawieniach Google (i innych kluczowych usług) przejrzyj dostęp zewnętrznych aplikacji, usuń nieużywane połączenia, a zostawionym ogranicz uprawnienia do niezbędnego minimum. Nazwy aplikacji i opisy uprawnień możesz wkleić asystentowi AI i poprosić o audyt jednym promptem.
Na co uważać: Słabość potrafi siedzieć głęboko w łańcuchu zależności — u dostawcy hostingu albo w komponencie, o którym nie masz pojęcia, a mimo to odsłania twoje dane.
5.Ogranicz uprawnienia rozszerzeń przeglądarki
Na czym polega: Rozszerzenia z blankietowym dostępem do wszystkich odwiedzanych stron to gotowa furtka dla intruza.
Jak stosować: Usuń rozszerzenia, z których nie korzystasz. W Chrome ogranicz pozostałym zasięg — do wybranych witryn albo do momentu, gdy sam je aktywnie użyjesz.
Na co uważać: Nie zgadzaj się hurtowo na pełne uprawnienia dla wielu rozszerzeń naraz — każde z nich to osobne wejście do twojej przeglądarki.
6.Aktualizuj systemy i domykaj restarty
Na czym polega: Poprawki krytycznych luk, jak te w PHP, chronią dopiero po instalacji i wymaganym ponownym uruchomieniu.
Jak stosować: Zaktualizuj przeglądarkę, telefon, systemy operacyjne i aplikacje; dokończ wszystkie restarty. Gdy usłyszysz o kolejnym wycieku, poproś Claude’a albo Codexa o sprawdzenie, które z twoich usług wymagają aktualizacji.
Na co uważać: Pobrana, ale nie „domyknięta” restartem łatka daje złudne poczucie bezpieczeństwa.
7.Zawiadomienie o wycieku to sygnał do natychmiastowego działania
Na czym polega: Komunikat „zaktualizowaliśmy oprogramowanie, chyba wszystko gra” nie wystarcza — firma ma obowiązek powiedzieć, co wie, czego jeszcze nie wie, czego dotyczył wyciek i co klient ma zrobić.
Jak stosować: Jako klient sprawdź, co konkretnie wyciekło; zmień hasła wszędzie tam, gdzie było zagrożone; przejrzyj i cofnij dotknięte połączenia aplikacji. Jako deweloper wygeneruj na nowo wszystkie sekrety API. Przy zagrożeniu tożsamości zgłoś się do właściwych instytucji (w USA także do biur informacji kredytowej).
Na co uważać: Nie chowaj głowy w piasek — przejęte poświadczenia bywają wykorzystane w ciągu godzin, a zwłoka gra na korzyść atakującego.
8.Unikalne hasła, drugi czynnik i rodzinne hasło głosowe
Na czym polega: Wyciek hasła z jednej usługi nie powinien otwierać pozostałych, a drugi czynnik logowania zamyka okno nawet przy znanym haśle.
Jak stosować: Trzymaj hasła w menedżerze — każde konto osobne i trudne do odgadnięcia. Włącz uwierzytelnianie wieloskładnikowe wszędzie, gdzie się da. Ustalcie w rodzinie tajne hasło głosowe, żeby nie dało się nabrać na nagranie podszywające się pod bliską osobę.
Na co uważać: Fałszerstwa głosu są już na tyle dobre, że sam brzmieniem „znajomego” głosu nie dowodzi tożsamości rozmówcy.
9.Audytuj też same narzędzia AI
Na czym polega: Narzędzia AI bywają źródłem wycieków same z siebie: Claude Code potrafił zapisać poświadczenie GitHub użytkownika w odpowiedzi trafiającej do logów, a agenci „przedstawiający się” odwiedzanym stronom modyfikują URL-e i przy okazji wplatają do nich dane osobowe, na przykład adres e-mail.
Jak stosować: Zapytaj swojego asystenta wprost: „gdzie przez URL-e i logi mogły wyciec moje dane?” — jeden z użytkowników dostał w ten sposób listę dziesięciu wycieków z dwóch tygodni. Regularnie przeglądaj logi pod kątem wkradających się sekretów.
Na co uważać: Mechanizmy wprowadzane „dla bezpieczeństwa”, jak wymóg, by agenty się ujawniały, mogą niechcący otwierać nowe kanały przecieków.
10.Zmniejszaj powierzchnię ataku zawczasu — i mów klientom prawdę
Na czym polega: Samo szybsze łatanie nie wystarczy. Anthropic w 25 projektach znalazło blisko 500 miejsc, gdzie da się ograniczyć eksponowany kod i niebezpieczne kombinacje konfiguracji; w OpenSSH usunięto kod dostępny jeszcze przed zalogowaniem (wersja 10.6). Liczą się też pieniądze — Bank of America zarezerwował kilkaset milionów dolarów w samym kwartale na cyberobronę.
Jak stosować: Mapuj zależności między konfiguracjami (pojedyncza wygląda sensownie, a w parze z drugą po cichu osłabia zabezpieczenie), usuwaj kod osiągalny przed uwierzytelnieniem, walcz o budżet na obronę. Przy incydencie wybieraj wobec klientów pełną przejrzystość.
Na co uważać: Czas na wieloletnie dyskusje o kompromisach się skończył — opiekunowie PHP widzieli symptomy problemu już w 2024 roku i nie zdążyli go domknąć.
Redakcyjne tłumaczenie
Dzień, w którym płonie jedna trzecia internetu
Podobno dzień, w którym płonie jedna trzecia internetu, jest zawsze dobrym dniem. Ten tygodnia to najbardziej intensywny okres w cyberbezpieczeństwie, jaki pamiętam — a siwych włosów nabyłem przy niejednym incydencie. Jeśli kiedykolwiek wklejałeś klucz AI do jakiejś aplikacji, żeby z niej skorzystać, ten materiał dotyczy właśnie ciebie.
Jeśli ktoś ukradnie taki klucz i przejmie dostęp do API Claude’a albo Codexa, będzie korzystał z AI na twój rachunek. Może uruchamiać modele sam, może sprzedać dostęp dalej — faktura i tak przyjdzie do ciebie. Tokeny zaczynają zachowywać się jak gotówka i w tym tygodniu wiele osób przekonało się, co to oznacza w praktyce. Popularne narzędzie łączące aplikacje z modelami wydało wersję, która kradła klucze programistów. Firma hostingowa ogłasza koniec działalności po kolejnym włamaniu. Założyciel jednego produktu wyłączył całą usługę po ostrzeżeniach, że firmowe klucze do AI i płatności zostały przejęte. A równocześnie agenci przeczesują nasze oprogramowanie i wyplatają z niego błędy, które tkwią tam od dziesięcioleci. Tajny klucz jednej firmy certyfikacyjnej miał wartość cztery. O tym też zaraz porozmawiamy.
Obrońcy nazywają ten miesiąc „Blocktober” — czarnym październikiem — i nie bez powodu. Te same agenty, które czynią ataki tanimi, mogą równie ciężko pracować dla ciebie. Odpowiedź na ten problem istnieje; pytanie tylko, po czyjej stronie stanie najlepsza inteligencja. Na końcu, jeśli korzystasz z aplikacji AI, dostaniesz konkretne zadania na ten tydzień: co zaktualizować, które połączenia odciąć i co robić, gdy trafiony zostanie serwis, któremu ufasz. Jeśli budujesz z AI, pokażę, jak ja ustawiłbym najsilniejszego obrońcę, jakiego da się dostać.
Moim zdaniem takich tygodni będzie znacznie więcej, bo agenci są „rodowitymi mieszkańcami” komputerów w sposób, w jaki człowiek nigdy nie będzie. Agent może dalej badać systemy, które zbudowaliśmy, podczas gdy my jeszcze zastanawiamy się, co wymaga naprawy i kto ma to zrobić.
Co to znaczy, że agenci są „natywni”
Agenci są natywni dla informatyki, ponieważ duże modele językowe potrafią posługiwać się narzędziami i na stałe zamieszkują nasze systemy. Ja nie żyję kodem dwadzieścia cztery godziny na dobę. Żaden inżynier nie żyje. AI tak — i nigdy się nie męczy. O to właśnie chodzi w tej „natywności”. W takim świecie musimy postawić naszych najlepszych agentów, najlepszą dostępną inteligencję, po stronie obrony — żeby mieć pewność, że umiemy się chronić.
PHP: obcy kod na cudzej stronie
Skąd się wzięło całe zamieszanie? 21 października PHP wydało poprawki dwóch krytycznych luk. PHP to oprogramowanie, na którym działa bardzo duża część internetu, w tym witryny oparte na WordPressie.
Na czym polegał sam atak, czyli co właściwie było nie tak? Atakującym udało się wymyślić, jak uruchomić kod PHP bez zgody na cudzej stronie. W konfiguracji Apache z modułem mod_php intruz może doprowadzić do tego, że jego kod zadziała przed kodem samej aplikacji — zanim witryna w ogóle wystartuje — i w ten sposób przejąć kontrolę nad całą platformą.
Brytyjskie i europejskie agencje bezpieczeństwa odpowiedziały wezwaniem: organizacje, które nie są w stanie szybko zaktualizować systemów albo zastosować obejść, powinny rozważyć ich odizolowanie albo całkowite odłączenie. Trudno o bardziej dosadny sygnał alarmowy: państwowa instytucja każe ci przerwać działalność, bo warstwa znajdująca się pod twoją aplikacją zagraża ogółowi użytkowników. To bardzo poważna sprawa.
eMudhra: tajny klucz o wartości cztery
PHP to może najbardziej rozpowszechniony problem, ale nie jedyny. Kolejna historia dotyczy firmy eMudhra, wystawcy certyfikatów służących do potwierdzania, że łączysz się z właściwą stroną. Okazało się, że osiem jej kluczy prywatnych było rażąco słabych. Badacz bezpieczeństwa Scott Helme odzyskał je w mniej niż sekundę. Jeden z kluczy, które z założenia mają być długimi, losowo wygenerowanymi liczbami odpornymi na złamanie, miał wartość… cztery. Po prostu cztery.
Te sekrety powinny składać się z setek cyfr, ale firma wdrożyła je tak niefortunnie, że praktycznie każdy laptop odtwarzał je niemal natychmiast. A ponieważ internet jest zbudowany tak, że eMudhra pełniła rolę głównego urzędu certyfikacji, wystawiane przez nią certyfikaty były automatycznie uznawane za wiarygodne. Ten łańcuch zaufania pozwolił błędowi jednej firmy rozprzestrzenić się po całej sieci. Co gorsza, cała operacja jest banalnie prosta — Helme twierdzi, że kazał Claude’owi odzyskać klucze jednym promptem.
Dlatego traktuję te wydarzenia tak poważnie. Mamy warstwy oprogramowania, które wyglądają normalnie, istnieją od dekad, przechodzą wszystkie nasze kontrole i od lat cieszą się zaufaniem — a agent po prostu przekopuje się przez nie i znajduje słabości, które nam wszystkim umknęły.
Duzi gracze stają w obronie
To oznacza, że najwięksi gracze internetu muszą grać w obronie. Przykład: Mozilla rozprowadziła ochronę do standardowych konfiguracji Firefoksa w ciągu zaledwie kilku godzin od zgłoszenia. Cloudflare natychmiast zabrał się za zabezpieczanie stron stojących za jego siecią, podobnie Vercel i wielu innych dużych podmiotów.
Dzięki temu, jak zbudowany jest internet, te firmy pełnią rolę pierwszej linii — warstwy obsługującej ruch przed wieloma witrynami — więc mogą postawić swoiste tarcze, chroniące strony nawet wtedy, gdy ich właściciele nie zdążyli jeszcze załatać PHP albo zostali zaatakowani w inny sposób.
Włączył się też Microsoft, który w cyberobronie siedzi od dawna. Udokumentował grupę powiązaną z chińskim państwem, atakującą przy użyciu frameworka agentów AI o nazwie Artek setki organizacji. Większość prób spełzła na niczym, ale niektóre ataki zdobyły uprzywilejowany dostęp do systemów chmurowych w ciągu zaledwie kilku godzin. Ataki ruszają dziś równie szybko, jak szybko bronią się obrońcy. Microsoft doskonale zdaje sobie sprawę, że jego pozycja — jako wyjątkowo szerokiego celu — pozwala mu pełnić rolę wczesnego ostrzegania dla całej sieci. Jednym z rozpoznanych wektorów jest atak przez pośrednika: intruzi wykorzystują poświadczenia, którym klienci już zaufali, żeby uderzać w kolejne systemy.
Jeśli to wszystko brzmi zbyt fachowo — spokojnie. Nie musisz zajmować się cyberbezpieczeństwem zawodowo; zaraz dojdziemy do kroków, które możesz wykonać sam. Opowiadam te historie po to, żeby pokazać panoramę nowej wojny, w której wszyscy uczestniczymy — jej stronę ofensywną i defensywną.
Jak pracuje agent — tak samo dla ataku i obrony
Co właściwie robi agent, kiedy „straszy” w internecie? W gruncie rzeczy coś bardzo prostego: potrafi przeczytać nieznany kod, zauważyć coś podejrzanego, napisać test, go uruchomić, odkryć, że pierwsza hipoteza była błędna, i próbować dalej. Co ciekawe, to niemal identyczny zestaw czynności dla cyberataku i dla cyberobrony. Dlatego filtry bezpieczeństwa, które twórcy modeli wbudowali, żeby powstrzymywać ataki, zatrzymują również obrońców i zmuszają ich do sięgania po inne modele, gdy wybucha pożar.
Stąd ważny wniosek: jeśli prowadzisz firmę i odpowiadasz za cyberobronę, upewnij się już teraz, że masz dostęp do najlepszych dostępnych modeli do tego zadania. Nieprawdą jest, że w obronie potrzebujesz słabszego modelu, bo boisz się, że mocny „oszaleje”. Właściwe odczytanie jest odwrotne: chcesz najsilniejszego możliwego modelu po swojej stronie, bo przeciwnik użyje najsilniejszego, jaki tylko znajdzie.
Ludzie się męczą, agenci nie: koszt ataku spada
Ludzie atakują strony od dawna. Kultura hackerska jest realna i bardzo dobry inżynier potrafi zrobić wszystko to, co przed chwilą opisałem jako pracę agenta — ale nie tak szybko, nie w nieskończoność i nie w skali. Człowiek musi jeść i odpoczywać. Kiedyś przeprowadzenie poważnego ataku ludzkimi siłami wymagało… wielu ludzi. Ten koszt się przesunął — dziś jest związany z mocą obliczeniową. Jedna z cech tegorocznego czarnego października jest taka, że część ataków da się przypisać pojedynczym osobom dysponującym flotami agentów.
Wniosek dla atakowanych firm: nie musisz zakładać, że jesteś celem drogiej, wielkoskalowej operacji. Wystarczy, że jesteś celem taniej i świetnie wyposażonej akcji, którą może prowadzić jedna osoba — ktoś, kto po prostu chce szkodzić w internecie. To obniża próg wejścia i częściowo tłumaczy, czemu ataków przybyło.
Utrzymanie oprogramowania boli
Trzeba też powiedzieć o czymś niewygodnym: utrzymanie oprogramowania jest trudne. Jedna z ciemniejszych stron tej historii jest taka, że opiekunowie PHP widzieli symptomy jednego z problemów już w 2024 roku — dwa lata temu. Poprawki są trudne: niosą ryzyko niezgodności, czas ekspertów jest ograniczony, a do tego trzeba wybrać, jaki kompromis się akceptuje. Zespół PHP podejmował i porzucał te prace, ale nigdy ich nie dokończył.
Kłopot w tym, że nie masz już czasu na wieloletnie ważenie takich kompromisów. AI odbiera obrońcom luksus dwuletnich dyskusji o pojedynczej luce. To po prostu przestaje działać — musisz być gotowy teraz. Żeby zobrazować skalę: Anthropic zgłosiło ponad 29 tysięcy kandydujących słabości z zaledwie sześciu miesięcy skanowania ważnych projektów. Około 6 tysięcy z nich zostało już ręcznie przejrzanych i sklasyfikowanych. Potencjalnej ekspozycji jest mnóstwo — realistycznie możemy mówić o milionach nieodkrytych albo niezałatanych słabych punktów w oprogramowaniu, z którego korzystamy.
Dżungla pełna nieodkrytych błędów
Moja analogia pochodzi z dżungli — jako dziecko spędziłem w niej trochę czasu. W dżungli mówi się o gatunkach czekających na odkrycie i to dobre porównanie: wyznaczysz kilometr kwadratowy puszczy i prawdopodobnie znajdziesz nowe gatunki; wyznaczysz metaforyczny kilometr kwadratowy internetu — znajdziesz nowe błędy. AI daje nam czujność i nadzór, dzięki którym dostrzegamy te słabości w sposób, jaki wcześniej był niedostępny.
Zwykłe decyzje wystawiają nas na ryzyko
Część trudności polega na tym, że narażają nas zupełnie zwyczajne wybory, które wydają się rozsądne. Podłączamy użyteczną aplikację do plików albo kalendarza, a ta aplikacja zależy od dostawcy hostingu i oprogramowania, o którym nigdy nie słyszeliśmy. Słabość w dowolnym punkcie tej ścieżki może odsłonić informacje albo dostęp, na których nam zależy, choć o ich istnieniu nie wiedzieliśmy. Kiedy mówię o tym, do czego oprogramowanie potrafi się dokopać, mam na myśli także wchodzenie w twoje dokumenty. To sytuacje, w których dane ludzi mogą wyciec w sposób, jakiego nigdy by się nie spodziewali.
Pierwszy krok: przegląd połączonych aplikacji
I tu pierwszy konkretny tip. Jeśli cię to niepokoi, otwórz ustawienia połączonych aplikacji na każdym ważnym koncie i przejrzyj to, co autoryzowałeś. Google to świetny przykład: tam możesz obejrzeć i cofnąć dostęp nadany zewnętrznym aplikacjom. Przeczytaj, co każde połączenie pozwala — dostęp do podstawowych danych profilu, czytanie plików, ich zmienianie. Zatrzymaj to, czego potrzebujesz, i wytnij resztę. To elementarna zasada cyberobrony: zmniejszasz powierzchnię ataku.
Jeśli chcesz, żeby w przeglądzie pomogło ci narzędzie AI, podaj swojemu asystentowi — Claude’owi, Codexowi, czemukolwiek — nazwy aplikacji i opisy uprawnień, a potem poproś o wnikliwą analizę ustawień, wskazanie słabych punktów i pomoc w zabezpieczeniu całego systemu. Piękno tej sytuacji polega na tym, że skoro lukę da się znaleźć jednozdaniowym promptem, to i bezpieczny audyt da się zrobić jednym promptem.
Wszystko z tego materiału jest na moim Substacku, razem z dwoma promptami do skopiowania. Pierwszy przeprowadzi cię przez konta i urządzenia i sprawi, że AI zapisze każdy sprawdzony punkt — zostanie ci ślad po audycie. Drugi pozwoli powtórzyć kontrolę, gdy wybucha kolejny wyciek, a to, przy obecnym tempie, zdarza się codziennie. Jeśli chcesz, żeby twój asystent miał te materiały pod ręką, podłącz go do mojej biblioteki: Nate’s Library MCP łączy narzędzie, którego już używasz — Claude’a, ChatGPT czy Gemini — z moimi tekstami, przewodnikami i promptami. Linki w opisie.
Skala firmowa: LiteLLM i kradzież poświadczeń
Te same słabości istnieją w skali całych firm. Przykład: LiteLLM, narzędzie łączące aplikacje z modelami AI, przeszło w ostatnim roku kilka włamań. Jego październikowe ujawnienie opisuje wydanie zawierające malware kradnący poświadczenia. W marcu firma uporała się już z jedną kompromitacją. Jeśli zainstalowałeś dotkniętą wersję — a to podręcznikowy przykład tego, jak dochodzi do przejęcia — natychmiastowa rada brzmi: potraktuj swoje środowisko jako zaatakowane, wykonaj kroki izolacji i wygeneruj wszystkie sekrety od nowa. Musisz rozliczyć dostęp, który już się wydarzył, i zakładać najgorsze. Ta zasada obowiąguje tak samo w skali firmy, jak i pojedynczego człowieka.
(Informacja dodatkowa: LiteLLM to popularne narzędzie open source działające jako bramka między aplikacjami a modelami różnych dostawców — dlatego jest wymarzonym miejscem do kradzieży kluczy API.)
Ćwiczenie śledcze: co faktycznie się wykonało?
Rozłóżmy to na przykładowym środowisku, bo całość może przytłaczać. Wyobraź sobie: aplikacja kliencka wysyła zapytania przez bramkę AI, która korzysta z LiteLLM i trzyma klucze do dostawców modeli. Zautomatyzowane zadania budują i wdrażają całość, a kilka innych aplikacji korzysta z dokładnie tej samej bramki. Zadaniem obrońcy jest ustalić, co wydarzyło się w całym środowisku i co z tym zrobić.
I wtedy przychodzi komunikat o incydencie. Sprawdzasz repozytorium kodu — wygląda na czyste. Sprawdzasz działającą bramkę — ktoś już ją zaktualizował. Łatwo byłoby teraz stwierdzić: „problem rozwiązany”. Ale oficjalne ujawnienie LiteLLM mówi, że tag w repozytorium źródłowym był czysty, natomiast dystrybuowana paczka zawierała złośliwe pliki. Przeczytanie repozytorium nic zatem nie mówi o tym, co było w paczce, którą zainstalowała twoja maszyna.
Obrońca musi więc zapytać: jaki kod faktycznie się wykonał? Załóżmy, że historia wdrożeń pokazuje, że złośliwa wersja uruchomiła się w zadaniu budowania zakończonym kilka godzin temu. Nie ma już procesu, który można by zatrzymać. Produkcyjna bramka jest teraz czysta — ale tożsamość, z jaką działało to zadanie, miała uprawnienia do pobierania produkcyjnych kluczy dostawców. I to zmienia sposób reakcji: trzeba zbadać, czego to skończone już zadanie mogło nadużyć.
Jak wybrać model do śledztwa
Właśnie taki test użyłbym do wyboru modelu, który poprowadzi śledztwo razem z obrońcą. Jak się do tego zabrać? Daj kandydującym modelom te same dane i narzędzia w bezpiecznej replice incydentu, którego przebieg znasz. Odpowiedzi trzymaj dla siebie — i obserwuj: czy model rozwiązuje problem? Czy zatrzyma się na czystym repozytorium? Czy przekopie się głębiej i znajdzie rekord budowania? Czy połączy tożsamość zadania z poświadczeniami, tak jak omawialiśmy? Innymi słowy: czy potrafi drążyć i pomóc ci szybko dojść do prawdy? Bo po części po to potrzebujemy modeli — dla ich szybkości.
Jeśli szukasz punktu startowego: zacznij od najsilniejszych modeli, do których masz dostęp, pod kątem rozumienia kodu i rozumowania o systemach. Poprowadź nimi prawdziwe śledztwo przez wiele wywołań narzędzi. To jest warte pieniędzy, bo alternatywa może być dla firmy przerażająca. Znajdź dobry, mocny model, porównaj czas i koszt dojścia do odpowiedzi, którą mniej więcej znasz — i pilnuj, żeby oszczędzenie paru groszy na inferencji nie skończyło się kompletnie błędną diagnozą pod presją czasu. To zdecydowanie nie jest miejsce na oszczędzanie.
Klucz API jak gotówka
Wróćmy na moment do przykładu: załóżmy, że zadanie budowania sięga kluczy dostawców. Klucz API jest jak gotówka — daje posiadaczowi prawo poprosić dostawcę o wykonanie pracy i obciążenie ciebie. Kto ukradnie taki klucz, może konsumować te obliczenia, a to dla przestępcy wymarzony scenariusz: pracuje ktoś, płaci kto inny. Na tym „gotówkowym” argumencie opiera się cała ta historia.
I to jest również część śledztwa. Jeśli choć podejrzewasz, że klucze AI zostały dotknięte — a właśnie mierzysz skuteczność modeli w cyberobronie — sprawdź, czy rozpoznają one ten czynnik ryzyka i czy sięgają po skutki finansowe: ślady użycia kluczy, rozliczenia. To ważny wątek na przyszłość: będziemy potrzebować szybszych i lepszych sposobów wykrywania i blokowania przejętych kluczy.
Założyciel, który wyłączył własny produkt
Nic z tego nie jest teoretyczne. 21 października założyciel małego startupu AI o nazwie Post ogłosił, że na kilka godzin wyłącza usługę dla klientów, bo dostawał ostrzeżenia, że firmowe klucze do Anthropic i Stripe zostały przejęte. Było to część włamania do Railway — o którym nawet nie zdążyliśmy jeszcze porozmawiać. I moim zdaniem jako założyciel zagrał to wzorowo.
Założyciel często jest w sytuacji, w której to nie on został zhakowany bezpośrednio — a mimo to jest w całą sprawę uwikłany, bo jego środowisko skompromitowała usługa, od której zależy. A pod nim stoją klienci z niepełną informacją i z powodów, by sądzić, że dostęp wymknął się spod kontroli. Zatrzymanie usługi może być odpowiedzialnym ruchem: odzyskujesz kontrolę, ustalasz, co się stało, dokumentujesz wszystko i robisz dla klientów, co się da.
(Informacja dodatkowa: Railway to chmurowa platforma hostingowa popularna wśród startupów.)
Narzędzia AI same mogą cię wystawić
A teraz pułapka, o której trzeba pamiętać: narzędzia AI nie powinny niechcący kompromitować ciebie podczas cyberobrony. I znowu wraca historia LiteLLM. Firma zaobserwowała sytuacje, w których Claude Code wpisał poświadczenie GitHub użytkownika do odpowiedzi, która mogła trafić do logów. Jej zdaniem atakujący wydobyli dane logowania z logów wewnętrznego wdrożenia, a część tej sekwencji ataku jest nadal badana. Patrząc na własne ryzyka: tak, intruz w ogóle nie powinien się był dostać do środka — ale skoro już się dostał, Claude nie powinien wystawiać tego uchwytu w logach. To również luka, którą trzeba prześwietlić.
Drugi przykład, bardzo „rok 2026”: strony proszą agentów, żeby ujawniali, że są agentami. Ci robią to, modyfikując URL, którym odwiedzają witryny. I przy tej modyfikacji potrafią wpleść w adres twoje dane osobowe — na przykład zakodowany adres e-mail. Ktoś opowiadał, że zapytał Claude’a: „gdzie przez URL-e wyciekały moje dane?” — i dostał listę dziesięciu przecieków z ostatnich dwóch tygodni. To zachowania, do których modele się ustawiają, bo proszą o nie strony w dobrej wierze, chcąc rozpoznawać boty — a niechcący tworzą koszmar bezpieczeństwa.
Syuacja jest złożona, dlatego wracam do refrenu: rozmawiaj ze swoim AI, każ mu audytować twoje ustawienia, myśl o cyberobronie warstwami — i bądź szczerze mówiąc trochę obsesyjny i lekko paranojalny w zabezpieczaniu środowiska. Paranoja jest adekwatną reakcją na czarny październik.
Perspektywa klienta i rozszerzenia przeglądarki
Dużo mówiłem o stronie obrony — nie chcę stracić z oczu klientów. Jako klienci potrzebujemy jasno wytłumaczonych konsekwencji: gdzie byliśmy wystawieni, czy dostęp już ustał, co mamy zrobić. Firma może wciąż prowadzić śledztwo, ale musi powiedzieć, co wie, a czego nie — i nie może poprzestać na „zaktualizowaliśmy wasze oprogramowanie, chyba wszystko gra”. W takich momentach trzeba być naprawdę transparentnym, żeby zasłużyć na zaufanie.
Jeśli incydent dotyczy ciebie jako klienta: zmień hasło. Pilnuj kontaktu z odpowiednimi instytucjami państwowymi, jeśli podejrzewasz wyciek dokumentu tożsamości. W Stanach rozmawiaj z biurami informacji kredytowej, jeśli zagrożony może być twój kredyt. To działania, których większość konsumentów nie wykonuje, a które składają się na cyberobronę pojedynczej osoby.
Tę samą logikę można przenieść na rozszerzenia przeglądarki. Przejrzyj je. Chrome pozwala ograniczyć dostęp rozszerzeń do witryn — czasem do konkretnych stron, czasem do momentu, gdy sam je aktywujesz. Skorzystaj z tego i nie rozdawaj uprawnień hurtowo. Zmniejszaj powierzchnię ataku.
Mniej wystawionego kodu — mniej okazji dla intruzów
Chciałbym też, żeby obrońcy ograniczali to, czego atakujący mogą się dosięgnąć, zanim pojawi się następna luka. Anthropic opublikowało niedawno pracę obejmującą 25 projektów i zidentyfikowało prawie 500 okazji do zredukowania eksponowanego kodu oraz niebezpiecznych interakcji konfiguracji. Przykład: pojedyncze ustawienie może wyglądać sensownie, a w połączeniu z drugim po cichu osłabiać mechanizm bezpieczeństwa. Brzmi teoretycznie? Każdy w cyberobronie potwierdzi, że takie łańcuchowe zależności są bardzo częste i ułatwiają złożenie działającego exploita.
Konkretny przypadek: w OpenSSH, które zapewnia bezpieczny zdalny dostęp do komputerów, Claude pomógł zidentyfikować skomplikowany kod obsługi podpisów, osiągalny zanim użytkownik się uwierzytelni — nawet gdy odpowiedni algorytm nie był w ogóle włączony. Ta praca zaowocowała zmianami w wersji 10.6: usunięto sporo kodu, do którego niezarejestrowany klient miał wcześniej dostęp. W gruncie rzeczy mniej linii kodu i mniej części programu na wyciągnięcie ręki gościa bez loginu — a to czyni całość bezpieczniejszą.
Dlatego nie uważam, że „łatajcie szybciej” to adekwatna odpowiedź na to, co się dzieje. Łatanie jest konieczne i przykład PHP jest tu znakomity, ale to nie wszystko. Musimy rozumieć swoje systemy — rozpoznawać te łańcuchowe zależności, które pozwalają złożyć exploit, a AI jest do tego potężnym narzędziem. Potem trzeba drążyć, weryfikować realne wektory ataku i proaktywnie ścinać powierzchnię, jeszcze zanim luki zostaną wykryte.
Jeśli prowadzisz takie usługi, musisz uruchomić swoje najlepsze myślenie. A jeśli zasiadasz w zarządzie, może to wymagać budżetu. Bank of America zarezerwował w samym ostatnim kwartale kilkaset milionów dolarów na zatrudnienie obrońców i naprawę takich błędów. To realna pozycja kosztowa wielkich firm — bo nie mogą sobie pozwolić na konsekwencje włamania.
Pułapka domyka się: najlepsza inteligencja po stronie obrony
Wrócę do tego, co powiedziałem na początku. Agenci są natywni dla komputerów — i wystawią nas, ludzi, którzy od dawna napisali mnóstwo złego kodu. Ich zdolność do badania, testowania i śledzenia powiązań to zarazem największy atut obrońcy i narzędzie atakujących. Chcę, żebyśmy najlepszą dostępną inteligencję oddawali obrońcom — żeby mieli narzędzia, których potrzebują, i chronili nas wszystkich w internecie.
Pięć kroków dla każdego
Na koniec wskazówki osobiste. Jeśli jesteś zwykłym użytkownikiem, oto pięć rzeczy, które możesz zrobić dla własnego bezpieczeństwa.
Po pierwsze: zaktualizuj przeglądarkę, telefon, systemy operacyjne i aplikacje. Dokończ wymagane restarty, bo dopiero wtedy łatki zaczynają działać. Gdy usłyszysz o kolejnym wycieku, poproś Claude’a albo Codexa o sprawdzenie aktualizacji w usługach, których to dotyczy.
Po drugie: otwórz ustawienia połączonych aplikacji na ważnych kontach — zacznij od poczty i plików. Usuń połączenia, z których nie korzystasz, i sprawdź, czy te zatrzymane robią tylko to, na co im pozwalasz. Ścinaj powierzchnię ataku.
Po trzecie: przejrzyj rozszerzenia przeglądarki. Nieużywane usuń, a pozostałym — tam, gdzie przeglądarka na to pozwala — ogranicz dostęp do konkretnych witryn.
Po czwarte: korzystaj z menedżera haseł, żeby każde konto miało inne, trudne do zapamiętania hasło, i włącz uwierzytelnianie dwuetapowe wszędzie, gdzie się da — ten dodatkowy krok logowania ratuje konto nawet przy wycieku hasła. Ustalcie też w rodzinie tajne hasło głosowe, żeby nie dać się nabrać na fałszywy głos bliskiej osoby.
Po piąte: gdy przyjdzie zawiadomienie o wycieku, sprawdź, co dokładnie wyciekło, i natychmiast zareaguj. Nie chowaj głowy w piasek. Zmień wykradzione hasła wszędzie, przejrzyj i cofnij dotknięte połączenia aplikacji, a jeśli jesteś programistą — wygeneruj od nowa wszystkie sekrety API. Przeczytaj komunikat do końca i wykonaj dalsze kroki, których wymagają twoje dane.
Dla budujących produkty i obrońców
Jeśli budujesz produkty: wybieraj szczerość wobec klientów. To się zwróci, obiecuję. Jeśli bronisz firmy — nie pozwól, żeby ten kryzys poszedł na marne. Na Substacku rozpisuję pełne śledztwo od początku do końca na przykładzie kompromitacji LiteLLM; może służyć wam jako poligon. Twój zespół może jeszcze w tym tygodniu przejść nim w środowisku testowym z różnymi modelami i sprawdzić, co działa u was. Są tam też scenariusze czterech rozmów, które musisz teraz odbyć: z radą nadzorczą, dyrektorem finansowym, inżynierią i dostawcami. Link w opisie — do zobaczenia następnym razem.