简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

SlowMist: 금고의 딜레마, 가드가 바벨탑 계약을 재구축할 수 있을까?

이 글을 읽으려면 25 분

Bybit 공격은 보안 인프라를 적시에 업데이트하는 것의 중요성을 강조합니다. 모든 링크에 보안 개념을 통합해야만 해커의 "창"과 가디언의 "방패" 사이에 게임에서 실제 보안 장벽을 구축할 수 있습니다.

원래 제목: "SlowMist 분석 | 안전 딜레마, 경비원이 계약 바벨을 재구성할 수 있을까?" 》

원본 저자: flush & kong, SlowMist Technology

배경

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

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

서명 메커니즘에 대한 과도한 의존: 모든 보안 책임이 개인 키의 보관으로 넘겨집니다.

동적 방어 부족:거래 실행 전 실시간 위험 스캐닝이 부족합니다.

정밀한 권한 제어: delegatecall과 같은 고위험 작업에 대한 허용 목록 메커니즘은 확립되지 않았습니다.

(Bybit 도난 프로세스: Safe v1.1.1 사용)

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

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 계약을 상속한 하청 계약이 거래 실행 전에 사용자 정의 로직 처리를 수행할 수 있도록 설계되었습니다. 수신된 매개변수 집합에는 다음이 포함됩니다.

· to:대상 주소 - 트랜잭션에서 호출할 계약 또는 계정 주소

· value:이더 값 - 트랜잭션과 함께 전송된 이더의 양

· data:데이터 페이로드 - 함수 선택기 및 매개변수를 포함하는 호출 데이터

· operation:작업 유형 - 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 함수를 호출하여 거래 실행 결과를 확인합니다. 구체적인 구현은 다음과 같습니다.

안전 계약이 Guard 메커니즘을 통해 다중 서명 거래 사전 검사를 수행하는 경우, checkTransaction 함수는 대상 계약 주소, 호출 방법, 실행 데이터(예: delegatecall), 소유자 서명 정보, 가스 구성 및 지불 정보를 포함한 완전한 거래 컨텍스트 데이터를 수신합니다.

이 메커니즘을 통해 개발자는 계약 허용 목록 제어(대화형 주소 제한), 기능 수준 권한 관리(고위험 기능 선택기 비활성화), 거래 빈도 제한, 자본 흐름에 따른 동적 규칙과 같은 다차원적 위험 제어 전략을 구현할 수 있습니다. 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 버전 ≥ v1.3.0 Safe Guard 모듈 검증 작업 https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A를 사용할 때)

일반적으로 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이 Safe 계약의 버전 1.3.0 이상으로 업그레이드하고 자금을 수신하는 유일한 주소인 화이트리스트 주소를 지정하고 엄격한 계약 기능 ACL 검증을 수행하는 등 적절한 보호 메커니즘을 구현했다면 이러한 손실을 피할 수 있었을 것입니다. 이는 단지 가설일 뿐이지만, 향후 자산 보안 관리에 중요한 아이디어를 제공합니다.

Safe Guard 메커니즘은 디지털 자산 금고에 추가된 지능형 보안 시스템과 같습니다. 그 효과는 규칙 설계의 엄격성과 구현의 질에 따라 달라집니다. 점점 더 정교해지는 공격 방법에 대응하기 위해 필요한 것은 다음과 같습니다. · 자동 검증: 자동화된 거래 검증 메커니즘 구축 · 동적 정책 조정: 위협 인텔리전스를 기반으로 실시간으로 보안 정책 조정 · 다층 방어: 여러 보안 메커니즘을 결합하여 심층적인 방어 시스템 구축 · 지속적인 감사: Guard 구현에 대한 정기적인 보안 감사 수행 디지털 자산 관리의 미래는 스마트 계약 보안 메커니즘과 지속적인 공격 및 방어 진화의 공진화 과정이 될 것입니다. 해커의 "창"과 수호자의 "방패" 사이에 실제 보안 장벽을 구축하려면 모든 링크에 보안 개념을 통합해야 합니다.