Nguồn: SharkTeam
Vào ngày 30 tháng 1 năm 2024, MIM_SPELL đã phải hứng chịu một cuộc tấn công cho vay nhanh. Do lỗ hổng tính toán chính xác, dự án đã thiệt hại 6,5 triệu USD.
SharkTeam đã phản hồi ngay lập tức về sự cố này Phân tích kỹ thuật, và bản tóm tắt các biện pháp phòng ngừa bảo mật, hy vọng rằng các dự án tiếp theo có thể học hỏi từ điều này và cùng nhau xây dựng đường dây bảo mật cho ngành công nghiệp blockchain.
1. Phân tích giao dịch tấn công
Địa chỉ tấn công:
0x87F585809CE79AE39A5FA0C7C96D0D159EB678C9
77A4 5 < /p>
0x13AF445F81B0DEcA5dCb2Be6A4C691F545c95912
0xe59b54a9e37ab69f6e9312a9b3f72539ee184e5a
Hợp đồng đang bị tấn công:
0x7259e152103756e 161 6A77Ae982353c3751A6a90
Giao dịch tấn công:
0x26a83db7e28838dd9fee6fb7314ae58dcc6aee9a20bf224c386ff5e80f7e4cf2
0xdb4616b89ad82062787a4e924d520639791302476484b9a6eca5126f79 b 6d877
Quá trình tấn công:
1. Kẻ tấn công (0x87F58580) đã vay 300.000 mã thông báo MIM thông qua khoản vay nhanh.
2. Sau đó gửi tin nhắn đến người bị tấn công hợp đồng (0x7259e1520 ) đã gửi 240.000 mã thông báo MIM cho bước trả nợ tiếp theo của người dùng.
3. Kẻ tấn công (0x87F58580) sau đó gọi Hàm returnForAll hoàn trả các khoản vay của người dùng khác, sau đó gọi hàm hoàn trả để hoàn trả các khoản vay của người dùng khác nhằm giảm biến co giãn về 0.
4. Sau khi biến đàn hồi giảm xuống 0, kẻ tấn công (0x87F58580) tạo một hợp đồng tấn công mới (0xe59b54a9) và liên tục gọi các hàm vay và trả nợ cho đến khi đàn hồi = 0 và base = 120080183810681886665215049728.
5. Sau đó, kẻ tấn công (0x87F58580) gọi chức năng vay và chức năng rút tiền của hợp đồng DegenBox để cho vay 5.000.047 MIM mã thông báo .
6. Kẻ tấn công (0x87F58580) trả lại Lightning Chức năng cho vay được sử dụng để đổi 4.400.000 mã thông báo MIM thành 1.807 ETH. Lợi nhuận từ giao dịch này là khoảng 450W.
2. Phân tích lỗ hổng bảo mật
< p>Bản chất của cuộc tấn công là có vấn đề về độ chính xác khi tính toán các biến số cho vay, khiến các biến chính co giãn và giá trị cơ sở bị thao túng và tỷ lệ mất cân bằng, dẫn đến các vấn đề khi tính toán số tiền thế chấp và khoản vay, và cuối cùng là cho vay quá nhiều token MIM.
Cả hàm vay và hàm hoàn trả trong hợp đồng bị tấn công (0x7259e1520) đều áp dụng phương pháp làm tròn lên khi tính toán các biến co giãn và biến cơ sở.
Kẻ tấn công (0x87F58580) trước tiên đặt biến đàn hồi và biến cơ sở tương ứng bằng cách hoàn trả các khoản vay của người dùng khác. 0 và 97.
Sau đó tiếp tục gọi hàm mượn và trả nợ function Và số lượng tham số là 1. Khi hàm mượn được gọi lần đầu tiên, vì elastic=0, logic if ở trên sẽ được thực thi và trả về hàm add. Điều này dẫn đến co giãn = 1, cơ sở = 98.
Kẻ tấn công (0x87F58580) sau đó gọi hàm mượn và truyền vào 1. Vì elastic=1, logic else sẽ được thực thi và giá trị trả về được tính là 98. Theo cách này, khi quay lại phép cộng hàm, elastic= 2. Biến cơ sở là 196.
Nhưng tại thời điểm này, kẻ tấn công (0x87F58580) gọi hàm trả nợ và chuyển vào 1. Vì elastic=2, logic else sẽ được thực thi và biến đàn hồi tính toán ban đầu là 1*2 /98 =0, nhưng do làm tròn lên phía dưới nên giá trị tính toán trả về là 1 nên khi về hàm con biến đàn hồi đổi về 1, biến cơ sở là 195.
Có thể thấy sau một vòng vay-trả nợ, biến đàn hồi không thay đổi và biến cơ sở tăng gần gấp đôi.Lợi dụng lỗ hổng này, hacker thường xuyên lặp lại chức năng vay-trả nợ và cuối cùng gọi lệnh trả nợ Cuối cùng, elastic=0 base = 120080183810681886665215049728.
Khi tỷ số giữa biến đàn hồi và biến cơ sở Sau mất cân bằng nghiêm trọng, kẻ tấn công (0x87F58580) có thể cho vay một lượng lớn mã thông báo MIM bằng cách thêm một ít tài sản thế chấp để vượt qua các hạn chế trong công cụ sửa đổi dung môi.
3. Khuyến nghị bảo mật
< p>Để đối phó với cuộc tấn công này, chúng ta nên tuân theo các biện pháp phòng ngừa sau trong quá trình phát triển:
1. Khi phát triển logic liên quan đến tính toán chính xác, hãy xem xét cẩn thận độ chính xác và làm tròn.
2. Trước khi dự án đi vào hoạt động trực tuyến, nhóm kiểm toán chuyên nghiệp của bên thứ ba cần tiến hành kiểm tra hợp đồng thông minh.