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

Nhóm bảo mật Cobo: Rủi ro tiềm ẩn và cơ hội chênh lệch giá trong hard fork ETH

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

Sau khi hoàn thành hard fork, đã có ít nhất hai cuộc tấn công sử dụng cơ chế phát lại trên mạng chính ETHW.

Tiêu đề gốc: " Nhóm bảo mật Cobo - Rủi ro tiềm ẩn và cơ hội chênh lệch giá trong hard fork ETH 》

Nguồn gốc: Cobo toàn cầu

Bài viết này được đóng góp bởi nhóm bảo mật blockchain Cobo. Các thành viên trong nhóm đến từ các nhà cung cấp bảo mật blockchain nổi tiếng và có kinh nghiệm kiểm toán hợp đồng thông minh phong phú. Họ đã làm việc trong nhiều lỗ hổng có mức rủi ro cao được phát hiện trong một dự án DeFi. Nhóm hiện tập trung vào bảo mật hợp đồng thông minh, bảo mật DeFi và các hướng khác, đồng thời nghiên cứu và chia sẻ công nghệ bảo mật blockchain tiên tiến.

Chúng tôi cũng hy vọng rằng những người học tập suốt đời với tinh thần nghiên cứu và phương pháp khoa học trong lĩnh vực tiền kỹ thuật số mã hóa có thể tham gia cùng chúng tôi và xuất khẩu những hiểu biết cũng như ý tưởng cho thế giới. ngành công nghiệp. Ý tưởng nghiên cứu!

Bài viết này là 16 bài viết

của Cobo Global

Lời nói đầu

Với việc nâng cấp ETH lên hệ thống đồng thuận PoS , cơ chế PoW ban đầu của chuỗi ETH đã được củng cố thành công với sự hỗ trợ của một số cộng đồng Fork (sau đây gọi tắt là ETHW). Tuy nhiên, do một số giao thức trên chuỗi không được chuẩn bị cho các hard fork có thể xảy ra ngay từ đầu thiết kế nên các giao thức tương ứng có những rủi ro bảo mật nhất định trong chuỗi phân nhánh ETHW. Rủi ro bảo mật nghiêm trọng nhất là các cuộc tấn công lặp lại.

Sau khi hoàn thành hard fork, đã có ít nhất hai cuộc tấn công sử dụng cơ chế phát lại trên mạng chính ETHW, đó là cuộc tấn công phát lại OmniBridge và phát lại Polygon Bridge tấn công. Bài viết này sẽ sử dụng hai sự cố này làm trường hợp để phân tích tác động của các cuộc tấn công lặp lại đối với các chuỗi phân nhánh và cách giao thức ngăn chặn các cuộc tấn công như vậy.

Các loại phát lại

Trước hết, trước khi bắt đầu phân tích, chúng ta cần Hãy có hiểu biết sơ bộ về các loại tấn công phát lại. Nói chung, chúng tôi chia các cuộc tấn công phát lại thành hai loại, đó là phát lại giao dịch và phát lại tin nhắn chữ ký. Tiếp theo, hãy nói về sự khác biệt giữa hai loại cơ chế phát lại này

Phát lại giao dịch

Phát lại giao dịch đề cập đến hoạt động di chuyển nguyên vẹn các giao dịch trong chuỗi gốc sang chuỗi mục tiêu, là phát lại ở cấp độ giao dịch, sau khi phát lại, giao dịch có thể được thực hiện bình thường và quá trình xác minh giao dịch được hoàn tất. Trường hợp nổi tiếng nhất là cuộc tấn công của Wintermute vào Optimism, trực tiếp dẫn đến việc mất hơn 20 triệu OP Token. Tuy nhiên, sau khi triển khai EIP 155, do chữ ký của giao dịch chứa chainId (một mã định danh được sử dụng để phân biệt chuỗi đó với các chuỗi phân nhánh khác), bản thân giao dịch không thể hoàn thành khi chainId của chuỗi mục tiêu được phát lại khác. được phát lại.

Phát lại tin nhắn đã ký

Tính năng phát lại tin nhắn đã ký khác với việc phát lại giao dịch ở chỗ nó sử dụng khóa riêng Phát lại tin nhắn đã ký tin nhắn (ví dụ Cobo là tốt nhất). Khi phát lại tin nhắn đã ký, kẻ tấn công không cần phát lại toàn bộ giao dịch mà chỉ cần phát lại tin nhắn đã ký. Trong chữ ký tin nhắn, lấy Cobo là ví dụ tốt nhất. Vì tin nhắn không chứa bất kỳ tham số đặc biệt nào liên quan đến chuỗi nên về mặt lý thuyết, tin nhắn có thể hợp lệ trong bất kỳ chuỗi phân nhánh nào sau khi được ký. Chữ ký có thể được chuyển đi. Để tránh phát lại tin nhắn trên fork, bạn có thể thêm chainId vào nội dung tin nhắn, chẳng hạn như Cobo là tốt nhất + chainId(). Sau khi mang một mã định danh chuỗi cụ thể, nội dung tin nhắn trên các chuỗi phân nhánh khác nhau sẽ khác nhau và chữ ký tin nhắn cũng khác nhau nên không thể trực tiếp phát lại và sử dụng lại.

Nguyên tắc tấn công của OmniBridge và Polygon Bridge

Hãy phân tích nguyên tắc tấn công của OmniBridge và Polygon Bridge Nguyên tắc tấn công cầu đa giác. Trước hết, hãy rút ra kết luận rằng bản thân hai cuộc tấn công này không phải là cuộc tấn công phát lại giao dịch. Lý do là ETHW sử dụng chainId khác với mạng chính ETH nên không thể xác minh các giao dịch phát lại trực tiếp. Sau đó, lựa chọn duy nhất còn lại là phát lại tin nhắn, vì vậy hãy phân tích từng người một cách chúng bị tấn công bởi tính năng phát lại tin nhắn trên chuỗi phân nhánh ETHW.

OmniBridge

OmniBridge được sử dụng để chuyển tài sản giữa xDAI và mạng chính ETH Cây cầu được sử dụng chủ yếu dựa vào trình xác thực được chỉ định của cầu nối để gửi thông báo chuỗi chéo nhằm hoàn tất việc chuyển tài sản liên kết chéo. Trong OmniBridge, logic của thông báo xác minh do người xác thực gửi như sau

Trong chức năng này, trước tiên nó sẽ xác định xem chữ ký đã gửi có được ký bởi người xác thực được chỉ định hay không dựa trên việc kiểm tra chữ ký ở dòng #L2 và sau đó Dòng #L11 giải mã thông điệp dữ liệu. Đánh giá từ nội dung được giải mã, không khó để nhận thấy trường trả về có chứa trường chainId, điều này có nghĩa là tin nhắn đã ký không thể được phát lại? Hãy tiếp tục phân tích.

Bằng cách truy tìm hàm _executeMessage, chúng tôi nhận thấy rằng hàm này đã kiểm tra tính hợp lệ của chaindId trong dòng #L11

Bằng cách tiếp tục phân tích logic hàm tiếp theo, không khó để thấy rằng việc kiểm tra chainId thực hiện không thực sự sử dụng opcode chainId gốc evm để lấy chainId của chính chuỗi đó mà trực tiếp sử dụng giá trị được lưu trong biến uintStorage. Giá trị này rõ ràng là do quản trị viên đặt nên có thể coi rằng bản thân thông báo không mang chuỗi nhận dạng nên về lý thuyết có thể phát lại các tin nhắn đã ký.

Vì trong quá trình hard fork, tất cả các trạng thái trước fork sẽ được giữ nguyên trên cả hai chuỗi nên nhóm xDAI sẽ không thực hiện thêm hoạt động nào trong theo dõi trong trường hợp. Sau fork, trạng thái của hợp đồng Omni Bridge trên mạng chính ETHW và ETH sẽ không thay đổi, điều đó có nghĩa là người xác thực hợp đồng cũng sẽ không thay đổi. Dựa trên tình huống này, chúng tôi có thể suy ra rằng chữ ký của người xác thực trên mạng chính cũng có thể được xác minh trên ETHW. Sau đó, do bản thân thông báo chữ ký không chứa chainId nên kẻ tấn công có thể sử dụng tính năng phát lại chữ ký để trích xuất nội dung của cùng một hợp đồng trên ETHW.

Cầu đa giác

Giống như Omni Bridge, Polygon Bridge được sử dụng giữa Polygon và ETH Cây cầu để chuyển tài sản trên mạng chính. Không giống như Omni Bridge, Polygon Bridge dựa vào bằng chứng khối để rút tiền và logic như sau:

Qua chức năng logic, không khó nhận thấy hợp đồng xác định tính hợp pháp của tin nhắn thông qua hai bước kiểm tra, đó là kiểm tra giao dịchRoot và BlockNumber để đảm bảo rằng giao dịch thực sự xảy ra trong chuỗi con (Chuỗi Ploygon), kiểm tra đầu tiên thực sự có thể được bỏ qua, bởi vì bất kỳ ai cũng có thể xây dựng giao dịchRoot của riêng mình thông qua dữ liệu giao dịch, nhưng kiểm tra thứ hai không thể bỏ qua, vì có thể tìm thấy nó bằng cách xem logic _checkBlockMembershipInCheckpoint:

headerRoot tương ứng được trích xuất từ hợp đồng _checkpointManager. Theo logic này, chúng tôi kiểm tra_ Nơi checkpointManager đặt ;headerRoot

Không phải khó phát hiện rằng trong dòng mã #L2, dữ liệu chữ ký chỉ kiểm tra borChianId chứ không kiểm tra chainId của chính chuỗi. Vì tin nhắn được ký bởi người đề xuất được chỉ định trong hợp đồng nên về mặt lý thuyết, kẻ tấn công cũng có thể Bạn có thể phát lại chữ ký tin nhắn của người đề xuất trên chuỗi phân nhánh, gửi headerRoot hợp pháp, sau đó gọi hàm thoát trong chuỗi ETHW thông qua Polygon Bridge và gửi bằng chứng giao dịch tương ứng. Sau đó, bạn có thể rút tiền thành công và vượt qua kiểm tra headerRoot.

Lấy địa chỉ 0x7dbf18f679fa07d943613193e347ca72ef4642b9 làm ví dụ. Địa chỉ này đã hoàn thành thành công hoạt động chênh lệch giá của chuỗi ETHW thông qua các bước sau

Đầu tiên, hãy dựa vào khả năng tiền tệ để rút tiền trên nền tảng giao dịch mainnet.

Gửi tiền vào chuỗi Ploygon thông qua chức năng DepositFor của Polygon Bridge;

ETH master Gọi hàm thoát của Polygon Bridge để rút tiền;

Sao chép và trích xuất headerRoot do người đề xuất mạng chính ETH gửi;

Phát lại tin nhắn chữ ký của người đề xuất được trích xuất ở bước trước trong ETHW;

Gọi exit trên Polygon Bridge trong ETHW để rút tiền

Tại sao chuyện này lại xảy ra?

Từ hai ví dụ được phân tích ở trên, không khó để nhận ra rằng hai giao thức này gặp phải các cuộc tấn công lặp lại vào ETHW vì bản thân các giao thức này đã không làm tốt nhiệm vụ của mình. ngăn chặn việc lặp lại, bảo vệ, khiến các tài sản tương ứng với giao thức bị rỗng trên chuỗi phân nhánh. Nhưng vì hai cây cầu này về cơ bản không hỗ trợ chuỗi phân nhánh ETHW nên người dùng không chịu bất kỳ tổn thất nào. Nhưng điều chúng ta cần xem xét là tại sao hai cây cầu này không bao gồm các biện pháp bảo vệ chống lặp lại khi bắt đầu thiết kế? Trên thực tế, lý do rất đơn giản, vì dù là OmniBridge hay Polygon Bridge, các kịch bản ứng dụng mà họ thiết kế đều rất đơn lẻ, chỉ dùng để chuyển tài sản đến các chuỗi tương ứng được chỉ định, không có kế hoạch triển khai đa chuỗi, do đó không có cơ chế bảo vệ chống phát lại. Nó không có tác động bảo mật nào lên chính giao thức.

Nhìn vào người dùng trên ETHW, vì bản thân những cầu nối này không hỗ trợ các kịch bản đa chuỗi, nên nếu người dùng hoạt động trên chuỗi phân nhánh ETHW, họ sẽ phải hứng chịu tin tức trên mạng chính ETH. Phát lại các cuộc tấn công.

Lấy UniswapV2 làm ví dụ, hiện tại, trong hợp đồng pool của UnswapV2 có một hàm cấp phép chứa biến PERMIT_TYPEHASH, hàm này chứa biến DOMAIN_SEPARATOR.

Biến này được sử dụng lần đầu tiên trong EIP712 Được xác định trong, biến này chứa chainId, bao gồm khả năng ngăn chặn phát lại trong các kịch bản nhiều chuỗi khi bắt đầu thiết kế. Tuy nhiên, theo logic của hợp đồng nhóm uniswapV2, nó như sau:

DOMAIN_SEPARATOR đã được xác định trong hàm tạo, điều đó có nghĩa là sau hard fork, ngay cả khi chainId của chuỗi đã thay đổi, hợp đồng nhóm không thể lấy chianId mới để cập nhật DOMAIN_SEPARATOR. Nếu người dùng thực hiện ủy quyền có liên quan trên ETHW trong tương lai, thì ủy quyền chữ ký cấp phép trên ETHW có thể được phát lại trên mạng chính ETH. Ngoài Uniswap, còn có nhiều giao thức tương tự, chẳng hạn như hợp đồng Yearn Vault theo một phiên bản cụ thể, cũng sử dụng DOMAIN_SEPARATOR cố định. Người dùng cũng cần đề phòng rủi ro lặp lại các giao thức như vậy khi tương tác trên ETHW.

Các biện pháp phòng ngừa khi bắt đầu thiết kế giao thức

Dành cho nhà phát triển, Khi tùy chỉnh cơ chế chữ ký thông điệp cho chính giao thức, nên xem xét các kịch bản đa chuỗi tiếp theo có thể xảy ra. Nếu có khả năng triển khai đa chuỗi trong lộ trình, thì chainId phải được thêm dưới dạng một biến cho thông báo đã ký. Đồng thời , khi xác minh chữ ký, Vì hard fork sẽ không thay đổi bất kỳ trạng thái nào trước fork, nên chainId được sử dụng để xác minh các tin nhắn đã ký không được đặt làm biến hợp đồng mà phải được lấy lại trước mỗi lần xác minh và sau đó được xác minh để đảm bảo tính bảo mật .

Tác động

Tác động đến người dùng

Nói chung, khi giao thức không hỗ trợ chuỗi phân nhánh, bạn nên cố gắng không thực hiện bất kỳ thao tác nào trên chuỗi phân nhánh để ngăn các thông báo chữ ký tương ứng được phát lại trên mạng chính và khiến người dùng mất tài sản trên mạng chính mạng

Tác động đến nền tảng giao dịch và người giám sát

Vì bản thân nhiều nền tảng giao dịch cũng hỗ trợ ETHW Mã thông báo , vì vậy những thứ này được trích xuất do cuộc tấn công Mã thông báo Có thể nạp tiền vào nền tảng giao dịch để bán, nhưng cần lưu ý rằng các cuộc tấn công như vậy không phải là phát hành bổ sung độc hại do vấn đề với chính sự đồng thuận của chuỗi, vì vậy đối với nền tảng giao dịch, các cuộc tấn công như vậy không yêu cầu các biện pháp phòng ngừa bổ sung

Tóm tắt

Với sự phát triển của các kịch bản đa chuỗi, các cuộc tấn công lặp lại đã dần phát triển từ cấp độ lý thuyết Đối với các phương thức tấn công chính thống, các nhà phát triển nên xem xét cẩn thận thiết kế giao thức. Khi thiết kế cơ chế chữ ký tin nhắn, hãy thêm các yếu tố như chainId làm nội dung chữ ký càng nhiều càng tốt và tuân theo các phương pháp hay nhất có liên quan để ngăn chặn việc mất tài sản của người dùng.

Cobo là công ty giám sát tiền điện tử lớn nhất ở khu vực Châu Á - Thái Bình Dương. Kể từ khi thành lập, nó đã cung cấp các dịch vụ tuyệt vời cho hơn 500 tổ chức hàng đầu trong ngành và các tổ chức cấp cao. -các cá nhân có giá trị ròng, đảm bảo Trên cơ sở lưu trữ an toàn các tài sản được mã hóa, nó cũng nhận ra mức tăng ổn định của tài sản được mã hóa và được người dùng trên toàn thế giới tin tưởng sâu sắc. Cobo tập trung vào việc xây dựng cơ sở hạ tầng có thể mở rộng, cung cấp nhiều giải pháp như lưu ký an toàn, giá trị gia tăng tài sản, tương tác trên chuỗi cũng như các giải pháp xuyên chuỗi và nhiều lớp cho các tổ chức để quản lý nhiều loại tài sản và cung cấp công nghệ mạnh mẽ nhất cho các tổ chức chuyển đổi theo hướng Web 3.0. Hỗ trợ và trao quyền cơ bản. Cobo bao gồm Cobo Custody, Cobo DaaS, Cobo MaaS, Cobo StaaS, Cobo Ventures, Cobo DeFi Yield Fund và các lĩnh vực kinh doanh khác để đáp ứng các nhu cầu khác nhau của bạn.