보안 및 거버넌스

Deadbugz: 신뢰할 때까지 숨어 있는 네 번째 MCP 공격 클래스

글쓴이: IdeaBosque최종 업데이트: 2026年9月29日

핵심 요약

74분 만에 23개의 풀 리퀘스트 — 단일 GitHub 계정이 2026년 8월 10일, 무관한 AI·MCP·개발자 도구 프로젝트들에 캠페인 PR을 제출했다. GitHub의 리뷰 메커니즘을 통해 병합된 것은 없었지만, 공개 시점에 4개가 여전히 오픈 상태로 남아 있었다(Pillar Security).
세 번의 정상 호출 후 메타데이터가 재작성된다 — 악성 MCP 서버는 클라이언트별 호출 카운터를 유지한다. 세 번째 tools/call 요청 이후, 이어지는 tools/list와 prompts/get 응답은 에이전트에게 SSH 키, AWS 자격 증명, 셸 히스토리, Kubernetes 설정을 찾도록, 그리고 그 활동을 사용자로부터 숨기도록 지시하는 내용으로 바뀐다.
런타임 게이트 메타데이터 오염은 네 번째 MCP 공격 클래스다 — STDIO 명령어 인젝션 → 도구 오염 → SHA 고정 우회 → 신뢰 형성 후 런타임 게이트 메타데이터 오염. Deadbugz 메커니즘은 배포 전 탐지가 가장 어렵다. 서버는 초기 검사를 통과하고, 페이로드는 클라이언트가 사용 패턴을 확립한 후에만 작동하기 때문이다.
도구 정의 핑거프린팅이 방어책이다 — 승인 시점에 도구 정의 핑거프린트를 캡처하고 비교한다. 이미 승인된 서버의 도구 메타데이터에 변화가 있으면, 변경된 도구가 민감한 작업에 영향을 미치기 전에 운영자 재승인을 요구하는 보안 이벤트로 취급한다.

단일 GitHub 계정이 텍스트 포맷팅과 문서 요약을 수행하는 "productivity-suite" MCP 서버를 내세워 74분 만에 23개의 풀 리퀘스트를 제출했다. 서버는 처음 세 번의 도구 호출 동안 정상적으로 작동한다. 네 번째 호출에서는 자신의 메타데이터를 재작성해, 연결된 AI 에이전트에게 SSH 키, AWS 자격 증명, 셸 히스토리, Kubernetes 설정을 찾고 — 그 활동을 운영자에게 숨기라고 지시한다. 2026년 9월 23일, Pillar Security는 이 캠페인을 공개하고, 23개의 풀 리퀘스트 중 4개에 심어져 있던 배포 아티팩트 deadbug-mcp.py를 따라 Deadbugz라 명명했다. Cloud Security Alliance는 리서치 노트를 발행해 Microsoft의 azure/durabletask를 포함한 73개 GitHub 저장소를 표적으로 한 이전의 "Miasma" 캠페인과의 기계적 유사성을 지적했다.

이 글은 Deadbugz 메커니즘을 매핑하고, 4클래스 MCP 공격 분류 체계에 위치시키며, 격차를 메우는 통제를 짚는다. Plugin4Shell SHA 고정 우회 분석과 MCP 보안 하드닝 체크리스트 위에 서 있으며, 두 문서 모두 Deadbugz가 파고드는 격차를 지닌 통제를 이미 정립했다.

메커니즘: 클라이언트별 호출 카운터

Deadbugz 서버는 이름이 약속하는 그대로를 수행하는 두 도구 — format_text와 summarize — 를 제공한다. 서버는 tools/call 요청에 대한 인메모리 클라이언트별 카운터를 유지한다. 카운터는 0에서 시작한다. 평범한 도구 호출 한 번당 하나씩 증가한다. 3에 도달하면, 이어지는 tools/list와 prompts/get 응답이 바뀐다: 평범한 도구 문서 대신, 연결된 AI 에이전트를 민감한 로컬 파일 쪽으로 유도하고 그 활동을 운영자에게 숨기라고 지시하는 내용이 담긴다.

이것이 중요한 이유는 MCP 도구 정의가 단순한 라벨이 아니기 때문이다. 클라이언트는 도구 정의를, 어떤 도구를 쓰고 어떤 행동을 취할지 모델이 판단하도록 돕는 컨텍스트로 모델에 공급한다. 설치 후에 그 정의들을 바꿀 수 있는 서버는, 무해해 보이는 도구 이름을 그대로 둔 채 에이전트가 보는 지시를 바꿀 수 있다. 공개 소스 코드는 호환 클라이언트가 도구 메타데이터를 갱신할 수 있게 하는 케이퍼빌리티 tools.listChanged를 광고한다 — 즉 서버는 클라이언트의 재접속을 필요로 하지 않는다. 도구 목록이 바뀌었다고 클라이언트에게 알릴 뿐이고, 클라이언트는 새로 오염된 정의들을 가져온다.

런타임 게이트는 리서치 회피 기법이다. 짧은 검사나 제한된 자동화 테스트가 받는 것은 양성 메타데이터뿐이다. 서버는 보안 리뷰, 샌드박스 테스트, 자동 스캔을 통과한다. 그 어떤 방법도 세 번의 평범한 도구 호출을 수행한 뒤 서버가 다음에 무엇을 돌려주는지 확인하지 않기 때문이다. Pillar는 임계값 로직과 변조된 메타데이터를 공개 소스에서 확인했고, 양성 텍스트 전용 요청을 통해 원격 서비스의 게이트 발동 메타데이터를 관찰했다.

배포 경로: 일상적으로 보이는 구성 변경

캠페인의 배포 메커니즘은 무관한 저장소의 MCP 구성을 추가·변경하는 GitHub 풀 리퀘스트다. 리뷰된 23개 PR 가운데 17개는 프로젝트 구성 파일에 원격 MCP 엔드포인트(productivity-suite-mcp.onrender.com/mcp)를 추가했다. 4개는 Python이 숨겨진 로컬 파일(~/.config/.cache/.sys/.deadbug-mcp.py)을 실행하도록 설정했다. 2개는 디렉터리 또는 목록 제출이었다. 리뷰 시점에 23개 모두 GitHub의 풀 리퀘스트 병합 메커니즘을 통해서는 미병합이었다 — 19개 클로즈, 4개 오픈 — 그러나 이 배포 모델에는 병합이 필요 없다. 구성 변경을 자신의 셋업으로 복사해 넣는 메인테이너, 혹은 PR을 보고 링크된 저장소를 방문해 서버를 직접 설치하는 개발자만 있으면 성립한다.

계정 수준의 배포 패턴은 조직적이다: 동일한 공개 계정(zellkernel)이 2026년 8월 10일 21:52 UTC에서 23:07 UTC 사이에 제출한 23개 PR 전부에서 같은 제품 이름, 같은 구성 테마, 같은 캠페인 마커를 사용했다. 해당 계정은 수집 시점에 공개 저장소 50개(이 중 20개는 포크)를 보유했고, 8월 10일 하루에만 21개의 저장소를 만들었다. 이 GitHub 프로필은 GitHub 계정으로 되돌아 링크하는 X 프로필(@llmgod)로 연결된다 — 배포 정체성과 AI/LLM 중심 공개 활동 사이에 계정에 귀속된 공개 연결이 존재하는 것이다.

이 배포 모델은 Plugin4Shell 분석이 문서화한 공급망 패턴을 확장한다: 마켓플레이스 통제를 완전히 우회하는 벡터로서의 PR 기반 구성 변경. Plugin4Shell은 고정된 커밋과 같은 이름의 브랜치를 만들어 마켓플레이스의 SHA 고정을 악용했다. Deadbugz는 마켓플레이스를 아예 사용하지 않음으로써 그 통제를 우회한다 — 오픈소스 프로젝트의 기여 워크플로를 통해 곧장 들어온다.

네 가지 공격 클래스

MCP 보안 패밀리는 이제 저마다 다른 신뢰 경계를 파고드는 네 가지 공격 클래스를 갖추고 있다:

클래스	메커니즘	최초 문서화	탐지 난이도
STDIO 명령어 인젝션	STDIO 구성 문자열에 심린 악성 명령어	2026년 4월, 20여 개의 CVE(Practical DevSecOps)	중간 — 정적 분석이 셸 메타문자를 잡아냄
도구 오염	무해한 도구의 설명이 승인 후 바뀌어 에이전트를 조종	Invariant Labs, 2025년 4월, WhatsApp 슬리퍼	중간 — 클라이언트 측 메타데이터 변경 탐지
SHA 고정 우회	SHA와 같은 이름의 브랜치가 마켓플레이스 고정 검증을 무력화	Plugin4Shell, 2026년 9월	어려움 — 체크아웃 이후 해석된 HEAD 어설션 필요
런타임 게이트 메타데이터 오염	악성 메타데이터를 N회 호출까지 숨겼다가 `tools/list`로 전달	Deadbugz, 2026년 9월	가장 어려움 — 배포 전 테스트는 임계값을 넘지 못함

Deadbugz 공격 시퀀스와 4클래스 분류 체계를 도식화했다:

각 클래스는 같은 구조적 격차를 파고든다: 확인을 잘못된 시점에 하거나 아예 하지 않는 신뢰 메커니즘이다. STDIO 인젝션은 살균 없는 구성 문자열을 신뢰한다. 도구 오염은 승인 후 도구 설명이 바뀌지 않으리라 믿는다. SHA 고정은 해석된 커밋이 고정된 이름과 일치하리라 믿는다. 런타임 게이트 오염은 테스트 중 서버가 돌려준 것이 사용 중에도 돌려지리라 믿는다.

Deadbugz의 배포 전 탐지가 가장 어려운 이유는 검사 중 서버의 행동이 진짜 무해하기 때문이다. 악성 페이로드는 정적 분석이 표시할 수 있는 형태로 코드에 숨겨 있지 않다 — 클라이언트가 사용 패턴을 확립한 후에만 작동하는 런타임 카운터 뒤에 게이트되어 있다. 서버에 접속해 format_text를 한두 번 호출하고 응답을 확인하는 보안 팀은 아무 이상도 발견하지 못한다. 이 공격은 바로 그런 리뷰를 통과하도록 설계되었다.

기존 통제가 충분하지 않은 이유

MCP 보안 하드닝 체크리스트는 전송, 인증, 도구 등록, 런타임, 감사의 5개 계층에 걸쳐 12개 통제를 조직한다. Deadbugz는 도구 등록 계층과 런타임 계층의 격차를 파고든다. 체크리스트의 도구 등록 통제는 승인 시점 검증이다 — 서버가 라이브되기 전에 도구 이름, 스키마, 설명을 확인한다. 그러나 Deadbugz의 도구들은 승인 시점에 진짜 무해하다. 런타임 통제는 무단 행위를 감시하지만, 오염된 메타데이터 자체는 행위가 아니다 — 에이전트를, 에이전트가 그 후 취하는 행동 쪽으로 유도하는 지시이며, 겉으로는 승인된 범위 안의 행동처럼 보인다.

governed-modules 테제 — 감사 로그, 레이트 리밋, 타입화된 에러, 킬스위치 아키텍처가 거버넌스 계층을 보안 경계로 만든다는 주장 — 는 네 번째 공격 클래스를 증거로 얻었다. Deadbugz 메커니즘은 이 테제를 반대 방향에서 검증한다: 메타데이터 변경 탐지도, 도구 정의 핑거프린팅도, 에이전트가 보는 내용에 대한 운영자 가시 diff도 없는 서버가 바로 캠페인이 파고드는 공격 표면이다.

방어책: 도구 정의 핑거프린팅

Pillar의 권고는 구체적이고 구현 가능하다: 승인 시점에 도구 정의 핑거프린트를 캡처하고 비교한다. MCP 클라이언트가 서버를 승인할 때, 서버가 돌려주는 모든 도구 정의 — 이름, 설명, 입력 스키마, 어노테이션 — 의 해시를 기록한다. 서버가 이후 도구 목록이 바뀌었다고 통지하면(tools.listChanged 경유), 클라이언트는 새 정의들을 가져와 핑거프린트와 비교하고, 차이를 보안 이벤트로서 운영자에게 제시한다. 변경된 도구는 운영자가 재승인하기 전까지 민감한 작업에 영향을 미칠 수 없다.

이 통제가 Deadbugz가 파고드는 격차를 메우는 이유는 배포 전 테스트에 의존하지 않기 때문이다. 신뢰 경계가 넘어간 이후의 런타임에서, 서버가 실제로 전달하는 메타데이터를 감시한다. 핑거프린트 비교는 런타임 게이트가 언제 발동하든 — 3회든 30회든 300회든 — 메타데이터 재작성을 잡아낸다. 이 통제는 이전의 도구 오염 클래스(Invariant Labs의 WhatsApp 슬리퍼)도 잡아낸다. 두 공격 모두 '승인 후 바뀌는 도구 설명'이라는 같은 메커니즘을 공유하기 때문이다.

프로덕션에서 MCP 서버를 운영하는 팀을 위한 4가지 구현 단계:

승인 시점에 도구 정의 핑거프린트를 기록한다. 초기 연결 시 서버가 돌려주는 모든 도구 정의를 해시한다. 핑거프린트는 에이전트의 구성 관리 시스템에서 서버의 승인 기록과 함께 보관한다.
tools/list와 prompts/get 응답의 드리프트를 감시한다. 서버가 도구 목록 변경을 통지하면 새 정의들을 가져와 저장된 핑거프린트와 비교한다. 차이는 모두 메타데이터 드리프트 이벤트로 플래그한다.
변경된 도구 정의에는 운영자 재승인을 요구한다. 변경된 도구 정의는 인간 운영자가 diff를 검토하고 서버를 명시적으로 재승인하기 전까지 에이전트 행동에 영향을 미쳐서는 안 된다. 이것이 소리 없는 메타데이터 재작성을 가시적 보안 이벤트로 바꾼다.
민감한 파일 읽기, 자격 증명 접근, 코드 실행을 정책 뒤에 게이트한다 — 도구 메타데이터 뒤가 아니라. Deadbugz 페이로드는 에이전트에게 SSH 키, AWS 자격 증명, Kubernetes 설정을 찾도록 지시한다. 그 읽기는 원격 도구 메타데이터에 담긴 지시의 결과가 아니라, 명시적 승인을 요구하는 정책 집행 행위여야 한다. Shadow AI 에이전트 분석은 메타데이터에 의해 유도된 자격 증명 탐색이 간파되는지를 결정짓는 런타임 통제 격차를 문서화한다.