▲

Postmark 백도어가 이메일을 다운로드하고 있음

 (koi.security)
2P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 최근 postmark-mcp 모듈에서 악의적인 행위가 발견됨
  • 1.0.16 버전부터 메일을 개발자의 외부 서버로 복사하는 코드가 추가됨
  • 수백 개 조직의 민감한 이메일이 유출되는 구조적 취약점이 드러남
  • MCP 서버의 신뢰 모델 부재로 인해 공급망 공격 위험이 커지고 있음
  • 모든 MCP 사용자는 즉시 점검 및 제거 조치가 필요함

MCP 서버의 실체와 postmark-mcp 사건 개요

  • MCP 서버는 AI 어시스턴트가 이메일 전송, 데이터베이스 쿼리 실행 등 반복 작업을 자동으로 처리하도록 하는 도구임
  • 이들 도구는 아주 높은 권한으로 동작하며, 개발자가 만든 코드를 거의 신뢰만으로 설치하며 검증 체계가 사실상 없음
  • 인기 패키지인 postmark-mcp는 공식 Postmark GitHub 저장소에서 소스코드를 가져다가, 악성 BCC 한 줄을 추가한 뒤 npm에 동일한 이름으로 게시함
  • 1.0.16 버전부터 평범하게 동작하는 코드에 한 줄이 추가되어, 모든 이메일이 개발자 개인 서버(giftshop.club)로 복사되는 기능이 동작함
  • 즉, 패스워드 재설정, 송장, 내부 메모, 기밀문서까지 모든 이메일 정보가 노출되는 사고임

이상 행위 탐지 및 공격 구조

  • Koi의 Risk Engine이 1.0.16 버전에서 이상 징후를 탐지함
  • 개발자의 신원은 GitHub 등에서 정상적으로 보였으며, 초반 15개 버전은 문제 없이 동작하여 신뢰를 구축하였음
  • 1.0.16에서 단 한 줄의 코드로 중요한 정보를 외부로 유출하는 기능이 추가됨
  • 공격자는 코드 복사와 동시에 기존 개발자를 사칭하는 기법(Classic impersonation)을 사용함
  • 기존에 정상적으로 잘 쓰이던 도구가 어느 순간 신뢰 기반 인프라스트럭처로 자리잡아 이후 악성 동작을 수행하게 됨

이메일 유출의 영향과 방식

  • 대략 주 1,500회 다운로드, 실제로 약 20%가 활발히 사용된다고 가정할 때 수백 개 조직이 노출 대상임
  • 매일 3,000~15,000건 이메일이 giftshop.club로 전송되는 규모로 추정됨
  • 사용자는 도구의 동작을 일일이 검증하지 않고 AI 어시스턴트에 대부분 자동 실행을 맡김
  • 별도의 보안 모델, 샌드박스, 검증 과정이 전혀 없음
  • 개발자가 npm에서 패키지를 삭제했지만, 이미 설치한 사용자 환경에서는 삭제 효과가 없어 계속해서 데이터가 유출됨

공격 단계 분석

  • 1단계: 정상 도구 배포

    • 1.0.0~1.0.15까지는 문제없이 동작하며, 신뢰를 쌓음

  • 2단계: 악성 코드 삽입

    • 1.0.16에 한 줄의 BCC 추가, 외부로 메일 복사하는 기능 적용

  • 3단계: 정보 수집

    • giftshop.club로 비밀번호, API 키, 금융/고객 데이터 등이 유출됨

  • 개발자는 연락이 닿지 않았고, npm에서 패키지를 삭제했으나 이미 설치된 환경의 피해는 지속 중임

MCP 생태계의 구조적 결함

  • MCP 서버는 일반 npm 패키지와 다르게 AI 어시스턴트가 자동으로 수백, 수천 번 호출하는 고위험 도구임
  • 코드의 악성 여부를 AI나 기존 보안 솔루션이 탐지하지 못하며, 신뢰에만 의존하고 있음
  • MCP 생태계 전체가 익명의 개발자에게 위험 자산에 대한 모든 권한을 위임하는 위험 구조임
  • 행동 변화 탐지를 통한 공격 식별 및 공급망 게이트웨이 등 보안적 제어가 필요함
  • Koi는 Risk Engine과 게이트웨이로 유사 악성 패키지의 유입 차단 및 검증을 추진함

대응 방안 및 IOC

  • 악성 패키지: postmark-mcp (npm)
  • 악성 버전: 1.0.16 이상
  • 유출 이메일: phan@giftshop[.]club
  • 도메인: giftshop[.]club

탐지 방법

  • 이메일 로그에서 giftshop.club을 BCC로 전송한 흔적 확인
  • MCP 서버 설정에서 예상치 못한 이메일 전달 파라미터 점검
  • postmark-mcp 1.0.16 이상 버전 설치 내역 정밀 검토

대응 및 복구

  • postmark-mcp 즉시 삭제
  • 침해 기간 중 이메일로 공유한 모든 자격 증명 회전
  • 탈취된 민감 정보 이메일 로그 전수 조사
  • 피해 사실 확인 시 해당 당국에 즉시 보고

결론 및 권고

  • 모든 MCP 서버에 대해 개발자 신원, 코드검증, 보안 점검 절차 반드시 시행 필요
  • MCP(자동화 AI 보조 인프라) 특성상 최소한의 불신 모델 적용 및 지속적 모니터링 필수
  • postmark-mcp 1.0.16 이상 사용자 즉각적 삭제와 보안 조치 필수
  • 신뢰 기반 사용은 곧 공급망 공격의 위험에 직면함을 유념할 필요가 있음
  • Paranoia(불신/의심)를 기본 방침으로 받아들이는 것이 MCP 활용의 합리적 전략임
▲
GN⁺ 4일전  [-]
Hacker News 의견
  • Thunderbird 확장 프로그램의 백도어와 이 사건이 뭐가 다른지 궁금함. 예전에 Thunderbird 확장 유지하다가 관심이 사라지자, 어떤 사람이 몇 번 진짜 기여하더니 갑자기 계속 프로젝트 인수하겠다고 강하게 요구함. 결국 모르는 사람한테 수만 개의 메일함 키를 넘긴다는 건 말도 안 된다고 생각해서 거절함. 애초에 사람들이 나를 그렇게 신뢰한 것도 웃기지만, 나는 적어도 좋은 사람이긴 함
    • 나도 똑같은 생각임. 이게 MCP 때문은 아니고, 모든 소프트웨어에 똑같이 해당하는 문제임. 결국 개발자와 제공자를 신뢰할 수밖에 없음. Microsoft가 내 Outlook 메일 복사하는 걸 막을 수 없고, Google이 Gmail 복사하는 걸 막을 순 없음. 오픈소스라서 '많은 눈'이 코드를 검토한다고 해도, 인기 프로젝트는 되겠지만 그래도 위험은 남아 있음. 결국 대부분 개발자를 그냥 신뢰할 뿐임. 이 문제는 소프트웨어만큼 오래된 고질적인 이슈임
    • 네가 말한 상황에서 Zuckerberg가 한 프라이버시 관련 발언이 자꾸 떠오름. 왜 우리가 무작정 어떤 사람에게 데이터와 프라이버시를 맡기는지 생각할 필요 있음
    • 술에 취한 모르는 사람을 차에 태워 집에 데려다줬던 경험이 많음. 그런 낯선 사람에게 차를 얻어타는 건 진짜 위험하다는 점을 항상 알려줌. 솔직히 나 같은 시간 남는 선량한 사람을 우연히 만난 게 행운임. 동네 작은 술집에 늦게 가는 스타일이라 이런 일이 자주 있는 듯함
  • NPM 단일 다운로드가 곧 고유 조직 하나라는 전제엔 동의 못함. 그 수치는 정말 과장임. npm에서 다운로드 하나는 누군가(npm i 명령을 돌리는 것) 또는 무언가(자동화 환경)가 설치하는 것일 뿐임. 실무에서 CI가 대충 구성되어 있으면 실행 당, 아니면 단계 당 npm i가 돌아감. 그래서 1,500회 다운로드도 사실 2개 회사에서만 발생할 수도 있음. 한 곳은 개발자가 PoC용으로 쓰고 있고, 한 곳은 CI 설정이 엉망인 경우임. 공식 리포를 봐도 watch 1개 fork 0개 star 2개밖에 없음 https://github.com/ActiveCampaign/postmark-mcp. MCP와 공급망 문제 자체는 심각하지만, 이번 케이스는 실제 영향이 거의 0임
    • 같은 논리대로라면 인기 python 패키지 다운로드도 머지않아 지구상 전 인류—아이와 노인, 컴퓨터가 뭔지도 모르는 사람들까지—각자 한 개씩 다운로드할 수준임. https://pypistats.org/top
  • 이 기사 자체는 좋지만 왜 ChatGPT로 요약한 AI 번역 버전을 굳이 읽어야 하는지 모르겠음. 그냥 원본 프롬프트를 보여줬으면 좋겠음. 지금처럼 불필요하게 느려지고 사용자를 무시하는 느낌임
    • 너도 그렇게 느꼈다니 다행임. 나는 AI 개입 문체가 너무 싫은데, 친구들 중엔 아예 못 느끼거나 신경 안 쓰는 경우도 있더라
  • 요즘 자주 보이지만, 우리가 이런 툴에 신 같은 권한을 맡기는 것에 대해 충분히 얘기하지 않는 것 같음. 만든 사람 얼굴도 모르는 툴인데 그냥 믿고 맡기는 중임. AI 어시스턴트도 마찬가지임. 모두 다 그냥 100% 신뢰해 버림. 이런 걸 지적하는 기사들이 있는데, "총구를 발에 겨누고 방아쇠를 당기면 네 발에 총 맞는다는 걸 아셨나요??" 느낌임. 너무 당연한데 기사들은 별 내용도 아닌 걸로 콘텐츠 만든 것 같음. 진짜 이렇게 모르는 사람도 많을까, 아니면 글 쓰려고 억지로 만든 건가 궁금함
    • 얼마 전에 AI 코드 어시스턴트가 회사의 프로덕션 데이터베이스를 날려버렸던 기사도 있었음 https://fortune.com/2025/07/…. 층위가 있는데, 1) 그 창업자는 AI 툴을 전적으로 신뢰했다가 스스로 당함. 그러니까 정말 무지했던 셈임. 2) 게다가 프로덕션 DB에 개발환경에서 직접 접근하게 열어놨음. 어차피 언젠가 한번은 사고 터질 환경이었음
    • HN 유저한텐 당연한 얘기도 세상 대부분에겐 전혀 안 당연함. 이런 기사는 그런 분들에게 필요한 콘텐츠임. 실제로 MCP 서버와 AI 에이전트 설계는 보안이 애초에 논의조차 안 되었기 때문에 원천적으로 안전하지 않음. 앞으로 바뀔지 어쩔지 모르겠지만, 그 전까진 자꾸 알려주는 게 최선임
    • “사람들이 정말 이렇게 둔감한가?” 기본적인 SQL injection도 매년 막대한 피해를 지속적으로 일으키고 있고, 여전히 OWASP 상위에 있음. SQL injection도 결국 데이터베이스에 신 같은 권한을 주는데 동작 원리를 이해하지 않아서 생기는 문제임. AI 에이전트의 행위 권한도 사용자 입장에선 잘 보이지 않을 수 있음
    • MCP로 이런 무분별한 접근이 대규모로 벌어지고 있다는 사실이 더 널리 논의되어야 함. 평소 신중한 사람도 위험성을 제대로 인식 못 하는 경우 많음
    • 예전엔 이메일 클라이언트가 인터넷 아무나 보낸 스크립트 내장 메일을 실행하는 게 “자동화 혁명”이라 불렸음. 또 예전엔 아이들에게 TV 대신 인터넷을 쓰게 하는 게 더 건강하다고 생각했는데, 그게 어떻게 끝났는지 다 알지 않음?
  • "랜덤한 누군가가 만든 툴을 설치하는 게 당연해진 상황"이라는 내용이 있는데, 사실 Windows XP 시절부터 우리가 CD 리핑 소프트웨어나 Bonzi Buddy 등 아무거나 아무 걱정 없이 설치해왔기 때문임. 편리함이라는 건 늘 보안보다 우선이었음. 결국 가장 중요한 교훈은 왜 아직도 ‘샌드박스, 샌드박스, 샌드박스’가 현실이 안 되었냐는 질문임. 이번 사태에서는 AI가 완전히 기존 모든 보안 원칙을 공장초기화시킨 것 같음
    • “사람들은 편리함을 보안보다 쉽게 선택함. 왜 아직도 샌드박스가 현실이 안 된 거냐”는 질문에, 답은 샌드박스 구현이 쉽지 않아서임. 그리고 여기서 ‘쉽다’는 건 OS에서 기본으로 제공되는 걸 의미함
  • 사용자가 GMail에서 인간이 열어보지 않아도 AI에게 프롬프트 인젝션된 스팸 메일을 보낼 수도 있음 https://linkedin.com/posts/…
  • 이 블로그 포스트는 너무 읽기 힘듦. AI가 손댄 느낌임. 불필요한 문장과 장식이 너무 많음. 아쉽게도 주제 자체는 흥미로움
  • 공급망 보안 문제에서 npm 패키지가 거의 항상 언급됨. npm이 가장 널리 쓰이고 공격자 입장에서도 동기가 크니까 그렇겠지만, 그래도 씁쓸함이 남는 건 어쩔 수 없음
    • OpenAI도 npm으로 Codex CLI를 배포함. Rust로 만들었는데도 npm 패키지를 씀. 개인적으론 이게 말이 안 된다고 생각함. 그래도 대안 쪽이 더 불편한가 봄
    • 이런 이유로 나는 stdio MCP 서버를 돌리지 않음. 모든 MCP는 도커 컨테이너로 격리돼 있는 VM 호스트 위에서, 불신 VLAN에 올림. 그리고 나는 SSE로만 접속함. 물론 프롬프트 인젝션엔 취약하지만, 핵심 브라우저 프로필이나 이메일, 클라우드 계정엔 연결하지 않음. 민감 정보와는 완전 분리함
    • 위 댓글이 너무 많이 추천받아서 이 아티클의 주요 시사점인 것처럼 오해되는 건 바람직하지 않음. 그런 식으로 받아들이면 본질이 안 보임
  • 혹시 개발자가 진짜 의도적으로 그런 짓을 한 게 아닐 수도 있음. 나도 디버깅 코드 넣은 채로 릴리즈한 적이 더러 있음. plain bcc라면 진짜 디버깅 코드일 수 있음
    • 나도 이 말 하려고 왔음. 솔직히 본인 이메일을 저렇게 대놓고 남겨둘 리가 없음. 2025년에도 테스트용으로 개인 Gmail 쓰는 거 부끄럽지 않음. 그리고 이건 MCP만의 문제가 아니라 어떤 패키지에서든 벌어질 수 있음
    • 패키지 삭제라는 반응도 솔직히 보안 문제 첫 경험한 초보 개발자의 전형적인 대처임. 악의가 아닌 단순 디버깅 실수였다면, 커뮤니케이션이 핵심임: 악성 버전을 없애고, 패치를 배포하고, 블로그/이곳 HN/소셜 미디어 등 공개 채널에서 소통하는 게 신뢰를 회복하는 길임. 정확한 사건 타임라인(그리고 OP처럼 AI가 써놓은 요약 말고)도 신뢰 회복에 도움임
  • MCP 서버 문제도 위험하지만, 이런 유형의 공격은 smtp 패키지같은 외부 의존성 사용하는 모든 상황에서 일어날 수 있다고 생각함
    • 그렇지만 smtp 패키지는 검증된 오랜 신뢰의 라이브러리를 주로 쓰게 됨. MCP는 모든 게 새롭고 신뢰의 역사가 쌓이지 않아서 문제임. 일종의 소프트웨어 황무지라 총집(6-shooter) 장전하고 다녀야 하는 환경임
답변달기