Validator’s Note 9 — 미끼를 확 물어분 것이여(feat. 샌드위치 봇)
Disclaimer: 이 글은 정보 전달을 위한 목적으로 작성되었으며, 특정 프로젝트에 대한 투자 권고, 법률적 자문 등 목적으로 하지 않습니다. 모든 투자의 책임은 개인에게 있으며, 이로 발생된 결과에 대해 어떤 부분에서도 DSRV는 책임을 지지 않습니다. 본문이 포괄하는 내용들은 특정 자산에 대한 투자를 추천하는 것이 아니며, 언제나 본문의 내용만을 통한 의사결정은 지양하시길 바랍니다. 추가적으로 이 글이 쓰여진 시점과 현재 모두 DSRV는 이더리움의 벨리데이터로 참여하고 있음을 알려드립니다.
지난주 이더리움 생태계에서는 밸리데이터가 Mev-boost relay들의 취약점을 이용하여 여러 샌드위치 봇(sandwich bot)에게서 약 25M 달러를 탈취한 사건이 화제가 되었습니다.
MEV(Maximal Extracted Value)란 트랜잭션을 포함, 제외, 순서를 조정하여 얻을 수 있는 이득을 뜻합니다. MEV의 일종인 샌드위치 공격(Sandwich Attack)은 AMM(Automated Market Maker) 풀에서 자산을 교환하는 트랜잭션의 앞뒤로 자산 가격을 조작하는 트랜잭션을 배치하여 이익을 취하는 공격입니다. 공격자가 사용자의 트랜잭션 바로 앞에서 사용자가 교환하려는 자산을 매수하여 풀의 균형을 깨고 가격을 올려놓으면, 사용자는 더 높아진 가격으로 자산을 구매하여 지불한 금액보다 현저히 적은 양의 자산을 얻고 손해를 보게 됩니다. 사용자가 거래를 한 바로 뒤 트랜잭션에서 공격자가 매수했던 자산을 다시 판매하면 공격자는 사용자가 손해 본 만큼의 이익을 볼 수 있습니다. 샌드위치 봇은 멤풀(mempool)에서 공격 가능한 트랜잭션을 찾아 샌드위치 공격을 하는 프로그램입니다.
이 공격자는 16964664 블록에서 샌드위치 봇이 샌드위치 공격을 하려던 트랜잭션을 바꿔치기하여, 샌드위치 봇이 샌드위치 공격에 사용한 자금을 역으로 탈취하였습니다. 본 글에서는 그 과정과 어떻게 이러한 공격이 가능하였는지를 살펴보려 합니다.
어떻게 공격을 하였나?
1.우선 공격자는 블록을 생성할 권한을 얻기 위하여 자금의 출처를 숨길 수 있는 Aztec 브릿지를 통해 자금을 조달하여 밸리데이터를 등록하였습니다. [1] 공격자의 밸리데이터는 187922 에폭부터 활성화되었으며, 이후 공격자는 자신이 블록을 만들 권한을 얻을 때를 기다리며 계획을 준비합니다. 평균적으로 이더리움의 밸리데이터는 2달의 한 번꼴로 블록을 생성할 권한이 있는 proposer가 되지만 이 밸리데이터는 약 18일만에 6137846 슬롯의 proposer가 되었습니다. [2]
2.공격자는 공격 약 24일 전 부터 Uniswap V2에서 작은 STG/ETH pool을 만들어 샌드위치 봇을 유인하기 위한 준비를 시작합니다. 그리고 생성한 풀에서 의도적으로 자산을 교환하는 트랜잭션을 날려 샌드위치 봇들이 이 풀에 와서 샌드위치 공격을 하도록 유인하였습니다. 공격자는 공격 24일 전, 19일 전, 그리고 1일 전까지 미끼 트랜잭션을 날렸고 이에 봇들이 샌드위치 공격하였습니다. 공격자는 STG/ETH 풀 외에도 서로 다른 계정으로 UNI/WBTC, MKR/USDC, BIT/ETH, T/ETH, CRV/DAI, SHIB/USDC, AAVE/ USDT 등 여러 풀에서도 샌드위치 봇들이 공격할 수 있는 미끼 트랜잭션들을 전송하였습니다.
3.이더리움의 블록생성 매커니즘에 따라 두 에폭 전 자신이 어떤 슬롯의 proposer가 되었는지 알게 된 공격자는 다시 여러 풀에서 샌드위치 봇들을 유인하기 위한 미끼 트랜잭션들을 날렸고, 기존에 이득을 보았던 샌드위치 봇들은 의심 없이 다시 샌드위치 공격을 시도하였습니다. STG/WETH 풀 사례를 살펴보면, 샌드위치 봇은 풀의 균형을 깨트리기 위해 풀에 많은 ETH를 투입하여 STG로 교환하는 트랜잭션을 실행하였고, 공격 대상 트랜잭션 이후 STG를 ETH로 교환하여 다시 풀에 투입되었던 ETH를 반환하는 트랜잭션을 실행하려 하였습니다. 하지만 공격자는 샌드위치 봇이 노렸던 트랜잭션을 다른 트랜잭션으로 바꿔치기하여 이미 풀의 균형이 깨진 상태에서 적은 수의 STG로 샌드위치 봇이 풀에 투입했던 ETH를 모두 교환하여 가져갑니다. 결국 공격하려 했던 트랜잭션은 다른 트랜잭션으로 대체되었고, 대체된 트랜잭션으로 이미 풀에서 ETH가 모두 빠져나간 상황에서 STG를 다시 ETH로 교환하려던 샌드위치 봇의 다음 트랜잭션은 실패하게 됩니다.
4.공격자가 생성한 16964664 블록을 살펴보면 위와 같은 방식으로 8개의 샌드위치 공격에서 5개의 샌드위치 봇들이 자금을 탈취당한 것을 확인할 수 있습니다.
약 25M 달러에 달하는 탈취당한 자금들은 하나의 계정으로 수집되었으며, etherscan에는 해당 계정에 ‘Sandwich the Ripper’라는 네임택이 붙어있습니다. [3]
이후 Sandwich the Ripper뿐만 아니라 동일한 방법으로 샌드위치 봇을 탈취한 16개의 밸리데이터가 추가적으로 발견되었으며, 이들 또한 약 25M 달러의 이익을 본 것으로 확인되었습니다.
어떻게 블록을 조작하였나?
이더리움에서는 블록에 트랜잭션을 담고 순서를 정할 수 있는 밸리데이터들이 MEV 수익에 대한 권한을 독점하는 것을 방지하기 위하여 PBS(Proposer Builder Seperation), 즉 블록 내용을 만드는 builder와 블록을 생성하는 proposer로 밸리데이터의 역할을 분리하는 로드맵이 도입되었습니다. 프로토콜 단에 PBS가 구현되기 이전 플러그인 소프트웨어로 이 기능을 구현한 것이 바로 mev-boost입니다.
mev-boost를 실행하는 밸리데이터는 스스로 트랜잭션을 담아 블록을 만드는 대신, mev-boost relay를 통하여 MEV 트랜잭션들이 담긴 블록을 받게 됩니다. 이때 relay는 밸리데이터가 블록의 트랜잭션을 미리 확인하고 트랜잭션을 조작하여 MEV 이익을 가로챌 수 없도록, 블록 내용(body)을 제외한 블록 헤더(header)만을 밸리데이터에게 전달합니다. 밸리데이터가 블록 헤더에 사인을 하여 relay에게 전달하면, relay가 이를 받아 헤더와 블록 내용을 합쳐 완전한 블록을 만들어 다른 비콘 노드(BN)들에게 전파합니다. 그리고 밸리데이터들은 relay가 그들이 사인한 블록을 전파할 것이라는 것을 완전히 신뢰할 수 없으므로, relay가 전파하는 블록이 무엇인지를 전달받게 됩니다.
따라서 이론적으로는 mev-boost를 사용하는 밸리데이터가 블록 내용을 알고 트랜잭션을 조작하는 것은 매우 어렵습니다. 밸리데이터는 기본적으로 블록 내용을 알지 못한 채 블록에 사인을 하고, relay로부터 블록 내용을 전달받은 후에는 다시 새로운 블록을 relay보다 더 빠른 속도로 전파하여야 하며, 이때 같은 슬롯에서 두 개의 블록에 이중 서명을 하면 슬래시 당할을 감수해야 하기 때문입니다.
하지만 이번 사건에서는 relay에 존재하였던 취약점으로 인해 밸리데이터의 공격이 쉽게 성공하였습니다.
1.밸리데이터는 ultra sound money의 relay로부터 받은 블록 헤더의 parent root 와 state root를 0으로 바꿔, 유효하지 않게 만든 후 이에 사인을 하여 relay에게 전달하였습니다. 서명된 헤더를 받은 relay는 블록 내용과 합친 온전한 블록을 만들어 BN에 전파하려 했으나, 헤더가 유효하지 않았으므로 BN에서 reject 되어 전파되지 않았습니다.
2. 하지만 relay는 전파되지 않은 블록이었음에도 불구하고 해당 블록 내용을 밸리데이터에게 전달하였습니다. 밸리데이터는 블록 내용을 확인할 수 있었고, 트랜잭션을 변경하여 샌드위치 봇을 탈취하는 새로운 블록을 스스로 만들어 전파였습니다. relay가 전달한 블록은 유효하지 않아 BN에 전파되지 않았기 때문에, 밸리데이터는 쉽게 새로운 블록을 먼저 전파하여 슬롯에 포함시킬 수 있었습니다.
3. 이후 relay에게서 유효하지 않은 블록을 전달받았던 BN의 slasher는 새로운 블록을 보고, 밸리데이터가 같은 슬롯 높이에서 두개의 서로 다른 블록에 사인을 했다는 증거를 전파하였습니다. 따라서 해당 밸리데이터는 이후 슬래싱 당하였으나, 이미 슬래싱 당한 것보다 많은 이익을 얻을 수 있었습니다.
이에 대하여, flashbot의 mev-boost-relay에는 아래와 같은 패치가 적용되었습니다. [4]
1. relay가 BN에 블록을 성공적으로 전파하지 못한 경우 proposer에게 블록을 전달하지 않는다.
2. relay가 슬롯 시작 후 3초안에 proposer로부터 블록 헤더에 서명을 받지 못하면, proposer에게 블록을 전달하지 않는다.
이번 사건과 같은 방식의 공격을 방지하기 위하여 1번과 같은 패치가 적용되었지만, 여전히 proposer가 올바른 블록을 생성하고 다수의 BN을 이용하여 relay보다 빠르게 블록을 전파하는 공격(eclipse attack)을 감행하는 경우에 대해서는 별다른 대책이 없는 상황입니다.
뿐만 아니라 만약 밸리데이터가 두 슬롯 연속으로 블록을 생성하는 경우에는, relay에게 의도적으로 서명을 늦게 전달하여 첫 번째 슬롯에서는 블록 생성을 놓치더라도, 블록 내용을 확인한 후 두 번째 슬롯에서 공격을 할 수 있습니다. 따라서 이러한 공격을 방지하기 위하여, 3초의 제한 시간(cutoff)가 적용되었습니다.
하지만 이 제한 시간은 밸리데이터들의 블록 누락 비율을 증가시키기도 하였습니다. 현재 mev-boost를 통해 생성되는 블록이 전체의 약 87%에 달하고, 취약점이 발견된 오픈소스 mev-boost-relay, dreamboat를 기반으로 한 ultra sound money, flashbot, blocknative의 relay의 점유율이 약 55%에 달하기 때문에 전체적인 이더리움 네트워크 성능에 영향을 미치고 있는것으로 보입니다. [5]
제한 시간 도입 후 의도적으로 서명을 늦게 전달하는 것 외에도, 통신 지연 등으로 서명의 전달이 늦어진 밸리데이터들 또한 블록을 누락하는 사례가 많이 발생하게 되었습니다. 이 제한 시간은 처음 2초로 설정되었다가 블록을 누락하는 밸리데이터가 많아지자, (4/4일 10:00UTC) 3초로 조정되기도 하였으나, 블록 누락 비율은 계속해서 높게 나타났습니다. 블록 누락 비율은 4/4 2.24%까지 증가하였고, 현재(4/10) 약간은 감소하였지만 완전히 해결되지는 않은 상태로 보입니다.
또한 이렇게 밸리데이터들이 슬롯에서 블록 생성을 놓치거나(missed), 포크초이스룰(fork choice rule)에 의해 버려진 고아(orphaned) 블록이 많아지면, 블록에 대한 밸리데이터들의 attestation이 담길 공간이 부족해 지는 경우가 발생합니다. 결국 이러한 상황은 participation rate을 떨어 트리는 효과를 발생시켜, 네트워크에 안정성에 많은 영향을 미치고 있음을 알 수 있습니다.
Conclusion
Mev-boost, 더 나아가 PBS는 모두에게 공정한 MEV 기회를 제공하는 것을 목표로 합니다. 이와 같은 사건은 단편적으로는 사용자들에게 손해를 입히는 샌드위치 봇들이 벌을 받은 것처럼 보이지만, 조금 더 멀리 생각해보면 샌드위치 봇뿐만 아니라 다양한 MEV 기회를 탐색하는 참여자들이 자신이 찾은 MEV 기회를 빼앗기거나 공격받을 수 있다는 경우의 수를 우려하게 되고 MEV 시장의 신뢰를 떨어트리는 결과를 가져옵니다.
이번 사건은 MEV 시장에서 간과되었던 취약점과 공격 포인트들을 발견하였고 보다 건강하고 공정한 MEV 시장을 만들기 위한 연구의 필요성을 재조명하였습니다. flashbot에서 mev-boost-relay에 대하여 빠른 패치를 발표하였지만, relay의 변화에 따라 mev-boost 및 BN에 대한 패치도 이루어져야 합니다. 또한 위에서 살펴본 바와 같이 이더리움 네트워크의 성능 저하가 계속되고 있으며, MEV 시장의 신뢰에 대한 근본적인 원인을 해결한 것은 아니기 때문에 지속적인 연구 및 개선이 필요할 것으로 보입니다.
Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)
Reference
[1] https://etherscan.io/address/0x687a9414b0225092d4a8b859fe813f1f637d3383#internaltx
[2] https://beaconcha.in/validator/552061
[3] https://etherscan.io/address/0x3c98d617db017f51c6a73a13e80e1fe14cd1d8eb
[4] https://github.com/flashbots/mev-boost-relay/pull/330
[5] https://mevboost.pics/
