Claude Code pod presją: ukryte przejęcie MCP umożliwia kradzież tokenów OAuth - Security Bez Tabu

Claude Code pod presją: ukryte przejęcie MCP umożliwia kradzież tokenów OAuth

Cybersecurity news

Wprowadzenie do problemu / definicja

Bezpieczeństwo agentów AI wykorzystywanych w procesie tworzenia oprogramowania staje się jednym z kluczowych tematów dla zespołów DevSecOps. Najnowszy opisywany scenariusz pokazuje, że środowisko Claude Code może zostać wykorzystane do cichego przechwytywania tokenów OAuth poprzez manipulację konfiguracją MCP, czyli warstwy odpowiedzialnej za komunikację z narzędziami i usługami zewnętrznymi.

Problem nie ogranicza się wyłącznie do samej aplikacji. Dotyczy całego łańcucha zaufania obejmującego lokalne pliki konfiguracyjne, integracje SaaS, mechanizmy autoryzacji oraz zależności instalowane na stacji roboczej programisty.

W skrócie

  • Atakujący może przejąć ruch MCP i działać jako pośrednik między Claude Code a legalnym serwerem integracyjnym.
  • Celem operacji jest pozyskanie tokenów OAuth dających dostęp do podłączonych usług.
  • Wektor ataku wykorzystuje modyfikację lokalnej konfiguracji oraz złośliwy pakiet npm z mechanizmem postinstall.
  • Przejęcie może utrzymywać się po rotacji tokenu i nie musi generować widocznych alertów.
  • Skutki mogą objąć repozytoria kodu, systemy CI/CD, platformy komunikacyjne i inne usługi biznesowe.

Kontekst / historia

Claude Code to narzędzie agentowe wspierające programistów w pracy z kodem oraz integracjami zewnętrznymi. W tego typu architekturach istotną rolę odgrywają serwery MCP, które pośredniczą w dostępie do funkcji, narzędzi i usług. Oznacza to, że kompromitacja konfiguracji lub przepływu autoryzacji może przełożyć się na dostęp do wielu systemów jednocześnie.

Scenariusz został nagłośniony przez badaczy Mitiga Labs, którzy wskazali, że tokeny OAuth oraz konfiguracja MCP mogą być przechowywane lokalnie w plikach użytkownika. Jeżeli przeciwnik zyska możliwość zmiany tych ustawień, może przekierować komunikację przez kontrolowaną przez siebie infrastrukturę i przechwycić dane uwierzytelniające bez zakłócania pozornego działania aplikacji.

To ważny sygnał dla rynku: nowoczesne narzędzia AI coraz częściej łączą w jednym przepływie roboczym kod źródłowy, tożsamość użytkownika, automatyzację i dostęp do usług trzecich. W efekcie pojedynczy punkt kompromitacji może mieć znaczenie porównywalne z przejęciem konta uprzywilejowanego.

Analiza techniczna

Technicznie atak opiera się na dwóch podstawowych warunkach. Po pierwsze, napastnik musi doprowadzić do instalacji odpowiednio przygotowanego pakietu npm w środowisku, w którym Claude Code korzysta z dynamicznie autoryzowanych serwerów MCP. Po drugie, pakiet wykorzystuje hook postinstall, aby uruchomić dodatkową logikę bez potrzeby dalszej interakcji użytkownika.

Po instalacji złośliwy komponent może przeszukiwać typowe lokalizacje repozytoriów i modyfikować ustawienia zaufania, aby ograniczyć ryzyko pojawienia się ostrzeżeń. Następnie atakujący zmienia lokalny plik konfiguracyjny i dodaje lub podmienia adres serwera MCP na infrastrukturę pośredniczącą kontrolowaną przez siebie.

Od tego momentu inicjalizacja oraz odświeżanie sesji MCP może przebiegać przez serwer proxy napastnika. W praktyce jest to wariant ataku man-in-the-middle osadzony w legalnym przepływie aplikacyjnym. Użytkownik nadal widzi pozornie poprawny proces logowania i komunikacji, podczas gdy token OAuth trafia równolegle do infrastruktury przeciwnika.

Szczególnie groźna jest trwałość tego mechanizmu. Nawet jeśli ofiara ręcznie poprawi konfigurację lub przeprowadzi rotację tokenu, złośliwa logika może ponownie zapisać niepożądane ustawienia przy kolejnym uruchomieniu albo odświeżeniu środowiska. Taka persystencja sprawia, że przejęcie nie musi być jednorazowe i może być automatycznie odnawiane.

Dodatkowym zagrożeniem jest zakres uprawnień przechwyconego tokenu. Jeżeli zapewnia on dostęp do wielu usług SaaS zintegrowanych przez MCP, napastnik może uzyskać funkcjonalny odpowiednik uprzywilejowanego klucza sesyjnego. W praktyce może to oznaczać obejście ochron opartych na MFA, ponieważ celem staje się już wydany token, a nie sam proces logowania.

Konsekwencje / ryzyko

Ryzyko operacyjne jest wysokie, ponieważ skutki takiego incydentu wykraczają poza pojedynczą stację roboczą. Przejęty token może otworzyć drogę do repozytoriów kodu, systemów zgłoszeń, narzędzi CI/CD, platform komunikacyjnych oraz innych usług wykorzystywanych w codziennej pracy zespołów developerskich.

W zależności od zakresu przyznanych uprawnień możliwe stają się kradzież kodu źródłowego, manipulacja pipeline’ami, eksfiltracja danych, nadużycia w środowisku SaaS oraz dalszy ruch boczny w organizacji. To szczególnie niebezpieczne w firmach, gdzie narzędzia agentowe mają szeroki dostęp do zasobów produkcyjnych lub półprodukcyjnych.

Istotnym problemem pozostaje także niska wykrywalność. Ruch może wyglądać jak prawidłowa komunikacja aplikacji z serwerami integracyjnymi, a użytkownik nie musi zobaczyć żadnych alarmujących komunikatów. Dla zespołów SOC oznacza to konieczność monitorowania nie tylko aktywności w usługach końcowych, ale również zmian w lokalnej konfiguracji narzędzi AI i ich zależności.

Rekomendacje

Organizacje korzystające z agentów AI w procesie developerskim powinny wdrożyć kontrolę integralności lokalnych plików konfiguracyjnych, zwłaszcza tych przechowujących definicje serwerów MCP, ustawienia zaufania oraz dane autoryzacyjne. Każda nieautoryzowana zmiana takich plików powinna generować alert i zostać objęta analizą bezpieczeństwa.

Należy także ograniczyć możliwość instalowania niezweryfikowanych pakietów npm i tam, gdzie to możliwe, blokować wykonywanie ryzykownych hooków lifecycle. W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto stosować prywatne rejestry pakietów, allowlisting zależności oraz izolowane stacje robocze dla programistów.

Ważną praktyką jest minimalizacja uprawnień tokenów OAuth oraz skracanie ich czasu życia. Im mniejszy zakres dostępu i krótsza ważność tokenu, tym niższy wpływ potencjalnego przejęcia. Dobrą praktyką pozostaje również przechowywanie sekretów w bezpiecznych magazynach poświadczeń zamiast w prostych lokalnych plikach tekstowych.

Po stronie monitoringu należy obserwować zmiany adresów serwerów MCP, nietypowe odświeżenia tokenów, anomalie w ruchu wychodzącym oraz niespodziewane wywołania API w zintegrowanych usługach SaaS. Skuteczne może być korelowanie telemetrii endpointowej z logami dostawców chmurowych i aplikacyjnych.

W reakcji na incydent zalecane są:

  • przegląd lokalnych plików konfiguracyjnych i wpisów MCP,
  • unieważnienie aktywnych tokenów OAuth oraz ponowne wystawienie poświadczeń,
  • weryfikacja ostatnio instalowanych pakietów i skryptów postinstall,
  • analiza historii zmian w repozytoriach i integracjach SaaS,
  • traktowanie narzędzi agentowych jako zasobów uprzywilejowanych wymagających osobnego hardeningu.

Podsumowanie

Przypadek ukrytego przejęcia MCP w Claude Code pokazuje, że bezpieczeństwo narzędzi AI nie kończy się na modelu ani interfejsie użytkownika. Kluczowe znaczenie mają lokalne pliki konfiguracyjne, integracje SaaS, tokeny OAuth oraz łańcuch dostaw pakietów.

Opisany scenariusz łączy cechy ataku supply chain, lokalnej persystencji i man-in-the-middle. Jego skuteczność wynika z cichego charakteru operacji oraz zaufania do legalnego przepływu pracy. Dla zespołów bezpieczeństwa to wyraźny sygnał, że narzędzia agentowe używane przez programistów powinny być objęte równie rygorystyczną ochroną jak inne systemy uprzywilejowane.

Źródła

  1. SecurityWeek — Claude Code OAuth Tokens Can Be Stolen Through Stealthy MCP Hijacking — https://www.securityweek.com/claude-code-oauth-tokens-can-be-stolen-through-stealthy-mcp-hijacking/
  2. Mitiga — Technical write-up on Claude Code MCP hijacking research — https://www.mitiga.io/
  3. OAuth 2.0 Authorization Framework — https://datatracker.ietf.org/doc/html/rfc6749