Przejdź do treści

Szukaj w Security Magazine

Szukaj w Security Magazine

NewsletterNewsletter
Menu

Kampania Cairn: agenci AI i błędy aplikacji webowych

Agenci AI samodzielnie szukali w sklepach internetowych znanych klas błędów aplikacji webowych i zostawiali w nich web shelle. Firma NorForge opisała kampanię, w której jeden operator uruchomił przez platformę Cairn ponad 1 100 autonomicznych projektów ataku na sklepy w USA, Kanadzie, Japonii i Australii; według Reuters włamania dotknęły ponad 100 firm. Udane włamanie zajmowało agentom średnio niecałe 23 godziny. Dotyczy to firm z publiczną aplikacją e-commerce lub płatniczą, zwłaszcza na popularnych platformach sklepowych.

Ściana identycznych stalowych skrytek, jedna uchylona, ze smugą ciepłego światła na podłodze.
W tym tekście (5)

Co ustalili badacze

Badacze NorForge natrafili na ponad 20 niezabezpieczonych paneli administracyjnych platformy Cairn - otwartego narzędzia agentowego, które po zadaniu celu samo koordynuje agentów AI szukających drogi do włamania. Panele były wystawione do internetu bez uwierzytelnienia, więc badacze mogli obserwować działania napastników na żywo.

Najaktywniejszy operator, posługujący się językiem chińskim, prowadził ponad 1 100 projektów na 14 panelach. Według NorForge motywacja była finansowa, bez oznak działania sterowanego przez państwo. Dobór celów był zautomatyzowany: strony szeregowano według natężenia ruchu (od 200 tys. do 1,5 mln odwiedzin), a następnie sprawdzano narzędziem Playwright, czy umożliwiają składanie zamówień.

Agentom zlecano znalezienie podatności prowadzących do zdalnego wykonania kodu: SQL injection, niebezpiecznych uploadów plików, deserializacji, obejść uwierzytelniania, server-side template injection (SSTI) i server-side request forgery (SSRF). Po udanym włamaniu agent zostawiał tak zwany uploader shell - prosty web shell do wgrywania kolejnych plików. NorForge potwierdziło, że co najmniej jeden taki web shell działał na stronie realnego sprzedawcy.

Ataki wykorzystywały znane klasy błędów; uwagę zwracają skala automatyzacji i szacowane koszty. NorForge szacuje orientacyjnie, że dla obserwowanych kampanii skuteczność wynosi około 10 proc., i zastrzega, że definicje sukcesu w poszczególnych grupach się różnią. Udane włamanie zajmowało średnio niecałe 23 godziny samodzielnego sondowania. Koszt jednego zadania badacze szacują na około 5 dolarów, z zastrzeżeniem dużej niepewności; w przeliczeniu na udane włamanie Snorre Fagerland z NorForge podał Reuters szacowany koszt tokenów rzędu 50 dolarów.

Wpływ na biznes

Nie chodzi o pojedynczą lukę z numerem CVE i łatką, lecz o to, że sondowanie aplikacji pod kątem znanych błędów stało się tanie i samoobsługowe. Kiedy jedna próba kosztuje kilka dolarów i nie wymaga eksperta przy klawiaturze, opłaca się atakować też firmy wcześniej uznawane za zbyt małe. To przesuwa próg „kto jest wart ataku", a nie listę zagrożeń.

Pilność jest wysoka dla firm z publiczną aplikacją e-commerce lub płatniczą. Wśród narzędzi agenta badacze znaleźli środowisko testowe platformy Magento i artefakty frameworka Odoo, co świadczy o zainteresowaniu tymi technologiami. Ryzyko zależy od tego, co firma wystawia do internetu i jak jest to zabezpieczone, a nie od samej branży: celem bywa też zaplecze. Jedna z firm wskazanych przez Reuters badała doniesienie o potencjalnym ataku na stronę prowadzoną przez jej zewnętrznego dostawcę. Według Reuters doszło do włamań na strony internetowe ponad 100 firm; nie oznacza to potwierdzonego przejęcia ich głównych systemów ani ustalonego zakresu kradzieży danych.

Osobne ryzyko dotyczy samych testów bezpieczeństwa. Obserwowane panele ujawniały setki sekretów, z których 11 proc. zweryfikowano jako nadal ważne, a badacze trafili tą drogą także na panele legalnych zespołów pentesterskich z danymi ich klientów. Prowadzenie testu z użyciem niezabezpieczonego panelu może ujawnić poufne dane niezależnie od wyniku testu.

Rekomendacje: obrona aplikacji webowych

Obrona nie polega na „AI kontra AI". Kampania wykorzystywała znane klasy błędów, więc priorytetem są podstawy bezpieczeństwa aplikacji i wykrywanie incydentów. Kolejność działań warto uzależnić od ekspozycji, znanych podatności i znaczenia systemu, a nie od samej wielkości czy branży firmy.

DZIŚ:

  • Zinwentaryzować wszystkie aplikacje webowe wystawione do internetu, w tym panele logowania, portale dostawców i strony prowadzone przez zewnętrznych wykonawców - to one były punktem wejścia.
  • Unieważnić klucze API, tokeny i inne sekrety, które mogły zostać ujawnione - to one wyciekały z obserwowanych paneli.
  • Sprawdzić, czy w katalogach aplikacji nie pojawiły się nieznane pliki skryptowe o niepozornych nazwach, zdolne przyjmować wgrywane pliki - typowy ślad opisanego web shella.
  • Jeśli firma lub jej dostawca używa narzędzi AI do testów bezpieczeństwa, ograniczyć dostęp do ich paneli do uprawnionych osób i wymagać uwierzytelnienia - to z takich paneli wyciekały sekrety i dane klientów.

W TYM TYGODNIU:

  • Zlecić zespołowi lub dostawcy przegląd aplikacji transakcyjnych pod kątem wymienionych wyżej klas błędów: SQL injection, kontroli uploadu plików, deserializacji, obejść uwierzytelniania, SSTI i SSRF.
  • Przejrzeć monitoring pod kątem anomalii: pojedynczy cel był sondowany przez wiele godzin, więc długie serie nietypowych żądań to sygnał do reakcji.
  • Zweryfikować u dostawcy testów penetracyjnych, jakich narzędzi używa i gdzie przechowuje wyniki oraz przekazane mu sekrety.

DO ZAPLANOWANIA:

  • Wdrożyć ciągłe, a nie jednorazowe testowanie powierzchni ataku i skrócić czas między wykryciem a załataniem podatności.
  • Objąć aktualizacje platform sklepowych i ich komponentów regularnym harmonogramem.

Podsumowanie

Kampania Cairn daje nietypowo szczegółowy wgląd w to, jak agenci AI samodzielnie prowadzą włamania - przy niskim szacowanym koszcie i dużej liczbie równoległych zadań. Dla firmy z aplikacją webową oznacza to, że mały rozmiar nie powinien być argumentem za odkładaniem zabezpieczeń. Według raportów z 19-20 października 2026 r. panele częściowo nadal działają, trwa powiadamianie ofiar oraz podejmowane są próby wyłączenia paneli.

Pytania, na które zarząd powinien znać odpowiedź:

  • Które z naszych aplikacji webowych są wystawione do internetu i kiedy ostatnio były testowane pod kątem powszechnych klas błędów?
  • Czy nasz dostawca stron i testów bezpieczeństwa używa narzędzi AI z panelem webowym i gdzie trafiają nasze dane z tych testów?

Źródła