Tác giả gốc: Peter Zeitz
Bản dịch gốc: Miễn phí và dễ dàng
Lưu ý: Tác giả gốc là một nhà nghiên cứu kinh tế về 0x Nhóm giao thức Peter Zeitz đã phát hiện ra một lỗ hổng nghiêm trọng trong hợp đồng thông minh của giao thức Curve và viết một báo cáo. Theo báo cáo này, mặc dù các giao thức Curve và Swerve đã vượt qua nhiều cuộc kiểm tra hợp đồng nhưng người dùng của họ vẫn phải đối mặt với những lỗ hổng lớn. , họ tin rằng việc kiểm toán viên hợp đồng thông minh phát hiện các lỗ hổng khai thác kiến thức chuyên môn cao có thể không thực tế.
Tính đến thời điểm xuất bản, báo cáo này đã được Curve chính thức công nhận và tác giả cũng đã nhận được phần thưởng về lỗ hổng. Curve hiện đang triển khai nó cho giải pháp nhóm hợp đồng cũ, trong khi nhóm hợp đồng mới không bị ảnh hưởng bởi lỗ hổng này.

Sau đây là nội dung báo cáo lỗ hổng: p>
Vào sáng sớm ngày 19 tháng 9, tôi phát hiện ra một lỗ hổng nhắm vào hợp đồng Curve khi hệ số khuếch đại A của hợp đồng được cập nhật , kẻ tấn công có thể rút một lượng lớn số dư token. Swerve, sử dụng hợp đồng Curve, sau khi cập nhật hệ số A. Do đó, tổn thất tiềm tàng đối với người dùng là rất lớn, chiếm 36,9% số dư hợp đồng. Giả sử một cuộc tấn công được tối ưu hóa, tổn thất sẽ vào khoảng 92 triệu USD. May mắn thay, bản cập nhật Swerve đã được thực hiện mà không gặp sự cố nào. Chiều hôm đó, tôi đã thông báo cho nhóm Curve. Vài giờ sau, họ xác nhận có tồn tại lỗ hổng và chúng tôi bắt đầu cùng nhau tìm ra giải pháp.
Trên thực tế, cuộc tấn công này có thể xảy ra cả khi A điều chỉnh lên và xuống. Tuy nhiên, vì thiệt hại tiềm ẩn từ việc điều chỉnh giảm giá là lớn hơn nên chúng tôi sẽ tập trung vào kiểu tấn công này. Mức độ nghiêm trọng của các cuộc tấn công này tỷ lệ thuận với mức độ thay đổi của A. Hóa ra mức mất tối đa số dư chia sẻ mã thông báo được giới hạn bởi phương trình sau, trong đó A_old là giá trị tham số ban đầu, A_new là giá trị tham số được cập nhật và n là số loại mã thông báo trong hợp đồng.

Tổn thất do khai thác lỗ hổng phụ thuộc vào phần trăm thay đổi của tham số A
Ví dụ: bản cập nhật hợp đồng yCurve diễn ra sớm hơn trong cùng tuần. Hợp đồng có n=4 loại mã thông báo và bản cập nhật thay đổi từ A_old=2000 thành A_new=1000. Sử dụng công thức trong Phương trình 1, kẻ tấn công có thể khai thác lỗ hổng này để rút tới 12,9% số dư hợp đồng yCurve (hoặc khoảng 77 triệu USD).
Cuộc tấn công này chỉ có thể thực hiện được trong quá trình cập nhật theo lịch trình của tham số A. Hợp đồng Curve không dễ bị tấn công trong hoạt động bình thường, do đó, không cần thực hiện hành động khẩn cấp để bảo vệ tiền của người dùng. Tuy nhiên, điều quan trọng là phải vá lỗ hổng này trước khi các thay đổi khác đối với A xảy ra (các điều chỉnh giảm mạnh đối với A đặc biệt nguy hiểm). Nhóm Curve đang cải tiến quy trình cập nhật A để cho phép hợp đồng Curve tiếp tục cập nhật tham số A một cách an toàn.
Để hiểu được tấn công, chúng ta cần hiểu đường cong liên kết mã thông báo. Tôi sẽ giải thích một số khái niệm để người đọc có thể phát triển sự hiểu biết về khái niệm. Tôi có cách tiếp cận hơi khác đối với chủ đề này, tập trung vào mối quan hệ giữa đường cong liên kết mã thông báo và mức trung bình của một tập hợp các biến.
Trong toán học, giá trị trung bình (mean) biểu thị một lượng xu hướng trung tâm trong một nhóm dữ liệu. Do đó, nếu x_1 là số nhỏ nhất trong một tập hợp n số và x_n là số lớn nhất thì giá trị trung bình của tập hợp này sẽ xuất hiện là giá trị trung gian giữa x_1 và x_n. Hai loại trung bình phổ biến nhất là trung bình số học và trung bình hình học.

Trung bình số học

Trung bình hình học
Số trung bình đóng vai trò quan trọng trong đường cong liên kết tiền xu. Hợp đồng AMM cho phép người dùng giao dịch bất kỳ tổ hợp token nào sao cho số dư token hợp đồng AMM trung bình không đổi trước và sau khi giao dịch diễn ra. Trong các thiết kế AMM khác nhau, các loại phương pháp lấy trung bình khác nhau được sử dụng. Đối với Uniswap, nó sử dụng giá trị trung bình hình học không trọng số, đối với Balancer, nó sử dụng giá trị trung bình hình học có trọng số và đối với mStable, nó sử dụng giá trị trung bình số học không trọng số.
Và Curve sử dụng giá trị trung bình có trọng số của giá trị trung bình số học và giá trị trung bình hình học, mà tôi gọi là giá trị trung bình của Đường cong. Trọng số của đường trung bình được xác định bởi tham số khuếch đại A. Khi A tăng dần đến vô cùng, giá trị trung bình của Curve hội tụ về giá trị trung bình số học được mStable sử dụng. Ngược lại, nếu A được đặt thành 0, giá trị trung bình của Curve sẽ giống với giá trị trung bình hình học được Balancer và Uniswap sử dụng. Đối với các giá trị trung gian của A, đường cong liên kết token của Curve sẽ nằm ở giữa hai thái cực này.

Hình 1: Đường cong liên kết token
Hình 1 Bốn đường cong liên kết mã thông báo được hiển thị. Uniswap duy trì hằng số trung bình hình học, tạo ra độ cong rất dốc. mStable là hằng số trung bình số học, là một đường thẳng và Curve nằm ở giữa. Ở giá trị tham số A=1, Curve tương tự như Uniswap và ở A=10, Curve gần với mStable hơn.
p>
Tham khảo Hình 1, chúng ta có thể thấy rằng cả bốn đường cong đều cắt nhau tại một điểm 45 độ tính từ gốc của đồ thị. Chúng ta có thể sử dụng khoảng cách từ điểm giao nhau này đến điểm gốc để đo nhanh giá trị của danh mục mã thông báo hợp đồng AMM. Ví dụ: nếu khoảng cách từ giao lộ này đến điểm gốc tăng 20% thì giả sử không có tổn thất tạm thời thì giá trị nắm giữ hợp đồng AMM cũng sẽ tăng 20%. Điều này áp dụng cho cả bốn loại đường cong chung của chúng tôi. Thuộc tính này đặc biệt hữu ích khi chúng ta xem xét Curves, chúng có một thuộc tính duy nhất: khi A được cập nhật, hình dạng của đường cong khớp của nó sẽ thay đổi. Đối với Curve, chúng ta có thể sử dụng khoảng cách từ điểm gốc để đo giá trị của danh mục hợp đồng trước và sau khi cập nhật tham số. Rõ ràng, đây sẽ là một vấn đề nghiêm trọng nếu khoảng cách này giảm đi đáng kể sau khi cập nhật A.
Giới thiệu lại trong Hình 1, giả sử rằng số dư mã thông báo của hợp đồng Curve nằm chính xác ở giao điểm của đường 45 độ. Điều này xảy ra khi tất cả các token Curve giao dịch ở tỷ lệ giá một-một. Khi cập nhật A từ điểm bắt đầu này, không có nguy cơ mất tiền. Ví dụ: giả sử Curve thay đổi cài đặt tham số từ A_old = 10 thành A_new =1 kể từ thời điểm này. Bản cập nhật này không thay đổi khoảng cách của đường cong chung từ điểm gốc. Do đó, các thay đổi tham số sẽ hoàn toàn vô hại và sẽ không khiến Nhà cung cấp thanh khoản Curve (LP) gặp rủi ro tổn thất tài chính. Theo trực giác, nếu số dư ban đầu không chính xác ở điểm giao nhau mà ở gần điểm giao nhau thì nguy cơ thua lỗ vẫn rất nhỏ.
Bây giờ chúng ta hãy xem ở Hình 2. Sơ đồ minh họa cách kẻ tấn công có thể thao túng các điều kiện ban đầu để đạt được lợi nhuận khổng lồ khi A được cập nhật. Để dễ minh họa, tôi hiển thị sự thay đổi từ A_old = 10 thành A_new = 1 thay vì cập nhật Swerve từ A_old =1000 thành A_new =100. Tuy nhiên, hóa ra mức độ nghiêm trọng của lỗ hổng chỉ phụ thuộc vào tỷ lệ cũ và mới nên con số này mô tả chính xác tình huống của Swerve. Ngoài ra, cuộc tấn công thể hiện trong hình chỉ chiếm được 15% lượng token tồn kho của hợp đồng. Một cuộc tấn công được tối ưu hóa hoàn toàn sẽ giao dịch với số lượng thậm chí còn cực đoan hơn, chiếm tới 36,9% lượng tồn kho mã thông báo.

Hình 2: Thêm thay đổi giữa các giao dịch độc hại
Giả sử rằng số dư hợp đồng Curve ban đầu nằm ở giao điểm của đường 45 độ và giá trị tham số ban đầu là A_old=10. Bây giờ hãy tưởng tượng kẻ tấn công kẹp một bản cập nhật tham số giữa hai giao dịch độc hại. Trong giao dịch độc hại đầu tiên, kẻ tấn công đã bán một lượng lớn token để gây mất cân bằng hàng tồn kho. Tiếp theo, kẻ tấn công sẽ kích hoạt bản cập nhật có giá trị 10 và 1. Điều này thay đổi hình dạng của đường cong như trong hình. Cuối cùng, kẻ tấn công mua lại số token mà hắn đã bán với giá thấp hơn. Hành động này sẽ đưa hợp đồng trở lại trạng thái cân bằng hoàn toàn dọc theo đường 45 độ. Như được hiển thị, cuộc tấn công này sẽ dẫn đến mất 15% kho token AMM.
Có thực sự có thể thực hiện được một cuộc tấn công như vậy không? Thật ngạc nhiên, câu trả lời là có. Hợp đồng Curve yêu cầu các thay đổi đối với A phải được lên lịch trước nhiều ngày và đạt được sự đồng thuận thông qua quy trình quản trị phi tập trung trên chuỗi. Tuy nhiên, sau khi các thay đổi trong A được phê duyệt thông qua quản trị và vượt quá thời hạn kích hoạt, hợp đồng sẽ cho phép bất kỳ người gọi nào kích hoạt cập nhật. Do đó, kẻ tấn công có thể nhanh chóng thuê số lượng lớn stablecoin từ Uniswap, bán chúng cho Curve để gây ra sự mất cân bằng cực độ, kích hoạt cập nhật lên A, sau đó mua stablecoin từ Curve để thu được lợi nhuận khổng lồ. Một cuộc tấn công được tối ưu hóa hoàn toàn sẽ liên quan đến nhiều thứ hơn, vì vậy tôi sẽ không đi sâu vào chi tiết ở đây. Và cuộc tấn công đơn giản mà tôi mô tả ở trên cũng đủ để thu được phần lớn lợi nhuận tiềm năng.
Hiện tại, có hai phiên bản sản xuất của hợp đồng Curve. Đối với các hợp đồng cũ hơn, chưa được vá, trên đây là cách hoạt động của lỗ hổng bảo mật. Với các hợp đồng mới hơn, vẫn có một lỗ hổng tiềm ẩn, mặc dù nó ít nghiêm trọng hơn nhiều. Đầu tiên tôi sẽ mô tả những thay đổi được đề xuất đối với hợp đồng cũ.
Trong Curve cũ Trong hợp đồng, những thay đổi trong A xảy ra theo một bước lớn riêng biệt. Ngoài ra, logic hợp đồng cho phép kẻ tấn công thực hiện các giao dịch với các giá trị A khác nhau trong một giao dịch. Cụ thể, kẻ tấn công có thể sử dụng giao dịch ban đầu của chúng để tạo ra sự mất cân bằng cực độ trong kho, sau đó kích hoạt thay đổi trong A và sau đó thực hiện nhiều giao dịch hơn với giá trị cập nhật của A. Điều này cho phép kẻ tấn công thực hiện toàn bộ cuộc tấn công liên quan đến các giao dịch trị giá hàng trăm triệu đô la mà không gặp rủi ro. Để giải quyết vấn đề này, tôi khuyên bạn nên cập nhật hợp đồng cũ để chỉ những tài khoản multisig đáng tin cậy mới có thể kích hoạt các bản cập nhật cho A.
Ngoài ra, việc kích hoạt A phải yêu cầu kiểm tra số dư mã thông báo để xác nhận rằng số dư mã thông báo không thay đổi đáng kể kể từ thời điểm giao dịch cập nhật thông số được phát sóng. Việc kiểm tra số dư này ngăn chặn các cuộc tấn công của những kẻ khai thác lừa đảo. Cụ thể, kẻ khai thác lừa đảo có thể sắp xếp lại các giao dịch để thực hiện một giao dịch lớn trước khi cập nhật A, sau đó thực hiện một giao dịch lớn khác sau khi A được cập nhật.
Việc kiểm tra số dư sẽ ngăn các thay đổi đối với A được kích hoạt khi hợp đồng ở trạng thái mất cân bằng không mong muốn, đủ để bảo vệ Curve LP khỏi các cuộc tấn công như vậy.
Trong bản mới hơn Trong Curve hợp đồng, sự thay đổi trong A xảy ra dần dần theo một loạt các bước nhỏ rời rạc trước khi bắt đầu mỗi giao dịch. Hiểu biết của tôi là mỗi khối chỉ có thể được điều chỉnh một bước. Ngoài ra, hợp đồng yêu cầu phải thực hiện các bước xác định trước trước khi thực hiện bất kỳ giao dịch nào. Điều này đủ để bảo vệ khỏi những kẻ tấn công thông thường, nhưng không nhất thiết phải chống lại những kẻ khai thác lừa đảo. Cụ thể, một kẻ khai thác lừa đảo có thể đúc hai khối liên tiếp và chèn các giao dịch độc hại vào cả hai khối. Điều này sẽ cho phép người khai thác thực hiện giao dịch ban đầu có giá trị A cao hơn trong khối đầu tiên và giao dịch cuối cùng có giá trị A thấp hơn trong khối thứ hai. Tệ hơn nữa, những kẻ khai thác lừa đảo có cơ hội mở rộng để thực hiện các cuộc tấn công này. Miễn là A vẫn đang trong quá trình cập nhật, kẻ khai thác lừa đảo có thể tiếp tục cố gắng khai thác hai chuỗi khối.
Để bảo vệ những hợp đồng mới hơn này, tôi khuyên bạn nên giảm độ dài bước trong A xuống không quá 0,1% mỗi khối. Tại sao độ dài bước nhỏ lại hữu ích? Điều này liên quan đến một yếu tố mà tôi chưa đề cập đến - hợp đồng Curve tính phí và do khoản phí này, bất kỳ giao dịch nào cũng sẽ khiến đường cong liên kết mã thông báo lệch một chút so với ban đầu. Điều này cũng áp dụng cho các giao dịch lớn của kẻ tấn công, khiến cho cuộc tấn công ít sinh lợi hơn một chút. Nếu thay đổi trong A đủ nhỏ, lợi ích thu được từ một cuộc tấn công được tối ưu hóa hoàn toàn sẽ được bù đắp bằng khoản phí mà kẻ tấn công phải trả cho hợp đồng. Do đó, kẻ tấn công không thể kiếm lợi bằng cách bỏ qua sự thay đổi giữa hai giao dịch.
Liên quan đến cuộc tấn công này, nó đòi hỏi các nhà thiết kế phải hiểu sâu sắc về đường cong liên kết mã thông báo và việc kiểm tra viên hợp đồng thông minh phát hiện ra các lỗ hổng khai thác kiến thức chuyên môn cao có thể là không thực tế. Trên thực tế, hợp đồng Curve đã trải qua nhiều cuộc kiểm tra bảo mật và khi tôi viết bài này, hợp đồng Swerve vừa vượt qua một cuộc kiểm tra khác. Theo tôi, một chương trình kiểm tra lỗ hổng chung có thể được phát hiện thông qua phát hiện bạo lực thay vì phát hiện trên lý thuyết sẽ rất hữu ích. Để phát hiện những lỗ hổng như vậy, tôi khuyên bạn nên kiểm tra đường cong liên kết mã thông báo kết hợp mô phỏng các quy trình giao dịch hai bước tùy ý. Trong các quy trình này, kiểm toán viên sẽ thực hiện một giao dịch ngẫu nhiên đối với hợp đồng, kích hoạt hành động hợp đồng thông minh và sau đó thực hiện một giao dịch ngẫu nhiên khác. Tại đây, hoạt động hợp đồng thông minh sẽ kích hoạt bản cập nhật cho A. Đối với lỗ hổng này, quy trình kiểm tra lông tơ này sẽ tiết lộ các tình huống trong đó hợp đồng bị thiệt hại thảm khốc. Kiểm toán viên sau đó có thể điều tra sâu hơn để hiểu nguyên nhân gốc rễ.
Đối với các nhà thiết kế hợp đồng thông minh, việc hiểu được những hạn chế của hoạt động kiểm tra sẽ rất hữu ích. Khi một hợp đồng cho phép thực hiện một loạt tương tác phức tạp cùng một lúc thì việc kiểm tra fuzz toàn diện sẽ không khả thi. Vấn đề là có rất nhiều cách kết hợp tương tác của người dùng mà chúng tôi không thể khám phá hết mọi khả năng. Do đó, sẽ rất hữu ích khi giới hạn số lượng và loại hành động mà người dùng có thể thực hiện trong một khoảng thời gian ngắn. Ý tưởng ở đây là tránh tạo ra một hợp đồng thông minh phức tạp đến mức không thể kiểm tra nó bằng các biện pháp vũ phu.
Cảm ơn nhóm Curve đã trả cho tôi một khoản tiền thưởng lỗi rất hào phóng cho công việc báo cáo lỗ hổng bảo mật của tôi và một lời đề cập đặc biệt đến người bạn tốt của tôi Greg Hysen tại 0x, It chính anh ấy là người đã đào sâu mã của Curve và giúp tôi hiểu logic hợp đồng thông minh của bản cập nhật A.
Liên kết gốc blockquote>
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