안전 딜레마 가드 당신은 계약의 바벨탑을 재건할 수 있습니까?

02-26

이 기사는 기계로 번역되었습니다

원문 표시

저자: flush & kong

배경

2025년 2월 21일, 암호화폐 산업은 역사상 가장 심각한 자산 관리 위기에 직면했습니다. 거래 플랫폼 바이비트(Bybit)의 온체인 다중 서명 지갑이 표적 공격을 받아, 약 15억 달러의 자산이 "합법적인 서명"의 거래를 통해 조용히 유출되었습니다. 사후 온체인 분석 결과, 공격자는 정교한 사회공학 공격을 통해 다중 서명 권한을 획득하고, Safe 계약의 delegatecall 기능을 이용해 악성 로직을 주입하여, 결국 다중 서명 검증 메커니즘을 우회하고 자금을 익명 주소로 이체했습니다.

이번 사건은 "다중 서명"이 "절대적인 안전"을 의미하지 않는다는 잔혹한 현실을 드러냈습니다. Safe 다중 서명 지갑과 같은 안전 메커니즘도 추가적인 보호 조치가 없다면 여전히 공격 위험에 노출될 수 있습니다. 이는 Safe 다중 서명 지갑을 대상으로 한 첫 번째 공격 사례가 아닙니다. 지난해 와지르엑스(WazirX, 2.3억 달러 손실)와 래디언트 캐피탈(Radiant Capital, 5,000만 달러 손실)도 유사한 공격 기법을 겪었습니다. 슬로우 미스트(SlowMist)의 "바이비트 150억 달러 해킹 사건의 해커 기법과 의문점" 분석에 따르면, Safe 다중 서명 지갑 공격 사건에는 다음과 같은 기술적 공통점이 있습니다:

서명 메커니즘에 과도하게 의존: 보안 책임을 전적으로 개인 키 관리에 맡기고 있습니다.
동적 방어 기능 부족: 거래 실행 전 실시간 위험 검사가 부재합니다.
권한 제어 범위가 너무 넓음: delegatecall 등 고위험 작업에 대한 화이트리스트 메커니즘이 없습니다.

(바이비트 해킹 과정: Safe v1.1.1 사용)

이러한 일련의 사건의 핵심 문제는 Safe 계약 자체에 있는 것이 아니라, 전체 시스템 통합 과정에서 발생한 보안 취약점, 특히 전면 검증 단계에 있습니다. 이는 우리에게 다음과 같은 고민을 제기합니다: Safe의 추가 보안 조치 메커니즘을 통해 다중 서명 지갑의 방어 능력을 어떻게 강화할 수 있을까?

Safe

Safe는 다중 서명(Multi-Sig) 지갑으로, 주로 고가치 자산과 암호화폐의 안전한 보관 및 이체에 사용됩니다. 탈중앙화 자산 관리의 기반 인프라로서, 다자간 검증 메커니즘을 통해 자금 운용의 안전성을 보장하고 단일 관리자 또는 해커의 악의적 행위를 방지합니다. 이는 DAO 거버넌스, 기업 자금 관리, 탈중앙화 펀드 풀 등 다양한 시나리오에 광범위하게 활용됩니다. 이 계약은 Safe(구 Gnosis Safe) 팀이 개발했으며, 현재 업계 표준 온체인 자산 관리 솔루션입니다. 계약은 EIP-712 표준을 사용하여 구조화된 데이터 서명을 구현, 거래 데이터의 보안성과 검증성을 높였습니다.

핵심 용도

자금 안전 관리: 계약은 사전에 설정된 여러 소유자(Owners)의 공동 승인을 요구하여 거래를 실행, 단일 실수 또는 악의적 행위를 효과적으로 방지하고 자금 안전을 보장합니다.
거래 실행 및 관리: 내장된 다중 서명 검증 메커니즘을 통해, 서명 임계값 조건이 충족되면 계약이 대외 송금, 다른 계약 호출 또는 복잡한 비즈니스 로직 처리 등을 실행할 수 있으며, 토큰 및 기본 화폐의 지불과 수수료 보상을 지원합니다.
모듈화 확장: 계약은 모듈화 설계를 채택, OwnerManager, ModuleManager, GuardManager, FallbackManager 등 다양한 관리 모듈을 상속 및 조합하여 기능을 유연하게 확장하고 맞춤형 지원을 제공합니다.

함수 분석

execTransaction 함수는 다중 서명 검증을 거친 거래를 실행합니다:

거래의 고유 해시값(거래 매개변수, nonce 등 포함)을 계산합니다;
모든 서명의 유효성을 검증, 각 서명이 합법적인 소유자 또는 사전 승인된 주소에서 온 것을 확인합니다;
대상 주소의 비즈니스 로직을 호출하고, 거래 실행 후 이벤트를 통해 성공 또는 실패 상태를 기록합니다;
유연한 gas 수수료 처리를 지원, 보상 지불 시 정확한 거래 비용을 계산합니다.

checkContractSignatures & checkNSignatures 함수는 거래 또는 메시지의 서명 데이터를 검증합니다:

EOA 계정 서명, 계약 서명(EIP-1271), 사전 승인된 해시를 각각 처리합니다;
서명이 소유자 순서대로 배열되고 각 서명이 유효 주소에서 온 것을 확인, 재전송 공격 및 서명 변조를 방지합니다.

getTransactionHash 함수는 거래 해시를 생성, 서명 검증 및 재전송 공격 방지에 사용됩니다:

EIP-712 표준을 활용해 거래 데이터를 구조화된 해시로 변환합니다;
인라인 어셈블리를 사용해 메모리 작업을 최적화, 계산 효율성을 높입니다;
현재 nonce 값을 포함, 각 거래의 고유성을 보장합니다.

handlePayment 함수는 거래 실행 과정에서 gas 보상 지불을 처리합니다:

실제 소모된 gas 수수료와 기본 수수료를 기반으로 지불 금액을 계산합니다;
ETH 및 기타 토큰 지불을 지원, 수수료 보상의 정확성을 보장합니다.

onBeforeExecTransaction은 내부 가상 후크 함수로, execTransaction 함수 실행 전에 호출됩니다. 이 함수는 Safe 계약을 상속하는 하위 계약이 거래 실행 전 사용자 정의 로직을 처리할 수 있도록 설계되었습니다. 수신되는 매개변수 집합은 다음과 같습니다:

to: 대상 주소 - 거래가 호출할 계약 또는 계정 주소
value: 이더 값 - 거래와 함께 전송되는 이더 수량
data: 데이터 페이로드 - 함수 선택자와 매개변수가 포함된 호출 데이터
operation: 작업 유형 - CALL 또는 DELEGATECALL 결정
safeTxGas: 거래 gas 한도 - 거래 실행을 위해 예약된 gas 양
baseGas: 기본 gas - 거래 실행과 무관한 고정 gas 비용
gasPrice: gas 가격 - 거래 수수료 보상 계산에 사용되는 gas 가격
gasToken: gas 토큰 - 거래 수수료 지불에 사용되는 토큰 주소
refundReceiver: 환불 수령자 - 거래 수수료 보상을 받을 주소
signatures: 서명 집합 - 소유자가 거래에 서명한 데이터

다중 서명 지갑 계약은 엄격한 보안 설계와 유연한 모듈화 구조를 통해 디지털 자산 관리를 위한 효율적이고 안전한 솔루션을 제공하며, 거래 초기화부터 최종 실행까지의 전 과정에서 안전 관리를 실현, 블록체인 보안 관리의 중요한 도구가 되었습니다. 그러나 피해자들은 대부분 하드웨어 지갑을 통해 서명을 수행했는데, 일부 하드웨어 기기의 구조화된 데이터 서명 표시 효과가 좋지 않아 사용자가 단시간 내에 거래 데이터를 정확하게 식별하기 어려워 "블라인드 서명" 위험이 있습니다. 이 현상에 대해서는 하드웨어 및 데이터 표시 효과 최적화 외에도, 다중 확인, 스마트 알림, 강화된 서명 검증 도구 등의 조치를 탐색하여 블라인드 서명으로 인한 보안 위험을 더욱 낮출 수 있습니다.

Safe Guard

Safe 계약은 1.3.0 버전에서 중요한 보안 기능인 Safe Guard 메커니즘을 도입했습니다. 이 메커니즘은 표준 n-out-of-m 다중 서명 방식에 추가적인 제한 조건을 제공, 거래 보안성을 더욱 강화합니다. Safe Guard의 핵심 가치는 거래 실행의 다른 단계에서 보안 검사를 수행할 수 있다는 것입니다:

거래 전 검사(checkTransaction): Guard 메커니즘은 거래 실행 전에 모든 거래 매개변수를 프로그래밍 방식으로 검사하여 거래가 사전 설정된 보안 규칙을 준수하는지 확인합니다.
거래 후 검사(checkAfterExecution): 거래 실행 완료 후에도 Guard가 추가 보안 검증을 수행, Safe 지갑의 최종 상태가 예상대로 유지되는지 확인합니다.

아키텍처 분석

Safe에서 다중 서명 거래는 일반적으로 execTransaction 함수를 통해 실행됩니다. Safe Guard가 활성화된 경우, 사용자가 다중 서명 거래를 실행할 때 Safe 계약은 Guard 계약의 checkTransaction 함수를 호출하여 거래 전 검

최근 보안 사고가 계속 발생하면서 다중 서명 지갑 계약의 보안성에 대한 관심이 높아지고 있습니다. 하드웨어 지갑 제공업체들은 Safe 계약의 파싱 및 보호 기능을 강화하여 유사한 위험이 다시 발생하지 않도록 요구하고 있습니다. Bybit 사건 이후 많은 프로젝트들이 Safe 계약에 초점을 맞추고 Guard 메커니즘 기반의 업그레이드 및 확장 방안을 모색하고 있습니다. 그 중에는 Safe 다중 서명 지갑 위에 중간 계층 보안 솔루션을 구축하는 혁신적인 Guard 메커니즘 기반 애플리케이션도 있습니다. 이를 통해 기본 자산과 사용자 자산 간에 추가적인 보안 보장을 제공합니다.

주목할 점은 Safe 자체는 Guard 관리 및 콜백 기능만 제공하며, 실제 다중 서명 거래 검사 로직은 사용자가 직접 구현해야 한다는 것입니다. 따라서 Guard 구현의 품질에 따라 보안성이 달라집니다. Solv Guardian은 이 접근법을 확장하여 각 Vault에 전용 Guardian을 구성하여 허용된 대상 주소와 작업 권한을 지정하는 등 3가지 권한 제어 요소를 구현했습니다. 또한 분리된 거버넌스 메커니즘을 채택하여 Guardian에 문제가 발생해도 신속한 구제 조치를 취할 수 있습니다. 이와 유사한 설계 개념은 Elytro의 SecurityControlModule에서도 적용되고 있습니다.

Bybit 사건 공격 체인에서 Safe 계약에 적절한 Guard 메커니즘이 구현되었다면, 악의적인 delegatecall이 사전 검사 단계에서 차단되었을 것입니다. Guard의 checkTransaction 함수가 delegatecall 작업 유형을 식별하고 비정상적인 계약 주소와 위험한 함수 선택자를 감지하여 트랜잭션을 롤백했을 것입니다.

(Safe 버전 ≥ v1.3.0 Safe Guard 모듈의 검증 작업 https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)

요약하면, Safe는 1.3.0 버전 이후에야 Guard 기능을 제공하며, Guard를 사용할 때 사용자의 문턱이 높습니다. 사용자가 직접 Guard 검사 로직을 구현해야 하며, 부실한 Guard 구현은 Safe 지갑의 보안성 향상에 도움이 되지 않습니다. 따라서 Guard 구현에 대한 보안 감사가 필요합니다. 안전하고 적절한 Guard 구현은 Safe 지갑의 보안성을 크게 향상시킬 수 있습니다.

결론 및 전망

Bybit 공격 사건은 보안 기반 시설을 신속하게 업데이트하는 것의 중요성을 보여줍니다. Bybit은 Safe 계약의 1.1.1 (<1.3.0) 버전을 사용했기 때문에 Guard 메커니즘과 같은 핵심 보안 기능을 사용할 수 없었습니다. Bybit이 1.3.0 이상 버전의 Safe 계약으로 업그레이드하고 적절한 Guard 메커니즘을 구현했다면, 예를 들어 자금 수령 허용 주소 지정 및 엄격한 계약 함수 ACL 검증 등을 통해 이번 손실을 피할 수 있었을 것입니다. 이는 가정일 뿐이지만 향후 자산 보안 관리를 위한 중요한 시사점을 제공합니다.

Safe Guard 메커니즘은 디지털 자산 금고에 설치된 스마트 검색 시스템과 같습니다. 그 효과는 규칙 설계의 엄격성과 구현 품질에 달려 있습니다. 점점 정교해지는 공격 방식에 대응하기 위해서는 다음과 같은 노력이 필요합니다: