Lỗ hổng nghiêm trọng trong MCP Python SDK: Nguy cơ đánh cắp thông tin xác thực OAuth

• Bản chất lỗ hổng: Lỗi logic trong việc xác thực máy chủ ủy quyền (authorization server) cho phép kẻ tấn công chuyển hướng luồng xác thực OAuth.
• Tác động: Kẻ tấn công có thể đánh cắp client secret, mã ủy quyền (authorization code) và PKCE proof key để chiếm đoạt quyền truy cập dịch vụ.
• Phạm vi ảnh hưởng: Các ứng dụng sử dụng MCP Python SDK phiên bản 1.x (1.9.1 - 1.29.1) và 2.x (2.0.0 - 2.1.1).
• Khuyến nghị: Nâng cấp ngay lên phiên bản 1.30.0 hoặc 2.2.0 và cấu hình tham số issuer= cho các provider bị ảnh hưởng.

1. Bối cảnh & Tổng quan

Model Context Protocol (MCP) là một tiêu chuẩn mở quan trọng được thiết kế để kết nối các ứng dụng AI với các công cụ và nguồn dữ liệu bên ngoài. Tuy nhiên, một lỗ hổng logic nghiêm trọng đã được phát hiện trong MCP Python SDK, cho phép các máy chủ MCP độc hại đánh cắp thông tin xác thực OAuth từ các ứng dụng khách (client) tin cậy.

Lỗ hổng này đặc biệt nguy hiểm vì nó nhắm trực tiếp vào cơ chế trao đổi token OAuth, vốn là xương sống của việc xác thực trong các hệ thống tích hợp AI. Theo báo cáo từ công ty bảo mật Cycode, kẻ tấn công có thể thực hiện hành vi chiếm đoạt thông tin mà không cần sự can thiệp phức tạp, gây rủi ro lớn cho các hệ thống tự động hóa (machine-to-machine).

2. Phân tích Kỹ thuật & Chuỗi Khai thác

Nguyên nhân gốc rễ của lỗ hổng nằm ở việc thiếu kiểm tra tính hợp lệ của máy chủ ủy quyền (authorization server) trong quá trình thiết lập kết nối. Khi một MCP client cố gắng xác thực, nó sẽ truy vấn máy chủ MCP để tìm vị trí của dịch vụ đăng nhập. Các phiên bản bị ảnh hưởng đã không thực hiện xác thực chéo (cross-check) phản hồi này.

Chuỗi tấn công (Kill Chain)

• Bước 1 (T1190 - Exploit Public-Facing Application): Kẻ tấn công thiết lập một máy chủ MCP độc hại và dụ dỗ ứng dụng khách kết nối tới.
• Bước 2 (T1555 - Credentials from Password Stores): Khi client gửi yêu cầu xác thực, máy chủ độc hại cung cấp thông tin máy chủ ủy quyền giả mạo (hoặc chính máy chủ của kẻ tấn công).
• Bước 3 (T1567 - Exfiltration Over Web Service): Ứng dụng khách vô tình gửi client secret, authorization code và PKCE proof key trực tiếp tới endpoint do kẻ tấn công kiểm soát.
• Bước 4 (T1550 - Use Alternate Authentication Material): Kẻ tấn công sử dụng các thông tin đánh cắp được để yêu cầu token truy cập hợp lệ từ dịch vụ thực tế, từ đó chiếm quyền truy cập vào tài nguyên của nạn nhân.

Đáng chú ý, việc đánh cắp PKCE proof key vô hiệu hóa hoàn toàn cơ chế bảo vệ chống lại việc tái sử dụng mã ủy quyền, khiến cho các biện pháp bảo mật tiêu chuẩn trở nên vô hiệu.

3. Bảng tổng hợp phiên bản ảnh hưởng

4. Hướng dẫn Khắc phục & Hardening

Việc nâng cấp SDK là bước bắt buộc, nhưng chưa đủ đối với một số cấu hình cụ thể. Người dùng cần thực hiện các bước sau để đảm bảo an toàn tuyệt đối:

• Nâng cấp SDK: Cập nhật lên phiên bản 1.30.0 (cho dòng 1.x) hoặc 2.2.0 (cho dòng 2.x).
• Cấu hình Issuer: Đối với ClientCredentialsOAuthProvider hoặc PrivateKeyJWTOAuthProvider, bạn phải truyền tham số issuer= để chỉ định rõ máy chủ ủy quyền hợp lệ.
• Xoá đăng ký cũ: Sau khi nâng cấp, hãy xoá các đăng ký OAuth client cũ vì chúng không được liên kết với một issuer cụ thể.
• Rotate Credentials: Nếu nghi ngờ đã từng kết nối với máy chủ không tin cậy, hãy thực hiện xoay vòng (rotate) client secret và thu hồi các token hiện có tại dịch vụ xác thực.

⚠️ Cảnh báo quan trọng: Các phiên bản cũ không có cơ chế giảm thiểu (workaround) nào khác ngoài việc chỉ kết nối với các máy chủ MCP mà bạn hoàn toàn tin tưởng. Việc sử dụng RFC7523OAuthClientProvider (đã lỗi thời) cần được loại bỏ ngay lập tức vì nó không hỗ trợ tham số issuer=.

5. Kết luận

Lỗ hổng này là một lời nhắc nhở về tầm quan trọng của việc xác thực đầu vào trong các giao thức tích hợp AI. Các kỹ sư cần tuân thủ nguyên tắc Zero Trust khi kết nối với các máy chủ MCP bên thứ ba. Để biết thêm chi tiết kỹ thuật, bạn có thể tham khảo tài liệu từ GitHub chính thức của MCP Python SDK.