디지털 자산 관리의 미래는 스마트 계약 보안 메커니즘과 지속적인 공격 및 방어의 발전이 함께 진화하는 과정이 될 것입니다.

작성자: flush, kong, 슬로우 미스트 (SlowMist) 보안팀

편집자: Liz

배경

2025년 2월 21일, 암호화폐 산업은 역사상 최악의 자산 관리 위기를 맞았습니다. 거래 플랫폼 Bybit의 온체인 다중 서명 지갑이 공격을 받았으며, "합법적으로 서명된" 거래를 통해 약 15억 달러의 자산이 조용히 손실되었습니다. 이후 진행된 온체인 분석 결과, 공격자는 정교한 사회 공학적 공격을 통해 다중 서명 권한을 얻고 Safe 계약의 delegatecall 함수를 사용하여 악성 논리를 심어놓았으며 최종적으로 다중 서명 검증 메커니즘을 우회하여 익명의 주소로 자금을 이체했다는 사실이 드러났습니다.

이 사건은 잔인한 현실을 드러냈습니다. "다중 서명"은 "절대적인 보안"을 의미하지 않습니다. Safe 다중 서명 지갑과 같은 보안 메커니즘조차도 추가 보호 조치가 부족하면 여전히 해킹 리스크 에 처해 있습니다. 이것은 Safe 다중 서명 지갑에 대한 첫 번째 공격이 아닙니다. 작년에는 WazirX(2억 3,000만 달러)와 Radiant Capital(5,000만 달러)이 모두 비슷한 공격을 받았습니다. 슬로우 미스트 (SlowMist): Bybit에서 약 15억 달러를 훔친 사건의 배후에 있는 해커의 방법과 의문에 대한 기사에서 분석한 바와 같이, Safe 다중 서명 지갑 공격 사건은 다음과 같은 기술적 유사성을 보였습니다.

• 서명 메커니즘에 대한 과도한 의존: 모든 보안 책임을 개인 키에 맡김.
• 역동적인 방어가 부족합니다. 거래 실행 전 실시간 리스크 스캐닝이 부족합니다.
• 세부적인 권한 제어: delegatecall과 같은 리스크 작업에 대해서는 허용 목록 메커니즘이 확립되지 않았습니다.

이 일련의 사건의 핵심 문제는 안전 계약 자체에 있는 것이 아니라 전체 시스템의 통합 과정, 특히 프런트엔드 검증 링크의 보안 위험에 있습니다. 이는 우리에게 다음과 같은 생각을 하게 합니다. Safe의 추가 보안 조치를 통해 다중 서명 지갑의 보호 기능을 어떻게 강화할 수 있을까요?

안전한

Safe는 고가 자산과 디지털 통화의 안전한 보관 및 전송을 관리하는 데 주로 사용되는 다중 서명 지갑입니다. 탈중앙화 자산 관리를 위한 인프라로서, 다중 당사자 협력 검증 메커니즘을 통해 펀드 운영의 보안을 보장하여 단일 관리자 또는 해커가 단일 실패 지점을 악용하여 악의적인 운영을 수행하는 것을 방지합니다. DAO 거버넌스, 기업 펀드 보관, 탈중앙화 펀드 풀과 같은 시나리오에서 널리 사용됩니다. 이 계약은 Safe(이전 Gnosis Safe) 팀에서 개발한 것으로, 현재 업계 표준인 온체인 자산 관리 솔루션입니다. 이 계약에서는 EIP-712 표준을 사용하여 구조화된 데이터 서명을 구현하여 거래 데이터의 보안과 검증 가능성을 향상시킵니다.

핵심 목적

• 자금 보안 관리: 계약은 실행되기 전에 복수의 사전 설정된 소유자가 공동으로 거래를 확인하도록 요구하므로 단일 지점의 오류나 악의적인 작업을 효과적으로 방지하고 자금 보안을 보장합니다.
• 거래 실행 및 관리: 내장된 다중 서명 검증 메커니즘을 통해, 계약은 서명 임계값 조건이 충족될 때 외부 전송을 실행하고, 다른 계약을 호출하거나 복잡한 업무 로직을 처리할 수 있으며, 토큰 및 기본 통화의 지불 및 수수료 보상을 지원할 수 있습니다.
• 모듈 확장: 계약은 모듈 설계를 채택합니다. 여러 관리 모듈(예: OwnerManager, ModuleManager, GuardManager, FallbackManager 등)을 상속하고 결합함으로써, 그 기능은 유연하고 확장하기 쉽고, 다양한 애플리케이션 시나리오에 대한 맞춤형 지원을 제공합니다.

함수 분석

execTransaction 함수는 여러 서명으로 검증된 트랜잭션을 실행합니다.

• 거래의 고유한 해시 값을 계산합니다(거래 매개변수, nonce 등과 결합).
• 모든 서명의 유효성을 확인하고 각 서명이 합법적 소유자 또는 사전 승인된 주소에서 온 것인지 확인하세요.
• 트랜잭션이 실행된 후 대상 주소의 업무 로직을 호출하고 이벤트를 통해 성공 또는 실패 상태를 기록합니다.
• 보상 지급 시 거래 비용을 정확하게 계산할 수 있도록 유연한 가스 요금 처리를 지원합니다.

checkContractSignatures 및 checkNSignatures 함수는 트랜잭션 또는 메시지의 서명 데이터를 확인합니다.

• EOA 계정 서명, 계약 서명(EIP-1271) 및 사전 승인 해시를 별도로 처리합니다.
• 서명이 소유자 순서대로 정리되어 있는지 확인하고, 각 서명이 유효한 주소에서 왔는지 확인하여 재전송 공격 및 서명 변조를 방지합니다.

getTransactionHash 함수는 서명 검증 및 재생 공격 방지를 위해 트랜잭션 해시를 생성합니다.

• EIP-712 표준을 사용하여 거래 데이터에 대해 구조화된 해싱을 수행합니다.
• 인라인 어셈블리를 사용하여 메모리 작업을 최적화하고 컴퓨팅 효율성을 개선합니다.
• 현재의 nonce 값과 결합하여 각 거래의 고유성을 보장합니다.

handlePayment 함수는 거래 실행 프로세스 중에 가스 보상 지불을 처리합니다.

• 지불 금액은 실제로 소비된 가스 요금과 기본 요금을 기준으로 계산됩니다.
• 정확한 수수료 보상을 보장하기 위해 ETH 및 기타 토큰으로 결제를 지원합니다.

onBeforeExecTransaction은 execTransaction 함수가 실행되기 전에 호출되는 내부 가상 후크 함수입니다. 이 기능은 Safe 계약을 상속받은 하청 계약이 거래를 실행하기 전에 사용자 정의 로직 처리를 수행할 수 있도록 설계되었습니다. 수신된 매개변수 세트에는 다음이 포함됩니다.

• 대상 주소 - 거래에서 호출되는 계약 또는 계정 주소
• value: 이더 value – 거래와 함께 전송된 이더 의 양
• 데이터: 데이터 페이로드 - 함수 선택기 및 매개변수를 포함하는 호출 데이터
• 작업: 작업 유형 – CALL인지 DELEGATECALL인지 결정합니다.
• safeTxGas: 트랜잭션 가스 한도 – 트랜잭션 실행을 위해 예약된 가스 양
• baseGas: 기본 가스 - 거래 실행과 무관한 가스 비용
• gasPrice: 가스 가격 – 거래 수수료 보상을 계산하는 데 사용되는 가스 가격
• gasToken: 가스 토큰 – 거래 수수료 지불에 사용되는 토큰 주소
• refundReceiver: 환불 수신자 - 거래 수수료 보상을 받는 주소
• signatures: 서명 수집 – 거래에 대한 소유자의 서명 데이터

엄격한 보안 설계와 유연한 모듈 형 구조를 갖춘 다중 서명 지갑 계약은 디지털 자산 관리를 위한 효율적이고 안전한 솔루션을 제공하고, 거래 초기화에서 최종 실행까지 전체 프로세스 보안 제어를 실현하며, 블록체인 보안 관리를 위한 중요한 도구가 됩니다. 하지만 대부분의 피해자가 서명을 위해 하드웨어 지갑에 의존하고 있으며, 일부 하드웨어 장치는 구조화된 데이터 서명에 대한 표시 효과가 좋지 않아 사용자가 단시간 내에 거래 데이터를 정확하게 식별하지 못하는 경우가 많아 "블라인드 서명"의 리스크 있다는 점도 알아두는 것이 중요합니다. 이러한 현상을 해결하기 위해 하드웨어와 데이터 표시 효과를 최적화하는 것 외에도 다중 확인 추가, 지능형 프롬프트, 향상된 서명 검증 도구 등의 대책을 검토해 맹목 서명으로 인한 보안 위험을 더욱 줄일 수 있습니다.

안전 보호

안전 보호 메커니즘은 안전 계약 버전 1.3.0에서 도입된 중요한 보안 기능입니다. 이 메커니즘은 표준 n-out-of-m 다중 서명 방식에 추가적인 제한을 제공하여 거래 보안을 더욱 강화하도록 설계되었습니다. Safe Guard의 핵심 가치는 거래 실행의 다양한 단계에서 보안 검사를 수행하는 능력에 있습니다.

• 거래 전 검사(checkTransaction): Guard 메커니즘은 거래가 실행되기 전에 모든 거래 매개변수에 대한 프로그램적 검사를 수행하여 거래가 사전 설정된 보안 규칙을 준수하는지 확인할 수 있습니다.
• CheckAfterExecution: 거래가 실행된 후, Guard는 거래 실행 후 Safe 지갑의 최종 상태가 예상대로인지 확인하기 위해 추가적인 보안 검증을 수행합니다.

아키텍처 분석

Safe에서 다중 서명 거래는 일반적으로 execTransaction 함수를 통해 실행됩니다. Safe Guard가 활성화되면 사용자가 다중 서명 거래를 실행하면 Safe 계약은 Guard 계약의 checkTransaction 함수를 호출하여 거래 전 검사를 수행합니다. 다중 서명 거래가 완료되면 Safe 계약은 Guard 계약의 checkAfterExecution 함수를 호출하여 거래 실행 결과를 확인합니다. 구체적인 구현은 다음과 같습니다.

 function execTransaction( ... ) external payable override returns (bool success) { ... address guard = getGuard(); { if (guard != address(0)) { ITransactionGuard(guard).checkTransaction( // Transaction info to, value, data, operation, safeTxGas, // Payment info baseGas, gasPrice, gasToken, refundReceiver, // Signature info signatures, msg.sender ); } } ... { ... success = execute(to, value, data, operation, gasPrice == 0 ? (gasleft() - 2500) : safeTxGas); ... } { if (guard != address(0)) { ITransactionGuard(guard).checkAfterExecution(txHash, success); } }    }

Safe 계약이 Guard 메커니즘을 통해 다중 서명 거래 사전 검사를 수행하는 경우, checkTransaction 함수는 대상 계약 주소, 호출 방법, 실행 데이터(예: delegatecall), 소유자 서명 정보, Gas 구성 및 지불 정보를 포함한 완전한 거래 컨텍스트 데이터를 수신합니다. 이 메커니즘을 통해 개발자는 계약 허용 목록 제어(대화형 주소 제한), 기능 수준 권한 관리(고위험 기능 선택기 비활성화), 거래 빈도 제한, 자본 흐름에 따른 동적 규칙 등 다차원적 위험 제어 전략을 구현할 수 있습니다. Guard 전략을 올바르게 구성하면 공격자가 계약이 아닌 계층을 사용하여 공격을 시작하는 것을 효과적으로 차단할 수 있습니다.

최근 보안 사고의 맥락에서 모든 당사자는 다중 서명 지갑 계약의 보안에 점점 더 많은 주의를 기울이고 있습니다. KeyStone, OneKey, RigSec 등과 같은 하드웨어 지갑 공급업체는 유사한 리스크 다시 발생하지 않도록 Safe 계약의 구문 분석 및 보호 기능을 강화할 것을 요구했습니다. Bybit 사건 이후, 많은 프로젝트 당사자는 Safe 계약에 집중하고 Guard 메커니즘을 기반으로 한 업그레이드 및 확장 솔루션을 모색하기 시작했습니다. 그 중에는 Guard 메커니즘을 기반으로 하는 혁신적인 애플리케이션이 많이 있는데, 이는 Safe 다중 서명 지갑을 기반으로 중간 계층 보안 솔루션을 구축하여 기본 자산과 사용자 자산 사이에 추가적인 보안 보호 기능을 제공합니다. 핵심 기능은 안전한 다중 서명 거래에 관련된 대상 계약, 호출 방법, 실행 데이터, 소유자 서명 정보, 지불 정보 및 가스 정보를 checkTransaction 함수에 전달하여 거래에 대한 매우 세부적인 검사를 구현하는 것입니다. 여기에는 화이트리스트 계약 호출, 화이트리스트 함수 작업, 화이트리스트 전송 대상, 거래 빈도 및 기타 권한 제어가 포함됩니다.

Safe 자체는 Guard 관리 및 콜백 기능만 제공한다는 점에 유의해야 합니다. 실제 다중 서명 거래 검사 로직은 사용자가 직접 구현하며, 보안은 Guard 구현의 품질에 따라 달라집니다. 예를 들어 Solv Guardian은 각 Vault에 전담 Guardian을 구성하여 허용되는 대상 주소와 작업 권한을 지정하고, 허용되는 계약 지정, 허용되는 기능 작업 정의, ACL 확인 요구 사항의 세 가지 주요 권한 제어 요소를 구현하여 이러한 아이디어를 확장합니다. 동시에 별도의 거버넌스 메커니즘을 채택하여 Vault Guardian이 실행을 담당하고 Governor가 거버넌스 권한을 제어합니다. 이를 통해 Guardian에 문제가 발생하더라도 사용자 자산을 보호하기 위해 적절한 시기에 시정 조치를 취할 수 있습니다. 비슷한 설계 개념이 Elytro의 SecurityControlModule에도 적용됩니다. 모듈 preExecute 함수를 통해 주요 작업을 가로채고 화이트리스트 메커니즘을 사용하여 모듈 설치, 후크 설정, 검증자 관리와 같은 리스크 높은 작업을 미세 조정합니다. 이를 통해 신뢰할 수 있는 계약만 시스템에 추가되도록 보장하고 지갑에 장기적인 보안을 제공합니다.

Bybit 이벤트 공격 체인에서 Safe 계약이 적절하게 구성된 Guard 메커니즘을 배포하는 경우 공격자가 execTransaction을 통해 시작한 악의적인 delegatecall은 사전 확인 단계에서 여러 전략에 의해 가로채집니다. Guard의 checkTransaction 함수는 먼저 delegatecall 작업 유형을 식별하고 비활성화 규칙(예: 작업을 일반 호출로만 강제)을 트리거한 다음 데이터 필드를 구문 분석하여 비정상적인 계약 주소(0x4622...7242)와 고위험 함수 선택기를 감지하고 사전 설정된 계약 허용 목록 및 함수 차단 목록 전략을 통해 거래를 직접 롤백하여 궁극적으로 "전략 가로채기 → 논리 차단" 방어 시스템을 형성하여 저장소 변조 및 자금 이체 경로를 완전히 차단합니다.

일반적으로 Safe는 버전 1.3.0 이후에만 Guard 기능을 제공합니다. Guard는 매우 세분화된 다중 서명 거래 확인을 제공할 수 있지만, 사용자가 Guard 기능을 사용하기에는 높은 임계값이 있습니다. 그들은 스스로 Guard 체크 로직을 구현해야 합니다. 거칠거나 결함이 있는 Guard 구현은 사용자가 Safe 지갑의 보안을 개선하는 데 도움이 되지 않을 수 있으므로 Guard 구현에 대한 보안 감사 필요합니다. 안전하고 적절한 Guard 구현을 통해 Safe Wallet의 보안이 크게 향상될 수 있다는 점에는 의심의 여지가 없습니다.

결론 및 전망

Bybit 공격은 보안 인프라의 적시 업데이트의 중요성을 강조합니다. Bybit은 Safe 계약 버전 v1.1.1(<1.3.0)을 사용했는데, 이는 핵심 보안 기능인 Guard 메커니즘을 사용할 수 없다는 것을 의미합니다. Bybit이 안전 계약 버전 1.3.0 이상으로 업그레이드하고 자금을 수신하는 유일한 주소인 화이트리스트 주소를 지정하고 엄격한 계약 기능 ACL 검증을 수행하는 등 적절한 보호 메커니즘을 구현했다면 이러한 손실을 피할 수 있었을 것입니다. 이는 단지 가설일 뿐이지만, 향후 자산 보안 관리에 중요한 아이디어를 제공합니다.

Safe Guard 메커니즘은 디지털 자산 금고에 추가된 지능형 보안 시스템과 같습니다. 그 효과는 규칙 설계의 엄격성과 구현의 질에 따라 달라집니다. 점점 더 정교해지는 공격 방법 대면 우리는 다음과 같은 조치를 취해야 합니다.

• 자동 검증: 자동 거래 검증 메커니즘 구축
• 동적 정책 조정: 위협 인텔리전스를 기반으로 실시간으로 보안 정책을 조정합니다.
• 다층 방어: 여러 보안 메커니즘을 결합하여 심층적인 방어 시스템 구축
• 지속적인 감사: Guard 구현에 대한 정기적인 보안 감사 수행

디지털 자산 관리의 미래는 스마트 계약 보안 메커니즘과 지속적인 공격 및 방어의 발전이 함께 진화하는 과정이 될 것입니다. 해커의 "창"과 수호자의 "방패" 사이에 실제 보안 장벽을 구축하려면 모든 링크에 보안 개념을 통합해야 합니다.

참고문헌

[1] https://github.com/safe-global/safe-smart-account/blob/v1.3.0/CHANGELOG.md[2] https://docs.safe.global/advanced/smart-account-guards[3] https://docs.solv.finance/security/solv-guard[4] https://github.com/safe-global/safe-smart-account/tree/main/contracts/examples/guards[5] https://github.com/Elytro-eth/soul-wallet-contract/blob/v0.6/contracts/modules/securityControlModule/SecurityControlModule.sol

면책 조항: 블록체인 정보 플랫폼으로서, 이 사이트에 게시된 기사는 작성자와 게스트 관점 만을 나타내며 Web3Caff의 입장과 아무런 관련이 없습니다. 기사의 정보는 참고용일 뿐이며 어떠한 투자 조언이나 제안도 구성하지 않습니다. 귀하의 국가 또는 지역의 관련 법률 및 규정을 준수하십시오.