1월 18일, 저희 모니터링 시스템은 AnySwap 프로젝트(일명 Multichain)에 대한 공격을 감지했습니다. 이 취약점은 결함이 있는 anySwapOutUnderlyingWithPermit() 함수로 인해 발생하며, 해당 함수의 검증 메커니즘을 우회하여 승인된 토큰을 인출할 수 있습니다.
프로젝트 측은 피해를 입은 사용자들에게 알리기 위해 다양한 접근 방식(예: 그림 1에 표시된 것처럼 사용자에게 트랜잭션 전송)을 채택했지만, 일부 사용자들은 자신의 자금을 보호하기 위한 적시 조치(즉, 승인 취소)를 취하지 못했습니다. 그 결과, 공격자들은 지속적으로 공격을 감행하여 피해자의 자금을 탈취할 수 있었습니다.
잠재적 피해자를 보호하기 위해, 충분한 숙고 끝에 저희 팀은 이더리움에서 AnySwap 취약 컨트랙트(0x6b7a87899490EcE95443e979cA9485CBE7E71522)에 대한 긴급 구제를 수행하기로 결정했습니다. 구체적으로, 취약한 계정의 자금을 이더리움의 멀티시그 지갑(0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47)인 저희 화이트햇 지갑으로 이전할 수 있습니다.
화이트햇 구제 작업의 투명성을 확보하기 위해, 저희는 의도를 PDF 파일에 문서화하고 파일 해시를 커뮤니티와 공유했습니다. 이를 통해 저희의 긴급 구제를 공격과 구별할 수 있으며, 동시에 세부 정보는 유출하지 않았습니다(취약점이 여전히 악용될 수 있기 때문). 저희는 2022년 1월 21일부터 2022년 3월 11일까지 긴급 구제를 진행했으며, 관련 메시지는 다음과 같이 공개되었습니다:
긴급 구제는 결코 간단한 작업이 아니었습니다. 실제로 성공적인 구제를 위해 기술적, 비기술적 문제를 포함한 여러 가지 도전 과제가 존재했습니다. 긴급 구제가 이미 종료된 만큼, 저희는 전체 과정을 종합적으로 검토하고 배운 교훈을 공유할 수 있습니다. 저희는 이 경험이 DeFi 생태계 보안에 일부 시사점을 제공할 수 있다고 믿습니다.
핵심 요약 (TL;DR)
- 화이트햇과 공격자를 포함한 다양한 참여자들 간의 경쟁이 존재합니다. Flashbots에 대한 수수료 지불이 시간이 지남에 따라 급격히 증가했습니다.
- Flashbots가 항상 작동하지는 않았습니다. 일부 공격자들은 정교한 전략을 채택하여 일반 멤풀을 사용해 성공적인 공격을 감행했습니다.
- 일부 공격자는 탈취한 자금의 일부를 반환하여 면죄부를 받았으며, 나머지는 바운티 보상으로 유지되었습니다. 이 현상은 처음 등장한 것은 아니지만, 그러한 인센티브가 진정한 화이트햇에게 공정하지 않을 수 있기 때문에 커뮤니티에서 논란이 되고 있습니다.
- 커뮤니티를 설득하기 위해, 화이트햇은 민감한 세부 정보를 유출하지 않으면서 행동을 사전에 공개적으로 알리는 것이 좋은 관행입니다.
- 커뮤니티는 구제 작업을 더 효과적이고 효율적으로 수행하기 위해 협력할 수 있습니다. 예를 들어, 화이트햇 간의 경쟁을 줄이거나 방지하기 위한 조율 메커니즘을 구축하는 것입니다.
이하에서는 먼저 이 기간 동안의 구제 작업 전체 그림을 제시합니다. 그런 다음 저희가 구제를 수행한 방법과 해결해야 할 과제를 설명합니다. 이후 구제 작업에서 배운 교훈을 논의합니다. 마지막으로, 생태계를 보호하는 데 의미 있을 수 있는 몇 가지 생각/제안을 제공합니다.
0x1 구제 및 공격
0x1.1 전체 결과
이 보고서에서 조사하고 관찰한 공격과 구제는 블록 14028474(2022년 1월 18일)부터 블록 14421215(2022년 3월 20일)까지 수개월간 지속되었습니다.
구제 및 공격을 수행한 계정은 다음 표에 요약되어 있습니다. 간결성을 위해 EOA를 나타내기 위해 주소의 처음 네 자리만 제공됩니다. 계정은 구제 계정 또는 공격 계정으로 분류됩니다. 계정 유형은 Etherscan.io에서 표시한 레이블 또는 저희가 관찰한 전송 목적지 주소를 기반으로 결정된다는 점에 유의할 가치가 있습니다.
총 9개의 구제 계정이 483.027693 ETH를 구제했으며(수수료 295.970554 ETH, 즉 총액의 61.27%), 21개의 공격 계정이 1433.092224 ETH를 탈취했습니다(수수료 148.903707 ETH, 즉 총액의 10.39%). 일부 복잡한 상호작용으로 인해 손실액은 대략적인 추정치임을 유의하시기 바랍니다. 예를 들어, 공격 계정이 AnySwap과의 협상 후 구제 계정으로 전환될 수 있으며, 이러한 현상은 나중에 논의하겠습니다. 표의 마지막 열은 Flashbots 사용 경쟁에서 이기기 위해 채굴자에게 전송된 수수료를 나타냅니다.
| 번호 | 계정 | 유형 | 피해자 수 | 손실액 (ETH) | 수수료 (ETH) |
|---|---|---|---|---|---|
| 1 | 0x14ca** | 구제 계정 | 50 | 432.958062 | 287.849654 |
| 2 | 0x9a65** | 구제 계정 | 23 | 22.569429 | 0.000000 |
| 3 | 0x9117** | 구제 계정 | 14 | 18.897622 | 7.213585 |
| 4 | 0x17d2** | 구제 계정 | 3 | 3.552833 | 0.000000 |
| 5 | 0x6360** | 구제 계정 | 21 | 3.540061 | 0.907168 |
| 6 | 0x0edd** | 구제 계정 | 7 | 1.498706 | 0.000000 |
| 7 | 0x281e** | 구제 계정 | 1 | 0.006000 | 0.000000 |
| 8 | 0xd83b** | 구제 계정 | 1 | 0.004000 | 0.000000 |
| 9 | 0x8af3** | 구제 계정 | 6 | 0.000980 | 0.000147 |
| 10 | 0x4986** | 공격 계정 | 332 | 456.004547 | 0.000000 |
| 11 | 0xfa27** | 공격 계정 | 42 | 433.438935 | 46.636389 |
| 12 | 0x48e9** | 공격 계정 | 66 | 312.014657 | 0.000000 |
| 13 | 0x5738** | 공격 계정 | 67 | 83.589240 | 62.587238 |
| 14 | 0x34b2** | 공격 계정 | 7 | 63.599821 | 20.642705 |
| 15 | 0xd374** | 공격 계정 | 86 | 45.452703 | 12.824763 |
| 16 | 0x1fe7** | 공격 계정 | 9 | 12.817241 | 0.000000 |
| 17 | 0x98f5** | 공격 계정 | 20 | 8.381273 | 0.000000 |
| 18 | 0x455d** | 공격 계정 | 11 | 5.047377 | 0.544263 |
| 19 | 0x1b45** | 공격 계정 | 6 | 4.942442 | 3.074813 |
| 20 | 0x3ec7** | 공격 계정 | 6 | 3.705686 | 0.741137 |
| 21 | 0xbca4** | 공격 계정 | 1 | 2.784250 | 1.392125 |
| 22 | 0xb0ab** | 공격 계정 | 18 | 0.834068 | 0.296000 |
| 23 | 0x0a5b** | 공격 계정 | 1 | 0.286750 | 0.143375 |
| 24 | 0x2d3a** | 공격 계정 | 2 | 0.080090 | 0.000000 |
| 25 | 0x835d** | 공격 계정 | 5 | 0.063945 | 0.000000 |
| 26 | 0x1dbd** | 공격 계정 | 1 | 0.027431 | 0.012893 |
| 27 | 0x813d** | 공격 계정 | 1 | 0.019528 | 0.008007 |
| 28 | 0x85dd** | 공격 계정 | 6 | 0.002240 | 0.000000 |
| 29 | 0x2394** | 공격 계정 | 1 | 0.000000 | 0.000000 |
| 30 | 0x6360** | 공격 계정 | 2 | 0.000000 | 0.000000 |
0x1.2 Flashbots 입찰 수수료 추세
앞서 언급한 바와 같이, 화이트햇은 트랜잭션을 전송하기 위해 공격자들과 경쟁해야 합니다. 따라서 (Flashbots 트랜잭션에서) 채굴자에게 지불하는 수수료 비율은 경쟁 수준을 반영할 수 있습니다. 이를 정량적으로 측정하기 위해, 각 블록에 대한 수수료 비율(공격 트랜잭션과 구제 트랜잭션 각각 포함)을 조사했습니다.
그림 4는 현재까지(블록 14028474부터 블록 14369199까지) 관찰한 추세를 보여줍니다. 처음 몇 번의 공격 트랜잭션에는 수수료가 포함되지 않았으며, 이는 해당 기간 동안 경쟁이 거의(심지어 전혀) 없었음을 의미합니다. 이는 초기 공격이 다른 사람들에게 잘 알려지지 않았을 수 있기 때문에 합리적입니다.
실제로, 수수료가 있는 첫 번째 공격 트랜잭션(10%)은 블록 14029765에서 발생했습니다. 그 이후로 더 많은 참여자가 개입함에 따라 수수료 비율이 급격히 증가했습니다. 예를 들어, 블록 14072385에서 비율이 80%에 도달했으며, 블록 14129449에서 곧 91%에 달했습니다.
요약하면, 이 추세는 채굴자(들)에게 더 많은 수수료를 지정하여 경쟁에서 이기려는 것이 분명히 군비 경쟁임을 시사합니다.
0x2 저희의 구제 및 과제
0x2.1 구제 수행 방법
구제를 수행하는 기본 아이디어는 매우 간단합니다. 구체적으로, 취약한 컨트랙트에 WETH를 승인한 계정을 모니터링해야 합니다. 해당 계정으로 WETH가 전송될 때, 취약한 AnySwap 컨트랙트를 악용하여 이를 저희 멀티시그 지갑으로 직접 전송할 수 있습니다. 주요 요구 사항은 다음과 같습니다:
- R1: 피해자 계정으로 토큰을 전송하는 트랜잭션을 효율적으로 찾아내는 것. 이하에서는 이러한 트랜잭션을 전송 TX라고 합니다.
- R2: 구제를 수행하기 위한 트랜잭션을 올바르게 작성하는 것. 이하에서는 이러한 트랜잭션을 구제 TX라고 합니다.
- R3: 공격자(및 기타 제3자)가 보낸 트랜잭션보다 앞서 실행하는 것. 이하에서는 이러한 트랜잭션을 공격 TX라고 합니다.
R1과 R2는 저희에게 장애물이 아닙니다. 구체적으로, 저희는 멤풀을 모니터링하는 내부 시스템을 구축하여 전송 트랜잭션을 적시에 찾아낼 수 있습니다. 동시에, 트랜잭션을 자동으로 구성하는 도구도 개발했습니다.
그러나 R3은 여전히 도전 과제입니다. Flashbots를 사용하여 경쟁에서 이길 수 있을 것으로 예상할 수 있습니다. 하지만 이 목표를 달성하는 것은 그리 쉽지 않습니다. 첫째, 공격자들도 Flashbots를 채택할 수 있습니다. 수수료 입찰 시스템으로서 성공률은 채굴자에게 지정된 수수료에 따라 달라질 수 있습니다. 수수료 설정 전략을 결정해야 합니다. 둘째, 치열한 경쟁으로 인해 Flashbots를 사용하는 것이 좋은 선택이 아닐 수 있습니다. 따라서 저희는 멤풀을 사용하는 일반 트랜잭션도 전송합니다. 성공을 보장하기 위해 올바른 위치에 트랜잭션을 배치하는 전략을 고려해야 합니다. 마지막으로, 일부 경우에 의심스러운 행동을 보이는 다른 화이트햇과도 경쟁해야 합니다.
0x2.2 저희가 관여한 경쟁
저희는 총 171명의 잠재적 피해자를 보호하려 시도했으며, 그 중 10명은 저희가 구제를 시도하기 직전에 승인을 취소하여 스스로를 보호했습니다. 나머지 161명의 유효한 피해자 중, 저희는 경쟁으로 인해 14명만 성공적으로 구제할 수 있었습니다. 실패 사례는 3개의 구제 계정과 16개의 공격 계정을 포함하여 다음 표에 요약되어 있습니다.
| 번호 | 계정 | 유형 | 피해자 수 | 손실액 (ETH) | 수수료 (ETH) | 평균 수수료 비율 |
|---|---|---|---|---|---|---|
| 1 | 0x14ca** | 구제 계정 | 44 | 431.651020 | 286.891724 | 66.46% |
| 2 | 0x9a65** | 구제 계정 | 7 | 11.321441 | 0.000000 | 0.00% |
| 3 | 0x6360** | 구제 계정 | 3 | 3.300000 | 0.891000 | 27.00% |
| 4 | 0x48e9** | 공격 계정 | 35 | 301.681589 | 0.000000 | 0.00% |
| 5 | 0x5738** | 공격 계정 | 58 | 78.482472 | 58.851862 | 74.99% |
| 6 | 0x34b2** | 공격 계정 | 2 | 53.591712 | 17.685265 | 33.00% |
| 7 | 0xd374** | 공격 계정 | 6 | 23.658698 | 10.073638 | 42.58% |
| 8 | 0x4986** | 공격 계정 | 16 | 22.900105 | 0.000000 | 0.00% |
| 9 | 0x1fe7** | 공격 계정 | 6 | 12.057241 | 0.000000 | 0.00% |
| 10 | 0x1b45** | 공격 계정 | 5 | 4.402442 | 3.010013 | 68.37% |
| 11 | 0xbca4** | 공격 계정 | 1 | 2.784250 | 1.392125 | 50.00% |
| 12 | 0x98f5** | 공격 계정 | 8 | 2.339543 | 0.000000 | 0.00% |
| 13 | 0x455d** | 공격 계정 | 3 | 0.741817 | 0.175454 | 23.65% |
| 14 | 0xfa27** | 공격 계정 | 3 | 0.320288 | 0.032590 | 10.18% |
| 15 | 0x0a5b** | 공격 계정 | 1 | 0.286750 | 0.143375 | 50.00% |
| 16 | 0x3ec7** | 공격 계정 | 1 | 0.245000 | 0.049000 | 20.00% |
| 17 | 0xee7e** | 공격 계정 | 1 | 0.190000 | 0.096900 | 51.00% |
| 18 | 0x835d** | 공격 계정 | 3 | 0.024533 | 0.000000 | 0.00% |
| 19 | 0xb0ab** | 공격 계정 | 1 | 0.000618 | 0.000000 | 0.00% |
따라서 저희가 커뮤니티와 공유하고자 하는 몇 가지 교훈이 있습니다.
0x3 배운 교훈
0x3.1 Flashbots 채굴자에게 지불할 수수료를 어떻게 결정할 것인가?
요약하면, 저희는 Flashbots를 사용하는 2개의 구제 계정과 10개의 공격 계정을 포함한 12명의 경쟁자에게 패배했습니다.
채굴자 수수료를 설정하는 저희 전략은 상당히 보수적이었습니다. 구체적으로, 저희는 가능한 한 적은 수수료를 지출하여 피해자를 보호하는 것을 목표로 했습니다. 따라서 성공적인 공격 TX가 이미 수수료를 설정한 경우가 아니면 수수료를 적극적으로 사용하거나 늘리지 않았습니다. 예를 들어, 공격자가 자금의 10%를 수수료로 설정한다면, 저희는 다음 구제에서 11%를 사용하여 해당 공격자와 경쟁할 수 있었습니다. 그러나 결과는 이 전략이 효과가 없었음을 시사합니다. 공격자들(심지어 일부 화이트햇들)이 다음과 같이 다른 사람들을 이기기 위해 종종(항상은 아니더라도) 공격적으로 수수료를 늘렸기 때문입니다:
- 그림 5는 공격자 0x5738**이 블록 14071986에서 수수료 비율을 70%로 설정했음을 보여줍니다.
- 그림 6은 화이트햇 0x14ca**이 블록 14072255에서 수수료 비율을 79%로 설정했음을 보여줍니다.
- 그림 7은 화이트햇 0x14ca**이 블록 14072385에서 수수료 비율을 80%로 설정했음을 보여줍니다.
- 그림 8은 화이트햇 0x9117**이 블록 14072417에서 수수료 비율을 81%로 설정했음을 보여줍니다.
- 그림 9는 공격자 0x5738**이 블록 14073395에서 수수료 비율을 86%로 설정했음을 보여줍니다.
간단히 말해, 이는 경쟁에서 이기기 위해 다양한 참여자들의 행동을 모델링해야 하는 제로섬 게임인 것 같습니다.
그러나 실제로는 더 나은/최적의 전략을 찾아내면서 동시에 비용을 최대한 줄이는 것은 어렵습니다.
0x3.2 멤풀에서 올바른 위치를 어떻게 설정할 것인가?
이제 구제는 Flashbots를 입찰하기 위한 수수료 경쟁의 군비 경쟁에 의존하는 것처럼 보입니다. 그러나 저희는 구제 및 공격과 무관한 다른 참여자들의 치열한 경쟁으로 인해 Flashbots 사용이 만병통치약이 아님을 발견했습니다. 이러한 경우, 공격 TX가 지정한 가장 높은 수수료조차 Flashbots 사용 기회를 보장할 수 없습니다.
대안으로, 멤풀에서 올바른 위치에 있는 일반 트랜잭션이 목표를 달성할 기회를 가질 수 있습니다. 여기서 올바른 위치란 구제/공격 TX가 전송 TX 뒤에 배치되어야 하며, 전송 TX에 매우 가까운 위치여야 한다는 것을 의미합니다(가까울수록 좋습니다). 이 전략을 사용하여 공격자 0x48e9**가 Flashbots 채굴자에게 수수료를 지불하지 않고 312.014657 ETH를 탈취했습니다.
다음 네 그림은 공격자가 얻은 상위 2개의 최대 수익을 보여줍니다:
- 그림 10은 피해자가 블록 14051020의 위치 65에서 50 ETH를 입금했음을 보여주며, 그림 11은 공격자가 같은 블록의 위치 66에서 50 ETH를 탈취했음을 보여줍니다.
- 그림 12는 피해자가 블록 14052155의 위치 161에서 200 ETH를 입금했음을 보여주며, 그림 13은 공격자가 같은 블록의 위치 164에서 200 ETH를 탈취했음을 보여줍니다.
분명히, 이 정교한 전략은 매우 유용하고 시사하는 바가 크며, 더 많은 주목과 연구가 필요합니다.
0x4 기타 생각
0x4.1 화이트햇 해킹인가, 공격인가?
화이트햇 해킹의 인정에 관해서는, 일반적으로 예상하는 것만큼 간단하지 않을 수 있습니다.
예를 들어, 주소 0xfa27은 Etherscan.io에서 **Multichain Exploiter 4 (Whitehat)**로 레이블이 붙었습니다. 실제로 처음에는 Multichain Exploiter 4로 레이블이 붙었습니다. 공격자와 AnySwap 프로젝트 간의 여러 차례 협상 끝에, 공격자는 탈취한 자금의 일부를 반환하도록 설득되었습니다.
- TX 0x3c3d**에서, AnySwap이 공격자에게 연락했습니다:
먼저 weth를 확보해 주셔서 감사합니다. 저는 해킹에 대해 몰랐고, cowswap 트랜잭션 후 weth가 제 지갑에 도착하지 않아서야 상황을 알게 되었습니다. 관련된 금액을 고려할 때, 50 ETH를 적절한 팁으로 받아들이시겠습니까? 제 트랜잭션은 다음과 같습니다: 0x2db9a6a51604e2be8b2c3469773afb201f0b48a318fb7e5f5e49175e818df5ba 0xe50ed602bd916fc304d53c4fed236698b71691a95774ff0aeeb74b699c6227f7
- TX 0xd360**에서, 공격자가 답변했습니다:
트랜잭션을 보내서 확인해 주세요. 나머지 258 ETH를 보내드리겠습니다. 다른 공격자들이 있어 채굴자에게 39 ETH를 팁으로 지불해야 했습니다.
- TX 0x354f**에서, AnySwap은 자금을 받은 후 감사의 뜻을 전했습니다:
잘 받았습니다, 정직함에 감사드립니다.
분명히, 이 공격자는 면죄부를 받고 공격에서 이익도 얻었습니다. 비슷한 사례가 과거에 여러 번 발생했으며, 그러한 인센티브가 공정하지 않을 수 있기 때문에 커뮤니티에서 여전히 논란이 되고 있습니다.
0x4.2 화이트햇 해킹 간의 경쟁?
화이트햇 간의 경쟁을 줄이거나 방지하기 위한 조율 메커니즘을 구축하는 것이 필요합니다. 이러한 경쟁은 불가피하게 구제 역량의 낭비로 이어집니다. 이번 구제에서, 저희도 구제를 시도하는 동안 다른 세 명의 화이트햇에 의해 보호된 54명의 피해자(450 ETH 자금)가 있었습니다.
화이트햇 간의 경쟁은 구제 역량을 낭비할 뿐만 아니라 구제 비용도 증가시켰습니다. 예를 들어, 그림 7과 그림 8에서 보듯이, 두 명의 서로 다른 화이트햇이 보낸 두 구제 TX의 수수료는 각각 80%와 81%입니다.
불행히도, 서로 조율하는 메커니즘이 존재하지 않는 한 화이트햇들은 물러서지 않을 것입니다. 그렇지 않으면 경쟁을 없애는 것은 불가능합니다.
0x4.3 더 나은 구제를 위한 방법
한편으로는, 커뮤니티를 설득하기 위해, 화이트햇은 민감한 세부 정보를 유출하지 않으면서 행동을 사전에 공개적으로 알리는 것이 좋은 관행입니다. 구제는 일반적으로 특정 공격을 차단하는 것과 같은 일회성 작업과 달리 여러 번의 시도가 있는 일진일퇴의 싸움이므로, 이를 위한 충분한 시간이 있습니다. 물론, 취약점에 관한 세부 정보는 유출되어서는 안 됩니다.
이를 달성하기 위해, 세부 정보는 처음에 공개되지 않고 구제 완료 후 커뮤니티에 공개될 것입니다. 이는 저희가 AnySwap 구제에서 했던 것과 같습니다. 그러나 화이트햇 의도가 담긴 문서의 해시는 커뮤니티와 공유할 수 있습니다.
다른 한편으로는, 커뮤니티는 구제를 더 효과적이고 효율적으로 수행하기 위해 더 많은 일을 할 수 있습니다, 이에 국한되지 않고:
- Flashbots/채굴자는 인증된 화이트햇을 위한 그린 채널을 제공할 수 있습니다. 그린 채널은 공격자의 TX를 앞서 실행할 수 있는 높은 우선순위를 제공하고, 화이트햇 간의 경쟁을 피할 수 있습니다.
- 공격받은 프로젝트가 Flashbots/채굴자 비용을 부담합니다.
- 프로젝트는 사용자에게 편리하고 빠른 알림 메커니즘을 적용할 수 있습니다.
- 프로젝트는 코드에 긴급 메커니즘을 적용할 수 있습니다.
BlockSec 소개
BlockSec은 2021년 세계적으로 저명한 보안 전문가 그룹에 의해 설립된 선구적인 블록체인 보안 회사입니다. 이 회사는 대중적 채택을 촉진하기 위해 신흥 Web3 세계의 보안과 사용성을 향상시키는 데 전념하고 있습니다. 이를 위해 BlockSec은 스마트 컨트랙트 및 EVM 체인 보안 감사 서비스, 보안 개발 및 위협 사전 차단을 위한 Phalcon 플랫폼, 자금 추적 및 조사를 위한 MetaSleuth 플랫폼, 그리고 크립토 세계에서 효율적으로 서핑하는 web3 빌더를 위한 MetaSuites 확장 프로그램을 제공합니다.
현재까지 회사는 MetaMask, Uniswap Foundation, Compound, Forta, PancakeSwap과 같은 300개 이상의 저명한 고객에게 서비스를 제공했으며, Matrix Partners, Vitalbridge Capital, Fenbushi Capital을 포함한 저명한 투자자들로부터 두 차례의 자금 조달에서 수천만 달러를 받았습니다.
공식 웹사이트: https://blocksec.com/
공식 트위터 계정: https://twitter.com/BlockSecTeam
