Trong những tháng gần đây, đã xảy ra một số sự cố bảo mật liên quan đến lỗ hổng tính toán độ chính xác về giá trong quá trình phát triển hợp đồng, số tiền thiệt hại lên tới hơn 10 triệu đô la Mỹ, bao gồm 6,5 triệu USD của MIM_SPELL, 4,5 triệu USD của RadiantCapital, 2,1 triệu USD của Onyx Protocol. triệu, v.v. Do có vấn đề về độ chính xác trong quá trình tính toán nên các biến chính được tính toán không chính xác và bị tấn công.

SharkTeam đã tổng hợp những sự cố bảo mật như vậy và đưa ra những đề xuất bảo mật hiệu quả, hy vọng các giao thức tiếp theo có thể đóng vai trò cảnh báo và bảo vệ sự an toàn cho tài sản mã hóa của người dùng.

1. Sự cố tấn công MIM_SPELL

Thời gian diễn ra: 30/01/2024

Số tiền thiệt hại: khoảng 6,5 triệu USD,

Lý do dễ bị tổn thương: Trong hợp đồng có hai biến cho vay co giãn và cơ sở, khi tính toán độ chính xác của cả hai đều sử dụng phương pháp làm tròn lên trên. Thao tác này sẽ khiến tham số có kết quả tính toán phải là 0 cuối cùng được tính thành 1, gây ra sự mất cân bằng giữa hai tham số và cuối cùng cho phép cho mượn quá mức mã thông báo MIM.

Phân tích chi tiết: https://bit.ly/3ScR7TK

2. Sự cố tấn công RadiantCapital

Thời gian diễn ra: 02/01/2024

Số tiền thiệt hại: khoảng 4,5 triệu USD,

Nguyên nhân lỗ hổng: Hacker đã lợi dụng lỗ hổng trong hợp đồng là thị trường mới chưa được khởi tạo, chỉ số thanh khoản chưa được khởi tạo, cho phép hacker thao túng kích thước của nó thông qua chức năng flash loan. Tin tặc đã lợi dụng độ chính xác làm tròn trong hàm rayDiv. Vấn đề là khi số mũ trở nên lớn hơn, giới hạn trên của mức giảm độ chính xác do làm tròn cũng trở nên lớn hơn và tin tặc có thể thu lợi từ các hoạt động truy cập lặp đi lặp lại.

3. Sự cố tấn công giao thức Onyx

Thời gian diễn ra: 11/11/2023

Số tiền thiệt hại: khoảng 2,1 triệu USD,

Lý do lỗ hổng: Tương tự như vụ tấn công RadiantCapital, lỗ hổng của thị trường mới chưa khởi tạo thanh khoản cũng bị khai thác và có lỗ hổng làm tròn trong hàm divUint gây mất độ chính xác.

Phân tích chi tiết: https://bit.ly/47cKeI6

4. Sự cố tấn công WiseLending

Thời gian diễn ra: 12/01/2024

Số tiền thiệt hại: khoảng 465.000 USD,

Lý do gây ra lỗ hổng: Hợp đồng sử dụng cách làm tròn lên khi tính toán phần cho vay. Kẻ tấn công sử dụng điều này để thực hiện các hoạt động truy cập lặp đi lặp lại nhằm tăng giá cổ phiếu. Sau khi giá cổ phiếu tăng, anh ta vay một lượng lớn ETH bằng cổ phiếu của chính mình.

5. Cuộc tấn công HopeLend

Thời gian diễn ra: 18/10/2023

Số tiền thiệt hại: khoảng 850.000 USD

Lý do xảy ra lỗ hổng: Hacker ban đầu lợi dụng sự mất cân bằng thanh khoản trong nhóm tương ứng với tài sản mục tiêu, thao túng chỉ số thanh khoản của hToken liên quan đến tài sản mục tiêu và bóp méo giá trị của nó. Sau đó, tin tặc đã vay tất cả các tài sản cơ bản khác bằng cách sử dụng một lượng tài sản thế chấp hToken rất nhỏ. Sau đó, hacker còn khai thác lỗ hổng làm tròn trong chức năng rayDiv trong hoạt động phân tách hợp đồng để liên tục gửi và rút tiền, làm cạn kiệt tài sản cơ bản được đầu tư trong cuộc tấn công Hopelend.

Các vấn đề về độ chính xác thường được chia thành hai loại:

1. Một loại làm tròn lên không chính xác, có thể khiến tham số lẽ ra phải bằng 0 bị lấy về 1, gây ra sơ hở nghiêm trọng trong các phép tính tiếp theo;

2. Loại thứ hai là các vấn đề làm tròn, trong đó vấn đề nghiêm trọng nhất là các dự án sử dụng hàm rayDiv không chính xác.

Lời khuyên an toàn:

1. Đối với loại đầu tiên, nếu logic dự án yêu cầu thao tác làm tròn lên, các thử nghiệm lặp lại nhiều lần và đa dạng phải được thực hiện trong điều kiện biến làm tròn là 1 hoặc 0, v.v.

2. Đối với loại thứ hai, bạn có thể sử dụng phương pháp nhân và chia thứ nhất với độ chính xác đồng đều, ví dụ: sử dụng 10**18 làm hậu tố làm giá trị sau dấu thập phân.

3. Dù trong tình huống nào, hãy kiểm tra logic tính toán về mọi mặt và xem xét mọi tình huống càng nhiều càng tốt, đặc biệt khi các kết quả tính toán khác nhau có logic xử lý khác nhau thì cần phải kiểm tra cẩn thận. Thiết kế logic lý thuyết được kết hợp với việc triển khai mã thực tế để kiểm tra các chức năng hợp đồng một cách toàn diện mà không có bất kỳ điểm mù nào. Nếu các trường hợp kiểm thử có thể bao gồm nhiều thay đổi khác nhau thì có thể tránh được các vấn đề bảo mật do tính toán chính xác gây ra.

Tầm nhìn của SharkTeam là bảo vệ thế giới Web3. Nhóm bao gồm các chuyên gia bảo mật giàu kinh nghiệm và các nhà nghiên cứu cấp cao từ khắp nơi trên thế giới, những người thành thạo lý thuyết cơ bản về blockchain và hợp đồng thông minh. Nó cung cấp các dịch vụ bao gồm phân tích dữ liệu lớn trên chuỗi, cảnh báo rủi ro trên chuỗi, KYT/AML, kiểm toán hợp đồng thông minh, phục hồi tài sản được mã hóa và các dịch vụ khác, đồng thời đã tạo ra nền tảng nhận dạng rủi ro thông minh trên chuỗi ChainAegis. phân tích biểu đồ chuyên sâu và có thể chống lại mối đe dọa liên tục nâng cao (APT) một cách hiệu quả trong thế giới Web3. Nó đã thiết lập mối quan hệ hợp tác lâu dài với những người chơi chủ chốt trong các lĩnh vực khác nhau của hệ sinh thái Web3, như Polkadot, Moonbeam, Polygon, Sui, OKX, imToken, Collab.Land, v.v.

Trang web chính thức: https://www.sharkteam.org

Twitter: https://twitter.com/sharkteamorg

Bất hòa: https://discord.gg/jGH9xXCjDZ

Điện tín: https://t.me/sharkteamorg