본문으로 이동

다중 서명 모듈 위험: 어떤 권한이 임계값을 우회하는가?

활성화된 모듈은 일반 소유자 임계값을 모으지 않고 다중 서명 계정에서 작업을 실행할 수 있습니다. 모듈, Guard, Fallback Handler, 업그레이드 및 복구 경로 감사 방법을 설명합니다.

업데이트

교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.

직접 답변

활성화된 모듈은 별도의 승인 경로입니다. Safe 방식 스마트 계정에서는 승인된 모듈이 execTransactionFromModule을 호출하고, 해당 작업에 대해 일반적인 소유자 M-of-N 서명을 모으지 않고 CALL 또는 DELEGATECALL을 실행할 수 있습니다. 따라서 표시된 임계값은 하나의 실행 경로만 설명하며 계정의 전체 보안 경계는 아닙니다.

모듈은 지출 한도, 정기 결제, 복구, 프로토콜 운영 같은 유용한 자동화를 지원합니다. 하지만 권한은 광범위할 수 있습니다. Safe 공식 계약은 활성화된 모듈이 임의의 거래를 실행할 수 있다고 설명하며, 악성 모듈이 Safe를 장악할 수 있다고 경고합니다. 소유자와 임계값뿐 아니라 모든 활성 모듈을 검토해야 합니다.

작동 방식

소유자는 먼저 일반 Safe 거래를 통해 enableModule을 승인합니다. 계정은 모듈을 활성 모듈 레지스트리에 저장합니다. 이후 모듈이 자체적으로 호출자와 규칙을 검증한 뒤 execTransactionFromModule을 호출하고, 계정은 호출자가 활성 상태인지 확인하여 요청된 작업을 실행합니다. 이제 보안은 모듈의 코드, 구성, 관리자, 업그레이드 키 및 외부 종속성에도 좌우됩니다.

거래 Guard와 Module Guard는 서로 다른 제어입니다. 거래 Guard는 일반 execTransaction 호출을 검사하고, Module Guard는 모듈이 시작한 호출을 검사합니다. Guard는 실행을 거부할 수 있지만, 고장 났거나 지나치게 제한적인 Guard는 서비스 거부도 일으킬 수 있습니다. 설치된 유형, 검사 범위, 복구 또는 제거 방법을 확인해야 합니다.

Fallback Handler도 확장 지점입니다. calldata가 계정의 핵심 함수와 일치하지 않으면 계정은 구성된 Handler로 호출을 전달하고 원래 호출자의 주소를 덧붙입니다. Handler는 서명 검증과 토큰 콜백을 추가할 수 있지만, 안전하지 않은 로직이나 구성은 권한 및 해석 공격 표면을 늘립니다.

예시

한 금고가 3-of-5 소유자 임계값을 사용하고 일상 결제용 한도 모듈을 활성화했습니다. 모듈은 업그레이드할 수 있고 업그레이드 관리자는 단일 핫 월렛입니다. 그 키가 침해되면 공격자는 모듈을 업그레이드하고 모듈 실행 경로를 사용해 3명의 서명 없이 자산을 전송할 수 있습니다. 3-of-5 임계값은 그대로지만 이 경로에는 적용되지 않습니다.

감사에서는 모듈 주소와 검증된 구현, 프록시와 관리자, 지출 한도, 허용 대상과 함수 선택자, DELEGATECALL 허용 여부, 설치된 Module Guard, Fallback Handler, 모듈 비활성화에 필요한 정확한 거래를 식별해야 합니다. 월렛 화면만 믿지 말고 각 배포 체인의 계정 및 관련 프록시 계약에서 값을 검증해야 합니다.

위험

  • 권한 위험: 취약하거나 악성인 모듈은 자산 전송, 지출자 승인, DELEGATECALL을 통한 계정 상태 변경, 다른 특권 계약 호출을 수행할 수 있습니다. 제한적인 화면은 온체인 권한도 제한적이라는 증거가 아닙니다.
  • 제어 및 업그레이드 위험: 모듈 프록시, 관리자, 오라클, 자동 실행자 또는 복구 키가 겉보기의 3-of-5 구성을 더 작은 실질 제어 집합으로 축소할 수 있습니다. 모든 업그레이드 및 구성 경로를 최종 서명자와 지연 시간까지 추적해야 합니다.
  • 가용성 위험: 결함 있는 Guard는 유효한 거래를 차단할 수 있고, 침해된 모듈은 소유자가 제거를 조율하기 전에 행동할 수 있습니다. 비활성화와 복구를 시험하고 모듈, Guard, Handler 변경을 감시하며 제거 대상 구성 요소에 의존하지 않는 대응 경로를 유지해야 합니다.

흔한 오해

  • 오해 1: “계정이 3-of-5이므로 모든 전송에 3개 서명이 필요하다.” 임계값은 일반 소유자 승인 경로에 적용되며, 활성 모듈은 다른 승인 정책을 가질 수 있습니다.
  • 오해 2: “하나의 Guard가 모든 실행 경로를 보호한다.” 일반 거래 Guard와 Module Guard는 서로 다른 진입점을 담당하며 범위는 설치된 계약과 규칙에 따라 달라집니다.
  • 오해 3: “화면에서 모듈을 제거하면 위험이 끝난다.” 계정이 존재하는 각 체인에서 활성 모듈 레지스트리, Handler와 Guard 저장소, 프록시 구현, 실행된 변경 거래를 확인해야 합니다.

관련 주제

출처

탐색

위키 검색...