MCP
현재 MCP의 주요 문제
•
복잡도 감소, 보안 강화
•
스카마 변경
왜 보안에 취약한가?
•
개방형 확장성 우선 설계: "신뢰 전제" 트러스트 모델
◦
실시간으로 변화하는 도구와 권한을 신뢰한 결과, "누가, 언제, 어떻게 바꿔 끼웠는지"를 추적•검증하기 어려워짐
•
분산된 책임 구조
◦
클라이언트-서버-호스트 간의 모호한 책임으로, 전체 파이프라인이 무너지기 쉬워짐
•
생태계 수준의 구조적 문제
◦
연결된 도구들 간의 복잡한 의존성으로 하나의 취약점이 전체 시스템에 영향을 미침
◦
기존 API의 주 사용자가 확장됨 (개발자 → 비개발자(바이브코더))
•
검증 메커니즘 부족
◦
호환성과 빠른 도입 속도 우선으로 명세상의 보안 강화 지연
◦
서버의 진위성과 무결성을 보장하는 방법 (최근 보완)
신뢰 전제 트러스트 모델
•
실시간 도구 발견
◦
런타이
•
부작용
"신뢰 전제" 트러스트 모델
•
Rug pull
◦
MCP 서버 제공자가 초기 신뢰를 구축 후 일시적으로 서버를 악성 업데이트를 진행하여 prompt injection 공격 가능 및 증거인멸 가능
•
WhatsApp MCP 서버 메시지 이력 유출 공격 시나리오
1. 악의적인 MCP 서버가 get_fact_of_the_day() 같은 정상적인 도구를 제공
2. 도구 정의가 나중에 변경되어 WhatsApp 메시지 전송 기능을 하이재킹
3. 사용자의 이전 메시지 이력이 공격자가 제어하는 번호로 자동 전송
분산된 책임구조
•
Over-privileged Tool을 무지성으로 이용하기 쉬움
•
호스트, 클라이언트, 서버 간 복합적 신뢰 관계로 인해 보안 책임 소재 모호
공급망 공격 시나리오: GitHub private repository 데이터 탈취
1.
공격자가 공개 리포지토리에 악의적인 프롬프트 인제션이 포함된 이슈를 생성
2.
사용자가 "공개 리포지토리의 이슈를 확인해달라"고
AI 에이전트에 요청
3.
AI가 악의적 이슈를 읽고 숨겨진 명령을 실행하여 비공개 리포지토리의 데이터 반환
4.
탈취된 데이터가 공개 리포지토리의 PR(PullRequest)로 자동 생성되어 공격자가 접근 가능
결국 호스트에서 책임지고 입/출력 sanitization을 구현해야 함
•
인증 정보: API 키
•
내부 식별자: UUID, 내부 ID, 데이터베이스 키 등의 시스템 식별자
•
개인정보: PI(Personally Identifiable Information)
•
민감한 메타데이터: 생성 시간, 내부 버전 정보, 시스템 경로 등
•
인가되지 않은 사내 데이터
생태계 수준의 구조적 문제
•
공급망 공격: 제4자 인젝션 위험
◦
데이터 체인 오염: 하나의 MCP 서버가 다른 외부 데이터 소스의 정보를 신뢰하여 간접적 공격이 가능
◦
생태계 신뢰망 취약: 연결된 도구들 간의 복잡한 의존성으로 인해 하나의 취약점이 전체 시스템에 영향을 미침
검증 메커니즘 부족
•
도구 진위성 검증 부족
◦
출처 확인불가: 도구의 실제 제공자나 무결성을 검증할 메커니즘이 없음
◦
메타데이터 위조 가능: 도구 이름, 설명, 공급자 정보 등이 쉽게 위조될 수 있음
•
지속적 무결성 검사 부재
◦
일회성 승인: 한 번 승인된 도구는 이후 변경사항에 대한 재검증 없이 계속 신뢰됨
◦
기존 MCP 명세에서 인증이 필수가 아니어서 인증을 생략하거나 자체 방식으로 처리함
•
MCP(2025-06-18)에 보완된 기존 취약점
◦
OAuth 구현 미비
◦
세션 하이재킹 위험
◦
토큰 패스스루 금지 위반
