7702 피싱 공격 원리를 심층적으로 분석하고, 지갑과 사용자가 어떻게 방어해야 하는지 살펴보겠습니다.

2025.06.04

7702 피싱 공격 원리를 심층적으로 분석하고, 지갑과 사용자가 어떻게 방어해야 하는지 살펴보겠습니다.

서명을 할 때는 어떤 지갑을 사용하든 서명 내용을 주의 깊게 확인하고, 눈 blind 서명이나 잘못된 서명을 하지 않도록 주의하세요.

2025.06.04 - 06:36:11

钱包钓鱼攻击

Web3 심층 보도에 집중하고 흐름을 통찰

서명을 할 때는 어떤 지갑을 사용하든 서명 내용을 주의 깊게 확인하고, 눈 blind 서명이나 잘못된 서명을 하지 않도록 주의하세요.

EIP-7702은 주소에 스마트 계약과 유사한 기능성과 유연성을 부여하며, 점점 더 많은 7702 기반 애플리케이션이 개발되고 있어, 이는 더 많은 사용자가 Web3에 참여하고 사용자 경험을 향상시키는 데 매우 중요합니다.

그러나 7702의 유연성과 대부분의 사용자가 아직 7702에 익숙하지 않은 상황은 사기 조직에 의해 악용되고 있습니다. 최근 우리는 메타마스크(Metamask)의 7702 일괄 실행 기능으로 인해 원래 수십 차례의 승인 절차가 필요한 상호작용이 #InfernoDrainer이라는 낚시 공격 그룹에 의해 단 한 건의 트랜잭션으로 통합되어 자산이 도난당한 사례를 관찰했습니다.

참고: 메타마스크 자체에는 보안 문제가 없습니다. 메타마스크는 사용자에게 7702 관련 기능을 제공할 때 항상 사용자 보안을 최우선으로 하며 다양한 보안 조치를 시행하고 있습니다. 사용자는 7702의 기능과 관련 리스크에 대해 더 많이 이해하고 있어야 하며, 이를 통해 이러한 보안 사고를 방지할 수 있습니다.

1. 메타마스크 7702 Delegator 서명 승인 원리 및 보안 설계

1. 기술 분석

사용자가 이미 배포된 Delegator Contract에 승인을 부여하면, 사용자의 계정 code 필드가 해당 컨트랙트를 가리키게 됩니다. 현재 메타마스크 공식 Delegator Contract 주소: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
승인 구조: (chainId, delegatorAddress, nonce, signature)가 authorization_list에 기록됩니다.
서명 방식: 메타마스크 내부에서 EIP-7702 관련 승인 거래는 통일된 서명 로직을 사용하며, signEIP7702Authorization 메서드를 통해 승인 데이터 digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce))에 대해 ECDSA 서명을 수행하여 (v, r, s) 서명 구조를 생성하고, 이후 Type-4 트랜잭션에 추가함으로써 계정의 승인 및 업그레이드를 실현합니다. 구체적인 구현은 다음 링크 참고: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
검증 방식: 컨센서스 계층에서 ecrecover(digest7702, sig) == tx.from을 통해 검증을 완료합니다.
보안 설계: 웹 페이지는 사용자가 임의의 Delegator에 대한 승인을 유도할 수 없습니다. signEIP7702Authorization 메서드는 메타마스크 지갑 내부에서만 구현되며, window.ethereum을 통해 웹 페이지에 노출되지 않습니다. 웹 페이지에서 접근 가능한 서명 방법 예를 들어 eth_signTypedData_v4는 EIP-7702 승인 서명에 적합하지 않으며, 그 서명 다이제스트 형식은 다음과 같습니다:

반면 EIP-7702 명세가 요구하는 서명 형식은 다음과 같습니다:

eth_signTypedData_v4는 고정적으로 0x1901 접두사를 포함하며, 다이제스트 계산 과정이 7702과 완전히 다르기 때문에, 아무리 정교하게 domainSeparator, primaryType 및 message를 구성하더라도 digest712 == digest7702이 되도록 만드는 것은 거의 불가능합니다.

따라서 웹 페이지는 이 방법을 통해 합법적인 7702 승인 서명을 위조할 수 없습니다. 또한 메타마스크는 Delegator 주소에 대해 화이트리스트 메커니즘을 적용하며, 기본적으로 오직 공식 Delegator(0x63c0...32B)에 대한 승인만 허용하고 DApp이 임의로 주소를 주입하는 것을 금지함으로써 사용자가 악성 Delegator 승인 데이터에 서명하도록 유도되는 것을 추가로 방지합니다.

2. 사용 방법

현재 메타마스크에서 기존 EOA를 7702 스마트 계정(Smart Account)으로 업그레이드하는 방법은 크게 두 가지로 나뉩니다: 능동적 업그레이드와 수동적 업그레이드입니다.

능동적 업그레이드란 사용자가 지갑 인터페이스에서 직접 "전환" 버튼을 클릭하여 특정 Delegator Contract에 승인을 부여하는 것을 말합니다.

수동적 업그레이드는 사용자가 일부 7702을 지원하는 DApp과 상호작용할 때, 메타마스크가 관련 동작을 감지한 후 자동으로 알림을 표시하며 사용자에게 업그레이드를 권장하는 경우입니다.

2.1 능동적 업그레이드:

거래 내용: 계정 업그레이드 작업만 포함되며, 즉 특정 Delegator Contract에 대한 승인을 의미합니다.
업그레이드 절차: 지갑의 계정 세부 정보 화면으로 이동하여 아래 이미지의 전환 버튼을 클릭하면, 이더리움 메인넷에서 사용자의 계정을 스마트 계정으로 업그레이드할 수 있습니다. 전환을 클릭하면 현재 업그레이드 거래에 대한 서명 창이 나타납니다:

승인 기록: 확인 후 거래가 블록체인에 등재될 때까지 기다리면, 등재 성공 시 사용자가 스마트 계정으로 성공적으로 업그레이드된 것입니다. etherscan에서 현재 지갑 주소 페이지의 **Authorizations (EIP-7702)** 항목을 통해 구체적인 승인 거래 정보를 확인할 수 있습니다.

2.2 수동적 업그레이드

거래 내용: 계정 업그레이드 작업과 체인 상 컨트랙트와의 일괄 상호작용을 포함합니다.
업그레이드 절차: 사용자가 체인 상 특정 DApp과 상호작용할 때, 메타마스크는 현재 거래가 스마트 계정으로 업그레이드하여 일괄 전송 방식으로 완료할 수 있음을 자동으로 안내합니다. 예를 들어 Uniswap에서 일부 토큰 스왑을 할 때, 'Use smart account' 버튼을 클릭하여 스마트 계정으로 업그레이드하면, 이후 토큰 승인 및 스왑이 하나의 트랜잭션에서 일괄 처리됩니다.

2.3 일반 EOA로 전환하기

능동적 또는 수동적 업그레이드를 통해 현재 계정이 스마트 계정으로 변환된 후에도, 연결된 Delegator Contract 주소는 영구적으로 체인 상에 저장되어 계정의 현재 실행 로직으로 작용합니다.

사용자가 계정을 다시 일반 EOA로 복원하려면 수동으로 'EOA로 전환' 작업을 시작해야 합니다. 이 작업의 본질은 EIP-7702 승인을 통해 address(0)를 새로운 Delegator 컨트랙트 주소로 제출하는 것입니다. 해당 거래가 성공적으로 체인에 등재되면 계정의 code 필드가 비워지고 실행 로직이 기본 빈 코드로 복귀하며, 계정은 일반 EOA 상태로 돌아갑니다.

지갑의 계정 세부 정보 화면으로 이동하여 전환 버튼을 클릭하면, 이더리움 메인넷에서 사용자의 계정을 일반 EOA 계정으로 전환할 수 있습니다.

확인을 클릭한 후 거래가 체인에 등재될 때까지 기다리면, 등재 성공 시 사용자는 스마트 계정에서 일반 EOA 계정으로 전환된 것입니다. 구체적인 거래 정보는 etherscan의 현재 지갑 주소 페이지에서 동일하게 확인할 수 있습니다.

2. 7702 낚시 공격 사례

5월 24일, #InfernoDrainer 낚시 조직은 메타마스크 7702-Delegator 컨트랙트의 일괄 실행 기능을 이용하여 사용자(0xc6D2…06DC)로부터 여러 번의 토큰 승인을 일괄적으로 사기로 얻어내고 낚시 공격을 수행했으며, $HashAI, $HUMANS, $ParallelAI, $NeuralAI, $DSync, $Zero1, $NodeAI, $Sensay, $Virtual 등 총 14.6만 달러 이상의 손실이 발생했습니다.

사기 주소

0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181

낚시 거래 예시

https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba

낚시 당한 이유

사용자(0xc6D2…06DC)가 악성 일괄 승인 거래를 실행했습니다:

이더리움 트랜잭션 해시: 0x1ddc8cecbc... | Etherscan

Call 0xe9ae5c53 Method By 0xc6D289d5...0d2E606DC on 0xc6D289d5...0d2E606DC | Success | May-23-2025 02:31:35 PM (UTC)

etherscan.io

#InfernoDrainer 및 #PinkDrainer는 현재 더욱 은밀하고 광범위한 영향을 미칠 수 있는 7702 활용 낚시 범죄 산업을 연구하고 실험 중입니다.

저희 연구 결과에 따르면, 현재 낚시 범죄 조직 #InfernoDrainer 및 #PinkDrainer 모두 보다 은밀하고 큰 피해를 일으킬 수 있는 7702 활용 낚시 범죄 산업을 연구 및 실험 중이며, 관련 주소는 다음과 같습니다. 추후 보다 자세한 보고서를 발표할 예정입니다:

Inferno Drainer:

0x0000db5c8B030ae20308ac975898E09741e70000

Pink Drainer:

0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624

3. 보안 권고사항

지갑 제공업체:

메타마스크의 7702 Delegator 구현 및 보안 관리 방식을 참조하여, 사용자가 임의의 Delegator에 승인하는 것을 금지하고 앱 내에서만 운영이 가능하도록 해야 합니다. 웹 페이지를 통해 사용자에게 서명 승인을 유도하는 모든 행위는 낚시 공격임을 사용자에게 알려야 합니다.
체인이 현재 네트워크와 일치하는지 확인하고, chainID가 0일 때 서명하는 경우 재생 공격(replay attack)의 위험이 있음을 사용자에게 경고해야 합니다.
사용자가 서명 승인을 할 때 대상 컨트랙트를 표시하고, Delegator를 통해 일괄 실행 시 구체적인 함수 호출 내용을 표시하여 네트워크 낚시 공격 위험을 줄여야 합니다.

사용자: