Dự án Poolz bị tấn công do lỗ hổng tràn số, tổn thất khoảng 66,5 triệu đô la.
Gần đây, một vụ tấn công nhắm vào dự án Poolz đã thu hút sự chú ý rộng rãi từ cộng đồng tiền điện tử. Theo dữ liệu giám sát trên chuỗi, vụ tấn công xảy ra vào ngày 15 tháng 3 năm 2023, liên quan đến ba mạng lưới Ethereum, BNB Chain và Polygon. Kẻ tấn công đã lợi dụng lỗ hổng tràn số trong hợp đồng thông minh, thành công đánh cắp một lượng lớn token, tổng giá trị khoảng 665.000 USD.
Chi tiết tấn công
Kẻ tấn công đã thực hiện cuộc tấn công này thông qua các bước sau:
Trước tiên, bạn đã trao đổi một số lượng nhất định MNZ token trên sàn giao dịch phi tập trung.
Sau đó, đã gọi hàm CreateMassPools trong hợp đồng Poolz. Hàm này lẽ ra cho phép người dùng tạo hàng loạt các bể thanh khoản và cung cấp thanh khoản ban đầu, nhưng có một lỗ hổng nghiêm trọng trong đó.
Vấn đề xuất hiện trong hàm getArraySum. Hàm này được sử dụng để tính toán số lượng thanh khoản ban đầu do người dùng cung cấp, nhưng không xử lý đúng tình huống tràn số nguyên.
Kẻ tấn công đã khéo léo tạo ra các tham số đầu vào, khiến cho mảng _StartAmount chứa các số vượt quá giá trị tối đa của uint256. Điều này dẫn đến việc tổng cộng bị tràn, và giá trị trả về cuối cùng là 1.
Do hợp đồng đã sử dụng giá trị gốc của _StartAmount khi ghi lại thuộc tính của bể, thay vì số lượng token thực tế đã chuyển vào, kẻ tấn công chỉ cần chuyển vào 1 token là có thể tạo ra một bể có tính thanh khoản cao hơn nhiều so với thực tế.
Cuối cùng, kẻ tấn công đã rút ra một lượng lớn token không được ủy quyền bằng cách gọi hàm withdraw, hoàn thành toàn bộ quá trình tấn công.
Tài sản bị đánh cắp
Cuộc tấn công này đã khiến nhiều loại token bị tổn thất, bao gồm nhưng không giới hạn ở:
2,805,805 MEE
525,134 ESNC
774,997 DON
2.007.504.238 ASW
6,510,689 KMON
2,521,065 POOLZ
35,976,107 DCD
760,845 PORTX
Kẻ tấn công đã đổi một phần token bị đánh cắp sang BNB, nhưng tính đến thời điểm báo cáo, số tiền này vẫn chưa được chuyển ra khỏi địa chỉ của kẻ tấn công.
Lời khuyên phòng ngừa
Để ngăn chặn các lỗ hổng tràn số học tương tự, các chuyên gia khuyên nên thực hiện các biện pháp sau:
Sử dụng phiên bản trình biên dịch Solidity mới hơn, các phiên bản này sẽ tự động kiểm tra tràn trong quá trình biên dịch.
Đối với các dự án sử dụng phiên bản Solidity cũ hơn, khuyến nghị 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 vấn đề tràn số.
Thực hiện kiểm toán mã toàn diện, đặc biệt chú ý đến các phần liên quan đến tính toán số lớn.
Thực hiện kiểm tra đầu vào nghiêm ngặt, đảm bảo rằng các tham số do người dùng cung cấp nằm trong phạm vi hợp lý.
Cân nhắc thêm các cơ chế bảo mật như chữ ký đa chữ hoặc khóa thời gian vào các hoạt động quan trọng.
Sự kiện này một lần nữa làm nổi bật tầm quan trọng của an toàn hợp đồng thông minh, nhắc nhở các nhà phát triển và các bên dự án cần luôn giữ cảnh giác, liên tục hoàn thiện tính an toàn của mã. Đồng thời, cũng nhắc nhở người dùng cần đặc biệt cẩn thận khi tương tác với các dự án tài chính phi tập trung, đặc biệt là khi tham gia vào các dự án mới ra mắt hoặc chưa được kiểm toán đầy đủ.
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.
Dự án Poolz bị tấn công tràn số học, thiệt hại 665.000 USD mã hóa
Dự án Poolz bị tấn công do lỗ hổng tràn số, tổn thất khoảng 66,5 triệu đô la.
Gần đây, một vụ tấn công nhắm vào dự án Poolz đã thu hút sự chú ý rộng rãi từ cộng đồng tiền điện tử. Theo dữ liệu giám sát trên chuỗi, vụ tấn công xảy ra vào ngày 15 tháng 3 năm 2023, liên quan đến ba mạng lưới Ethereum, BNB Chain và Polygon. Kẻ tấn công đã lợi dụng lỗ hổng tràn số trong hợp đồng thông minh, thành công đánh cắp một lượng lớn token, tổng giá trị khoảng 665.000 USD.
Chi tiết tấn công
Kẻ tấn công đã thực hiện cuộc tấn công này thông qua các bước sau:
Trước tiên, bạn đã trao đổi một số lượng nhất định MNZ token trên sàn giao dịch phi tập trung.
Sau đó, đã gọi hàm CreateMassPools trong hợp đồng Poolz. Hàm này lẽ ra cho phép người dùng tạo hàng loạt các bể thanh khoản và cung cấp thanh khoản ban đầu, nhưng có một lỗ hổng nghiêm trọng trong đó.
Vấn đề xuất hiện trong hàm getArraySum. Hàm này được sử dụng để tính toán số lượng thanh khoản ban đầu do người dùng cung cấp, nhưng không xử lý đúng tình huống tràn số nguyên.
Kẻ tấn công đã khéo léo tạo ra các tham số đầu vào, khiến cho mảng _StartAmount chứa các số vượt quá giá trị tối đa của uint256. Điều này dẫn đến việc tổng cộng bị tràn, và giá trị trả về cuối cùng là 1.
Do hợp đồng đã sử dụng giá trị gốc của _StartAmount khi ghi lại thuộc tính của bể, thay vì số lượng token thực tế đã chuyển vào, kẻ tấn công chỉ cần chuyển vào 1 token là có thể tạo ra một bể có tính thanh khoản cao hơn nhiều so với thực tế.
Cuối cùng, kẻ tấn công đã rút ra một lượng lớn token không được ủy quyền bằng cách gọi hàm withdraw, hoàn thành toàn bộ quá trình tấn công.
Tài sản bị đánh cắp
Cuộc tấn công này đã khiến nhiều loại token bị tổn thất, bao gồm nhưng không giới hạn ở:
Kẻ tấn công đã đổi một phần token bị đánh cắp sang BNB, nhưng tính đến thời điểm báo cáo, số tiền này vẫn chưa được chuyển ra khỏi địa chỉ của kẻ tấn công.
Lời khuyên phòng ngừa
Để ngăn chặn các lỗ hổng tràn số học tương tự, các chuyên gia khuyên nên thực hiện các biện pháp sau:
Sử dụng phiên bản trình biên dịch Solidity mới hơn, các phiên bản này sẽ tự động kiểm tra tràn trong quá trình biên dịch.
Đối với các dự án sử dụng phiên bản Solidity cũ hơn, khuyến nghị 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 vấn đề tràn số.
Thực hiện kiểm toán mã toàn diện, đặc biệt chú ý đến các phần liên quan đến tính toán số lớn.
Thực hiện kiểm tra đầu vào nghiêm ngặt, đảm bảo rằng các tham số do người dùng cung cấp nằm trong phạm vi hợp lý.
Cân nhắc thêm các cơ chế bảo mật như chữ ký đa chữ hoặc khóa thời gian vào các hoạt động quan trọng.
Sự kiện này một lần nữa làm nổi bật tầm quan trọng của an toàn hợp đồng thông minh, nhắc nhở các nhà phát triển và các bên dự án cần luôn giữ cảnh giác, liên tục hoàn thiện tính an toàn của mã. Đồng thời, cũng nhắc nhở người dùng cần đặc biệt cẩn thận khi tương tác với các dự án tài chính phi tập trung, đặc biệt là khi tham gia vào các dự án mới ra mắt hoặc chưa được kiểm toán đầy đủ.