"이미 인증된 이메일"이라는 말을 다른 곳에서도 믿어버린 대가 — Shopify 계정 탈취
“이미 인증된 이메일”이라는 말을 다른 곳에서도 믿어버린 대가 — Shopify 계정 탈취
분류: Bugbounty · 웹·서버 · 계정탈취(ATO) [정보성]
덱. 보안 연구자 NullSecurityX는 Shopify에서 낮은 심각도 결함 두 개를 이어 붙여, 별도의 Shopify ID를 만든 적 없는 스토어를 통째로 탈취할 수 있는 경로를 찾았습니다. 보고된 포상금은 22,500달러로 알려져 있습니다. 핵심은 “한 곳에서 확인된 이메일”이라는 상태를 다른 곳에서도 그대로 믿어버린 신뢰 경계 설계였습니다.
리드
같은 시스템 안에 정체성(identity)을 관리하는 계층이 여러 겹으로 있을 때, “이 정보는 이미 검증됐다”는 상태를 계층 간에 그대로 재사용하면 위험합니다. 한 계층에서의 검증이 다른 계층에서도 똑같이 유효하다고 가정하는 순간, 공격자는 검증이 느슨한 계층에서 상태를 만들고 그 상태를 검증이 엄격한 계층으로 옮겨 씁니다. 이번 사례가 그 구조를 잘 보여줍니다.
핵심 사실 요약
- Shopify는 두 개의 독립된 정체성 계층을 운영합니다. 하나는 개별 스토어의 관리자 패널·직원 계정, 다른 하나는
accounts.shopify.com의 중앙 정체성인 Shopify ID로, 여러 스토어를 하나의 로그인으로 관리할 수 있게 해줍니다. 연구자에 따르면, 오래전부터 운영해 온 상당수 스토어는 이 Shopify ID를 아직 만들지 않은 상태였습니다. - 결함 1 — POS 직원 이메일 변경에 확인 절차 없음.
pos-channel.shopifycloud.com의 특정 GraphQL 엔드포인트가 직원 계정의 이메일 주소를 변경할 수 있게 해주는데, 원래대로라면 새 이메일로 확인 메일이 발송돼야 할 이 절차가 완전히 생략돼 있었습니다. - 결함 2 — Partner Dashboard의 “이미 확인됨” 상태를 다른 곳에서도 신뢰. Shopify Partner Dashboard에서 개발용 스토어를 만들 때, 해당 스토어 이메일의 활성화 링크를 클릭하면 그 이메일 주소가 Shopify 전체 시스템에서 “확인됨” 상태로 표시됩니다. 문제는 Shopify ID 생성 흐름이 이 상태를 그대로 재사용해, 이미 확인됨으로 표시된 이메일은 Shopify ID 생성 시 별도 확인 절차를 건너뛴다는 것입니다.
- 두 결함을 이으면 이런 순서가 됩니다: (1) 공격자가 자신이 통제하는 이메일로 개발용 스토어를 만들고 그 이메일을 “확인됨” 상태로 만든다 → (2) POS 직원 이메일 변경 엔드포인트를 이용해, 자신의 스토어 직원 프로필의 이메일을 확인 절차 없이 피해자의 이메일 주소로 바꿔치기한다(피해자에게는 아무 알림도 가지 않음) → (3) 이제 자신의 스토어 계정에는 피해자 이메일이 걸려 있고, 그 이메일은 앞서 “확인됨” 상태이므로, 이 상태로 Shopify ID 생성을 시작하면 확인 절차가 생략된다 → (4) 공격자가 원하는 비밀번호로 Shopify ID 생성을 마친다 → (5) 이렇게 만들어진 Shopify ID에는 피해자의 스토어(피해자 스토어 이메일이 아직 Shopify ID에 연결되지 않은 상태였으므로)가 자동으로 연결된다.
- 결과적으로 공격자는 피해자의 스토어 관리자 패널에 완전히 접근하게 됩니다 — 주문 내역, 고객 데이터, 결제 설정을 포함해서입니다. 연구자는 이 과정 전체에서 피해자에게는 어떤 알림·이메일도 가지 않았다고 밝혔습니다.
- 이 리포트는 Shopify의 버그바운티 프로그램을 통해 제출됐고, 보고된 심각도는 Critical, 포상금은 22,500달러로 원문에 명시돼 있습니다. ⚠️미확인(팩트체크 대상) — 정확한 제출일·수정 여부·트리아지 세부는 이 초안에서 1차출처(HackerOne 리포트 원문)로 직접 확증하지 못했습니다.
짧은 논평
연구자 본인이 원문에서 정리한 교훈 세 가지가 이 사례의 핵심을 잘 짚습니다. 낮은 심각도 결함도 조합하면 치명적이 될 수 있다는 것, 한 문맥에서의 “확인됨” 상태가 다른 문맥에서 자동으로 유효한 것은 아니라는 것, 그리고 정체성에 영향을 주는 모든 API 엔드포인트는 자신만의 독립된 인가·확인 로직을 가져야 한다는 것입니다. 저희가 다른 사례에서도 반복해서 짚는 원칙과 같습니다 — 신뢰 경계는 시스템 전체에서 하나로 통일돼 있어야지, 계층마다 다른 기준을 쓰면 그 틈이 공격 표면이 됩니다.
References / 참고자료
- NullSecurityX, “Shopify Account Takeover via Email Verification Bypass | Bug Bounty PoC $22,500” — 이 글이 재구성한 원 분석. 두 결함의 발견 과정과 전체 공격 절차를 다룸. https://nullsecurityx.medium.com/shopify-account-takeover-via-email-verification-bypass-bug-bounty-poc-22-500-2088b7d539d4
이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·요청 페이로드·스크린샷을 그대로 옮기지 않았으며, 작동하는 재현 절차는 싣지 않았습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 확증·정정되어야 합니다.