GitHub MCP pomaga wykradać dane z prywatnych repozytoriów – kolejna sprytna technika prompt injection w wydaniu indirect

W naszym ostatnim tekście przybliżyliśmy problemy opisane przez firmę Legit, które pozwalały na wykorzystanie asystenta Duo do kradzieży poufnych informacji z prywatnych repozytoriów lub zmuszania modelu LLM do wykonywania niepożądanych przez prawowitego właściciela projektu działań. Jak można się było domyślić, poruszana tematyka jest związana raczej z architekturą rozwiązań niż z konkretnym produktem, dlatego na podobne podatności nie trzeba było długo czekać.

Tym razem na warsztat badaczy z firmy Invariantlabs, trafił projekt GitHub MCP Server. Jest to oficjalny serwer zgodny z Model Context Protocol. Pokrótce – MCP pozwala na rozszerzanie możliwości dużych modeli językowych przez zunifikowany interfejs, który umożliwia wykorzystanie zewnętrznych narzędzi (takich jak bazy danych, interfejsy programistyczne etc.). Dzięki temu model LLM to nie tylko chat, ale prawowity agent, który potrafi np. sprawdzić prognozę pogody, wyciągnąć informacje z bazy Redis czy dokonać analizy zdekompilowanego kodu. W przypadku tego konkretnego serwera MCP możliwe jest budowanie narzędzi opartych o duże modele językowe, które współpracują z ekosystemem GitHuba – co może stanowić wygodne rozwiązanie dla developerów.

W przytoczonym artykule zaprezentowano atak, który można określić jako indirect prompt injection, lub jak określają autorzy, toxic agent flow. Generalna idea ataku jest taka, że atakujący zamieszczając prompt w publicznym repozytorium (np. jako issue), zmusza model (który działając w kontekście użytkownika-ofiary, ma dostęp zarówno do publicznych jak i prywatnych zasobów) do złośliwego zachowania i doprowadzenia do wycieku informacji o niejawnych repozytoriach. Schemat ataku został przedstawiony na poniższej grafice:

Jako przykład, zademonstrowano spreparowane issue, które skłania do rozszerzenia sekcji README publicznego projektu. 

W przypadku gdy właściciel repozytorium korzysta z serwera MCP GitHuba, np. w postaci wtyczki do VS Code, będzie on mógł rozwiązać to issue w sposób zautomatyzowany. Najczęściej operacje realizowane przez MCP wymagają zatwierdzenia. 

Jednak autorzy znaleziska słusznie zauważają, że częste wywoływanie narzędzi MCP może skłonić użytkowników, do wybrania opcji “pozwalaj zawsze” – to znaczy, że operacje wykonywane przez narzędzie wykorzystujące MCP nie będzie każdorazowo zatwierdzane przez użytkownika. Przykładowe issue spowodowało wygenerowanie commita zawierającego informacje wyciągnięte z prywatnych repozytoriów użytkownika.

Jak się przed tym bronić? Cóż, jak zaznaczyliśmy na wstępie, ta klasa błędów jest stosunkowo trudna do wyeliminowania w całości (tak samo jak zwykły prompt injection). Rozsądne wydaje się przede wszystkim ograniczenie zakresu danych do jakich model ma dostęp. Oprócz tego dobrze byłoby monitorować wywołanie poszczególnych funkcji MCP i w razie wykrycia niepożądanych akcji podejmować działania. Jedno jest pewne – i tutaj zgadzamy się z badaczami – zabezpieczenia MCP muszą być realizowane na poziomie systemu, sam alignment i zabezpieczenia modelu nie rozwiążą tego problemu.

A Wy, wspomagacie się w swojej pracy MCP?

~Black Hat Logan