Tôi tin Uniswap v4 sẽ sớm được cung cấp cho mọi người!

Lần này, nhóm Uniswap có những mục tiêu và kế hoạch đầy tham vọng là 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 cặp giao dịch, thiết kế đơn lẻ, kế toán Lightning, Hooks và hỗ trợ mã thông báo ERC1155 tiêu chuẩn. 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 các hook chắc chắn sẽ mang đến các 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 nó, chúng ta cần có hiểu biết cơ bản về cơ chế của Uniswap v4.

Theo thông báo chính thức [1] và sách trắng [2], Hooks, kiến ​​trúc đơn lẻ và tính toán Lightning là ba chức năng quan trọng để triển khai các nhóm thanh khoản tùy chỉnh và đạt được định tuyến hiệu quả trên nhiều nhóm. 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 các lệnh giới hạn trên chuỗi hoặc dàn trải các lệnh 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 tại 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

- trướcSwap/sauSwap

- beforeDonate/afterDonate

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

- trướcSwap/sauSwap

- 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 đã giới thiệu phương thức hoạt động với một số ví dụ (chẳng hạn như TWAMM Hook[3]) và những người tham gia cộng đồng cũng có một số đóng góp. 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 flash đượ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 cơ chế tính toán Lightning và cơ chế khóa.

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

1. Hợp đồng khóa yêu cầu khóa PoolManager.

2. PoolManager thêm địa chỉ của hợp đồng khóa vào hàng đợi lockData và gọi lạ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 tức thời. Mọi sửa đổi sẽ đượ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ế sẽ được thực hiện 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 cơ chế khóa, Tài khoản thuộc sở hữu 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. Hợp đồng này hoạt động như một khóa trung gian và cần yêu cầu khóa trước khi thực hiện bất kỳ hoạt động nào của nhóm.

Có hai kịch bản 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.

Một hợp đồng tủ khóa và Hook nhất định đượ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 đơn vị 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 vừa đóng vai trò 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 mô hình mối đe dọa. 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 mối đ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.

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 mối đ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 Vấn đề bảo mật trong mô hình mối đ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 rằng các nhà phát triển và hook của họ là 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 đề liên quan đến lỗ hổng UUPSUpgradeable của OpenZeppelin.

Do 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ó 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ù 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 móc đầu tiên là giữ 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 tổn thấ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 tôi. 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ê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ừ các 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 dưới đây để biết những phát hiện cụ thể:

Tổng cộng, chúng tôi đã tìm thấy 22 dự án có 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 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 đề có thể xảy ra do các hàm gọi lại trong v4, 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 các 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 có 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 cách trong một số triển khai Hook dễ bị tổn thương:

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 có 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 cách 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 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 kiểu tấn công khác nhau, bao gồm cả những gì chúng ta gọi là tấn công reentrancy. Để 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 quỹ độc hại cho các mã thông báo giả của riêng mình, sau đó gọi hook để thực hiện các hoạt động trong nhóm quỹ. 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 Biện pháp phòng ngừa mối đe dọa mô hình 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 các 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 đó.

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

Trong mô hình mối đe dọa này, 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ý: 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 Móc được quản lý

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 mã thông báo gốc và các mã thông báo khác) sẽ được chuyển hoặc ủy quyền cho bộ định tuyến. Vì PoolManager thực hiện kiểm tra số dư nên không dễ để các hook độc hại 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 Móc độc lập Khi một Móc được sử dụng làm điểm vào, tình hình sẽ phức tạp hơn.

Trong trường hợp này, hook thu được nhiều sức mạnh hơn vì người dùng có thể tương tác trực tiếp với nó. 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 trong trường hợp có các lệnh gọi chung để tự hủy và tạo2.

2.2.3 Biện pháp phòng ngừa mối đe dọa mô hình II

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 trong trường hợp có các lệnh gọi chung để tự hủy và tạo2.

2.2.3 Biện pháp phòng ngừa mối đe dọa mô hình 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ý chi 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 phác thảo ngắn gọn 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!