멀티시그는 숫자가 아니라 분산이다: Humanity Protocol 사고로 보는 ProxyAdmin 권한 설계

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 3-of-5나 3-of-6 멀티시그가 있어도, 세 개의 키가 같은 노트북 백업에 있다면 정말 세 명의 승인이라고 부를 수 있을까?
• 핵심 출처:
  • The Defiant - Humanity Protocol Traces $36M Hack to Single Malware-Infected Machine That Held Seven Keys - 2026-06-10, 확인일 2026-06-13
  • Safe - How To: Configure Your Safe for Secure Protocol Operations - 2026-03-10, 확인일 2026-06-13
  • SEAL - Secure Multisig Best Practices - 게시일 미표기, 확인일 2026-06-13
  • OpenZeppelin Contracts 5.x - Proxy - 문서, 확인일 2026-06-13

1. 왜 지금 봐야 하나

2026년 6월 Humanity Protocol의 H 토큰 사고는 “스마트컨트랙트 버그가 없었다”는 말이 왜 충분한 해명이 아닌지 보여준다. The Defiant가 확인한 Humanity 측 포렌식 보고 요약에 따르면, 공격자는 멀웨어에 감염된 개발자 장비 한 대에서 여러 production key 백업을 확보했고, 그 안에는 admin hot wallet key, Ethereum Safe owner key 3개, BNB Smart Chain Safe owner key 3개가 포함되어 있었다. 결과적으로 공격자는 Ethereum 쪽에서는 3-of-6 Safe 임계값을, BNB Chain 쪽에서는 3-of-5 Safe 임계값을 넘겨 ProxyAdmin 권한을 장악할 수 있었다.

중요한 점은 공격 트랜잭션이 “비정상 서명”이 아니었다는 것이다. 보고 요약은 모든 transfer, Safe transaction, proxy upgrade가 유효한 private key signature를 가졌고, 그래서 온체인에서는 정상 권한 실행처럼 보였다고 설명한다. 공격자는 Ethereum bridge의 ProxyAdmin ownership을 가져가 악성 implementation으로 upgrade한 뒤 약 1억4118만 H를 빼냈고, BNB Chain에서는 token ProxyAdmin을 장악해 1억 H씩 세 번 mint해 유통량을 크게 늘렸다. 일부 보도는 수치가 2억 또는 3억 mint로 엇갈리므로, 이 글에서는 출처가 명시한 범위를 그대로 분리해 적는다. 핵심은 손실 숫자가 아니라 업그레이드 권한이 곧 계약의 미래 상태를 쓰는 권한이라는 점이다.

블록체인 개발자에게 이 사건은 access control, upgradeability, bridge 운영이 한 문제라는 사실을 다시 확인시킨다. multisig라는 단어는 분산을 보장하지 않는다. 키가 서로 독립된 사람, 장비, 위치, 절차에 나뉘어 있을 때만 분산이다.

2. 핵심 개념

오늘의 핵심 개념은 **상관된 키(correlated keys)**다. 멀티시그는 M-of-N 구조다. 예를 들어 3-of-5는 5개 signer 중 3개가 승인해야 실행된다. 이 모델의 보안 가정은 “공격자가 한 번에 3개 signer를 얻기 어렵다”는 데 있다. 그런데 세 signer key가 같은 노트북, 같은 클라우드 백업, 같은 브라우저 프로필, 같은 비밀번호 관리자, 같은 사무실 서랍에 있다면 실제 보안 모델은 3-of-5가 아니라 1-of-1에 가까운 correlated failure가 된다.

두 번째 개념은 ProxyAdmin 권한이다. OpenZeppelin 문서는 transparent proxy에서 사용자가 proxy 주소와 상호작용하고, proxy가 delegatecall로 implementation logic을 실행한다고 설명한다. 상태는 proxy에 남고 logic은 implementation에서 바뀐다. 그래서 ProxyAdmin은 단순 설정 계정이 아니다. 어떤 implementation을 실행할지 바꾸는 administrative interface다. 이 권한을 가진 쪽은 token mint, bridge release, pause, drain 같은 기능이 들어간 악성 logic으로 시스템의 의미를 바꿀 수 있다.

세 번째 개념은 **권한 범위 분리(scope isolation)**다. Safe의 2026년 protocol operations 글은 Safe가 treasury wallet에서 contract upgrade, parameter change, governance action, emergency response를 실행하는 coordination layer로 커진다고 설명한다. 그래서 treasury, ops, emergency 기능을 한 Safe에 몰아넣지 말고, 역할별 Safe와 permission을 분리하라고 권한다. 같은 이유로 bridge ProxyAdmin과 token ProxyAdmin, emergency pause, treasury transfer가 같은 signer 세트에 묶이면 하나의 장비 감염이 여러 권한면으로 번질 수 있다.

3. 최신 이슈와 연결

Humanity 사고의 최신성은 “키가 털렸다”가 아니라, 키 운영 실패가 proxy upgrade failure로 변환되는 경로가 드러났다는 데 있다.

1. 서명은 유효했다. 공격자는 충분한 Safe owner key를 얻었기 때문에 온체인 검증은 통과했다. 컨트랙트 입장에서는 msg.sender와 Safe threshold가 맞다.
2. 업그레이드는 정상 기능이었다. ProxyAdmin이 새 implementation을 가리키게 하는 것은 transparent proxy의 의도된 기능이다. 문제는 새 implementation을 선택할 권한이 공격자 손에 들어갔다는 점이다.
3. 브리지와 토큰 권한이 이어졌다. Ethereum에서는 bridge drain, BNB Chain에서는 malicious mint가 가능했다. 체인이 다르더라도 signer backup과 운영 절차가 같으면 공격면은 분리되지 않는다.
4. 사후 대응이 어려웠다. Humanity는 bridge deposit/withdrawal을 중단하고 추적·보상·현상금 절차를 시작했지만, 한쪽 chain의 ProxyAdmin이 공격자 지갑에 남아 있다는 보도도 있었다. ProxyAdmin을 잃는다는 것은 “다음 upgrade로 고치면 된다”가 아니라 “고칠 권한 자체를 잃을 수 있다”는 뜻이다.

Safe와 SEAL 문서가 말하는 운영 원칙은 그래서 추상적 권고가 아니다. SEAL은 critical multisig의 목표를 single point of failure 제거와 distributed control로 정의하고, 여러 signer key를 같은 장비나 같은 물리 위치에 두는 것이 멀티시그의 보안 이점을 무너뜨린다고 경고한다. 이 사건은 그 문장이 실제 손실 경로로 번역된 사례다.

4. 개발자 관점 해석

첫 번째 해석은 threshold는 수학이지만, 독립성은 운영이다. 3-of-5라는 숫자는 컨트랙트가 검증할 수 있다. 하지만 세 키가 같은 노트북에 백업되어 있는지, 같은 MDM 정책을 쓰는지, 같은 seed phrase 사진첩에 있는지는 컨트랙트가 모른다. 그래서 멀티시그 보안은 배포 후 운영 문서, signer onboarding, hardware wallet 정책, backup 금지, 주기적 증명까지 포함해야 한다.

두 번째 해석은 ProxyAdmin은 production root 권한이다. 개발팀은 종종 owner, pauser, upgrader, bridge admin을 코드 변수처럼 다룬다. 하지만 ProxyAdmin owner는 사실상 “다음 상태 전이 규칙을 선택하는 사람”이다. 토큰의 현재 supply cap이 안전해도, admin이 악성 implementation으로 바꾸면 그 cap은 의미가 없어질 수 있다. 따라서 upgrade 권한에는 treasury transfer보다 더 강한 절차가 필요할 때가 많다.

세 번째 해석은 브리지 권한은 chain별로 독립되어야 한다. 같은 제품의 Ethereum Safe와 BNB Safe가 같은 setup ceremony에서 만들어지고 같은 장비에 백업되었다면, 두 체인의 권한은 독립이 아니다. 멀티체인 배포에서는 chainId만 다르다고 위험이 분산되지 않는다. signer composition, hardware, cloud backup, emergency runbook까지 달라야 blast radius가 줄어든다.

네 번째 해석은 감사는 코드만 보면 부족하다. OpenZeppelin proxy pattern을 올바르게 써도, Safe threshold를 걸어도, 운영 키가 상관되어 있으면 시스템은 깨진다. 보안 리뷰에는 누가 ProxyAdmin을 소유하는가, 그 signer들이 같은 조직·장비·백업 경로를 공유하는가, upgrade transaction을 누가 시뮬레이션하고 누가 최종 실행하는가가 들어가야 한다.

5. 내 프로젝트에 적용할 체크포인트

• ProxyAdmin, DefaultAdminRole, owner, pauser, minter, bridge operator 주소를 모두 표로 뽑았는가?
• 각 권한이 어떤 Safe에 연결되어 있고, 그 Safe의 threshold와 signer 수가 무엇인지 문서화했는가?
• 같은 signer가 treasury, bridge, token upgrade, emergency pause에 반복 등장하는가?
• signer key가 hardware wallet인지, hot wallet인지, browser wallet인지, MPC인지 구분되어 있는가?
• 여러 signer가 같은 노트북, 같은 password manager, 같은 cloud backup, 같은 seed phrase 보관 위치를 공유하지 않는다고 확인했는가?
• upgrade transaction은 실행 전에 simulation, decoded calldata review, expected implementation address 확인을 거치는가?
• upgradeToAndCall, transferOwnership, addOwnerWithThreshold, changeThreshold, mint, pause, unpause 이벤트에 알림이 걸려 있는가?
• chain별 ProxyAdmin owner가 서로 독립적인가, 아니면 한 장비 감염으로 여러 chain이 동시에 넘어가는가?
• emergency Safe가 정말 pause만 할 수 있는가, 아니면 upgrade나 fund transfer까지 할 수 있는가?
• signer rotation과 compromise response runbook이 있는가?

6. 오늘 10분 액션

10분만 써서 내 프로젝트의 권한 상관관계 표를 만들어보자.

1. 배포 주소 목록에서 proxy contract 1개를 고른다.
2. explorer나 스크립트로 그 proxy의 admin 또는 ProxyAdmin owner를 확인한다.
3. 그 owner가 Safe라면 Safe threshold와 signer 주소를 적는다.
4. 같은 signer 주소가 다른 chain, treasury Safe, emergency Safe에도 들어 있는지 검색한다.
5. 표에 권한, 주소, threshold, signer 중복, 키 보관 방식 확인 여부, 알림 여부 열을 만든다.
6. 키 보관 방식 확인 여부가 unknown이면, 그것을 보안 TODO로 남긴다.

코드를 한 줄도 바꾸지 않아도 된다. 오늘의 목표는 “우리 멀티시그가 진짜 여러 실패 지점으로 나뉘어 있는가?”를 눈으로 보는 것이다.

7. 더 볼 자료

• Safe - How To: Configure Your Safe for Secure Protocol Operations
  • Safe를 treasury, ops, emergency, upgrade coordination layer로 나눠 보는 기준이 좋다.
• SEAL - Secure Multisig Best Practices
  • signer 분산, hardware wallet, threshold, monitoring, out-of-band verification을 점검표로 바꾸기 좋다.
• OpenZeppelin Contracts 5.x - Proxy
  • Transparent proxy, UUPS, ProxyAdmin, ERC-1967 slot을 다시 확인할 수 있다.
• The Defiant - Humanity Protocol Traces $36M Hack to Single Malware-Infected Machine That Held Seven Keys
  • 사건의 권한 탈취 경로와 아직 남은 공개 질문을 빠르게 파악하기 좋다.

중복 회피 메모

최근 blockchain_dev 글은 ZK Gateway settlement layer, FOCIL inclusion list, Solana Alpenglow finality, EIP-7928 block-level access list, PeerDAS/data availability, Arbitrum Nova 오프보딩, Ethereum native account abstraction, Gnosis Pay 모듈 권한 검증, KelpDAO bridge verifier 구성을 다뤘다. 이번 글은 bridge verifier 수나 모듈 signature bug가 아니라 upgradeable proxy의 ProxyAdmin 권한과 멀티시그 signer 상관성에 집중한다. 같은 “권한 사고” 계열이지만, 결론을 3-of-N 숫자가 아니라 키 독립성·Safe 역할 분리·upgrade root authority 운영으로 좁혀 기존 글과 관점을 분리했다.