CryptoBike - Vấn đề lớn trong contract ERC721.
CryptoBike - Vấn đề lớn trong contract ERC721.
Bài viết đã được gửi cho đội ngũ phát triển game trước khi public. Đội ngũ làm game đã biết về các vấn đề trong vài viết và có kế hoạch triển khai để giảm thiểu tác động.
Trong quá trình trace transactions ở một proxy contract, mình có tìm thấy một contract ERC721 đã được verified nên vào đọc code để xem thử và tìm thấy vài điểm thú vị.
Phạm vi bài viết
Bài viết phân tích về contract ERC721 của dự án CryptoBike đã được audit:
CryptoBike là contract NFT chính của dự án CryptoBike, trong contract có chứa các logic về mint, transferNFT, fixBike , upgradeBike,... trong đó một số hàm khi gọi sẽ cần cung cấp một lượng phí nhất định và hàm upgradeBike sẽ nâng cấp NFT với các giá trị ngẫu nhiên.
Thông chức năng chính trong trò chơi ta có thể đọc được trong whitepaper của dự án:
https://whitepaper.cryptobike.net/guides/how-to-start-playing/cryptobike-gameplay
Mã nguồn của contract mình phân tích đã được verified trên bscscan: https://bscscan.com/address/0x54ed3b6e9c103b80a0b3af24504dfb7e78216560#code
Quá trình phân tích
Trong quá trình đọc source code của contract mình để ý tới hàm upgradeBike.
Hàm upgradeBike là hàm nâng cấp vật phẩm trong game được truyền vào thông số _winRate và _rewardRate lại được có tầm vực truy cập là external- ai cũng có thể gọi được. Đây là một điểm khá lạ, những chỉ số quan trọng như vậy không thể nào để người chơi tự điền trực tiếp như vậy được. Và người dùng phải tốn ít nhất là 25 cryptoBike token để lệnh gọi này được thực hiện.
Hàm upgradeBike này sử dụng modifier bikeUpgrade để hỗ trợ kiểm tra đầu vào. Tuy nhiên modifier này chỉ giới hạn vùng giá trị của hai thông số _winRate , _rewardRate và đảm bảo rằng chỉ có chủ của token mới có quyền nâng cấp nó.
Hàm _setUpNewBike được upgradeBike sử dụng cũng chỉ đơn thuần là cập nhật trạng thái của token ứng với các thông số được truyền vào.
Vậy là không có một mối ràng buộc nào với các input do người chơi truyền vào cả mặc dù 2 tỉ lệ này rất quan trọng. Thông thường các giá trị quan trọng như thế này sẽ được random onchain hoặc xử lý offchain sau đó được verify bằng các chữ ký số trong quá trình vận hành.
Để xem lại tầm quan trọng của các giá trị này thì mình đã đọc lại document của dự án.
https://whitepaper.cryptobike.net/guides/how-to-start-playing/bike-upgrade
Trong document của dự án có ghi rõ giá trị upgrade sẽ là ngẫu nhiên với giá trị reward từ 1-3% và win-rate từ 2-5% giống với giới hạn trong modifier bikeUpgrade . Lượng phí yêu cầu để nâng cấp là 25$CB.
Dựa vào document mình có thể kết luận hàm upgradeBike có tới hai lỗi:
Giá trị nâng cấp là ngẫu nhiên nhưng hàm hiện thực lại cho phép người nâng cấp lại có thể điều khiển được.
Lượng phí yêu cầu để nâng cấp là 25$CB thế nhưng nếu người dùng lỡ nhập vào
amounthơn 25$ CB thì nó tất cả sẽ là phí để nâng cấp.
Với lỗi thứ 2 mình tiếp tục thấy nó ở các hàm fixbike và buynewbox.
Phí dịch vụ của các hàm đều là hằng số, message nếu lỗi cũng ghi rõ ra số token cần. Nhưng nếu người dùng nhập dư amount thì tất cả sẽ đều là phí và được chuyển về cho contract này.
Hai lỗi mà mình đề cập là lỗi rất cơ bản trong quá trình phát triển contract tuy nhiên tác động của chúng đều rất lớn.
Với lỗi đầu tiên, người dùng có thể lợi dụng để nâng cấp token của mình lên giá trị tối đa và đợi market để bán với giá trị lớn.
Lỗi thứ hai sẽ khiến người chơi bị tốn nhiều hơn phí dự kiến nếu nhầm lẫn trong quá trình nhập liệu trước khi gọi tới contract.
Một điểm lạ là contract của họ đã được audit nhưng không hề có một issue nào về các lỗi mình đề cập ở trên.
Kết luận
Những lỗi trên sẽ gây ảnh hưởng rất lớn đến dự án và mình mong các dự án sẽ quan tâm và đầu tư hơn về các vấn đề bảo mật của cả ở phần offchain hay trên blockchain. Rất nhiều dự án đã phải chết yểu hay bị tấn công gây ra rất nhiều thiệt hại nghiêm trọng cho cả nhà đầu tư và chủ dự án. Audit mã nguồn sẽ là một phương pháp để phát hiện sớm các lỗi, tuy nhiên việc audit cũng chưa chắc đã phát hiện hết lỗi trong hệ thống. Để đảm bảo hơn dự án nên được audit bởi các công ty uy tín và sẽ càng tốt nếu được audit nhiều lần bởi nhiều đội ngũ hoạt động độc lập với nhau.