Home Blackhat Asia 2026 - Remote Server, Local Root. Welcome to MCP
Post
Cancel

Blackhat Asia 2026 - Remote Server, Local Root. Welcome to MCP

2026 블랙햇 Asia에서 발표한 MCP 보안에 대한 내용을 정리해봅시다.

TL;DR

MCP(Model Context Protocol)의 인증 흐름에 설계상 결함이 존재하여 악의적인 MCP 서버가 클라이언트를 공격할 수 있는 통로가 됩니다.

  1. MCP 인증은 Oauth 신뢰 모델을 무너뜨린다는 것
  2. 두 번째 모든 MCP 서버는 위협 벡터로 간주해야 한다는 것
  3. 보안을 설계 단계에서 고려해야 함 ( 나중에 패치하는 방식이 아닌.. )

MCP 만들어진 배경

MCP는 Agent들이 나오면서 외부와 상호 작용 하는 통일된 규격이 없어 만들어 졌습니다.
MCP

MCP가 만들어지기 이전에는 여러 문제점이 존재했습니다.

  1. 재사용 문제
    • Tool을 만들때 개발자들이 선호하는 프레임워크도 각각이며, 이를 `통합하기가 매우 어려웠습니다.
  2. 격리 부족 문제
    • 도구 실행이 로컬에서 이루어지기 땨문에 클라이언트 애플리케이션과 동일한 프로세스를 공유합니다.

MCP_problum

MCP는 이러한 문제점을 해결할 수 있도록 설계 되었습니다.
MCP는 stdio 방식과 SSE, streamable http 전송을 지원하는데 streamable http 방식을 권고하고 있습니다. (이유는 나중에 블로그로 작성하겠슴…)

요약하자면 MCP 서버는 도구를 재사용할 수 있도록하고, MCP 클라이언트는 원활한 통합을 가능하게 하며, 전송 방식은 격리 옵션을 제공합니다.

MCP2

MCP와 인증흐름

MCP 서버는 단순히 도구를 실행하는 기능 뿐만아니라 외부와 상호 작용하여 데이터를 가져옵니다.
MCPServer

MCP 클라이언트가 에이전트 시스템과 MCP를 이용하여 데이터에 접근할 수 있도록 하려면 특정 권한 부여 절차가 필요합니다.

  • Long Term API Keys : Simple, Dangerous ( API Key 탈취 )
  • Oauth-Based Flow (공식) : Dynamic, Scoped, Server-directed, Safer but Complicated

Oauth의 플로우를 보면 상당히 복잡한 것을 알 수 있습니다.
MCP인증

기본적으로 MCP 인증을 5가지의 아래 프로토콜로 구성됩니다.
4가지의 항목은 MCP에서만 채택된 것이고, 맨 아래 항목은 기존 OAuth2.0에 대한 흐름입니다.

  • OAuth Client ID Metadata Documents (draft-ietf-oauth-client-id-metadata-document-00)
  • OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
  • OAuth 2.0 Protected Resource Metadata (RFC9728)
  • OAuth 2.0 Authoriztion Server Metadata (RFC8414)
  • OAuth 2.1 IETF DRAFT (draft-ietf-oauth-v2-1-13)

MCP 인증에 대한 FLOW는 해당 발표 자료를 보는 것을 추천드립니다.

MCP Trust Assumptions Break

핵심은 모든 프로토콜이 MCP 서버가 MCP 클라이언트에게 인증 URL을 알려주는 역할을 하는 것입니다.

MCP인증플로우

위협 모델링을 하면 악의적인 공격자가 MCP 서버를 악용하는 경우 실행 프로세스에 전달 될 인증 URL을 완전히 제어할 수 있다는 뜻이기도 합니다.

MCP_ATTACK

Exploring and Exploiting MCP Clients

MCP Client는 크게 3가지의 유형으로 나눌수 있습니다.

  • Process-Based: CLI ( Gemini, Claude Code, IDE(vscode))
  • Browser-Based: WebAPP ( Smithery.ai )
  • Hybrid-Based: MCP Inspector

Process-based

process-based는 인증된 URL을 크게 두가지 방법이 있습니다.

  • 서드파티 라이브러리 사용
  • 프로그래밍 언어에서 제공하는 표준라이브러리 및 네이티브 API 사용

MCP_process_based

  1. 서드파티 라이브러리 ex) NodeJS Open
    해당 서드파티는 인기있는 오픈소스 중 하나이며, 신뢰할 수 없는 입력에 대한 검증은 별도로 구현해야 합니다.

아래 예시를 보면 파워쉘에 Command Injection이 가능한 포인트가 존재합니다.

MCP_process_based_open

  1. 표준 라이브러리 ex) Electron Shell API
    라이브러리 구현을 보면 내부적으로 OS URL 핸들러를 호출할 수 있습니다. 스킴 제어가 가능하며, file:// 스킴으로 열릴때 일부는 실행으로도 이루어 질 수 있습니다.

MCP_process_based_electron

Browser-based

브라우저 기반 클라이언트는 window.open 이나 location.href 같은 브라우저 네이티브 API를 사용합니다.
따라서 javascript을 실행할 수 있습니다.

MCP_browser_based

Hybrid-based

다양한 방식의 공격이 존재하며, 그 중 가장 유명한게 MCP Inspector 입니다.

엔트로픽의 공식 MCP 디버거로 모든 MCP 기능을 제공합니다.(STDIO/Steaming HTTP등) 그러나 공격에 대한 방어 기능은 제공하지 않습니다.

MCP Inspector는 Stateless 애플리케이션이기 때문에 XSS 공격으로도 민감한 데이터는 포함되어 있지 않습니다.

그러나 이 취약점을 악용하여 여러 피해(XSS to RCE)가 가능했습니다.

Mitigation

  • MCP 클라이언트는 유효한 스킴(http://, https://)으로 시작하지 않는 메타데이터 URL을 허용하지 말아야 합니다.
  • 메타데이터 URL 인코딩 : Powershell 서브 표현식과 같은 명령 공격 주입을 방지
  • 이를 방어하는 SDK 사용

Conclusion

블랙햇에서 좋은 발표자료를 정리해보면서 MCP 보안에 대해서 알아보는 유익한 시간이였습니다.