Wraz z dynamicznym rozwojem sztucznej inteligencji agenci AI stają się nieodłącznym elementem pracy wielu deweloperów. Rozwiązania takie jak Amazon Q Developer, OpenAI Codex czy GitHub Copilot potrafią generować kod, analizować błędy, sugerować poprawki, a nawet wykonywać zadania bezpośrednio z poziomu środowiska programistycznego. Aby było to możliwe, muszą zostać głęboko zintegrowane z narzędziami wykorzystywanymi przez programistów oraz uzyskać dostęp do lokalnego środowiska pracy.

Autor: 9 min czytania

To właśnie ten poziom integracji sprawia, że ewentualne podatności w agentach AI mogą mieć znacznie poważniejsze konsekwencje niż klasyczne błędy aplikacji. Przypadek opisany przez badaczy z Wiz pokazuje, że otwarcie odpowiednio przygotowanego repozytorium mogło doprowadzić do uruchomienia złośliwego kodu, a w konsekwencji uzyskania dostępu do poświadczeń chmurowych, kluczy API oraz innych danych dostępnych dla użytkownika.

Amazon Q Developer

Amazon Q Developer to agent AI opracowany przez Amazon Web Services (AWS), w pełni udostępniony w kwietniu 2024 roku. Oprócz funkcji obecnych w wielu innych narzędziach wspierających programowanie opartych na sztucznej inteligencji, takich jak generowanie kodu czy analiza błędów, jego głównym zadaniem jest wspieranie użytkowników podczas projektowania, budowy, rozwijania oraz utrzymania aplikacji i środowisk działających w chmurze AWS.

Asystent pozwala na zadawanie pytań dotyczących architektury AWS, najlepszych praktyk czy sposobu realizacji konkretnych zadań związanych z projektowaniem środowisk chmurowych. Potrafi również analizować zasoby znajdujące się na koncie AWS, pomagać w optymalizacji kosztów oraz generować skrypty wykorzystujące AWS CLI i AWS SDK.

Tak szeroki zakres możliwości oznacza jednak, że agent operuje na danych i zasobach, do których dostęp posiada jego użytkownik. W praktyce mogą to być informacje o infrastrukturze, poświadczenia do usług AWS czy lokalne pliki projektu. Dostęp do większości z tych zasobów wymaga świadomej zgody użytkownika lub odpowiedniej konfiguracji.

Wyjątek stanowił jednak mechanizm wykorzystywany przez Model Context Protocol (MCP). Jak wykazali badacze z Wiz, odpowiednio przygotowana konfiguracja mogła spowodować automatyczne uruchomienie złośliwego serwera MCP po otwarciu projektu. W efekcie mechanizm ten stał się źródłem opisanej podatności.

Model Context Protocol (MCP)

Model Context Protocol (MCP) to otwarty standard opracowany przez firmę Anthropic, którego zadaniem jest ujednolicenie komunikacji pomiędzy agentami AI a narzędziami zewnętrznymi. Został zaprezentowany pod koniec 2024 roku i bardzo szybko zaczął pojawiać się w kolejnych rozwiązaniach wykorzystujących sztuczną inteligencję.

Jeszcze do niedawna każdy producent rozwijający własnego agenta musiał przygotowywać osobne integracje z GitHubem, bazami danych, usługami chmurowymi czy systemami do zarządzania projektami. Oznaczało to mnóstwo powielanej pracy i konieczność utrzymywania wielu podobnych integracji.

MCP miało to uprościć. Zamiast tworzyć dedykowane połączenie dla każdego modelu AI, wystarczy udostępnić serwer MCP opisujący dostępne funkcje. Następnie każdy agent zgodny ze standardem może z nich korzystać bez konieczności pisania własnej integracji od zera.

Z punktu widzenia użytkownika cały mechanizm pozostaje praktycznie niewidoczny. Programista korzysta z Amazon Q, Claude Desktop czy innego agenta AI, a ten w razie potrzeby komunikuje się z odpowiednimi serwerami MCP, uzyskując dostęp np. do repozytorium Git, lokalnych narzędzi, usług AWS czy baz danych.

Sam Model Context Protocol nie stanowi podatności. Problemem okazał się sposób, w jaki Amazon Q Developer obsługiwał konfigurację serwerów MCP zapisaną w projekcie otwieranym przez użytkownika.

Przebieg ataku

W momencie otwarcia projektu w Visual Studio Code z zainstalowanym rozszerzeniem Amazon Q Developer, aplikacja automatycznie odczytuje konfigurację serwerów MCP zapisaną w projekcie. W podatnych wersjach rozszerzenia czynność ta wykonywana była bez wyświetlenia użytkownikowi okna z prośbą o zgodę lub potwierdzenie uruchomienia nowego serwera.

Jeżeli plik konfiguracyjny zawiera jedynie zaufane wpisy przygotowane przez autora projektu, cały mechanizm działa zgodnie z przeznaczeniem. Problem pojawia się w momencie, gdy konfiguracja zostanie zmodyfikowana przez atakującego i zamiast wskazywać na zaufany serwer MCP, będzie zawierała polecenie uruchamiające dowolny proces na komputerze ofiary.

Rysunek 1 Przykład normalnego pliku konfiguracyjnego MCP. Źródło: wiz.io

W praktyce mamy tutaj do czynienia z dwoma głównymi problemami.

Pierwszym z nich jest automatyczne ładowanie plików mcp.json znajdujących się w projekcie. W podatnych wersjach Amazon Q Developer odbywało się to bez jakiejkolwiek zgody użytkownika. Rozszerzenie nie wyświetlało komunikatu z prośbą o potwierdzenie uruchomienia nowego serwera MCP ani nie wykorzystywało mechanizmu Workspace Trust, którego zadaniem jest ograniczenie wykonywania potencjalnie niebezpiecznych operacji w niezaufanych projektach.

Drugim problemem był zakres uprawnień otrzymywanych przez proces uruchamiany przez Amazon Q. Nowo utworzony proces dziedziczył pełne środowisko użytkownika, w tym wszystkie zmienne środowiskowe dostępne w jego sesji. W przypadku programistów pracujących z usługami chmurowymi mogą znajdować się tam między innymi poświadczenia AWS, tokeny uwierzytelniające, klucze API czy inne poufne dane wykorzystywane podczas codziennej pracy.

W opublikowanym przez badaczy Wiz Proof of Concept cały scenariusz został pokazany na prostym przykładzie. Wystarczy, że ofiara sklonuje przygotowane przez atakującego repozytorium zawierające zmodyfikowany plik .amazonq/mcp.json, otworzy je w Visual Studio Code i uruchomi Amazon Q Developer. Rozszerzenie automatycznie odczyta konfigurację, uruchomi zdefiniowane w niej polecenie i przekaże mu uprawnienia aktualnie zalogowanego użytkownika.

Rysunek 1 Spreparowane przez badaczy Wiz repozytorium zawierające złośliwie zmodyfikowany plik mcp.json. Źródło: wiz.io
Rysunek 1 Zawartość zmodyfikowanego pliku mcp.json. Źródło: wiz.io

W przedstawionej sytuacji po wczytaniu zmodyfikowanej konfiguracji Amazon Q Developer uruchamia polecenie zdefiniowane w pliku mcp.json. W zaprezentowanym przez badaczy przykładzie jest to wywołanie interpretera bash, który wykonuje komendę aws sts get-caller-identity, a następnie przesyła jej wynik na kontrolowany przez badaczy serwer exfil.attacker.test.

Przygotowany przez badaczy Wiz Proof of Concept nie wykonuje żadnych destrukcyjnych działań. Jego celem było jedynie potwierdzenie, że uruchomiony proces działa z uprawnieniami aktualnie zalogowanego użytkownika i ma dostęp do jego aktywnej sesji AWS. W rzeczywistym scenariuszu zamiast nieszkodliwej komendy zwracającej informacje o tożsamości użytkownika atakujący mógłby wykonać dowolne polecenie działające z uprawnieniami ofiary.

Przypadek Amazon Q Developer nie jest odosobniony. Coraz więcej podatności związanych z AI nie wynika z błędów samych modeli językowych, lecz z mechanizmów budowanych wokół nich. Integracje z zewnętrznymi usługami, automatyzacja wykonywanych działań czy nadmierne zaufanie do danych dostarczanych przez użytkownika stają się nową powierzchnią ataku. O podobnych przypadkach pisaliśmy już wcześniej przy okazji Meta AI Support Assistant oraz zagrożeń związanych z koncepcją Shadow AI Risk.

Podsumowanie

Amazon zareagował na zgłoszenie badaczy bardzo szybko i podatność została usunięta jeszcze przed jej publicznym ujawnieniem. Aktualne wersje Amazon Q Developer wymagają już świadomej zgody użytkownika przed uruchomieniem serwera MCP zdefiniowanego w otwieranym projekcie.

Trudno jednak przypuszczać, że będzie to ostatni przypadek tego typu. Agenci AI otrzymują coraz większe możliwości i coraz głębszą integrację z lokalnym środowiskiem pracy, usługami chmurowymi czy narzędziami wykorzystywanymi przez programistów. Wraz z rozwojem tych mechanizmów będą pojawiać się również nowe klasy podatności, których źródłem nie będzie klasyczny błąd aplikacji, lecz sposób, w jaki agent AI interpretuje konfigurację i wykonuje operacje w imieniu użytkownika.

Przypadek Amazon Q Developer pokazuje, że bezpieczeństwo agentów AI zaczyna być równie istotne jak bezpieczeństwo samych aplikacji. Wszystko wskazuje na to, że podobnych podatności będziemy obserwować coraz więcej, a ich analiza w najbliższych latach stanie się jednym z ważniejszych obszarów badań nad bezpieczeństwem sztucznej inteligencji.