Złośliwy serwer może przechwycić dane uwierzytelniające OAuth w MCP Python SDK

Badacze bezpieczeństwa z Cycode odkryli podatność, dzięki której złośliwy serwer MCP może nakłonić SDK Python do wysłania danych uwierzytelniających do atakującego.

TLDR:

• Badacze z Cycode odkryli podatność w MCP Python SDK, która pozwala złośliwemu serwerowi MCP na przechwycenie danych uwierzytelniające OAuth i uzyskanie access tokenu ofiary.
• Atak wykorzystuje błąd w mechanizmie discovery: na ścieżce awaryjnej SDK pomija weryfikację tożsamości dostawcy logowania.
• Ofiara korzysta z prawdziwej strony logowania, dlatego atak może pozostać niezauważony. Przejęte dane pozwalają atakującemu działać w zakresie uprawnień przyznanych klientowi OAuth.
• Podatne są wersje MCP Python SDK od 1.9.1 do 1.29.1 oraz od 2.0.0 do 2.1.1. Luka otrzymała ocenę 7.5 w skali CVSS. Zalecana jest aktualizacja do wersji 2.2.0 lub nowszej z 2.x albo 1.30.0 lub nowszej z 1.x.

Model Context Protocol (MCP) to standard wprowadzony przez firmę Anthropic i przekazany Agentic AI Foundation (AAF), która go utrzymuje. Służy on do łączenia asystentów AI z zewnętrznymi narzędziami i źródłami danych.

Badacze przyjrzeli się MCP Python SDK (zestaw narzędzi programistycznych do wdrożenia integracji z MCP) i odkryli, że złośliwy serwer może przejąć proces uwierzytelniania użytkownika w zewnętrznej usłudze (przez OAuth). Mowa o wykradzeniu wartości client secret, authorization code oraz proof key. Umożliwiają one wykonywanie żądań do danej usługi tak, jakby robił to użytkownik na swoim koncie – ale jedynie w zakresie uprawnień nadanych przy autoryzacji OAuth.

Z poziomu użytkownika, widoczna będzie jedynie standardowa strona logowania oraz komunikat o awarii serwera MCP. Nie jest wymagana żadna dodatkowa interakcja poza zwykłym logowaniem przez OAuth.

Podatne są wersje SDK od 1.9.1 do 1.29.1 oraz od 2.0.0 do 2.1.1 dla trzech dostawców uwierzytelniania: OAuthClientProvider, ClientCredentialsOAuthProvider i PrivateKeyJWTOAuthProvider. Luka została oceniona na 7.5 w skali CVSS.

Gdy klient MCP łączy się z serwerem, SDK musi ustalić, gdzie wykonywane jest uwierzytelnienie. Dzieje się to za pomocą procesu discovery. W bezpiecznym wariancie serwer zwraca URL wskazujący dostawcę logowania (np. Google, Okta, Azure AD). Następnie SDK pobiera konfigurację dostawcy logowania z tego URL-a. Na koniec sprawdza, czy pole issuer w konfiguracji odpowiada adresowi URL uzyskanemu na początku.

Istnieje również ścieżka awaryjna. Jeśli pierwszy krok zakończy się niepowodzeniem (np. serwer zwróci błąd 404), SDK próbuje starszej metody discovery – odpyta o konfigurację logowania bezpośrednio serwer MCP. To właśnie ta ścieżka awaryjna powoduje cały problem.

W takiej ścieżce awaryjnej SDK nigdy nie otrzymuje adresu URL tak jak w standardowym mechanizmie, więc zmienna przechowująca go jest pusta. Kontrola z ostatniego kroku nigdy nie zostanie wykonana, bo przy ścieżce awaryjnej nie ma z czym porównać pola issuer.

Atakujący może więc skonfigurować złośliwy serwer, tak aby zwracał błąd 404 na zapytanie o serwer obsługujący logowanie. SDK przechodzi wtedy na ścieżkę awaryjną, pyta serwer atakującego bezpośrednio o konfigurację i akceptuje wszystko, co ten zwróci. Atakujący przejmuje więc kontrolę nad tym, na jakie adresy URL wysyłane są dane uwierzytelniające użytkownika.

Konfiguracja zwracana przez serwer atakującego zawiera URL prawdziwej strony logowania dostawcy takiego jak np. Google czy Okta. Użytkownik wchodzi więc na autentyczną stronę, bez żadnych cech phishingu. Po zatwierdzeniu authorization code wraca do SDK, które wraz z wartością client secret i kluczem proof key wysyła go do endpointu dostawcy logowania… wskazanego przez serwer atakującego.

Oznacza to, że atakujący może przejąć te wartości, a następnie wysłać je do dostawcy uwierzytelniania i otrzymać ważny access token. Możliwości, jakie dzięki niemu zyskuje, zależą od zakresów uprawnień (scopes) przyznanych klientowi OAuth. Jeśli użytkownik udzielił szerokich uprawnień – np. dostęp do maila czy plików w chmurze – atakujący otrzymuje każde z nich.

Ofiara nie otrzymuje żadnego sygnału. Nic w procesie logowania nie wygląda nieprawidłowo. Nie ma powiadomienia o nieudanym logowaniu ani podejrzanym IP. Atakujący uwierzytelnił się przy użyciu prawidłowego client secret, ważnego authorization code oraz prawidłowego PKCE proof key. Z perspektywy dostawcy uwierzytelniania jest to prawidłowe logowanie.

Badacze zgłosili podatność zespołowi MCP firmy Anthropic i została ona załatana. Użytkownikom i programistom polecamy więc zaktualizować MCP Python SDK do wersji 2.2.0 (dla wersji 2.x), 1.30.0 (dla wersji 1.x) lub nowszej. W poprawionych wersjach SDK ustala, którego dostawcy logowania oczekuje, zanim pobierze jakąkolwiek konfigurację, odrzuca dane od innego dostawcy i oznacza zapisane dane uwierzytelniające etykietą dostawcy.

Badacze wskazali, że samo zaktualizowanie SDK nie rozwiązuje problemu w pełni. Jeśli aplikacja korzysta z wstępnie skonfigurowanych danych uwierzytelniających (pre-provisioned credentials) – należy także zdefiniować pole issuer w ClientCredentialsOAuthProvider lub PrivateKeyJWTOAuthProvider podając URL tego dostawcy. Parametr ten będzie wymagany od wersji 3.0, a jego brak spowoduje wyrzucenie ostrzeżenia.

Warto także wyczyścić zapisane rejestracje – te zapisane przez starsze wersje nie mają etykiety issuer i mogą pozostać niezwiązane z konkretnym dostawcą. Wyczyszczenie i dodanie na nowo sprawi, że użytkownicy będą logować się już naprawioną ścieżką z przypisaniem parametru issuer.

Źródło: cycode.com

~Tymoteusz Jóźwiak