最정상급 MEV 봇, 750만 달러 도난: Approval이 체인에서 가장 간과하기 쉬운 치명적 위험?

오랫동안 이더리움에서 일반 거래자들을 사냥해 온 MEV 봇이 결국 750만 달러 상당의 '맞춤형' 함정에 빠졌습니다.

6월 21일, 이더리움에서 유명한 샌드위치 차익거래 봇 Jaredfromsubway.eth가 공격을 받아 지갑 내의 WETH, USDC 등 자산이 이체되었으며, 초기 추산 손실액은 750만 달러를 초과합니다(현재 공개된 손실 규모에는 차이가 있습니다).

흥미로운 점은 이번 공격이 개인키 유출도 아니고 전통적인 스마트 계약 취약점을 이용한 것도 아니라는 점입니다. 공격자가 사전에 대량의 가짜 토큰, 유동성 풀 및 보조 계약을 배포하여 차익거래 기회가 있을 법한 거래 경로로 포장하고, 봇이 자동 실행 과정에서 악의적인 계약에 ERC-20 Approval을 부여하도록 유도하여 최종적으로 MEV 봇의 자산을 '합법적으로' 이체한 것입니다.

글 작성 시점 기준으로 Jaredfromsubway.eth는 온체인 메시지를 통해 공격자에게 공개적으로 "48시간 이내에 2150 ETH를 반환한다면 50%의 화이트 햇 현상금을 지급할 의향이 있으며, 그렇지 않을 경우 가능한 모든 법적 및 법 집행 수단을 동원하여 책임을 추궁할 것"이라고 밝혔습니다.

하지만 고도로 전문화된 코드 기반의 MEV 봇조차 Approval 문제로 인해 무너질 수 있다는 사실은, 우리가 매일 사용하는 'Approval' 동작이 얼마나 큰 위험을 내포하고 있는지 다시금 생각하게 합니다.

1. MEV 봇을 위한 역추적 사냥

이번 공격 사건을 면밀히 분석해 보면, 이는 우연히 발생한 취약점이 아니라 Jaredfromsubway.eth의 거래 로직을 겨냥한 장기적인 사냥이었음을 알 수 있습니다.

Jaredfromsubway.eth는 항상 이더리움에서 가장 유명한 샌드위치 차익거래 봇 중 하나였습니다. 샌드위치 공격이란 간단히 말해, 봇이 곧 실행될 온체인 거래를 발견한 후 사용자보다 먼저 매수하여 가격을 올리고, 사용자가 더 나쁜 가격에 거래를 완료한 후 즉시 매도하여 차익을 얻는 방식입니다.

이러한 전략은 봇이 지속적으로 온체인 거래를 스캔하고, 매우 빠른 속도로 차익거래 기회를 판단하며, 다양한 토큰과 계약을 호출하는 거래 경로를 구성해야 함을 의미합니다. 즉, 속도가 빠르고 커버하는 자산과 프로토콜이 많을수록 봇이 포착할 수 있는 기회도 늘어납니다.

그러나 바로 이 점이 이번 사건의 돌파구가 되었습니다.

사후 분석에 따르면, 공격자는 봇의 자금 계약을 직접 공격하는 대신 몇 주에 걸쳐 수익을 낼 수 있을 것처럼 보이는 거래 환경을 구축했습니다:

• 첫째, 대량의 가짜 토큰과 유동성 풀을 배포했습니다. 이 토큰들은 이름, 인터페이스 및 거래 행동을 WETH, USDC, USDT 등 일반 자산을 모방하여 봇의 자동 인식 시스템이 정상적인 거래 경로로 오인하도록 했습니다;
• 둘째, 점진적으로 봇의 신뢰를 얻었습니다. 초기 테스트에서 봇이 부여한 승인은 정상적인 거래와 함께 사용되었으며, 봇의 시스템이 유사한 경로를 반복 실행하기 시작하자 공격자는 계약 로직을 조정하여 봇이 생성한 일부 승인이 실제로 소비되지 않고 거래 종료 후에도 초기화되지 않도록 하여 이러한 승인이 그대로 남게 했습니다;
• 마지막으로, 공격자는 여전히 유효한 승인 한도를 집중적으로 호출하여 봇 계약 내의 실제 WETH, USDC 및 USDT를 이체했습니다;

요컨대, 이 공격은 전적으로 MEV 봇의 운영 특성을 노렸습니다. 즉, 먼저 봇의 수익 판단 규칙에 부합하는 환경을 조성한 후, 자동 거래 경로 실행 메커니즘을 이용하여 시스템이 스스로 자산 호출 권한을 넘겨주도록 만든 것입니다.

이것이 고도로 전문화된 MEV 봇조차 당한 이유를 설명합니다.

가격 차이, Gas 비용 및 거래 순서를 계산하는 방법을 알지만, 새로 등장하는 모든 계약에 대해 충분한 신원 확인을 수행하지는 않을 수 있습니다. 이러한 관점에서 볼 때, 일반 사용자의 문제는 '이해하지 못하고 확인을 누른 것'이고, 자동화된 봇의 문제는 '확인 없이 자동 실행한 것'입니다.

표면적으로는 완전히 다르지만, 근본적인 위험은 매우 가깝습니다. 둘 다 승인을 거래를 완료하기 전의 일반적인 단계로 간주하고 그 잠재적 위험의 심각성을 명확히 인식하지 못했기 때문입니다.

2. Approval이 항상 과소평가되는 이유는?

잘 알려진 바와 같이, 이더리움 및 EVM 호환 체인의 ERC-20 표준에서 Approve(승인)은 상당히 기본적인 설계입니다.

그러나 사용자가 지갑에서 직접 송금할 때는 일반적으로 transfer를 호출하며, Approve는 거의 필요하지 않습니다. DEX, 대출, 스테이킹 또는 유동성 추가와 같은 스마트 계약 시나리오에서 사용자가 스마트 계약이 자신을 대신하여 토큰을 호출하도록 해야 할 때 비로소 Approval이 필요합니다.

예를 들어, Uniswap에서 USDT를 사용하여 ETH를 교환하려고 할 때, Uniswap의 스마트 계약은 사용자 지갑에서 직접 USDT를 가져갈 수 없습니다. 먼저 Approve를 실행하여 "Uniswap이 내 지갑에서 X개의 USDT를 인출하도록 허용한다"고 시스템에 알려야 합니다.

승인이 완료되면 권한을 얻은 계약이 transferFrom을 통해 설정된 한도 내에서 사용자의 USDT를 호출할 수 있고, 이후의 Swap도 정상적으로 완료될 수 있습니다.

즉, Approval 자체는 취약점이 아니라 DeFi가 정상적으로 작동하는 데 필요한 중요한 기반입니다. 다만 문제는 이것이 알리페이/위챗의 자동 결제 권한과 다소 비슷하다는 점입니다:

사용자는 계좌 비밀번호를 가맹점에 제공하지 않지만, 가맹점이 약정된 범위 내에서 자동으로 결제를 실행하도록 허용합니다. 승인이 유효한 한, 이후 결제 시 사용자가 다시 비밀번호를 입력하거나 건별로 확인할 필요가 없으므로 자연스럽게 몇 가지 문제가 발생합니다.

첫 번째는 무한 승인 문제로, 사람들이 종종 일회성 거래를 장기 권한으로 만듭니다. 반복적인 승인 작업과 Gas 비용을 줄이기 위해 많은 DApp이 기본적으로 매우 큰 승인 한도, 즉 소위 '무한 승인'을 요청합니다.

사용자는 단지 100 USDC로 한 번의 거래를 완료하려 했을 뿐인데, 계약이 향후 자신의 주소에 있는 모든 USDC를 사용하도록 허용할 수 있습니다. 해당 승인이 취소되지 않는 한, 사용자의 지갑에 당시 소량의 자산만 있더라도 나중에 새로 입금된 USDC도 계속 영향을 받을 수 있습니다.

두 번째는 승인이 DApp을 떠나도 자동으로 사라지지 않는다는 점입니다. 많은 사용자가 '지갑 연결 해제'와 '승인 취소'를 혼동합니다. 실제로 연결 해제는 웹페이지가 현재 지갑을 읽거나 요청하지 못하도록 할 뿐, 이미 블록체인에 기록된 Approval을 변경하지는 않습니다.

웹페이지를 닫고, DApp을 삭제하고, 브라우저 캐시를 지우고, 지갑 앱을 변경해도 자동으로 만료되지 않습니다.

마지막으로, 정상적인 계약이라도 미래에 위험해질 수 있습니다. 많은 승인 위험이 처음부터 악의적인 피싱 사이트에서 비롯된 것은 아니기 때문입니다. 이번 사냥에서처럼, 사용자는 당시 정상적인 프로토콜에 권한을 부여했지만, 이후 프로토콜 계약이 공격을 받거나, 관리자 키가 유출되거나, 업그레이드 가능한 로직이 교체되거나, 호출하는 라우팅 계약에 문제가 발생할 수 있습니다.

사용자의 입장에서 자산은 여전히 자신의 주소에 있지만, 권한 측면에서 보면 다른 계약이 계속해서 이러한 자산을 호출할 수 있는 능력을 가지고 있습니다. 따라서 Approval 위험은 "내가 나쁜 사람에게 승인했는가"뿐만 아니라 "내가 승인한 대상이 나중에 문제를 일으키지 않을까"도 포함합니다.

3. Approval 위험을 어떻게 관리해야 할까?

Approval 위험에 대한 가장 간단한 조언은 '무한 승인을 하지 말라'는 것입니다.

그러나 실제 DeFi 사용 환경에서 승인을 완전히 거부하는 것은 현실적이지 않습니다. 앞서 언급했듯이 승인 자체는 취약점이 아니며, 온체인 애플리케이션이 자산을 호출하는 기본적인 방식이기 때문입니다.

진정으로 바뀌어야 할 것은 Approval을 일회성 확인 동작에서 지속적인 권한 관리 메커니즘으로 전환하는 것입니다.

일반 사용자의 경우, 우선 몇 가지 기본적인 습관을 들여야 합니다:

• 첫째, '최소 권한' 원칙을 따르십시오. 지갑에 승인提示가 표시되면, 가능한 한 이번 상호작용의 실제 필요에 따라 한도를 설정하십시오. 예를 들어 100 USDT만 사용할 계획이라면, 무한 권한을 여는 대신 100 USDT에 가까운 한도만 승인하십시오;
• 둘째, 저장용 지갑과 상호작용용 지갑을 구분하십시오. 장기간 많은 자산을 보관하는 주소는 낯선 DApp에 자주 연결하지 마십시오. 에어드롭, Mint, 신규 프로젝트 및 고위험 DeFi 상호작용에 참여할 때는 별도의 주소를 사용하여 잠재적 손실을 작은 범위로 제한하십시오;
• 셋째, 정기적으로 더 이상 필요하지 않은 승인을 확인하고 취소하십시오. 사용자는 Revoke.cash와 같은 도구를 사용하거나 imToken에서 해당 토큰 페이지로 이동하여 왼쪽 하단의 '토큰 기능(Token Function)'을 클릭한 후 '승인 관리(Authorization Management)'를 선택하여 해당 주소의 승인 대상, 토큰 및 한도를 확인하고, 더 이상 사용하지 않거나 출처가 불분명한 권한에 대해 취소를 시작할 수 있습니다(관련 기사: 'Revoke.cash를 사용한 승인 관리 방법 안내');

물론, 아무리 강조해도 방심할 수 없는 승인 공격에 대해 사용자의 보안 인식과 정기적인 확인만으로는 충분하지 않습니다. 대부분의 사용자는 일련의 계약 주소가 실제로 누구의 것인지 구분하기 어렵고, 특정 승인 한도가 합리적인지 판단하기도 어렵기 때문입니다.

따라서 사용자가 Web3에 진입하는 첫 번째 방어선인 지갑은 제품 기능 차원에서 능동적인 방어를 제공해야 합니다.

imToken의 경우, 식별된 위험 토큰, 주소 및 DApp을 표시하거나 차단하며, 사용자가 일반 외부 계정에 토큰 권한을 부여하거나 계약 주소로 직접 송금할 때도 맞춤형 위험 경고를 제공합니다. 이러한 경고는 사용자의 판단을 대체할 수는 없지만, 실제 서명 전에 필요한 안전 버퍼를 추가할 수 있습니다.

이 외에도 imToken은 DApp 로그인, 송금, 토큰 교환 및 승인과 같은 중요 단계에서 서명 내용을 구조적으로 분석하고 읽기 쉽게 표시하여, 사용자가 확인하기 전에 자신이 동의하는 바를 이해할 수 있도록 돕고, 사용자가 서명하는 내용이 자신이 보는 행동과 일치하도록 보장하며, 식별하기 어려운 해시 데이터로 압축되지 않도록 합니다.

ERC-7730과 같은 Clear Signing 표준이 더욱 발전함에 따라, 이러한 '보는 대로 서명한다(What You See Is What You Sign)'는 가독성 표시는 단일 지갑의 제품 기능에서 점차 지갑, DApp 및 스마트 계약 간 공유되는 업계 표준이 될 것으로 기대됩니다.

종합적으로 보면, 개인키는 누가 계정을 소유하는지 결정하고, Approval은 누가 계정 내 자산을 호출할 수 있는지 결정합니다. 둘은 동일하지 않지만 똑같이 중요합니다.

이는 또한 지갑 보안이 '개인키 유출 여부'에만 국한되어서는 안 되며, 사용자부터 지갑까지 모두 함께 노력해야 함을 의미합니다: 사용자의 경우, 승인 전에 대상과 한도를 명확히 확인하고, 상호작용 종료 후 더 이상 필요하지 않은 권한을 신속히 정리해야 합니다. 지갑의 경우, 계약 내에 숨겨진 이러한 권한을 더 잘 보이고, 이해하기 쉽게 만들며, 제한 및 취소하기 쉽게 만들어야 합니다.

결국, 진정으로 위험한 것은 방금 발생한 송금이 아니라, 이미 오래