Dự án Poolz gặp phải lỗ hổng bảo mật, khoảng 66,5 triệu đô la tài sản bị ảnh hưởng
Gần đây, một sự kiện an ninh liên quan đến dự án cross-chain Poolz đã thu hút sự chú ý của ngành. Theo dữ liệu giám sát an ninh blockchain, vào rạng sáng ngày 15 tháng 3, hợp đồng thông minh của Poolz trên các mạng Ethereum, BNB Chain và Polygon đã bị tấn công, dẫn đến nhiều tài sản token bị thiệt hại, tổng giá trị khoảng 66,5 triệu đô la.
Sự kiện này liên quan đến nhiều loại token, bao gồm MEE, ESNC, DON, ASW, KMON, POOLZ, v.v. Kẻ tấn công đã lợi dụng một lỗ hổng tràn số học trong hợp đồng thông minh để thành công thao túng quá trình tạo ra các pool token. Hiện tại, một phần tài sản bị đánh cắp đã được chuyển đổi sang BNB, nhưng vẫn chưa được chuyển ra khỏi địa chỉ của kẻ tấn công.
Kẻ tấn công chủ yếu đã lợi dụng lỗ hổng trong hàm CreateMassPools của hợp đồng Poolz. Hàm này ban đầu được sử dụng để tạo hàng loạt hồ bơi token và cung cấp thanh khoản ban đầu, nhưng hàm getArraySum bên trong gặp vấn đề tràn số nguyên. Kẻ tấn công thông qua các tham số đầu vào được xây dựng cẩn thận, khiến cho kết quả cộng dồn vượt quá phạm vi của kiểu uint256, dẫn đến số lượng token thực tế chuyển vào không khớp với số lượng được ghi nhận.
Lỗ hổng này cho phép kẻ tấn công ghi lại một số lượng lớn số dư token trong hệ thống với một lượng token đầu vào rất nhỏ. Sau đó, kẻ tấn công gọi hàm withdraw để rút các token được ghi lại giả mạo này, hoàn thành toàn bộ quá trình tấn công.
Các vấn đề tràn số học như vậy không phải là hiếm trong phát triển hợp đồng thông minh. Để phòng ngừa các rủi ro tương tự, các nhà phát triển nên sử dụng các phiên bản mới hơn của ngôn ngữ lập trình Solidity, những phiên bản này sẽ tự động kiểm tra tràn số khi biên dịch. Đối với các dự án sử dụng phiên bản Solidity cũ hơn, nên đưa vào thư viện SafeMath của OpenZeppelin để xử lý các phép toán số nguyên, nhằm tránh rủi ro tràn số.
Sự kiện này một lần nữa nhắc nhở các dự án blockchain và các nhà phát triển rằng trong quá trình thiết kế và triển khai hợp đồng thông minh, cần phải đặc biệt chú ý đến tính an toàn. Đồng thời, nó cũng làm nổi bật tầm quan trọng của việc thực hiện kiểm toán an toàn định kỳ và các chương trình thưởng cho lỗ hổng, nhằm phát hiện và sửa chữa sớm những rủi ro tiềm ẩn về an ninh.
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.
17 thích
Phần thưởng
17
4
Chia sẻ
Bình luận
0/400
SignatureVerifier
· 08-04 12:54
smh... một trường hợp điển hình khác của việc xác thực đầu vào không đủ
Xem bản gốcTrả lời0
CoffeeNFTrader
· 08-04 12:53
Một dự án khác đã bị lạnh lẽo.
Xem bản gốcTrả lời0
nft_widow
· 08-04 12:50
又 một đồ ngốc chơi đùa với mọi người dự án đã kết thúc
Poolz遭 Hacker攻击 66.5万美元资产受损
Dự án Poolz gặp phải lỗ hổng bảo mật, khoảng 66,5 triệu đô la tài sản bị ảnh hưởng
Gần đây, một sự kiện an ninh liên quan đến dự án cross-chain Poolz đã thu hút sự chú ý của ngành. Theo dữ liệu giám sát an ninh blockchain, vào rạng sáng ngày 15 tháng 3, hợp đồng thông minh của Poolz trên các mạng Ethereum, BNB Chain và Polygon đã bị tấn công, dẫn đến nhiều tài sản token bị thiệt hại, tổng giá trị khoảng 66,5 triệu đô la.
Sự kiện này liên quan đến nhiều loại token, bao gồm MEE, ESNC, DON, ASW, KMON, POOLZ, v.v. Kẻ tấn công đã lợi dụng một lỗ hổng tràn số học trong hợp đồng thông minh để thành công thao túng quá trình tạo ra các pool token. Hiện tại, một phần tài sản bị đánh cắp đã được chuyển đổi sang BNB, nhưng vẫn chưa được chuyển ra khỏi địa chỉ của kẻ tấn công.
Kẻ tấn công chủ yếu đã lợi dụng lỗ hổng trong hàm CreateMassPools của hợp đồng Poolz. Hàm này ban đầu được sử dụng để tạo hàng loạt hồ bơi token và cung cấp thanh khoản ban đầu, nhưng hàm getArraySum bên trong gặp vấn đề tràn số nguyên. Kẻ tấn công thông qua các tham số đầu vào được xây dựng cẩn thận, khiến cho kết quả cộng dồn vượt quá phạm vi của kiểu uint256, dẫn đến số lượng token thực tế chuyển vào không khớp với số lượng được ghi nhận.
Lỗ hổng này cho phép kẻ tấn công ghi lại một số lượng lớn số dư token trong hệ thống với một lượng token đầu vào rất nhỏ. Sau đó, kẻ tấn công gọi hàm withdraw để rút các token được ghi lại giả mạo này, hoàn thành toàn bộ quá trình tấn công.
Các vấn đề tràn số học như vậy không phải là hiếm trong phát triển hợp đồng thông minh. Để phòng ngừa các rủi ro tương tự, các nhà phát triển nên sử dụng các phiên bản mới hơn của ngôn ngữ lập trình Solidity, những phiên bản này sẽ tự động kiểm tra tràn số khi biên dịch. Đối với các dự án sử dụng phiên bản Solidity cũ hơn, nên đưa vào thư viện SafeMath của OpenZeppelin để xử lý các phép toán số nguyên, nhằm tránh rủi ro tràn số.
Sự kiện này một lần nữa nhắc nhở các dự án blockchain và các nhà phát triển rằng trong quá trình thiết kế và triển khai hợp đồng thông minh, cần phải đặc biệt chú ý đến tính an toàn. Đồng thời, nó cũng làm nổi bật tầm quan trọng của việc thực hiện kiểm toán an toàn định kỳ và các chương trình thưởng cho lỗ hổng, nhằm phát hiện và sửa chữa sớm những rủi ro tiềm ẩn về an ninh.