Poolz bị tấn công tràn số học, thiệt hại khoảng 66,5 nghìn đô la
Gần đây, nhiều dự án Poolz trên các mạng blockchain đã bị tấn công, dẫn đến việc một lượng lớn token bị đánh cắp, tổng giá trị khoảng 665.000 USD. Cuộc tấn công này xảy ra vào ngày 15 tháng 3 năm 2023, ảnh hưởng đến các hợp đồng Poolz trên nhiều mạng như Ethereum, BNB Chain và Polygon.
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 Poolz. Cụ thể, vấn đề nằm ở hàm getArraySum trong hàm CreateMassPools. Hàm này khi tính toán tính thanh khoản ban đầu của các pool, do tràn số nguyên, đã khiến kẻ tấn công chỉ cần chuyển vào một lượng nhỏ token đã có thể tạo ra ảo giác về thanh khoản lớn.
Quá trình tấn công như sau:
Kẻ tấn công trước tiên đã đổi một lượng nhỏ token MNZ trên một sàn DEX.
Sau đó gọi hàm CreateMassPools có lỗ hổng. Hàm này 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.
Khi tính toán số tiền thanh khoản ban đầu, hàm getArraySum gặp phải tràn số nguyên. Tổng của mảng được kẻ tấn công truyền vào vượt quá giá trị tối đa mà uint256 có thể biểu diễn, dẫn đến giá trị trả về của hàm trở thành 1.
Tuy nhiên, hợp đồng vẫn sử dụng giá trị mảng _StartAmount gốc khi ghi lại thuộc tính của bể. Điều này dẫn đến việc kẻ tấn công thực tế chỉ chuyển vào 1 mã thông báo, nhưng lại được ghi nhận là có tính thanh khoản khổng lồ.
Cuối cùng, kẻ tấn công gọi hàm withdraw để rút tiền, hoàn thành cuộc tấn công.
Sự kiện này đã phơi bày nguy cơ của việc tràn số trong hợp đồng thông minh. Để ngăn chặn các vấn đề tương tự, các nhà phát triển nên xem xét sử dụng phiên bản mới hơn của trình biên dịch Solidity, vì chúng sẽ tự động thực hiện kiểm tra tràn. Đối với các dự án sử dụng phiên bản Solidity cũ hơn, có thể sử dụng thư viện SafeMath của OpenZeppelin để xử lý phép toán số nguyên nhằm tránh rủi ro tràn.
Cuộc tấn công lần này lại nhấn mạnh rằng khi phát triển và kiểm toán hợp đồng thông minh, cần đặc biệt chú ý đến tính an toàn của các thao tác số học. Đồng thời, các bên dự án cũng nên thực hiện kiểm toán an toàn định kỳ, kịp thời phát hiện và sửa chữa các lỗ hổng tiềm ẩn để bảo vệ tài sản 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.
17 thích
Phần thưởng
17
6
Chia sẻ
Bình luận
0/400
OnChainDetective
· 08-05 14:50
đã phát hiện ra mô hình tấn công này trước đây... sai lầm tràn số nguyên của người mới. khi nào các nhà phát triển mới học cách sử dụng safeMath thật đáng thất vọng
Xem bản gốcTrả lời0
AirdropGrandpa
· 08-05 14:44
Lại là tràn ngăn xếp, thật không ra gì.
Xem bản gốcTrả lời0
CryptoSurvivor
· 08-05 14:42
Lỗ hổng nhỏ như vậy cũng có thể bị phát hiện, thật sự là những kẻ hèn mọn.
Xem bản gốcTrả lời0
FrogInTheWell
· 08-05 14:38
Lại là tràn số... Bạn có hiểu về kiểm toán an toàn không?
Poolz bị tấn công tràn số học, thiệt hại 665.000 USD, nhiều dự án đa chuỗi bị ảnh hưởng.
Poolz bị tấn công tràn số học, thiệt hại khoảng 66,5 nghìn đô la
Gần đây, nhiều dự án Poolz trên các mạng blockchain đã bị tấn công, dẫn đến việc một lượng lớn token bị đánh cắp, tổng giá trị khoảng 665.000 USD. Cuộc tấn công này xảy ra vào ngày 15 tháng 3 năm 2023, ảnh hưởng đến các hợp đồng Poolz trên nhiều mạng như Ethereum, BNB Chain và Polygon.
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 Poolz. Cụ thể, vấn đề nằm ở hàm getArraySum trong hàm CreateMassPools. Hàm này khi tính toán tính thanh khoản ban đầu của các pool, do tràn số nguyên, đã khiến kẻ tấn công chỉ cần chuyển vào một lượng nhỏ token đã có thể tạo ra ảo giác về thanh khoản lớn.
Quá trình tấn công như sau:
Kẻ tấn công trước tiên đã đổi một lượng nhỏ token MNZ trên một sàn DEX.
Sau đó gọi hàm CreateMassPools có lỗ hổng. Hàm này 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.
Khi tính toán số tiền thanh khoản ban đầu, hàm getArraySum gặp phải tràn số nguyên. Tổng của mảng được kẻ tấn công truyền vào vượt quá giá trị tối đa mà uint256 có thể biểu diễn, dẫn đến giá trị trả về của hàm trở thành 1.
Tuy nhiên, hợp đồng vẫn sử dụng giá trị mảng _StartAmount gốc khi ghi lại thuộc tính của bể. Điều này dẫn đến việc kẻ tấn công thực tế chỉ chuyển vào 1 mã thông báo, nhưng lại được ghi nhận là có tính thanh khoản khổng lồ.
Cuối cùng, kẻ tấn công gọi hàm withdraw để rút tiền, hoàn thành cuộc tấn công.
Sự kiện này đã phơi bày nguy cơ của việc tràn số trong hợp đồng thông minh. Để ngăn chặn các vấn đề tương tự, các nhà phát triển nên xem xét sử dụng phiên bản mới hơn của trình biên dịch Solidity, vì chúng sẽ tự động thực hiện kiểm tra tràn. Đối với các dự án sử dụng phiên bản Solidity cũ hơn, có thể sử dụng thư viện SafeMath của OpenZeppelin để xử lý phép toán số nguyên nhằm tránh rủi ro tràn.
Cuộc tấn công lần này lại nhấn mạnh rằng khi phát triển và kiểm toán hợp đồng thông minh, cần đặc biệt chú ý đến tính an toàn của các thao tác số học. Đồng thời, các bên dự án cũng nên thực hiện kiểm toán an toàn định kỳ, kịp thời phát hiện và sửa chữa các lỗ hổng tiềm ẩn để bảo vệ tài sản của người dùng.