BTC

$96,000

5.73%

ETH

$3,521.91

3.97%

HTX

$0.{5}2273

5.23%

SOL

$198.17

3.05%

BNB

$710

3.05%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Khám phá các rủi ro bảo mật của cơ chế Hook trong Uniswap V4

Đọc bài viết này mất 28 phút

Uniswap v4 dự kiến sẽ được phát hành sau bản nâng cấp Ethereum Cancun và có kế hoạch giới thiệu nhiều tính năng, bao gồm hỗ trợ số lượng nhóm thanh khoản không giới hạn và phí linh hoạt cho mỗi cặp giao dịch, thiết kế đơn lẻ, kế toán Lightning, Hook và hỗ trợ cho ERC1155 tiêu chuẩn mã thông báo.

Nguồn gốc: BlockSec

Tôi tin rằng Uniswap v4 sẽ tương thích với Uniswap v4 sớm Mọi người đều gặp nhau!

Lần này nhóm Uniswap có 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[1], bao gồm hỗ trợ số lượng nhóm thanh khoản không giới hạn và phí linh hoạt cho mỗi nhóm cặp giao dịch, thiết kế Singleton, kế toán Lightning, Hook và hỗ trợ tiêu chuẩn mã thông báo ERC1155. Tận dụng bộ lưu trữ 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 cải tiến, cơ chế Hook đã thu hút được sự chú ý rộng rãi nhờ tiềm năng mạnh mẽ của nó. Cơ chế Hook hỗ trợ thực thi mã cụ thể tại các điểm cụ thể trong vòng đời của nhóm thanh khoản, giúp nâng cao đáng kể khả năng mở rộng và tính linh hoạt của nhóm. Tuy nhiên, cơ chế móc cũng có thể là con dao hai lưỡi. Mặc dù mạnh mẽ và linh hoạt nhưng việc sử dụng Hook một cách an toàn cũng là một thách thức lớn.

Sự phức tạp của hook chắc chắn sẽ mang đến những hướng tấn công tiềm năng mới. Vì vậy, chúng tôi mong muốn viết một loạt bài để 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 và tin rằng những hiểu biết này sẽ giúp xây dựng một Uniswap v4 Hook an toàn. Mở đầu 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à nêu ra các rủi ro bảo mật của cơ chế Hook.

1 - Cơ chế của Uniswap V4

Trước khi đi sâu vào tìm hiểu, chúng ta cần tìm hiểu hiểu Uniswap Có hiểu biết cơ bản về cơ chế của v4.

Theo thông báo chính thức [1] và sách trắng [2], Hook, kiến trúc singleton và kế toán Lightning là những cách tốt nhất để triển khai nhóm và nhịp thanh khoản tùy chỉnh nhiều nhóm. Ba chức năng quan trọng để đạt được định tuyến hiệu quả. 1.1 HookHook đề cập đến các hợp đồng chạy ở các giai đoạn khác nhau trong vòng đời của nhóm thanh khoản. Nhóm Uniswap hy vọng có thể cho phép mọi người đưa ra quyết định đánh đổi bằng cách giới thiệu Hook. Bằng cách này, có thể hỗ trợ các khoản phí linh hoạt, thêm giới hạn giá trên chuỗi hoặc dàn trải các đơn đặt hàng lớn thông qua một nhà tạo lập thị trường trung bình có trọng số theo thời gian (TWAMM).

Hiện có tám lệnh gọi lại Hook, được chia thành bốn nhóm (mỗi nhóm chứa một cặp lệnh gọi lại):

- beforeInitialize/afterInitialize

- beforeModifyPosition/afterModifyPosition

- beforeSwap/afterSwap

- beforeDonate/afterDonate

Sau đây là quá trình trao đổi Hook được giới thiệu trong sách trắng [2] .

Hình 1: Quá trình trao đổi hook

Nhóm Uniswap Cách thực hiện được giới thiệu kèm theo một số ví dụ (chẳng hạn như TWAMM Hook [3]) và có một số đóng góp từ những người tham gia cộng đồng. Tài liệu chính thức [4] cũng liên kết đến kho lưu trữ Awesome Uniswap v4 Hooks [5], nơi thu thập thêm nhiều ví dụ về Hook.

1.2 Cơ chế khóa và tính toán Singleton, Lightning

Kiến trúc Singleton và kế toán nhanh được thiết kế để 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 đơn lẻ mới, trong đó tất cả các nhóm thanh khoản được giữ trong cùng một hợp đồng thông minh. Thiết kế đơn lẻ này dựa vào PoolManager để lưu trữ và quản lý trạng thái của tất cả các nhóm.

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 chuyển mã thông báo trực tiếp. Phiên bản v4 khác ở chỗ nó giới thiệu tính năng Lightning Accounting và lock cơ chế.

Cơ chế khóa hoạt động như sau:

1. Một hợp đồng tủ khóa nhất định là in Yêu cầu khóa trên PoolManager

2. PoolManager Thêm địa chỉ của hợp đồng khóa vào hàng đợi lockData và gọi lệnh gọi lại lockAcquired của nó.

3. Hợp đồng khóa thực thi logic của nó trong lệnh gọi lại. Trong quá trình thực hiện, sự tương tác của hợp đồng khóa với nhóm có thể dẫn đến gia tăng tiền tệ khác 0. Tuy nhiên, khi kết thúc quá trình thực thi, tất cả các vùng đồng bằng phải bằng 0. Ngoài ra, nếu hàng đợi lockData không trống thì chỉ hợp đồng khóa cuối cùng mới có thể thực hiện các thao tác.

4. PoolManager Kiểm tra trạng thái của hàng đợi lockData và mức tăng tiền tệ. Sau khi xác minh, PoolManager sẽ xóa hợp đồng khóa. Tóm lại, cơ chế khóa ngăn chặn truy cập đồng thời và đảm bảo rằng tất cả các giao dịch có thể bị xóa. Hợp đồng khóa áp dụng cho các khóa theo trình tự, sau đó thực hiện các giao dịch thông qua lệnh gọi lại lockAcquired. Lệnh gọi lại Hook tương ứng sẽ được kích hoạt trước và sau mỗi hoạt động của nhóm. Cuối cùng, PoolManager kiểm tra trạng thái.

Cách tiếp cận này có nghĩa là hoạt động điều chỉnh số dư ròng 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 đều được ghi lại vào số dư nội bộ của nhóm và việc chuyển tiền thực tế xảy ra khi kết thúc hoạt động (tức là khóa). Quá trình này đảm bảo rằng không có token nào tồn đọng, do đó duy trì tính toàn vẹn của tiền.

Do sự tồn tại của cơ chế khóa, tất cả các tài khoản bên ngoài (EOA) không thể tương tác trực tiếp với PoolManager . Thay vào đó, mọi tương tác đều phải xảy ra thông qua hợp đồng. Là một khóa trung gian, hợp đồng này cần yêu cầu khóa trước khi thực hiện bất kỳ hoạt động nhóm nào

Có hai tình huống tương tác hợp đồng chính:

Một hợp đồng khóa nhất định xuất phát từ cơ sở mã chính thức hoặc được người dùng triển khai. Trong trường hợp này, chúng ta có thể coi sự tương tác là đi qua bộ định tuyến.

Hợp đồng tủ khóa và Hook được tích hợp vào cùng một hợp đồng hoặc được kiểm soát bởi một bên thứ ba. Trong trường hợp này, chúng ta có thể coi sự tương tác xảy ra thông qua Hook. Trong trường hợp này, Hook đóng vai trò vừa là hợp đồng khóa vừa chịu trách nhiệm xử lý các lệnh gọi lại.

2 - Mô hình mối đe dọa

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

Mô hình mối đe dọa I: Bản thân Hook là lành tính nhưng có lỗ hổng.

Mô hình đe dọa II: Hook vốn có tính độc hại.

Trong các phần sau, chúng tôi thảo luận về các vấn đề bảo mật tiềm ẩn dựa trên hai mô hình mối đe dọa này.

2.1 Các vấn đề bảo mật trong mô hình mối đe dọa Tô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 rằng các nhà phát triển và Hook của họ vô 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 đề tương tự như lỗ hổng UUPSUpgradeable của OpenZeppelin.

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 dành riêng cho phiên bản v4. Trong Uniswap v4, Hook là các hợp đồng thông minh có khả năng 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ù Hook dự kiến sẽ triển khai các giao diện tiêu chuẩn nhưng chúng cũng cho phép đưa vào logic tùy chỉnh. Do đó, cuộc thảo luận của chúng ta sẽ giới hạn ở logic liên quan đến 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 có thể có, ví dụ: Hook có thể lạm dụng các chức năng Hook tiêu chuẩn này như thế nào.

Cụ thể chúng ta sẽ tập trung vào 2 loại Hook sau:

Loại thứ nhất móc, bảo quản an toàn tiền của 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 tiền, gây mất tài sản.

Loại hook thứ hai lưu trữ dữ liệu trạng thái chính mà người dùng hoặc các giao thức khác dựa 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. Rủi ro tiềm ẩn có thể phát sinh khi người dùng hoặc giao thức khác sử dụng trạng thái không chính xác.

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

Nói chung, chúng tôi đã tìm thấy 22 các dự án liên quan (không bao gồm các dự án không liên quan đến Uniswap v4). Trong số các dự án này, chúng tôi tin rằng 8 (36%) dự án dễ bị tổn thương. Trong số 8 dự án dễ bị tấn công, 6 dự án có vấn đề về kiểm soát quyền truy cập và 2 dự án dễ bị tấn công bởi các cuộc gọi không đáng tin cậy từ bên ngoài.

2.1.1 Các vấn đề về kiểm soát truy cập

Trong phần này của thảo luận , mối quan tâm chính của chúng tôi là các vấn đề có thể do chức năng gọi lại trong v4 gây ra, bao gồm 8 lệnh gọi lại móc và lệnh gọi lại khóa. Tất nhiên, có những tình huống khác cần được xác minh, nhưng những tình huống này khác nhau tùy theo thiết kế và nằm ngoài phạm vi thảo luận của chúng ta.

Các chức năng này chỉ được gọi bởi PoolManager và không thể được gọi bởi các địa chỉ khác (bao gồm EOA và hợp đồng). Ví dụ: trong trường hợp phần thưởng được phân phối theo khóa nhóm, phần thưởng có thể được nhận không chính xác nếu bất kỳ tài khoản nào cũng có thể gọi chức năng tương ứng.

Do đó, điều quan trọng là phải thiết lập các cơ chế kiểm soát truy cập mạnh mẽ cho hook, đặc biệt vì chúng có thể được gọi bởi các bên khác ngoài chính nhóm đó. Bằng cách quản lý chặt chẽ quyền truy cập, nhóm thanh khoản có thể giảm đáng kể nguy cơ tương tác trái phép hoặc độc hại với hook.

2.1.2 Nhập câu hỏi xác minh

Trong Uniswap v4, do cơ chế khóa, người dùng phải có được khóa thông qua hợp đồng trước khi thực hiện bất kỳ hoạt động nhóm quỹ nào. Điều này đảm bảo rằng hợp đồng hiện đang tham gia tương tác là hợp đồng khóa mới nhất. Tuy nhiên, vẫn tồn tại một kịch bản tấn công có thể xảy ra, cụ thể là các cuộc gọi bên ngoài không đáng tin cậy do xác thực đầu vào không đúng trong một số triển khai Hook dễ bị tấn công:

Đầu tiên, hook không xác minh nhóm nhóm người dùng dự định tương tác. Đây có thể là một nhóm độc hại chứa mã thông báo giả và thực thi logic có hại.

Thứ hai, một số chức năng móc khóa cho phép các cuộc gọi bên ngoài tùy ý.

Các cuộc gọi bên ngoài không đáng tin cậy cực kỳ nguy hiểm vì chúng có thể dẫn đến nhiều loại tấn công khác nhau, bao gồm cả cuộc tấn công reentrancy nổi tiếng. Để tấn công các hook dễ bị tổn thương này, kẻ tấn công có thể đăng ký một nhóm độc hại cho các mã thông báo giả của chúng và sau đó gọi hook để thực hiện các hoạt động trên nhóm. Khi tương tác với nhóm, logic mã thông báo độc hại sẽ chiếm quyền điều khiển luồng điều khiển để thực hiện hành vi không mong muốn.

2.1.3 Các biện pháp phòng ngừa chống lại mô hình mối đe dọa I

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

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

Trong mối đe dọa này Trong model, chúng tôi cho rằng nhà phát triển và hook của anh ta là độc hại. Do phạm vi rộng nê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 v4. Do đó, điều quan trọng là liệu hook được cung cấp có thể xử lý các tài sản tiền điện tử được người dùng chuyển hoặc ủy quyền hay không. Vì phương thức truy cập hook xác định các quyền có thể được cấp cho hook nên chúng tôi chia hook thành hai loại:

Móc được quản lý (Mook được quản lý): móc không phải là điểm vào. Người dùng phải tương tác với hook thông qua bộ định tuyến (có thể do Uniswap cung cấp).

Móc độc lập: Móc là điểm vào cho phép người dùng tương tác trực tiếp với chúng.

Hình 2: Ví dụ về Hook độc hại

2.2.1 Giám sát Hook

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 cả mã thông báo gốc và các mã thông báo khác) được chuyển giao hoặc ủy quyền tới bộ định tuyến . Bởi vì PoolManager thực hiện kiểm tra số dư nên không dễ để một kẻ lừa đảo độc hại có thể trực tiếp đánh cắp những tài sản này. Tuy nhiên, vẫn có một bề mặt tấn công tiềm năng. Ví dụ: cơ chế quản lý chi phí của phiên bản v4 có thể bị kẻ tấn công thao túng thông qua hook.

2.2.2 Độc lập Hook Khi Hook được sử dụng làm điểm vào, tình hình phức tạp hơn.

Trong trường hợp này, hook tăng thêm sức mạnh vì người dùng có thể tương tác trực tiếp với hook. Về lý thuyết, hook có thể làm bất cứ điều gì nó muốn với sự tương tác này. Trong phiên bản v4, việc xác minh logic mã là rất quan trọng. Vấn đề chính là liệu logic mã có thể bị thao túng hay không. Nếu một hook có thể nâng cấp được, đ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 được nâng cấp, gây ra rủi ro đáng kể. Những rủi ro này bao gồm:

Tác nhân có thể nâng cấp (có thể bị tấn công trực tiếp);

Với logic tự hủy. Có thể bị tấn công nếu tự hủy và tạo2 được gọi chung.

2.2.3 Các biện pháp phòng ngừa chống lại mô hình mối đe dọa II

Điều quan trọng là phải đánh giá xem 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 tập trung vào 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à liệu chúng có thể nâng cấp được hay không. - 3 -Kết luận Trong bài viết này, trước tiên chúng tôi cung cấp một cái nhìn tổng quan ngắn gọn về các cơ chế cốt lõi liên quan đến vấn đề bảo mật Hook của Uniswap v4. Sau đó, chúng tôi đề xuất hai mô hình mối đe dọa và phác thảo ngắn gọ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 chuyên sâu về các vấn đề bảo mật theo từng mô hình mối đe dọa. giữ nguyên!