2022년 1월 18일 우리의 비정상 거래 모니터링 시스템은 AnySwap 프로젝트(즉, Multichain)에 대한 공격을 감지했습니다. anySwapOutUnderlyingWithPermit() 함수가 관련 검증 메커니즘을 올바르게 구현하지 못하기 때문에 사용자가 프로젝트에 권한을 부여한 토큰이 공격자에 의해 탈취될 수 있습니다. 프로젝트 파티(https://medium.com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8).
프로젝트 당사자는 영향을 받는 사용자에게 상기시키기 위해 다양한 방법을 시도했지만(예: 그림 1과 같이 트랜잭션 알림 보내기) 많은 사용자가 여전히 적시에 응답하지 못했으며(권한 철회) 공격자는 계속해서 수행할 수 있었습니다. 공격하고 이익을 얻습니다.
공격이 계속되자 BlockSec 팀은 잠재적인 피해자를 보호하기 위해 비상 대응 조치를 구현하기로 결정했습니다. 이 구조는 특히 이더리움의 영향을 받는 계정을 대상으로 합니다. 이와 관련된 프로젝트 계약 주소는 0x6b7a87899490EcE95443e979cA9485CBE7E71522입니다. 관련 계정 자금을 특별히 설정된 다중 서명 화이트햇 계정(0xd186540FbCc460f6a3A9e705DC6d240 6cBcc1C4)으로 이체합니다. 7).
조치의 투명성을 확보하기 위해 해당 조치 계획을 pdf 파일로 설명하고, 즉시 파일 해시(내용 아님)를 커뮤니티에 공개했습니다. 이렇게 하면 세부 정보를 공개하지 않고도 공격자의 작업과 우리의 작업을 구분할 수 있습니다(공격이 계속 진행 중이므로).
우리의 구조 작업은 2022년 1월 21일에 공식적으로 시작되었으며 2022년 3월 11일에 공식적으로 종료됩니다. 관련 공개 성명은 각각 그림 2와 그림 3에 나와 있습니다.
긴급 구조는 쉬운 일이 아니며 극복해야 할 다양한 기술 및 비기술적 문제가 있습니다. 운영이 종료되었기 때문에 전체 프로세스를 검토하고 관련 경험과 경험을 커뮤니티와 공유할 수 있었습니다. 우리는 이러한 공유가 커뮤니티와 DeFi 생태계의 보안에 도움이 되기를 희망하고 믿습니다.
간략한 요약(버전을 읽기에는 너무 깁니다)
서로 다른 진영의 참가자들은 화이트 햇 그룹과 공격자 그룹을 포함하여 각 그룹 내에서도 Flashbots의 광범위한 사용을 위해 치열하게 경쟁했으며 Flashbots에 지불하는 수수료도 시간이 지남에 따라 빠르게 증가했습니다.
Flashbot은 만병통치약이 아니며 항상 작동하는 것은 아닙니다. 일부 공격자는 멤풀로 전환하여 교묘한 전략으로 공격 거래를 정리하고 성공적으로 공격을 수행했습니다.
일부 공격자는 공격 수익금의 일부를 반환하고 공격 수익금의 일부를 보상으로 보유하기로 프로젝트 당사자와 합의했으며 성공적으로 세탁되었습니다. 이러한 현상은 처음이 아니며 인센티브의 공정성도 커뮤니티 내에서 큰 논란과 토론을 불러일으켰습니다.
투명성의 관점에서 White Hats는 민감한 정보를 공개하지 않고 자신의 행동을 커뮤니티에 공개적으로 발표할 수 있으며, 이러한 커뮤니티의 신뢰를 얻는 방법은 실제로 잘 작동합니다.
지역 사회의 모든 당사자가 함께 협력하여 구호 활동을 보다 신속하고 효과적으로 수행할 수 있습니다. 예를 들어 무효 경쟁을 줄이거나 피하기 위해 흰색 모자 간의 조정을 수행할 수 있습니다.
첫 번째 레벨 제목
보조 제목
0x1.1 전체 결과
우리의 관찰 범위(2022년 1월 18일 블록 높이 14028474에서 2022년 3월 20일 블록 높이 14421215까지) 내에서 전체 공격 및 구조 상황은 공격 또는 구조 계정 주소 통계에 관련된 이더리움에 따라 표 1에 표시됩니다. (표시의 편의를 위해 주소의 처음 4자리만 표시됩니다.) 구체적으로 계정 주소는 복구 계정 또는 공격 계정이며 Etherscan.io 태그와 자금 이체 주소를 기반으로 유형이 결정됩니다. 또한 공격 및 구조 과정에서 White Hats와 공격자 모두 Flashbot을 사용하여 대량의 거래를 전송했기 때문에 채굴자에게 추가 수수료를 지불해야 하며 이를 Flashbot 수수료라고 합니다.
보조 제목
0x1.2 Flashbots 수수료 추세
위에서 언급한 바와 같이 White Hats는 구조를 구현하기 위해 Flashbots 트랜잭션을 전송하기 위해 공격자와 경쟁해야 하며 Flashbots에 지불하는 수수료의 변화 추세는 경쟁의 강도를 반영할 수 있습니다. 정량적 평가를 위해 트랜잭션 블록에 따라 공격 및 구조 트랜잭션에 대한 Flashbots 수수료의 비율을 계산했습니다.
첫 번째 레벨 제목
보조 제목
0x2.1 구조 작업은 어떻게 수행합니까?
구조의 기본 아이디어는 간단하고 간단합니다. 특히 문제가 있는 프로젝트 당사자 계약에서 WETH를 사용하도록 승인한 잠재적 피해자 계정을 모니터링해야 합니다. 이 계정으로 WETH 전송이 있을 때 계약 허점을 사용하여 화이트 햇 다중 서명 지갑으로 직접 전송합니다. 여기서 핵심은 다음 세 가지 요구 사항을 충족하는 것입니다.
R1: 피해자의 계정으로 전송된 트랜잭션을 효과적으로 찾습니다.설명의 편의를 위해 이러한 트랜잭션을 아래에서 전송된 트랜잭션(transferred TXs)으로 명명합니다.
R2: 구조를 구현하기 위해 트랜잭션을 올바르게 구성 설명의 편의를 위해 이러한 트랜잭션을 아래 구조 트랜잭션(구조 TX)으로 명명합니다.
R3: 공격자(또는 다른 제3자) 트랜잭션 선점 성공 설명의 편의를 위해 아래에서 이러한 트랜잭션을 공격 트랜잭션(공격 TX)으로 명명합니다.
R1과 R2는 우리에게 방해가 되지 않습니다. mempool을 모니터링하는 내부 시스템을 구축했기 때문에 이체 트랜잭션을 적시에 찾을 수 있으며 동시에 복구 트랜잭션을 자동으로 구성하는 도구 세트도 개발했습니다.
보조 제목
0x2.2 우리가 참여하는 대회
전반적으로 우리는 171개의 고유한 잠재적 피해자 계정을 보호하려고 시도했습니다. 이 중 10개는 적시에 권한을 철회하여 자체 보호되었고 나머지 161개의 계정 중 위에서 언급한 다양한 경쟁이 존재하여 14개의 계정만 성공적으로 복구했습니다. 3개의 복구 계정과 16개의 공격 계정이 포함된 실패를 아래 표에 요약했습니다.
첫 번째 레벨 제목
보조 제목
0x3.1 Flashbots 수수료를 결정하는 방법은 무엇입니까?
구조 과정에서 우리는 2개의 구조 계정과 10개의 공격 계정을 포함하여 Flashbot을 악용한 12개의 경쟁사에 연속적으로 패배했습니다.
Flashbots 수수료 설정 전략은 비교적 보수적입니다. 특히 피해자의 이익을 보호하기 위해 항상 Flashbots 수수료를 가능한 한 낮게 설정하는 것을 선호합니다. 따라서 Flashbot을 사용한 성공적인 공격이 없는 한 Flashbot을 적극적으로 사용하거나 Flashbots 요금을 인상하지 않을 것입니다. 예를 들어 성공적인 공격 트랜잭션은 Flashbots 수수료율을 10%로 설정하고 다음 복구 트랜잭션에서 11%로 설정할 수 있습니다. 그러나 이러한 전술은 그다지 성공적인 것으로 입증되지 않았으며 공격자(일부 흰색 모자 포함)는 종종 다음과 같이 경쟁에서 이기기 위해 수수료를 설정하기 위해 더 공격적인 전술에 의존합니다.
그림 5는 블록 높이 14071986에서의 공격 트랜잭션을 보여주며 공격자 0x5738**은 비율을 70%로 설정했습니다.
그림 6은 블록 높이 14072255에서의 공격 트랜잭션을 보여주며 흰색 모자 0x14ca**는 비율을 79%로 설정했습니다.
그림 7은 블록 높이 14072385에서의 공격 트랜잭션을 보여주며 흰색 모자 0x14ca**는 비율을 80%로 설정합니다.
그림 8은 블록 높이 14072417에서의 공격 트랜잭션을 보여주며 흰색 모자 0x9117**은 비율을 81%로 설정합니다.
그림 9는 블록 높이 14073395에서의 공격 트랜잭션을 보여주며 공격자 0x5738**은 비율을 86%로 설정했습니다.
첫 번째 레벨 제목
0x3.2 mempool에서 트랜잭션 위치를 올바르게 정렬하는 방법은 무엇입니까?
현재 구조의 성공은 Flashbots 비용의 군비 경쟁에 달려 있는 것으로 보입니다. 그러나 차익 거래 등과 같이 공격/구제와 관련이 없는 다른 거래 발신자로부터 여러 당사자의 치열한 경쟁으로 인해 Flashbot이 항상 효과적인 것은 아니라는 사실을 발견했습니다. 이 경우 공격 거래소에서 설정한 가장 높은(다른 공격 및 구조 거래와 비교하여) Flashbots 수수료도 Flashbots 경쟁에서 승리하는 것을 보장하지 않습니다.
또 다른 가능한 접근 방식은 mempool을 통해 정상적인 트랜잭션을 보내는 것입니다. 트랜잭션이 올바른 위치에 배치되면 목표를 달성하는 것도 가능합니다. 여기서 적절한 위치는 공격/구제 트랜잭션이 이체 트랜잭션 이후에 있고 이체 트랜잭션과 매우 가깝다는 것을 의미합니다(가까울수록 좋으며 이상적으로는 이체 트랜잭션의 다음 위치에 있는 경우). 실제로 공격자 0x48e9**는 이 전략을 사용하여 Flashbots 수수료를 지불하지 않고 312.014657 ETH를 성공적으로 수확했습니다. 다음 네 가지 그래프는 공격자의 가장 수익성이 높은 두 가지 공격을 보여줍니다.
그림 10과 그림 11은 각각 블록 높이 14051020에서 피해자 0x3acb**의 전송 트랜잭션(전송 50 ETH)이 65에 있는 반면 공격 트랜잭션(이익 50 ETH)은 66에 있음을 보여줍니다.
그림 12와 그림 13은 각각 블록 높이 14052155에서 피해자 0xbea9**의 전송 트랜잭션(전송 200 ETH)이 161에 있는 반면 공격 트랜잭션(이익 200 ETH)은 164에 있음을 보여줍니다.
첫 번째 레벨 제목
보조 제목
0x4.1 흰 모자와 공격자를 구별하는 방법은 무엇입니까?
흰색 모자와 그들의 행동을 식별하는 것은 생각만큼 간단하지 않을 수 있습니다. 예를 들어, 계정 주소 0xfa27은 Etherscan.io에서 흰색 모자인 Multichain Exploiter 4(Whitehat)로 표시되었습니다. 그러나 처음에는 이 주소가 공격자로 표시되었습니다: Multichain Exploiter 4. 여기서 변경 사항은 프로젝트 당사자와 공격자 간의 상호 작용에서 비롯되며, 몇 차례의 협상 후 공격자는 보상으로 50 ETH 수익을 유지하고 다른 수익(Flashbots 수수료 공제 등)을 반환하기로 합의했습니다.
트랜잭션 0x3c3d**에서 프로젝트 당사자는 공격자에게 연락했습니다.
트랜잭션 0xd360**에서 공격자는 다음과 같이 응답합니다.
트랜잭션 0x354f**에서 프로젝트 당사자는 반환된 자금을 받은 후 감사를 표시했습니다.
보조 제목
0x4.2 흰 모자 간의 경쟁
보조 제목
0x4.3 구조 작업을 더 잘 수행하는 방법은 무엇입니까?
한편으로 투명성의 관점에서 White Hats는 민감한 정보를 공개하지 않고 자신의 행동을 커뮤니티에 공개적으로 발표할 수 있으며, 커뮤니티의 신뢰를 얻는 이 방법은 실제로 잘 작동합니다. 특정 공격에 대한 차단 임무에 비해 이러한 구조 작업은 일반적으로 흰색 모자와 공격자가 일정 기간 동안 여러 번 교전하는 줄다리기이므로 충분한 시간이있을 것입니다. 물론 작업 초기에는 취약점에 대한 자세한 내용을 공개할 필요가 없으므로 불필요한 피해가 발생하지 않습니다(단, 행동 의도를 기록한 파일 해시는 우리가 이 구조에서 했다) ; 작업이 끝난 후 이 정보는 커뮤니티에 완전히 공개되어야 합니다.
한편, 지역 사회의 모든 세력은 다음을 포함하되 이에 국한되지 않는 구조 작업을 보다 신속하고 효과적으로 수행하기 위해 협력할 수 있습니다.
Flashbots/Miner는 인증되고 신뢰할 수 있는 화이트 햇에 녹색 채널을 제공하여 트랜잭션을 급히 공격하고 화이트 햇 간의 경쟁을 피하는 데 사용할 수 있습니다.
공격을 받은 프로젝트 당사자는 Flashbots 수수료 비용을 책임집니다.
프로젝트 당사자는 적시에 사용자에게 경고하기 위해 더 편리하고 빠른 메커니즘을 채택합니다.
프로젝트 당사자는 코드에서 몇 가지 필요한 긴급 조치를 채택합니다.
