안녕하세요, 블록체인 애호가 여러분! EVM 호환 체인에서 스마트 컨트랙트 개발에 뛰어들고 있다면 보안 위협에 항상 경계를 늦추면 안 됩니다. 최근 프록시 초기화 포이즈닝 공격(proxy initialization poisoning attacks)이 다시 기승을 부리고 있다는 소식이 들려오고 있으며, 전통적인 MEV가 없는 체인들—예를 들어 Base 같은 곳에서도 발생하고 있습니다. 여기서는 Trading Protocol 공동창업자 Mikko Ohtamaa(@moo9000)의 상세 스레드를 바탕으로 위험 요소와 완화 방법을 단계별로 정리해 드리겠습니다.

먼저, 무슨 일이 벌어지고 있냐고요? 몇 주 전 VennBuild, Dedaub 등 보안 리서치 팀들이 수천 개의 스마트 컨트랙트에 백도어를 몰래 심어 $1,000만 이상을 위험에 빠뜨린 대규모 캠페인을 발견했습니다. 다행히 이 전문가들이 대부분의 자금을 공격자들에게 넘겨주기 전에 구출했지만, 이 사건은 업계 전체에 경종을 울립니다.

이 공격은 프록시 계약(proxy contracts)을 노립니다. 프록시는 EVM 체인에서 스마트 컨트랙트를 업그레이드하는 흔한 우회 방법입니다. 2014년 등장한 Ethereum Virtual Machine(EVM)은 네이티브 코드 업그레이드를 지원하지 않기 때문에(NEAR Protocol 같은 최신 체인과 달리), 개발자들은 프록시를 씁니다: 실제 로직을 담은 implementation 컨트랙트와 연결되는 프록시 컨트랙트를 배포하고, 사용자는 프록시와 상호작용하면 프록시가 implementation으로 호출을 라우팅합니다. 소유자는 이후 프록시가 가리키는 implementation 주소를 바꿔 "업그레이드"할 수 있죠.

문제는 여기서 생깁니다. 일반적인 과정은 두 단계로 이뤄집니다: 프록시 배포 후 implementation 주소를 설정해 초기화합니다. 해커들은 이 둘 사이의 시간 차이를 악용합니다. 체인에서 프록시 배포를 감시하다가 초기화 전에 프런트런을 걸어 자신들의 악성 implementation을 설정해 버립니다. 그렇게 되면—끝입니다—프록시는 이제 자금을 탈취하거나 시스템을 망가뜨릴 수 있는 코드로 향하게 됩니다.

과거에는 공격자들이 MEV(Miner Extractable Value)를 이용해 트랜잭션을 프런트런했습니다. MEV는 블록 생성자가 이익을 위해 트랜잭션 순서를 재정렬하는 것을 의미하며, 종종 악의적으로 사용됩니다. Shutter Network 같은 솔루션이 있긴 하지만 아직 널리 보급되진 않았습니다. 그런데 최근 문제는 Base 같은 Coinbase의 Layer-2에서 이런 일이 발생하고 있다는 점입니다. Base는 중앙화된 sequencer로 트랜잭션 순서를 제어하므로 전형적인 MEV는 존재하지 않습니다. 그렇다면 해커들은 어떻게 성공시키고 있을까요? 아마도 배포를 감시하는 봇을 돌리거나 이전에도 있었던 JSON-RPC 공급자의 누수(leaks)를 악용하는 방식일 가능성이 큽니다.

심지어 Etherscan 같은 블록 탐색기조차 속았습니다. 공격자들은 하나의 프런트런 트랜잭션에서 두 개의 서로 다른 프록시 슬롯을 설정해 놨습니다: Etherscan이 먼저 확인하는 오래된 OpenZeppelin 슬롯에는 무해한 주소를, 표준 EIP-1967 슬롯에는 악성 주소를 넣는 식이었죠. 교묘합니다.

Base에서 발견된 공격자는 FixedFloat(해커들 사이에 인기 있는 브리지)를 통해 자금을 충당받았고, 이는 이전 캠페인들과의 연관성을 보여 줍니다. 한 피해자는 Gnosis Safe를 사용해 배포했는데, Base에서 배포한 지 단 두 블록 만에 제어권을 잃었습니다.

그렇다면 어떻게 스스로를 보호할 수 있을까요? 핵심은 배포와 초기화를 단일 트랜잭션으로 처리하는 것입니다. Foundry 스크립트 같은 도구가 도움이 되고, 영감을 얻을 수 있는 접근 방법도 있습니다. 멀티체인에서 주소 일관성을 유지하려면 emo.eth가 만든 Deterministic Proxy Factory를 시도해 보세요—이 방법은 체인 간에 같은 주소를 보장합니다.

Base 같은 레이어-2에서는 항상 sequencer에 직접 브로드캐스트해 mempool 누수를 피하세요. web3-ethereum-defi 같은 라이브러리가 이를 처리해 줄 수 있습니다. 자세한 내용은 이 Ethereum Stack Exchange 토론을 참고하세요.

블록 번호를 포함한 전체 사건을 보면 이런 호출들이 얼마나 근접하게 일어날 수 있는지 알 수 있습니다. 개발자라면 Ethereum Security Researchers Telegram 그룹에 참여해 지속적인 토론과 팁을 얻으세요.

빠른 배포가 빈번한 밈 토큰 세계에서는 이런 취약점이 프로젝트에 재앙을 불러올 수 있습니다. 안전하게 행동하고, 프로세스를 감사하며, 블록체인에서는 속도와 보안이 함께 가야 한다는 점을 잊지 마세요. 질문이 있다면 댓글에 남기거나 전문가들에게 문의하세요!