Hãy tin hoặc không, Uniswap v4 sẽ sớm đáp ứng mọi người!

Lần này, nhóm Uniswap đã đặt ra các mục tiêu và kế hoạch đầy tham vọng để giới thiệu nhiều tính năng mới, bao gồm số lượng bể thanh khoản không giới hạn và phí động cho mỗi cặp giao dịch, thiết kế singleton, kế toán flash, Hook và hỗ trợ ERC1155 tiêu chuẩn mã thông báo. Sử dụng bộ nhớ tạm thời được giới thiệu bởi EIP-1153, Uniswap v4 dự kiến sẽ được phát hành sau khi nâng cấp Ethereum Cancun. Trong số nhiều đổi mới, cơ chế Hook đã thu hút được sự chú ý rộng rãi do tiềm năng mạnh mẽ của nó. Cơ chế Hook cho phép mã cụ thể được thực thi tại các điểm cụ thể trong vòng đời của nhóm thanh khoản, tăng cường đáng kể khả năng mở rộng và tính linh hoạt của các nhóm. Tuy nhiên, cơ chế Hook cũng có thể là con dao hai lưỡi. Mặc dù nó mạnh mẽ và linh hoạt, nhưng sử dụng Hook một cách an toàn cũng là một thách thức đáng kể. Sự phức tạp của Hook chắc chắn mang đến các vectơ tấn công tiềm năng mới. Do đó, chúng tôi hy vọng sẽ viết một loạt bài viết để giới thiệu một cách có hệ thống các vấn đề bảo mật và rủi ro tiềm ẩn liên quan đến cơ chế Hook, nhằm thúc đẩy sự phát triển bảo mật của cộng đồng. Chúng tôi tin rằng những hiểu biết này sẽ giúp xây dựng Uniswap v4 Hooks an toàn. Là bài viết mở đầu của loạt bài này, bài viết này giới thiệu các khái niệm liên quan đến cơ chế Hook trong Uniswap v4 và phác thảo các rủi ro bảo mật liên quan đến cơ chế Hook.

- 1 - Cơ chế của Uniswap V4

Trước khi đào sâu hơn, chúng ta cần hiểu cơ bản về cơ chế đằng sau Uniswap v4. Theo thông báo chính thức [1] và whitepaper [2], Hooks, kiến trúc đơn lẻ, và flash accounting là ba tính năng quan trọng cho phép tạo các hồ bơi thanh khoản tùy chỉnh và định tuyến hiệu quả qua nhiều hồ bơi.

1.1 Hook

Hooks đề cập đến các hợp đồng chạy tại các giai đoạn khác nhau trong vòng đời của một hồ chứa thanh khoản. Nhóm Uniswap hy vọng sẽ cho phép bất kỳ ai đưa ra quyết định đánh đổi bằng cách giới thiệu Hooks. Điều này giúp hỗ trợ tự nhiên cho các phí động, đơn đặt hàng trên chuỗi, hoặc thị trường tạo lập trung bình trọng số theo thời gian (TWAMMs) để chia nhỏ các đơn đặt hàng lớn có thể được triển khai. Hiện tại, có tám Hooks gọi lại, chia thành bốn cặp (mỗi cặp chứa một gọi lại trước và một gọi lại sau):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• trướcSwap/sauSwap
• beforeDonate/afterDonate

Dưới đây là luồng của việc thay đổi Hook được giới thiệu trong bản sách trắng [2].

Hình 1: Luồng Swap Hook

Nhóm Uniswap đã thể hiện phương pháp với một số ví dụ (ví dụ như TWAMM Hook [3]), và cộng đồng các thành viên cũng đã đóng góp. Tài liệu chính thức [4] cũng liên kết với kho lưu trữ Awesome Uniswap v4 Hooks [5], nơi thu thập thêm ví dụ về Hook.

1.2 Singleton, Flash Accounting, và Cơ chế Khóa

Kiến trúc đơn và kế toán flash nhằm cải thiện hiệu suất bằng cách giảm chi phí và đảm bảo hiệu quả. Nó giới thiệu một hợp đồng duy nhất mới, nơi tất cả các hồ bơi thanh khoản được lưu trữ trong cùng một hợp đồng thông minh. Thiết kế duy nhất này dựa vào một PoolManager để lưu trữ và quản lý trạng thái của tất cả các hồ bơi. Trong các phiên bản trước của giao thức Uniswap, các hoạt động như trao đổi hoặc thêm thanh khoản liên quan đến việc chuyển token trực tiếp. Phiên bản 4 khác biệt ở chỗ nó giới thiệu kế toán flash và cơ chế khóa.

👇🏻 Cơ chế khóa hoạt động như sau: 1. Hợp đồng tủ yêu cầu một khóa từ PoolManager. 2. PoolManager thêm địa chỉ hợp đồng tủ vào hàng đợi lockData và gọi lockAcquired callback của nó. 3. Hợp đồng tủ thực thi logic của mình trong callback. Tương tác với pool trong quá trình thực thi có thể dẫn đến việc tăng tiền tệ không bằng không. Tuy nhiên, đến cuối quá trình thực thi, tất cả các tăng này phải net về không. Ngoài ra, nếu hàng đợi lockData không trống, chỉ hợp đồng tủ cuối cùng mới có thể thực thi các hoạt động. 4. PoolManager kiểm tra trạng thái của hàng đợi lockData và tăng tiền tệ. Sau khi xác minh, PoolManager loại bỏ hợp đồng tủ.

Tóm lại, cơ chế khóa ngăn chặn việc truy cập đồng thời và đảm bảo tất cả giao dịch có thể được giải quyết. Hợp đồng Locker yêu cầu khóa theo chuỗi, sau đó thực hiện giao dịch thông qua cuộc gọi lockAcquired. Các cuộc gọi Hook tương ứng được kích hoạt trước và sau mỗi hoạt động của hồ bơi. Cuối cùng, PoolManager kiểm tra trạng thái. Điều này có nghĩa là các hoạt động điều chỉnh cân đối nội bộ (tức là delta) thay vì thực hiện chuyển khoản ngay lập tức. Mọi sửa đổi được ghi lại trong cân đối nội bộ của hồ bơi, với việc chuyển khoản thực sự xảy ra khi hoạt động (tức là khóa) kết thúc. Quy trình này đảm bảo không có token nào chưa thanh toán, duy trì tính toàn vẹn của quỹ. Do cơ chế khóa, các tài khoản sở hữu bên ngoài (EOAs) không thể tương tác trực tiếp với PoolManager. Thay vào đó, mọi tương tác phải thông qua một hợp đồng. Hợp đồng này hoạt động như một người trung gian locker, yêu cầu một khóa trước khi tiến hành bất kỳ hoạt động của hồ bơi.

👇🏻 Có hai kịch bản tương tác hợp đồng chính:

• Một hợp đồng tủ đựng đến từ cơ sở mã nguồn chính thức, hoặc được triển khai bởi một người dùng. Trong trường hợp này, chúng ta có thể xem xét tương tác như đang thông qua một bộ định tuyến.
• Một hợp đồng khóa và Hook được tích hợp vào cùng một hợp đồng, hoặc được điều khiển bởi một bên thứ ba. Trong trường hợp này, chúng ta có thể xem xét việc tương tác như đang thông qua một Hook. Ở đây, Hook đóng vai trò của cả hợp đồng khóa và xử lý các cuộc gọi lại.

- 2 -Mô hình Đe dọa

Trước khi thảo luận về các vấn đề liên quan đến an ninh, chúng ta cần xác định mô hình đe dọa. Chúng tôi chủ yếu xem xét hai trường hợp sau:

• Mô hình Đe dọa I: Hook chính nó là vô hại nhưng chứa các lỗ hổng.
• Mô hình Đe Dọa II: Chính cái Hook đó độc hại.

Trong các phần tiếp theo, chúng tôi sẽ thảo luận về các vấn đề an ninh tiềm năng theo hai mô hình đe dọa này.

2.1 Vấn đề Bảo mật trong Mô hình Đe dọa I

Mô hình mối đe dọa I tập trung vào các lỗ hổng liên quan đến chính Hook. Mô hình mối đe dọa này giả định nhà phát triển và Hook của họ không độc hại. Tuy nhiên, các lỗ hổng đã biết hiện có trong hợp đồng thông minh cũng có thể xuất hiện trong Hooks. Ví dụ: nếu Hook được triển khai dưới dạng hợp đồng có thể nâng cấp, nó có thể gặp phải các vấn đề liên quan đến lỗ hổng như OpenZeppelin UUPSUpgradeable. Với các yếu tố trên, chúng tôi chọn tập trung vào các lỗ hổng tiềm ẩn duy nhất cho phiên bản 4. Trong Uniswap v4, Hooks là các hợp đồng thông minh có thể thực thi logic tùy chỉnh trước hoặc sau các hoạt động của nhóm lõi (bao gồm khởi tạo, sửa đổi vị trí, hoán đổi và thu thập). Mặc dù Hooks dự kiến sẽ triển khai một giao diện tiêu chuẩn, nhưng chúng cũng cho phép logic tùy chỉnh. Do đó, cuộc thảo luận của chúng ta sẽ bị giới hạn ở logic liên quan đến các giao diện Hook tiêu chuẩn. Sau đó, chúng tôi sẽ cố gắng xác định các nguồn lỗ hổng tiềm ẩn, ví dụ: cách Hooks có thể lạm dụng các chức năng Hook tiêu chuẩn này.

👇🏻 Cụ thể, chúng tôi sẽ tập trung vào hai loại Hooks sau đây:

• Loại hook đầu tiên giữ quỹ người dùng. Trong trường hợp này, kẻ tấn công có thể tấn công hook này để chuyển quỹ, gây mất tài sản.
• Loại thứ hai của hook lưu trữ dữ liệu trạng thái quan trọng mà người dùng hoặc các giao thức khác phụ thuộc vào. Trong trường hợp này, kẻ tấn công có thể cố gắng thay đổi trạng thái quan trọng. Khi người dùng hoặc các giao thức khác sử dụng trạng thái không đúng, có thể có nguy cơ tiềm ẩn.

Lưu ý rằng các hooks bên ngoài hai phạm vi này không được thảo luận ở đây. Vì không có trường hợp sử dụng Hook thực tế nào vào thời điểm viết bài này, chúng tôi sẽ lấy một số thông tin từ kho Awesome Uniswap v4 Hooks. Sau khi nghiên cứu sâu về kho Awesome Uniswap v4 Hooks (commit hash 3a0a444922f26605ec27a41929f3ced924af6075), chúng tôi xác định một số lỗ hổng nghiêm trọng. Những lỗ hổng này chủ yếu xuất phát từ sự tương tác mạo hiểm giữa hook, PoolManager và bên thứ ba bên ngoài, và có thể chia thành hai loại: vấn đề kiểm soát truy cập và vấn đề xác thực đầu vào. Các kết luận cụ thể được hiển thị trong bảng dưới đây:

Tóm lại, chúng tôi đã xác định 22 dự án liên quan (trừ những dự án không liên quan đến Uniswap v4). Trong số những dự án này, chúng tôi tin rằng có 8 (36%) dự án có lỗ hổng. Trong số 8 dự án có lỗ hổng, 6 dự án gặp vấn đề về kiểm soát truy cập và 2 dự án có lỗ hổng với cuộc gọi bên ngoài không đáng tin cậy.

2.1.1 Vấn đề Kiểm soát Truy cập

Trong phần thảo luận này, chúng tôi chủ yếu tập trung vào các vấn đề mà các hàm callback trong v4 có thể gây ra, bao gồm 8 hàm callback và hàm callback lock. Tất nhiên có các trường hợp khác cần xác minh nhưng chúng thay đổi theo thiết kế và hiện đang nằm ngoài phạm vi. Những hàm này chỉ nên được gọi bởi PoolManager, không phải địa chỉ khác (bao gồm cả EOAs và hợp đồng). Ví dụ, trong trường hợp phần thưởng được phân phối từ các khóa của pool, phần thưởng có thể bị yêu cầu một cách không chính xác nếu các hàm tương ứng có thể được gọi bởi các tài khoản tùy ý. Do đó, việc thiết lập các cơ chế kiểm soát truy cập mạnh mẽ là rất quan trọng cho các hook vì chúng có thể được gọi bởi các bên khác ngoài các pool chính mình. Bằng cách nghiêm ngặt quản lý quyền truy cập, các liquidity pool có thể giảm đáng kể các rủi ro liên quan đến việc tương tác không được ủy quyền hoặc độc hại với các hook.

2.1.2 Vấn đề Xác thực Đầu vào

Trong Uniswap v4, do cơ chế khóa, người dùng phải có được một khóa thông qua một hợp đồng trước khi thực hiện bất kỳ thao tác nào trên pool. Điều này đảm bảo rằng hợp đồng đang tương tác hiện tại là hợp đồng locker mới nhất. Tuy nhiên, vẫn tồn tại một kịch bản tấn công tiềm ẩn của cuộc gọi bên ngoài không đáng tin cậy do việc xác nhận đầu vào không đúng trong một số cài đặt Hook có lỗ hổng:

• Đầu tiên, hook không xác minh pool mà người dùng dự định tương tác với. Điều này có thể là một pool độc hại với token giả thực hiện logic gây hại.
• Thứ hai, một số chức năng hook chính cho phép cuộc gọi bên ngoài tùy ý.

Cuộc gọi bên ngoài không đáng tin cậy rất nguy hiểm vì chúng có thể dẫn đến các loại tấn công khác nhau bao gồm cả các cuộc tấn công tái nhập biết đến rõ. Để tấn công các hook dễ bị tấn công này, kẻ tấn công có thể đăng ký một pool độc hại với các token giả mạo cho riêng mình, sau đó kích hoạt hook để thực thi các hoạt động trên pool. Khi tương tác với pool, logic token độc hại chiếm quyền điều khiển cho hành vi không đúng đắn.

2.1.3 Biện pháp phòng ngừa cho Mô hình Mối đe doạ I

Để tránh những vấn đề bảo mật liên quan đến khóa, việc thực hiện kiểm soát truy cập cần thiết đúng cách trên các chức năng bên ngoài/công cộng nhạy cảm và xác minh thông tin đầu vào để xác minh tương tác là rất quan trọng. Ngoài ra, các bộ bảo vệ tái nhập có thể giúp đảm bảo rằng các hook không bị tái nhập trong quá trình luồng logic tiêu chuẩn. Bằng cách triển khai các biện pháp bảo mật thích hợp, các hồ bơi có thể giảm thiểu các rủi ro liên quan đến những mối đe dọa như vậy.

2.2 Vấn đề Bảo mật trong Mô hình Đe dọa II

Trong mô hình đe dọa này, chúng tôi giả định rằng nhà phát triển và hook của họ đều độc ác. Với phạm vi rộng lớn, chúng tôi chỉ tập trung vào các vấn đề bảo mật liên quan đến phiên bản 4. Chìa khóa nằm ở chỗ xem các hook được cung cấp có thể xử lý việc chuyển khoản hoặc ủy quyền của tiền điện tử hay không. Khi phương pháp truy cập hook xác định quyền mà có thể được cấp cho hook, chúng tôi phân loại hook thành hai loại dựa trên điều này:

• Managed Hooks: Hook không phải là một điểm nhập. Người dùng phải tương tác với hook qua một bộ định tuyến (có thể do Uniswap cung cấp).
• Hooks độc lập: Hook là một điểm nhập, cho phép người dùng tương tác trực tiếp với nó.

Hình 2: Ví dụ về mắc kẹt độc hại

2.2.1 Quản lý Hooks

Trong trường hợp này, tài sản tiền điện tử của người dùng (bao gồm token bản địa và các token khác) được chuyển hoặc được phê duyệt đến bộ định tuyến. Vì PoolManager thực hiện kiểm tra số dư, các kết nối độc hại không dễ dàng trực tiếp ăn cắp những tài sản này. Tuy nhiên, vẫn tồn tại các bề mặt tấn công tiềm năng. Ví dụ, cơ chế quản lý phí trong phiên bản 4 có thể bị thao túng bởi một kẻ tấn công thông qua các kết nối độc hại.

2.2.2 Standalone Hooks

Khi các hook được sử dụng như điểm vào, tình hình trở nên phức tạp hơn. Ở đây, vì người dùng có thể tương tác trực tiếp với hook, hook được cấp quyền nhiều hơn. Trong lý thuyết, hook có thể thực thi bất kỳ hoạt động mong muốn nào thông qua các tương tác đó. Trong phiên bản 4, xác minh logic mã cực kỳ quan trọng. Vấn đề chính là liệu logic mã có thể bị thao túng hay không. Nếu hook có thể nâng cấp, điều này có nghĩa là một hook có vẻ an toàn có thể trở nên độc hại sau khi nâng cấp, gây ra những rủi ro đáng kể. Những rủi ro này bao gồm:

• Các proxy có thể nâng cấp (có thể bị tấn công trực tiếp)
• Logic với tự phá hủy. Có thể bị tấn công kèm theo việc gọi selfdestruct và create2.

2.2.3 Biện pháp ngăn chặn cho Mô hình Đe dọa II

Một điểm quan trọng là đánh giá xem các hook có độc hại hay không. Cụ thể, đối với các hook được quản lý, chúng ta nên chú ý đến hành vi quản lý phí; trong khi đối với các hook độc lập, trọng tâm chính là xem chúng có thể nâng cấp được hay không.

- 3 - Kết luận

Trong bài viết này, chúng tôi trước tiên đã đề cập ngắn gọn đến các cơ chế cốt lõi liên quan đến vấn đề bảo mật Uniswap v4 Hook. Sau đó, chúng tôi đề xuất hai mô hình đe dọa và đề cập ngắn gọn đến các rủi ro bảo mật liên quan. Trong các bài viết tiếp theo, chúng tôi sẽ tiến hành phân tích sâu hơn về các vấn đề bảo mật dưới mỗi mô hình đe dọa. Hãy đồng hành!

Tham khảo

[1] Tầm nhìn của chúng tôi về Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] Bản nháp báo cáo kỹ thuật Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Uniswap v4 TWAMM Hook
https://blog.uniswap.org/v4-twamm-hook

[4] Ví dụ Hook
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Hooks Tuyệt vời của Uniswap v4
https://github.com/fewwwww/awesome-uniswap-hooks

[6] UUPSUpgradeable Vulnerability Bài học sau sự cố
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

Về BlockSec BlockSec là một công ty bảo mật blockchain hàng đầu toàn cầu được thành lập vào năm 2021 bởi những chuyên gia nổi tiếng trong ngành công nghiệp bảo mật. Công ty cam kết nâng cao tính bảo mật và khả năng sử dụng cho thế giới Web3 để thúc đẩy sự thông dụng rộng rãi của Web3. Để đạt được điều này, BlockSec cung cấp dịch vụ kiểm định bảo mật hợp đồng thông minh và chuỗi EVM, một hệ thống phát triển, kiểm thử và ngăn chặn hacker gọi là Phalcon cho chủ sở hữu dự án, một nền tảng theo dõi quỹ và điều tra gọi là MetaSleuth, cũng như các plugin hiệu suất cho người xây dựng web3 gọi là MetaDock. Hiện tại, công ty đã phục vụ hơn 300 khách hàng, bao gồm các dự án nổi tiếng như MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, và đã nhận được hai vòng đầu tư với tổng số tiền hơn chục triệu đô la từ các tổ chức đầu tư như Oasis Capital, IDG Capital, và Distributed Capital. Trang chủ:www.blocksec.com

Twitter：https://twitter.com/KhốiSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

免責聲明：

1. Bài viết này được tái bản từ [ KhốiSec]. Tất cả bản quyền thuộc về tác giả gốc [KhốiSec]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Họcđội, và họ sẽ xử lý ngay lập tức.
2. Từ chối trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.