Dự án NFT bị khoá 11.539 ETH vĩnh viễn trong smartcontract vì lỗi code cơ bản

Vào ngày 23 tháng 4, nhà phát triển Solidity foobar đã tweet rằng 11.539 ETH (trị giá 34 triệu đô la) đã bị khóa vĩnh viễn trong hợp đồng AkuDreams và cả người dùng cá nhân hoặc nhóm phát triển đều không thể rút tiền. 

Vào 23/04/2022, một giám sát đã phát hiện 11.539 ETH (trị giá khoảng 34 triệu đô la) đã bị khóa do những lỗ hổng trong smartcontarct trong hợp đồng AkuAuction của Akutar. Nhóm kỹ thuật đã phân tích sự cố và kết quả như sau.

Thông tin liên quan đến sự kiện

Vào ngày 23 tháng 4, nhà phát triển Solidity foobar đã tweet rằng 11.539 ETH (trị giá 34 triệu đô la) đã bị khóa vĩnh viễn trong hợp đồng AkuDreams và cả người dùng cá nhân hoặc nhóm phát triển đều không thể rút tiền. 

Sau khi quá trình xử lý hoàn tiền hoàn tất, trạng thái giá thầu đặt thành 1. Do đó, người dùng không thể gọi hàm emergenyWithdraw(). Do đó nhóm không thể nhận được tiền, về cơ bản nó giống như quá trình burn.

• Hợp đồng bị lỗi:  0xf42c318dbfbaab0eee040279c6a2588fa01a961d

Phân tích lỗ hổng

Hợp đồng thông minh của dự án Akutar gồm 2 lỗ hổng:

Lỗ hổng 1

1. Lỗ hổng đầu tiên của hợp đồng là hàm processRefunds, nhà thiết kế thực hiện hoàn tiền theo chu kỳ theo hàm refundProgress.

2. Hàm gọi được sử dụng cho hoạt động hoàn tiền và kết quả hoàn tiền được sử dụng làm điều kiện phán quyết theo yêu cầu.

3. Do đó, nếu kẻ tấn công thực hiện thao tác hoàn tiền trong hàng đợi tại thời điểm này, khi hàm gọi để hoàn tiền cho kẻ tấn công, kẻ tấn công thực hiện các hoàn nguyên độc, điều này sẽ khiến hàng đợi hoàn tiền bị mắc kẹt, dẫn đến Refunds không có sẵn cho bất kỳ ai đứng sau hàng đợi.

4. Lỗ hổng này đã được chứng minh là hợp lệ trên chuỗi, nhưng sau đó hợp đồng tấn công đã được unlock nhưng không có cuộc tấn công nào bị khai thác và nó đã được tuyên bố công khai.

Lỗ hổng thứ hai

Lỗ hổng này là thủ phạm khiến tài sản ETH trị giá khoảng 34 triệu USD bị khóa trong hợp đồng.

1. Trong hàm claimProjectFunds dùng để rút tiền từ phía dự án. Để tránh sự lạm quyền quá mức của bên dự án, tất cả các tài sản trong hợp đồng được chuyển đi trước khi người dùng hoàn thành việc rút tiền, do đó người dùng không thể được hoàn lại tiền và dự án chỉ có thể rút tiền sau khi tất cả các hoạt động hoàn tiền được hoàn thành. Về logic kinh doanh thì thiết kế này là bình thường, không có vấn đề gì. Tuy nhiên, trong quá trình triển khai code, code hiện tại dễ bị lỗ hổng 1, điều này khiến bên dự án không thể rút tiền, nhưng đây chỉ là rủi ro tiềm ẩn và đây không phải là lý do cho việc khóa quỹ lần này.

2. Lưu ý dòng code thứ 620 trong hàm: require (refundProgress > = totalBids) trong đó refundProgress cho biết có bao nhiêu khoản hoàn tiền của người dùng đã được xử lý và totalBids cho biết tổng số NFT mà tất cả người dùng đặt giá thầu là bao nhiêu. Lưu ý rằng vì người dùng có thể đặt giá thầu cho nhiều NFT, refundProgress có thể nhỏ hơn totalBids.

Chúng ta hãy xem xét quy trình hàm processRefunds: require (_refundProgress < _bidIndex), bidIndex đại diện cho tất cả người dùng tham gia đấu thầu và refundProgress sẽ không bao giờ cao hơn bidIndex.

Giá trị của bidIndex tại thời điểm đó là 3669.

Giá trị của totalBids là 5495.

3. Do đó, điều kiện thực thi của refundProgress> = 5495 và refundProgress<3669 sẽ không bao giờ được thiết lập, và cuối cùng nhóm dự án sẽ không bao giờ có thể thực hiện các hoạt động rút tiền tiếp theo. RefundProgress nên được so sánh với bidIndex ở đây, nhà phát triển đã phạm một sai lầm cấp độ rất cơ bản. Cuối cùng, số 11539 ETH (trị giá khoảng 34 triệu đô la) của dự án đã bị khóa và không thể rút lại.

Tổng kết

Để giải quyết tình trạng này:

1. Nhà phát triển cần phải biết cơ bản về phát triển bảo mật và quen thuộc với các vấn đề bảo mật trong phát triển hợp đồng thông minh.

2. Khi thiết kế và thực hiện hợp đồng, chú ý đến sự hoàn chỉnh về code.  Trước khi dự án được triển khai, bạn có thể chọn một công ty audit bảo mật chuyên nghiệp để tiến hành audit bảo mật toàn diện để tránh rủi ro bảo mật.