Đối tác nghiên cứu mô hình: Các cuộc tấn công chống lại NFT có thể sẽ trở nên thường xuyên hơn

Tiêu đề gốc: " Sự nguy hiểm của mật mã đáng ngạc nhiên 》

Tác giả gốc: samczsun

Bản tổng hợp gốc: Cháo qua đêm, Babbitt

Lưu ý: Tác giả gốc là samczsun, một hacker mũ trắng được mệnh danh là "Thần kiểm toán" , anh ấy cũng là đối tác nghiên cứu tại Paradigm, công ty gần đây đã giải cứu tài sản trị giá 350 triệu đô la Mỹ trong quỹ đấu giá BitDAO MISO Dutch. Trong bài viết này, anh ấy đã nhắc nhở về những rủi ro bảo mật tiềm ẩn của tiêu chuẩn mã thông báo NFT. Anh ấy cũng đưa ra các dự đoán như vậy Tiêu chuẩn token ERC-721 và ERC-1155 ngày càng trở nên phổ biến, các cuộc tấn công chống lại NFT có thể sẽ diễn ra thường xuyên hơn.

Nếu Nếu bạn làm việc trong lĩnh vực công nghệ phần mềm, rất có thể bạn đã nghe nói đến ít nhất một nguyên tắc công nghệ phần mềm. Mặc dù tôi không ủng hộ việc tuân thủ nghiêm ngặt mọi nguyên tắc, nhưng có một số nguyên tắc chắc chắn đáng được chú ý.

Điều tôi sắp nói hôm nay là nguyên tắc ít gây ngạc nhiên nhất. Nó có một cái tên lạ mắt nhưng lại là một ý tưởng rất đơn giản. Điều nó nói lên là khi được đưa ra đoạn mã tuyên bố sẽ làm điều gì đó, hầu hết người dùng sẽ đưa ra các giả định về cách thức thực hiện điều đó. Do đó, công việc của bạn với tư cách là nhà phát triển là viết mã tuân thủ các giả định này để người dùng của bạn không bị bất ngờ.

Đây là một nguyên tắc tốt vì các nhà phát triển thích đưa ra các giả định về mọi thứ. Nếu bạn xuất một hàm có tên là CalculateScore(GameState), nhiều người sẽ cho rằng hàm này sẽ chỉ đọc từ trạng thái trò chơi. Nếu bạn cũng thay đổi trạng thái trò chơi, bạn sẽ khiến nhiều người bối rối khi cố gắng tìm hiểu tại sao trạng thái trò chơi của họ lại bị hỏng ngẫu nhiên. Ngay cả khi bạn đưa nó vào tài liệu, vẫn không có gì đảm bảo rằng mọi người sẽ nhìn thấy nó, vì vậy tốt nhất bạn nên đảm bảo mã của mình không gây ngạc nhiên ngay từ đầu.

"Sáu giờ sửa lỗi có thể giúp bạn tiết kiệm được 5 phút về thời gian đọc tài liệu."

Càng an toàn càng tốt, phải không?

Ngay từ đầu năm 2018, khi chuẩn ERC-721 được soạn thảo, đã có người đề xuất thực hiện chuyển giao đề xuất bảo mật‌ để đảm bảo mã thông báo không bị kẹt trong hợp đồng người nhận không được sử dụng để xử lý mã thông báo. Vì mục đích này, các tác giả đề xuất đã sửa đổi hành vi của chức năng chuyển để kiểm tra xem người nhận có thể hỗ trợ chuyển mã thông báo hay không. Họ cũng giới thiệu chức năng không an toànTransfer, chức năng này sẽ bỏ qua việc kiểm tra này nếu người gửi muốn.

Tuy nhiên, do lo ngại về khả năng tương thích ngược, chức năng này đã được đổi tên trong lần chuyển giao tiếp theo. Điều này làm cho chức năng chuyển giao hoạt động giống hệt nhau đối với mã thông báo ERC-20 và ERC-721. Tuy nhiên, kiểm tra người nhận bây giờ cần phải được chuyển đi nơi khác. Do đó, tác giả tiêu chuẩn đã giới thiệu các hàm lớp an toàn: safeTransfer và safeTransferFrom.

Đây là giải pháp cho vấn đề tính hợp pháp, vì có nhiều token ERC-20 vô tình được chuyển sang các hợp đồng mà không bao giờ mong đợi nhận được token. Ví dụ (a sai lầm đặc biệt phổ biến là chuyển mã thông báo vào hợp đồng mã thông báo, khóa chúng vĩnh viễn). Không có gì ngạc nhiên khi khi soạn thảo tiêu chuẩn ERC-1155, các tác giả đề xuất đã lấy cảm hứng từ tiêu chuẩn ERC-721 để kết hợp việc kiểm tra bộ thu không chỉ tại thời điểm chuyển giao mà còn tại thời điểm đúc tiền.

Mặc dù các tiêu chuẩn này hầu như không hoạt động trong vài năm tới, nhưng tiêu chuẩn mã thông báo ERC-20 vẫn duy trì mức độ phổ biến của nó trong khi giá gas gần đây tăng vọt và cộng đồng ngày càng phát triển quan tâm đến NFT đã khiến các nhà phát triển ngày càng sử dụng nhiều hơn các tiêu chuẩn mã thông báo ERC-721 và ERC-1155. Với tất cả sự quan tâm mới này, chúng ta nên biết ơn vì những tiêu chuẩn này được thiết kế với mục đích bảo mật, phải không?

Càng an toàn thì càng tốt, phải không?

Được rồi, nhưng bảo mật có ý nghĩa gì đối với việc chuyển tiền và đúc tiền? Các bên khác nhau có cách giải thích khác nhau về bảo mật. Đối với nhà phát triển, chức năng an toàn có thể có nghĩa là nó không chứa bất kỳ lỗi nào hoặc gây ra các vấn đề bảo mật bổ sung. Và đối với người dùng, điều đó có thể có nghĩa là nó bao gồm các thanh chắn bổ sung để bảo vệ họ khỏi bị vô tình bắn vào chân.

Hóa ra là trong trường hợp này, các chức năng này thiên về cái sau hơn và ít hơn cái trước. Điều này đặc biệt đáng tiếc, vì khi được lựa chọn giữa hàm chuyển và hàm safeTransfer, tại sao bạn không chọn hàm an toàn? Tất cả đều thể hiện ở cái tên!

Chà, một trong những lý do có thể là do người bạn cũ của chúng ta quay lại hoặc điều gì đó mà tôi đang cố gắng đổi tên: không có cuộc gọi bên ngoài an toàn. Hãy nhớ rằng bất kỳ cuộc gọi bên ngoài nào cũng có thể không an toàn nếu người nhận bị kẻ tấn công kiểm soát, vì kẻ tấn công có thể khiến hợp đồng của bạn chuyển sang trạng thái không xác định. Theo thiết kế, các chức năng "an toàn" này thực hiện các cuộc gọi bên ngoài tới người nhận mã thông báo, thường do người gửi kiểm soát trong quá trình đúc hoặc chuyển. Nói cách khác, đây thực sự là một ví dụ trong sách giáo khoa về cuộc gọi bên ngoài không an toàn.

Tuy nhiên, bạn có thể tự hỏi, hậu quả tồi tệ nhất của việc cho phép hợp đồng người nhận từ chối các giao dịch chuyển tiền mà họ không thể xử lý là gì? Vâng, hãy để tôi trả lời câu hỏi này bằng hai nghiên cứu điển hình.

Ví dụ 1: Hashmasks

Hashmasks là một dự án hình đại diện NFT với nguồn cung hạn chế và người dùng có thể mua tối đa 20 NFT mặt nạ cho mỗi giao dịch (mặc dù chúng đã được bán hết trong nhiều tháng). Sau đây là chức năng mua khẩu trang:

Bạn có thể nghĩ chức năng này trông rất hợp lý. Tuy nhiên, như bạn có thể mong đợi, có điều gì đó nham hiểm ẩn giấu trong lệnh gọi  _safeMint . hãy xem nào.

Dành cho Để bảo mật, chức năng này thực hiện gọi lại người nhận mã thông báo để kiểm tra xem họ có sẵn sàng chấp nhận chuyển khoản hay không. Tuy nhiên, chúng tôi là người nhận mã thông báo, điều đó có nghĩa là chúng tôi vừa nhận được một lệnh gọi lại, tại thời điểm đó, chúng tôi có thể làm bất cứ điều gì mình muốn, bao gồm cả việc gọi lại hàm mintNFT. Nếu thực hiện việc này, chúng tôi sẽ gọi lại hàm sau khi chỉ tạo một mặt nạ, điều đó có nghĩa là chúng tôi có thể yêu cầu truyền 19 mặt nạ khác. Điều này dẫn đến 39 NFT mặt nạ được đúc, mặc dù số lượng tối đa được quy định cho phép đúc chỉ là 20.

Ví dụ 2: Trình bao bọc tên miền ENS

Gần đây, Nick Johnson từ ENS đã liên hệ với tôi, người muốn tôi xem qua công việc họ đang thực hiện trên trình bao bọc miền ENS. Trình bao bọc miền này cho phép người dùng mã hóa miền ENS của họ bằng mã thông báo ERC-1155 mới, cung cấp hỗ trợ cho các quyền chi tiết hơn và API nhất quán hơn.

Tóm lại, để đóng gói bất kỳ tên miền ENS nào (cụ thể hơn là tất cả các tên ENS ngoại trừ 2LD.eth), trước tiên bạn phải phê duyệt máy chủ đóng gói tên miền để truy cập tên miền ENS của bạn. Sau đó, bạn gọi gói (byte, địa chỉ, uint96, địa chỉ), cả hai đều tạo ra mã thông báo ERC-1155 cho bạn và quản lý tên miền ENS cơ bản.

Đây là hàm bọc, khá đơn giản. Đầu tiên, chúng ta gọi _wrap, thực hiện một số logic và trả về tên miền đã băm. Sau đó, chúng tôi đảm bảo rằng người gửi giao dịch thực sự là chủ sở hữu miền ENS trước khi tiếp quản miền. Lưu ý rằng nếu người gửi không sở hữu tên miền ENS cơ bản thì toàn bộ giao dịch sẽ được hoàn nguyên, hoàn tác mọi thay đổi được thực hiện trong _wrap 

Dưới đây Bản thân nó là hàm _wrap, không có gì đặc biệt ở đây.

Thật không may Hơn nữa, chính hàm _mint này có thể mang đến cho các nhà phát triển không nghi ngờ một bất ngờ đáng sợ. Thông số kỹ thuật ERC-1155 nêu rõ rằng khi tạo mã thông báo, người nhận phải được tư vấn xem họ có sẵn sàng chấp nhận mã thông báo hay không. Sau khi tìm hiểu mã thư viện, được sửa đổi một chút so với nền tảng của OpenZeppelin, chúng tôi nhận thấy rằng thực tế đúng như vậy.

Nhưng Điều này có ích gì cho chúng ta? Được rồi, một lần nữa chúng ta lại thấy một lệnh gọi bên ngoài không an toàn mà chúng ta có thể sử dụng để thực hiện một cuộc tấn công vào lại. Cụ thể, hãy lưu ý rằng trong quá trình gọi lại, chúng tôi sở hữu mã thông báo ERC-1155 cho tên ENS nhưng trình bao bọc tên vẫn chưa xác minh rằng chúng tôi sở hữu chính tên ENS cơ bản. Điều này cho phép chúng tôi hoạt động trên các tên miền ENS mà không thực sự sở hữu chúng. Ví dụ: chúng tôi có thể yêu cầu trình bao bọc miền mở khóa miền của chúng tôi, ghi mã thông báo mà chúng tôi vừa tạo và lấy miền ENS cơ bản.

Bây giờ Chúng tôi có tên miền ENS cơ bản và chúng tôi có thể làm bất cứ điều gì mình muốn với tên miền đó, chẳng hạn như đăng ký tên miền phụ mới hoặc thiết lập trình phân giải. Sau khi hoàn tất, chúng ta chỉ cần thoát khỏi cuộc gọi lại. Trình bao bọc miền sẽ tương tác với chủ sở hữu hiện tại của miền ENS cơ bản (tức là chúng tôi) và hoàn tất giao dịch. Cứ như vậy, chúng tôi đã tạm thời sở hữu bất kỳ tên miền ENS nào mà trình bao bọc miền đã được phê duyệt và thực hiện bất kỳ thay đổi nào đối với tên miền đó.

Kết luận

Mã đáng ngạc nhiên có thể phá vỡ mọi thứ theo những cách thảm khốc. Trong cả hai trường hợp trong bài viết này, các nhà phát triển đều giả định một cách hợp lý rằng các lớp chức năng an toàn đều an toàn khi sử dụng, nhưng đã vô tình làm tăng bề mặt tấn công của chúng. Khi các tiêu chuẩn mã thông báo ERC-721 và ERC-1155 trở nên phổ biến và phổ biến hơn, các kiểu tấn công này có thể sẽ trở nên thường xuyên hơn. Các nhà phát triển cần xem xét các rủi ro khi sử dụng các hàm tương tự an toàn và xác định cách các lệnh gọi bên ngoài có thể tương tác với mã họ viết.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia