Nhìn lại và rút kinh nghiệm từ hoạt động cứu trợ khẩn cấp Web3
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 nhằm vào dự án AnySwap ( tức là Multichain ). Do hàm anySwapOutUnderlyingWithPermit() có lỗ hổng, token mà người dùng ủy quyền cho dự án này có thể bị kẻ tấn công đánh cắp.
Mặc dù nhóm dự án đã thực hiện nhiều cách để nhắc nhở người dùng bị ảnh hưởng ( như gửi thông báo giao dịch ), vẫn có nhiều người dùng chưa kịp rút lại quyền ủy quyền, kẻ tấn công đã tiếp tục thu lợi.
Do các cuộc tấn công vẫn đang diễn ra, đội ngũ 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 tàng. Chúng tôi chủ yếu nhắm vào các tài khoản bị ảnh hưởng trên Ethereum, chuyển các quỹ liên quan vào một tài khoản multi-signature dành riêng cho các nhà bảo vệ. Để đảm bảo tính minh bạch của hành động, chúng tôi sẽ công khai mã băm tài liệu tóm tắt kế hoạch ( không phải nội dung ) cho cộng đồng, vừa có thể phân biệt hành động của chúng tôi với những kẻ tấn công, vừa không tiết lộ chi tiết. Hành động cứu trợ bắt đầu từ ngày 21 tháng 1 năm 2022 và kết thúc vào ngày 11 tháng 3.
Các hoạt động cứu hộ khẩn cấp phải đối mặt với nhiều thách thức kỹ thuật và phi kỹ thuật. Bây giờ khi hành động đã kết thúc, chúng tôi có thể xem lại toàn bộ quá trình và chia sẻ những kinh nghiệm và cảm nhận liên quan với cộng đồng, hy vọng có thể đóng góp cho an toàn của hệ sinh thái DeFi.
Tóm tắt ngắn gọn
Sự sử dụng rộng rãi của Flashbots đã dẫn đến sự cạnh tranh gay gắt giữa các hacker mũ trắng và kẻ tấn công, cũng như trong từng nhóm của họ, và chi phí phải trả cũng nhanh chóng tăng theo thời gian.
Flashbots không phải là tất cả, một số kẻ tấn công đã chuyển sang sử dụng mempool, thực hiện các cuộc tấn công thành công bằng cách sắp xếp khéo léo các giao dịch tấn công.
Một số kẻ tấn công đã đạt được thỏa thuận với bên dự án, hoàn trả một phần số tiền kiếm được và giữ lại một phần làm thưởng, từ đó "rửa tiền" thành công. Hành động này đã gây ra tranh cãi trong cộng đồng.
Mũ trắng có thể công khai hành động với cộng đồng mà không tiết lộ thông tin nhạy cảm, phương thức xây dựng lòng tin này có hiệu quả tốt.
Sự hợp tác của các lực lượng trong cộng đồng có thể làm cho công tác cứu trợ nhanh chóng và hiệu quả hơn, chẳng hạn như sự hợp tác giữa các hacker mũ trắng để giảm thiểu cạnh tranh không hiệu quả.
Dưới đây, chúng ta sẽ thảo luận từ bốn khía cạnh: trước tiên là ôn lại tình hình tổng thể của sự kiện, sau đó giới thiệu phương pháp cứu援 và những thách thức đang đối mặt, tiếp theo là chia sẻ những kinh nghiệm trong hành động, cuối cùng là đưa ra một số đề xuất.
Tổng quan về tình hình tấn công và cứu hộ
Kết quả tổng thể
Thời gian quan sát của chúng tôi là từ ngày 18 tháng 1 năm 2022 đến ngày 20 tháng 3. Tình hình tổng thể như sau:
9 tài khoản cứu hộ đã bảo vệ 483.027693 ETH, trong đó đã trả phí Flashbots 295.970554 ETH( chiếm 61.27%)
21 tài khoản tấn công đã thu lợi 1433.092224 ETH, trả phí Flashbots 148.903707 ETH( chiếm 10.39%)
Cần lưu ý rằng, do có một số tình huống phức tạp như ( việc kẻ tấn công thương lượng với bên dự án để hoàn lại một phần lợi nhuận, ) những dữ liệu này chỉ là thống kê sơ bộ.
Xu hướng thay đổi phí Flashbots
Các hacker mũ trắng cần cạnh tranh với kẻ tấn công để gửi giao dịch Flashbots nhằm thực hiện cứu trợ, phí phải trả phản ánh mức độ cạnh tranh. Chúng tôi đã thống kê tỷ lệ phí Flashbots của các giao dịch tấn công và cứu trợ theo khối giao dịch.
Ban đầu, một số giao dịch tấn công có phí Flashbots là 0, cho thấy kẻ tấn công chưa sử dụng Flashbots. Sau đó, tỷ lệ phí nhanh chóng tăng lên, trong một số khối thậm chí đạt 80% và 91%. Điều này cho thấy đã phát triển thành một cuộc đua vũ trang về phí để giành quyền lên chuỗi trên Flashbots.
Các hành động cứu trợ mà chúng tôi thực hiện và những thách thức phải đối mặt
Ý tưởng cơ bản của hoạt động cứu hộ
Chúng tôi đã theo dõi một nhóm tài khoản tiềm năng đã ủy quyền WETH cho hợp đồng có vấn đề. Khi có WETH được chuyển vào những tài khoản này, chúng tôi đã lợi dụng lỗ hổng của hợp đồng để chuyển ra ví đa chữ ký của những người thiện nguyện. Chìa khóa là phải đáp ứng ba điều sau:
Xác định hiệu quả giao dịch chuyển khoản cho nạn nhân giao dịch ( chuyển khoản )
Xây dựng giao dịch cứu trợ đúng cách ( giao dịch cứu trợ )
Thành công vượt lên trên các giao dịch của kẻ tấn công ( hoặc bên thứ ba khác ) trong giao dịch ( tấn công giao dịch )
Hai điểm đầu tiên không gây trở ngại cho chúng tôi, vì chúng tôi có hệ thống giám sát mempool và công cụ tự động tạo giao dịch cứu trợ. Nhưng điểm thứ ba vẫn còn thách thức.
Mặc dù về lý thuyết có thể sử dụng Flashbots để giành chiến thắng trong việc chạy trước, nhưng trong thực tế không phải là điều dễ dàng. Đầu tiên, kẻ tấn công cũng có thể sử dụng Flashbots, tỷ lệ thành công phụ thuộc vào mức giá đặt. Thứ hai, sự cạnh tranh gay gắt làm cho Flashbots không phải lúc nào cũng là lựa chọn tốt nhất, chúng tôi cũng sẽ gửi giao dịch thông thường qua mempool. Cuối cùng, chúng tôi còn cạnh tranh với các "hacker mũ trắng" khác, và một số hành vi được gọi là "hacker mũ trắng" thực sự là khá đáng ngờ.
Tình hình cạnh tranh
Chúng tôi đã cố gắng bảo vệ 171 tài khoản nạn nhân tiềm năng độc lập. Trong số đó, 10 tài khoản đã kịp thời thu hồi quyền ủy quyền tự bảo vệ, và trong số 161 tài khoản còn lại, chúng tôi chỉ thành công cứu trợ được 14 tài khoản. Tình huống thất bại liên quan đến 3 tài khoản cứu trợ và 16 tài khoản tấn công.
Kinh nghiệm và bài học
Cài đặt phí Flashbots
Trong quá trình cứu援, chúng tôi đã bị các đối thủ khác đánh bại 12 lần, bao gồm 2 tài khoản cứu援 và 10 tài khoản tấn công.
Chiến lược của chúng tôi khá thận trọng, có xu hướng đặt phí Flashbots thấp để bảo vệ lợi ích của nạn nhân. Trừ khi có giao dịch tấn công sử dụng Flashbots thành công xuất hiện, nếu không chúng tôi sẽ không chủ động sử dụng hoặc tăng phí. Tuy nhiên, chiến lược này không hiệu quả, đối thủ thường tấn công mạnh mẽ hơn:
Một kẻ tấn công đã đặt tỷ lệ phí là 70%
Một hacker mũ trắng đã đặt tỷ lệ phí là 79%, 80%
Một hacker mũ trắng khác đã đặt tỷ lệ phí là 81%
Kẻ tấn công sau đó đã tăng tỷ lệ phí lên 86%
Đây có vẻ là một trò chơi không có tổng, cần mô hình hóa để khám phá các mô hình hành vi của các bên. Trong thực tiễn, vừa phải cố gắng giảm chi phí, vừa phải tìm ra chiến lược tối ưu để giành chiến thắng trong cạnh tranh, là một nhiệm vụ vô cùng thách thức.
Sắp xếp giao dịch Mempool
Cạnh tranh gay gắt khiến Flashbots không phải lúc nào cũng hiệu quả. Gửi giao dịch thông thường qua mempool, nếu có thể sắp xếp ở vị trí thích hợp ( ngay sau giao dịch chuyển tiền ), cũng có thể đạt được mục tiêu.
Một kẻ tấn công đã sử dụng chiến lược này để thu lợi 312 ETH mà không phải trả phí Flashbots. Ví dụ:
Khối 14051020: Giao dịch chuyển tiền của nạn nhân nằm ở 65, giao dịch tấn công nằm ở 66
Khối 14052155: Giao dịch chuyển khoản của nạn nhân nằm ở 161, giao dịch tấn công nằm ở 164
Chiến lược khéo léo này vừa thực tiễn vừa mang tính gợi mở, rất đáng để chú ý.
Những suy nghĩ khác
Định nghĩa giữa mũ trắng và kẻ tấn công
Việc nhận diện hacker mũ trắng không phải lúc nào cũng đơn giản. Ví dụ, một tài khoản ban đầu bị đánh dấu là kẻ tấn công, sau đó qua thương lượng với đội ngũ dự án, đã đồng ý giữ lại 50 ETH như phần thưởng và hoàn trả các khoản lợi nhuận khác, sau đó được đánh dấu lại là hacker mũ trắng.
Hiện tượng này không phải là lần đầu xuất hiện, tính công bằng của cơ chế khuyến khích đã gây ra tranh cãi trong cộng đồng.
Cạnh tranh giữa những chiếc mũ trắng
Cộng đồng cần thiết lập cơ chế phối hợp để giảm bớt sự cạnh tranh giữa các hacker mũ trắng. Sự cạnh tranh này không chỉ lãng phí tài nguyên mà còn làm tăng chi phí cứu trợ. Chẳng hạn, chúng tôi cùng với ba tổ chức hacker mũ trắng khác đều cố gắng bảo vệ 54 nạn nhân ( liên quan đến 450 ETH). Nếu không có cơ chế phối hợp, các hacker mũ trắng khó có thể từ bỏ hoặc ngừng sự cạnh tranh này.
Cải thiện hoạt động cứu hộ
Những người đội mũ trắng có thể công khai hành động với cộng đồng mà không tiết lộ thông tin nhạy cảm, cách làm này mang lại hiệu quả tốt.
Các bên trong cộng đồng có thể hợp tác để nâng cao hiệu quả cứu trợ:
Flashbots/Thợ mỏ cung cấp lối đi xanh cho những người bảo mật đáng tin cậy
Phía dự án chịu phí Flashbots
Đội ngũ dự án áp dụng cơ chế cảnh báo người dùng thuận tiện hơn
Nhóm dự án đã thêm các biện pháp khẩn cấp vào mã.
Thông qua nỗ lực chung của tất cả các bên, chúng ta có thể ứng phó tốt hơn với những thách thức về an ninh trong hệ sinh thái Web3, bảo vệ quyền lợi của người dùng.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
18 thích
Phần thưởng
18
7
Đăng lại
Chia sẻ
Bình luận
0/400
WinterWarmthCat
· 3giờ trước
Lỗ hổng quá nghiêm trọng bạn bè
Xem bản gốcTrả lời0
SellLowExpert
· 5giờ trước
又要 Cắt lỗ bảo lãnh了
Xem bản gốcTrả lời0
SchrodingerAirdrop
· 08-06 16:46
Phòng ngừa trước khi xảy ra là điều quan trọng nhất
Bản ghi an ninh và phòng thủ Web3: Kinh nghiệm và bài học từ hành động cứu trợ AnySwap
Nhìn lại và rút kinh nghiệm từ hoạt động cứu trợ khẩn cấp Web3
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 nhằm vào dự án AnySwap ( tức là Multichain ). Do hàm anySwapOutUnderlyingWithPermit() có lỗ hổng, token mà người dùng ủy quyền cho dự án này có thể bị kẻ tấn công đánh cắp.
Mặc dù nhóm dự án đã thực hiện nhiều cách để nhắc nhở người dùng bị ảnh hưởng ( như gửi thông báo giao dịch ), vẫn có nhiều người dùng chưa kịp rút lại quyền ủy quyền, kẻ tấn công đã tiếp tục thu lợi.
Do các cuộc tấn công vẫn đang diễn ra, đội ngũ 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 tàng. Chúng tôi chủ yếu nhắm vào các tài khoản bị ảnh hưởng trên Ethereum, chuyển các quỹ liên quan vào một tài khoản multi-signature dành riêng cho các nhà bảo vệ. Để đảm bảo tính minh bạch của hành động, chúng tôi sẽ công khai mã băm tài liệu tóm tắt kế hoạch ( không phải nội dung ) cho cộng đồng, vừa có thể phân biệt hành động của chúng tôi với những kẻ tấn công, vừa không tiết lộ chi tiết. Hành động cứu trợ bắt đầu từ ngày 21 tháng 1 năm 2022 và kết thúc vào ngày 11 tháng 3.
Các hoạt động cứu hộ khẩn cấp phải đối mặt với nhiều thách thức kỹ thuật và phi kỹ thuật. Bây giờ khi hành động đã kết thúc, chúng tôi có thể xem lại toàn bộ quá trình và chia sẻ những kinh nghiệm và cảm nhận liên quan với cộng đồng, hy vọng có thể đóng góp cho an toàn của hệ sinh thái DeFi.
Tóm tắt ngắn gọn
Sự sử dụng rộng rãi của Flashbots đã dẫn đến sự cạnh tranh gay gắt giữa các hacker mũ trắng và kẻ tấn công, cũng như trong từng nhóm của họ, và chi phí phải trả cũng nhanh chóng tăng theo thời gian.
Flashbots không phải là tất cả, một số kẻ tấn công đã chuyển sang sử dụng mempool, thực hiện các cuộc tấn công thành công bằng cách sắp xếp khéo léo các giao dịch tấn công.
Một số kẻ tấn công đã đạt được thỏa thuận với bên dự án, hoàn trả một phần số tiền kiếm được và giữ lại một phần làm thưởng, từ đó "rửa tiền" thành công. Hành động này đã gây ra tranh cãi trong cộng đồng.
Mũ trắng có thể công khai hành động với cộng đồng mà không tiết lộ thông tin nhạy cảm, phương thức xây dựng lòng tin này có hiệu quả tốt.
Sự hợp tác của các lực lượng trong cộng đồng có thể làm cho công tác cứu trợ nhanh chóng và hiệu quả hơn, chẳng hạn như sự hợp tác giữa các hacker mũ trắng để giảm thiểu cạnh tranh không hiệu quả.
Dưới đây, chúng ta sẽ thảo luận từ bốn khía cạnh: trước tiên là ôn lại tình hình tổng thể của sự kiện, sau đó giới thiệu phương pháp cứu援 và những thách thức đang đối mặt, tiếp theo là chia sẻ những kinh nghiệm trong hành động, cuối cùng là đưa ra một số đề xuất.
Tổng quan về tình hình tấn công và cứu hộ
Kết quả tổng thể
Thời gian quan sát của chúng tôi là từ ngày 18 tháng 1 năm 2022 đến ngày 20 tháng 3. Tình hình tổng thể như sau:
Cần lưu ý rằng, do có một số tình huống phức tạp như ( việc kẻ tấn công thương lượng với bên dự án để hoàn lại một phần lợi nhuận, ) những dữ liệu này chỉ là thống kê sơ bộ.
Xu hướng thay đổi phí Flashbots
Các hacker mũ trắng cần cạnh tranh với kẻ tấn công để gửi giao dịch Flashbots nhằm thực hiện cứu trợ, phí phải trả phản ánh mức độ cạnh tranh. Chúng tôi đã thống kê tỷ lệ phí Flashbots của các giao dịch tấn công và cứu trợ theo khối giao dịch.
Ban đầu, một số giao dịch tấn công có phí Flashbots là 0, cho thấy kẻ tấn công chưa sử dụng Flashbots. Sau đó, tỷ lệ phí nhanh chóng tăng lên, trong một số khối thậm chí đạt 80% và 91%. Điều này cho thấy đã phát triển thành một cuộc đua vũ trang về phí để giành quyền lên chuỗi trên Flashbots.
Các hành động cứu trợ mà chúng tôi thực hiện và những thách thức phải đối mặt
Ý tưởng cơ bản của hoạt động cứu hộ
Chúng tôi đã theo dõi một nhóm tài khoản tiềm năng đã ủy quyền WETH cho hợp đồng có vấn đề. Khi có WETH được chuyển vào những tài khoản này, chúng tôi đã lợi dụng lỗ hổng của hợp đồng để chuyển ra ví đa chữ ký của những người thiện nguyện. Chìa khóa là phải đáp ứng ba điều sau:
Hai điểm đầu tiên không gây trở ngại cho chúng tôi, vì chúng tôi có hệ thống giám sát mempool và công cụ tự động tạo giao dịch cứu trợ. Nhưng điểm thứ ba vẫn còn thách thức.
Mặc dù về lý thuyết có thể sử dụng Flashbots để giành chiến thắng trong việc chạy trước, nhưng trong thực tế không phải là điều dễ dàng. Đầu tiên, kẻ tấn công cũng có thể sử dụng Flashbots, tỷ lệ thành công phụ thuộc vào mức giá đặt. Thứ hai, sự cạnh tranh gay gắt làm cho Flashbots không phải lúc nào cũng là lựa chọn tốt nhất, chúng tôi cũng sẽ gửi giao dịch thông thường qua mempool. Cuối cùng, chúng tôi còn cạnh tranh với các "hacker mũ trắng" khác, và một số hành vi được gọi là "hacker mũ trắng" thực sự là khá đáng ngờ.
Tình hình cạnh tranh
Chúng tôi đã cố gắng bảo vệ 171 tài khoản nạn nhân tiềm năng độc lập. Trong số đó, 10 tài khoản đã kịp thời thu hồi quyền ủy quyền tự bảo vệ, và trong số 161 tài khoản còn lại, chúng tôi chỉ thành công cứu trợ được 14 tài khoản. Tình huống thất bại liên quan đến 3 tài khoản cứu trợ và 16 tài khoản tấn công.
Kinh nghiệm và bài học
Cài đặt phí Flashbots
Trong quá trình cứu援, chúng tôi đã bị các đối thủ khác đánh bại 12 lần, bao gồm 2 tài khoản cứu援 và 10 tài khoản tấn công.
Chiến lược của chúng tôi khá thận trọng, có xu hướng đặt phí Flashbots thấp để bảo vệ lợi ích của nạn nhân. Trừ khi có giao dịch tấn công sử dụng Flashbots thành công xuất hiện, nếu không chúng tôi sẽ không chủ động sử dụng hoặc tăng phí. Tuy nhiên, chiến lược này không hiệu quả, đối thủ thường tấn công mạnh mẽ hơn:
Đây có vẻ là một trò chơi không có tổng, cần mô hình hóa để khám phá các mô hình hành vi của các bên. Trong thực tiễn, vừa phải cố gắng giảm chi phí, vừa phải tìm ra chiến lược tối ưu để giành chiến thắng trong cạnh tranh, là một nhiệm vụ vô cùng thách thức.
Sắp xếp giao dịch Mempool
Cạnh tranh gay gắt khiến Flashbots không phải lúc nào cũng hiệu quả. Gửi giao dịch thông thường qua mempool, nếu có thể sắp xếp ở vị trí thích hợp ( ngay sau giao dịch chuyển tiền ), cũng có thể đạt được mục tiêu.
Một kẻ tấn công đã sử dụng chiến lược này để thu lợi 312 ETH mà không phải trả phí Flashbots. Ví dụ:
Chiến lược khéo léo này vừa thực tiễn vừa mang tính gợi mở, rất đáng để chú ý.
Những suy nghĩ khác
Định nghĩa giữa mũ trắng và kẻ tấn công
Việc nhận diện hacker mũ trắng không phải lúc nào cũng đơn giản. Ví dụ, một tài khoản ban đầu bị đánh dấu là kẻ tấn công, sau đó qua thương lượng với đội ngũ dự án, đã đồng ý giữ lại 50 ETH như phần thưởng và hoàn trả các khoản lợi nhuận khác, sau đó được đánh dấu lại là hacker mũ trắng.
Hiện tượng này không phải là lần đầu xuất hiện, tính công bằng của cơ chế khuyến khích đã gây ra tranh cãi trong cộng đồng.
Cạnh tranh giữa những chiếc mũ trắng
Cộng đồng cần thiết lập cơ chế phối hợp để giảm bớt sự cạnh tranh giữa các hacker mũ trắng. Sự cạnh tranh này không chỉ lãng phí tài nguyên mà còn làm tăng chi phí cứu trợ. Chẳng hạn, chúng tôi cùng với ba tổ chức hacker mũ trắng khác đều cố gắng bảo vệ 54 nạn nhân ( liên quan đến 450 ETH). Nếu không có cơ chế phối hợp, các hacker mũ trắng khó có thể từ bỏ hoặc ngừng sự cạnh tranh này.
Cải thiện hoạt động cứu hộ
Những người đội mũ trắng có thể công khai hành động với cộng đồng mà không tiết lộ thông tin nhạy cảm, cách làm này mang lại hiệu quả tốt.
Các bên trong cộng đồng có thể hợp tác để nâng cao hiệu quả cứu trợ:
Thông qua nỗ lực chung của tất cả các bên, chúng ta có thể ứng phó tốt hơn với những thách thức về an ninh trong hệ sinh thái Web3, bảo vệ quyền lợi của người dùng.