Euler Finance遭遇 cuộc tấn công cho vay chớp nhoáng，损失近2亿美元
Vào ngày 13 tháng 3, dự án Euler Finance đã bị tấn công cho vay chớp nhoáng do lỗ hổng hợp đồng, dẫn đến thiệt hại khoảng 197 triệu đô la Mỹ. Kẻ tấn công đã lợi dụng lỗ hổng trong hàm donateToReserves của dự án do thiếu kiểm tra tính thanh khoản, thông qua nhiều lần thao tác với các loại tiền tệ khác nhau để hoàn thành việc kiếm lợi. Hiện tại, số tiền bị đánh cắp vẫn đang bị giữ trong tài khoản của kẻ tấn công.
Phân tích quá trình tấn công
Kẻ tấn công đầu tiên vay 30 triệu DAI từ một nền tảng cho vay chớp nhoáng và triển khai hai hợp đồng vay và thanh lý.
Đặt cọc 20 triệu DAI vào hợp đồng Euler Protocol, nhận được 19 triệu eDAI.
Sử dụng tính năng đòn bẩy 10 lần của Giao thức Euler, vay 1.956 triệu eDAI và 2 triệu dDAI.
Sử dụng 10 triệu DAI còn lại để trả một phần nợ và tiêu hủy số dDAI tương ứng, sau đó lại vay số lượng eDAI và dDAI tương đương.
Thông qua hàm donateToReserves, quyên góp 100 triệu eDAI, ngay lập tức gọi hàm liquidate để thực hiện thanh lý, nhận được 310 triệu dDAI và 250 triệu eDAI.
Cuối cùng rút 3890 vạn DAI, hoàn trả 3000 vạn Khoản vay nhanh, lợi nhuận ròng khoảng 887 vạn DAI.
Phân tích nguyên nhân lỗ hổng
Nguyên nhân chính dẫn đến cuộc tấn công thành công là do hàm donateToReserves thiếu kiểm tra thanh khoản cần thiết. So với các hàm quan trọng khác như mint, hàm donateToReserves không gọi checkLiquidity để xác thực thanh khoản của người dùng. Điều này đã khiến kẻ tấn công có thể thực hiện các thao tác cụ thể để làm cho tài khoản của mình ở trạng thái có thể bị thanh lý, sau đó hoàn tất việc thanh lý để thu lợi.
Trong trường hợp bình thường, hàm checkLiquidity sẽ gọi mô-đun RiskManager, đảm bảo rằng số lượng Etoken của người dùng luôn lớn hơn số lượng Dtoken. Tuy nhiên, hàm donateToReserves đã bỏ qua bước quan trọng này, tạo cơ hội cho cuộc tấn công.
Lời khuyên an toàn
Sự kiện này một lần nữa nhấn mạnh tầm quan trọng của việc kiểm tra an toàn hợp đồng thông minh. Các bên dự án nên thực hiện kiểm tra an toàn toàn diện và chi tiết trước khi ra mắt, đặc biệt đối với các dự án cho vay, cần chú ý nhiều đến một số khía cạnh sau:
Tính toàn vẹn của cơ chế hoàn trả vốn
Tính toàn diện của việc kiểm tra tính thanh khoản
Độ an toàn của quy trình thanh lý nợ
Chỉ khi đảm bảo an toàn cho những khâu quan trọng này, chúng ta mới có thể ngăn chặn hiệu quả sự xảy ra của những cuộc tấn công tương tự. Với sự phát triển không ngừng của hệ sinh thái Web3, an toàn của hợp đồng thông minh sẽ tiếp tục là trọng tâm được ngành công nghiệp quan tâm.
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.
12 thích
Phần thưởng
12
6
Đăng lại
Chia sẻ
Bình luận
0/400
LongTermDreamer
· 21giờ trước
Ba năm sau nhìn lại, lại là một câu chuyện về giá trị hồi quy ngược. Ai hiểu thì sẽ hiểu.
Xem bản gốcTrả lời0
GasBandit
· 21giờ trước
Lại là lỗi của hợp đồng thông minh sao? Kiểm toán thế nào đây?
Euler Finance遭cuộc tấn công cho vay chớp nhoáng损失1.97亿美元 合约漏洞成主因
Euler Finance遭遇 cuộc tấn công cho vay chớp nhoáng，损失近2亿美元
Vào ngày 13 tháng 3, dự án Euler Finance đã bị tấn công cho vay chớp nhoáng do lỗ hổng hợp đồng, dẫn đến thiệt hại khoảng 197 triệu đô la Mỹ. Kẻ tấn công đã lợi dụng lỗ hổng trong hàm donateToReserves của dự án do thiếu kiểm tra tính thanh khoản, thông qua nhiều lần thao tác với các loại tiền tệ khác nhau để hoàn thành việc kiếm lợi. Hiện tại, số tiền bị đánh cắp vẫn đang bị giữ trong tài khoản của kẻ tấn công.
Phân tích quá trình tấn công
Kẻ tấn công đầu tiên vay 30 triệu DAI từ một nền tảng cho vay chớp nhoáng và triển khai hai hợp đồng vay và thanh lý.
Đặt cọc 20 triệu DAI vào hợp đồng Euler Protocol, nhận được 19 triệu eDAI.
Sử dụng tính năng đòn bẩy 10 lần của Giao thức Euler, vay 1.956 triệu eDAI và 2 triệu dDAI.
Sử dụng 10 triệu DAI còn lại để trả một phần nợ và tiêu hủy số dDAI tương ứng, sau đó lại vay số lượng eDAI và dDAI tương đương.
Thông qua hàm donateToReserves, quyên góp 100 triệu eDAI, ngay lập tức gọi hàm liquidate để thực hiện thanh lý, nhận được 310 triệu dDAI và 250 triệu eDAI.
Cuối cùng rút 3890 vạn DAI, hoàn trả 3000 vạn Khoản vay nhanh, lợi nhuận ròng khoảng 887 vạn DAI.
Phân tích nguyên nhân lỗ hổng
Nguyên nhân chính dẫn đến cuộc tấn công thành công là do hàm donateToReserves thiếu kiểm tra thanh khoản cần thiết. So với các hàm quan trọng khác như mint, hàm donateToReserves không gọi checkLiquidity để xác thực thanh khoản của người dùng. Điều này đã khiến kẻ tấn công có thể thực hiện các thao tác cụ thể để làm cho tài khoản của mình ở trạng thái có thể bị thanh lý, sau đó hoàn tất việc thanh lý để thu lợi.
Trong trường hợp bình thường, hàm checkLiquidity sẽ gọi mô-đun RiskManager, đảm bảo rằng số lượng Etoken của người dùng luôn lớn hơn số lượng Dtoken. Tuy nhiên, hàm donateToReserves đã bỏ qua bước quan trọng này, tạo cơ hội cho cuộc tấn công.
Lời khuyên an toàn
Sự kiện này một lần nữa nhấn mạnh tầm quan trọng của việc kiểm tra an toàn hợp đồng thông minh. Các bên dự án nên thực hiện kiểm tra an toàn toàn diện và chi tiết trước khi ra mắt, đặc biệt đối với các dự án cho vay, cần chú ý nhiều đến một số khía cạnh sau:
Chỉ khi đảm bảo an toàn cho những khâu quan trọng này, chúng ta mới có thể ngăn chặn hiệu quả sự xảy ra của những cuộc tấn công tương tự. Với sự phát triển không ngừng của hệ sinh thái Web3, an toàn của hợp đồng thông minh sẽ tiếp tục là trọng tâm được ngành công nghiệp quan tâm.