Vào ngày 18 tháng 1 năm 2022, hệ thống giám sát giao dịch bất thường của chúng tôi đã phát hiện một cuộc tấn công vào dự án AnySwap (tức là Multichain). Vì hàm anySwapOutUnderlyingWithPermit() không triển khai đúng cơ chế xác minh có liên quan, nên kẻ tấn công có thể lấy đi mã thông báo được người dùng ủy quyền cho dự án. bên dự án (https://medium.com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8).

Mặc dù bên dự án đã thử nhiều phương pháp khác nhau để nhắc nhở những người dùng bị ảnh hưởng (chẳng hạn như gửi lời nhắc giao dịch, như trong Hình 1), nhưng nhiều người dùng vẫn không phản hồi kịp thời (rút lại ủy quyền của họ) và những kẻ tấn công vẫn có thể tiếp tục thực hiện tấn công và kiếm lợi nhuận.

Khi cuộc tấn công tiếp tục, nhóm BlockSec đã quyết định thực hiện các biện pháp ứng phó khẩn cấp để bảo vệ các nạn nhân tiềm năng. Cuộc giải cứu này đặc biệt nhắm vào tài khoản bị ảnh hưởng trên Ethereum. Địa chỉ hợp đồng dự án được liên kết với nó là 0x6b7a87899490EcE95443e979cA9485CBE7E71522. Chúng tôi sẽ chuyển tiền tài khoản có liên quan sang tài khoản mũ trắng đa chữ ký được thiết lập đặc biệt của chúng tôi (0xd186540FbCc460f6a3A9e705DC6d240 6cBcc1C4 7).

Để đảm bảo tính minh bạch của hành động, chúng tôi đã giải thích kế hoạch hành động có liên quan trong tệp pdf và ngay lập tức phát hành tệp băm (không phải nội dung) cho cộng đồng. Điều này đảm bảo rằng hành động của chúng tôi có thể được phân biệt với hành động của kẻ tấn công mà không tiết lộ bất kỳ chi tiết nào (vì cuộc tấn công vẫn đang tiếp diễn).

Chiến dịch giải cứu của chúng tôi chính thức bắt đầu vào ngày 21 tháng 1 năm 2022 và sẽ chính thức kết thúc vào ngày 11 tháng 3 năm 2022. Các tuyên bố công khai có liên quan lần lượt được trình bày trong Hình 2 và Hình 3.

Cứu hộ khẩn cấp không phải là một nhiệm vụ dễ dàng và có nhiều thách thức kỹ thuật và phi kỹ thuật cần vượt qua. Vì hoạt động đã kết thúc, chúng tôi đã có thể xem lại toàn bộ quá trình và chia sẻ kinh nghiệm và trải nghiệm có liên quan với cộng đồng. Chúng tôi hy vọng và tin rằng những chia sẻ như vậy sẽ hữu ích cho cộng đồng và tính bảo mật của hệ sinh thái DeFi.

Tóm tắt ngắn gọn (quá dài để đọc phiên bản)

• Những người tham gia từ các phe khác nhau đã cạnh tranh khốc liệt để sử dụng rộng rãi Flashbot, bao gồm cả nhóm mũ trắng và những kẻ tấn công, và thậm chí trong các nhóm tương ứng của họ, và phí trả cho Flashbot cũng tăng nhanh theo thời gian.

• Flashbots không phải là thuốc chữa bách bệnh và không phải lúc nào cũng hoạt động. Một số kẻ tấn công đã chuyển sang mempool, sắp xếp các giao dịch tấn công thông qua các chiến lược thông minh và thực hiện thành công cuộc tấn công.

• Một số kẻ tấn công đã đạt được thỏa thuận với bên dự án để trả lại một phần số tiền thu được từ cuộc tấn công và giữ lại một phần số tiền thu được từ cuộc tấn công làm phần thưởng, phần thưởng đã được rửa thành công. Hiện tượng này không phải là lần đầu tiên và tính công bằng của các ưu đãi của nó cũng đã gây ra tranh cãi và thảo luận lớn trong cộng đồng.

• Từ góc độ minh bạch, mũ trắng có thể công khai hành động của mình với cộng đồng mà không tiết lộ thông tin nhạy cảm, cách lấy lòng tin của cộng đồng này hoạt động tốt trong thực tế.

• Tất cả các bên trong cộng đồng có thể làm việc cùng nhau để thực hiện các hoạt động cứu trợ nhanh chóng và hiệu quả hơn. Ví dụ, sự phối hợp giữa các mũ trắng có thể được thực hiện để giảm hoặc tránh cạnh tranh không hợp lệ.

tiêu đề cấp đầu tiên

tiêu đề phụ

Kết quả tổng thể 0x1.1

Trong phạm vi quan sát của chúng tôi (từ chiều cao khối 14028474 vào ngày 18 tháng 1 năm 2022 đến chiều cao khối 14421215 vào ngày 20 tháng 3 năm 2022), tình hình tấn công và giải cứu tổng thể được trình bày trong Bảng 1, theo thống kê địa chỉ tài khoản của Ethereum liên quan đến cuộc tấn công hoặc giải cứu (để thuận tiện cho việc hiển thị, chỉ 4 chữ số đầu tiên của địa chỉ được hiển thị). Cụ thể, địa chỉ tài khoản là tài khoản cứu hộ hoặc tài khoản tấn công và loại được xác định dựa trên thẻ Etherscan.io và địa chỉ chuyển tiền. Ngoài ra, trong quá trình tấn công và giải cứu, cả mũ trắng và kẻ tấn công đều sử dụng Flashbot để gửi giao dịch với số lượng lớn nên họ cần trả thêm phí cho thợ mỏ, mà chúng tôi gọi là phí Flashbot.

tiêu đề phụ

0x1.2 Xu hướng phí Flashbots

Như đã đề cập ở trên, mũ trắng cần phải cạnh tranh với những kẻ tấn công để gửi giao dịch Flashbots để thực hiện giải cứu và xu hướng thay đổi của phí trả cho Flashbots có thể phản ánh cường độ cạnh tranh. Để đánh giá định lượng, chúng tôi đã tính tỷ lệ phí Flashbots cho các giao dịch tấn công và giải cứu theo khối giao dịch.

tiêu đề cấp đầu tiên

tiêu đề phụ

0x2.1 Chúng tôi tiến hành các hoạt động cứu hộ như thế nào?

Ý tưởng cơ bản của giải cứu là đơn giản và dễ hiểu. Cụ thể, chúng tôi cần theo dõi một loạt tài khoản nạn nhân tiềm năng đã cho phép WETH được sử dụng bởi các hợp đồng bên dự án có vấn đề. Khi có bất kỳ giao dịch chuyển WETH nào vào tài khoản này, chúng tôi sẽ sử dụng lỗ hổng hợp đồng để chuyển trực tiếp vào ví đa chữ ký mũ trắng của chúng tôi. Chìa khóa ở đây là đáp ứng ba yêu cầu sau:

• R1: Định vị hiệu quả các giao dịch được chuyển đến tài khoản của nạn nhân. Để thuận tiện cho việc mô tả, chúng tôi sẽ đặt tên các giao dịch này là giao dịch được chuyển (TX đã chuyển) bên dưới.

• R2: Xây dựng chính xác các giao dịch để thực hiện cứu hộ Để thuận tiện cho việc mô tả, chúng tôi sẽ đặt tên các giao dịch này là giao dịch cứu hộ (rescue TXs) bên dưới.

• R3: Đánh chặn thành công các giao dịch của kẻ tấn công (hoặc bên thứ ba khác) Để thuận tiện cho việc mô tả, chúng tôi sẽ đặt tên cho các giao dịch này là giao dịch tấn công (tấn công TX) bên dưới.

R1 và R2 không phải là trở ngại đối với chúng tôi. Do chúng tôi đã xây dựng hệ thống nội bộ giám sát mempool nên có thể định vị kịp thời các giao dịch chuyển nhượng, đồng thời chúng tôi cũng phát triển bộ công cụ để tự động xây dựng các giao dịch cứu hộ.

tiêu đề phụ

0x2.2 Cuộc thi mà chúng tôi tham gia

Nhìn chung, chúng tôi đã cố gắng bảo vệ 171 tài khoản nạn nhân tiềm năng duy nhất. Trong số đó, 10 tài khoản đã được tự bảo vệ bằng cách thu hồi ủy quyền kịp thời và trong số 161 tài khoản còn lại, do tồn tại các cuộc thi khác nhau nêu trên, chúng tôi chỉ giải cứu thành công 14 tài khoản. Chúng tôi tóm tắt các lỗi trong bảng bên dưới, liên quan đến 3 tài khoản giải cứu và 16 tài khoản tấn công.

tiêu đề cấp đầu tiên

tiêu đề phụ

0x3.1 Làm cách nào để xác định phí Flashbots?

Xuyên suốt quá trình giải cứu, chúng ta đã liên tiếp bị đánh bại bởi 12 đối thủ cũng khai thác Flashbot, trong đó có 2 tài khoản giải cứu và 10 tài khoản tấn công.

Chiến lược đặt phí Flashbot của chúng tôi tương đối thận trọng. Cụ thể, chúng tôi luôn ưu tiên đặt phí Flashbots càng thấp càng tốt để bảo vệ quyền lợi của nạn nhân. Do đó, trừ khi đã có các cuộc tấn công thành công bằng Flashbots, chúng tôi sẽ không tích cực sử dụng Flashbots hoặc tăng phí Flashbots. Ví dụ: một giao dịch tấn công thành công đặt tỷ lệ phí Flashbot là 10% và chúng tôi có thể đặt tỷ lệ này thành 11% trong giao dịch giải cứu tiếp theo. Tuy nhiên, những chiến thuật như vậy đã không được chứng minh là rất thành công và những kẻ tấn công (thậm chí một số mũ trắng) thường sử dụng các chiến thuật tích cực hơn để đặt phí nhằm giành chiến thắng trong cuộc cạnh tranh, chẳng hạn như:

• Hình 5 cho thấy một giao dịch tấn công ở độ cao khối 14071986 và kẻ tấn công 0x5738** đặt tỷ lệ thành 70%.

• Hình 6 cho thấy một giao dịch tấn công ở độ cao khối 14072255 và mũ trắng 0x14ca** đặt tỷ lệ thành 79%.

• Hình 7 cho thấy một giao dịch tấn công ở độ cao khối 14072385 và mũ trắng 0x14ca** đặt tỷ lệ thành 80%.

• Hình 8 cho thấy một giao dịch tấn công ở độ cao khối 14072417 và mũ trắng 0x9117** đặt tỷ lệ thành 81%.

• Hình 9 cho thấy một giao dịch tấn công ở độ cao khối 14073395 và kẻ tấn công 0x5738** đặt tỷ lệ này thành 86%.

tiêu đề cấp đầu tiên

0x3.2 Làm cách nào để sắp xếp chính xác các vị trí giao dịch trong mempool?

Hiện tại có vẻ như sự thành công của cuộc giải cứu phụ thuộc vào một cuộc chạy đua vũ trang về chi phí của Flashbots. Tuy nhiên, chúng tôi nhận thấy rằng Flashbot không phải lúc nào cũng hiệu quả do có sự cạnh tranh khốc liệt từ nhiều bên, từ những người gửi giao dịch khác không liên quan đến cuộc tấn công/cứu hộ, chẳng hạn như chênh lệch giá, v.v. Trong trường hợp này, ngay cả mức phí Flashbots cao nhất (so với các giao dịch tấn công và giải cứu khác) do một sàn giao dịch tấn công đặt ra cũng không đảm bảo sẽ giành chiến thắng trong cuộc thi Flashbots.

Một cách tiếp cận khả thi khác là sử dụng việc gửi các giao dịch bình thường thông qua mempool, cũng có thể đạt được mục tiêu nếu giao dịch được sắp xếp đúng chỗ. Vị trí thích hợp ở đây có nghĩa là giao dịch tấn công/cứu hộ nằm sau giao dịch chuyển nhượng và rất gần với giao dịch chuyển nhượng (càng gần càng tốt, lý tưởng nhất là nếu nó xảy ra ở vị trí tiếp theo của giao dịch chuyển nhượng). Trên thực tế, kẻ tấn công 0x48e9** đã sử dụng chiến lược này để thu hoạch thành công 312,014657 ETH mà không phải trả bất kỳ khoản phí Flashbot nào. Bốn biểu đồ sau đây cho thấy hai cuộc tấn công có lợi nhất của kẻ tấn công:

• Hình 10 và Hình 11 tương ứng cho thấy ở độ cao khối 14051020, giao dịch chuyển khoản của nạn nhân 0x3acb** (chuyển 50 ETH) ở vị trí 65, trong khi giao dịch tấn công (lợi nhuận 50 ETH) ở vị trí 66.

• Hình 12 và Hình 13 tương ứng cho thấy ở độ cao khối 14052155, giao dịch chuyển khoản của nạn nhân 0xbea9** (chuyển 200 ETH) nằm ở 161, trong khi giao dịch tấn công (lợi nhuận 200 ETH) nằm ở 164.

tiêu đề cấp đầu tiên

tiêu đề phụ

0x4.1 Làm cách nào để phân biệt giữa mũ trắng và kẻ tấn công?

Việc xác định những chiếc mũ trắng và hành động của họ có thể không đơn giản như mọi người vẫn nghĩ. Ví dụ: địa chỉ tài khoản 0xfa27 đã được Etherscan.io gắn cờ là mũ trắng: Multichain Exploiter 4 (Whitehat). Tuy nhiên, ngay từ đầu, địa chỉ này đã bị gắn cờ là kẻ tấn công: Multichain Exploiter 4. Sự thay đổi ở đây đến từ sự tương tác giữa bên dự án và kẻ tấn công, sau nhiều vòng đàm phán, kẻ tấn công đã đồng ý giữ lại 50 ETH lợi nhuận làm phần thưởng và trả lại các khoản lợi nhuận khác (trừ phí Flashbot, v.v.):

• Trong giao dịch 0x3c3d**, bên dự án đã liên hệ với kẻ tấn công:

• Trong giao dịch 0xd360**, kẻ tấn công trả lời:

• Trong giao dịch 0x354f**, bên dự án bày tỏ lòng biết ơn sau khi nhận được tiền hoàn trả:

tiêu đề phụ

0x4.2 Cạnh tranh giữa những chiếc mũ trắng

tiêu đề phụ

0x4.3 Làm thế nào để thực hiện tốt hơn các hoạt động cứu hộ?

Một mặt, từ góc độ minh bạch, mũ trắng có thể công khai hành động của mình với cộng đồng mà không tiết lộ thông tin nhạy cảm, cách này để lấy được lòng tin của cộng đồng hoạt động tốt trong thực tế. So với nhiệm vụ ngăn chặn một cuộc tấn công cụ thể, hoạt động giải cứu như vậy thường là một cuộc chiến kéo co, với mũ trắng và những kẻ tấn công tham gia nhiều lần trong một khoảng thời gian, vì vậy sẽ có nhiều thời gian để đưa ra thông báo. Tất nhiên, khi bắt đầu hoạt động, các chi tiết về lỗ hổng không cần phải tiết lộ, để không gây ra tác hại không cần thiết (nhưng tệp băm ghi lại ý định hành động có thể được chia sẻ với cộng đồng, giống như những gì chúng tôi đã làm trong cuộc giải cứu này); Sau khi hoạt động kết thúc, thông tin này cần được công bố đầy đủ cho cộng đồng.

Mặt khác, tất cả các lực lượng trong cộng đồng có thể làm việc cùng nhau để thực hiện các hoạt động cứu hộ nhanh chóng và hiệu quả hơn, bao gồm nhưng không giới hạn ở:

• Flashbots/Miners cung cấp một kênh màu xanh lá cây cho những chiếc mũ trắng được xác thực và đáng tin cậy, có thể được sử dụng để tấn công nhanh các giao dịch và tránh sự cạnh tranh giữa những chiếc mũ trắng.

• Dự án bị tấn công chịu trách nhiệm về chi phí phí ​​Flashbots.

• Bên dự án áp dụng một cơ chế thuận tiện hơn và nhanh hơn để cảnh báo người dùng kịp thời.

• Bên dự án thông qua một số biện pháp khẩn cấp cần thiết trong quy tắc.