Cầu chuỗi khối cho phép người dùng chuyển tài sản hoặc dữ liệu từ chuỗi khối này sang chuỗi khối khác. Vì hầu hết các chuỗi khối được phát triển trong môi trường biệt lập và sử dụng các quy tắc và cơ chế đồng thuận khác nhau, nên chúng không thể giao tiếp tự nhiên và các mã thông báo không thể di chuyển tự do giữa chúng. Cầu nối được thiết kế để kết nối các chuỗi khối, tạo điều kiện thuận lợi cho việc chuyển thông tin và mã thông báo giữa chúng.

Cầu xuyên chuỗi là gì?

Sau đây là luồng điều khiển đơn giản hóa của một cây cầu:

Để bắt đầu chuyển tiền, trước tiên người dùng phải gửi tài sản hoặc dữ liệu vào hợp đồng chuỗi nguồn, hợp đồng này sẽ phát sinh sự kiện gửi tiền. Máy chủ phụ trợ có thể bao gồm từ một máy chủ tập trung đơn giản giám sát sự kiện gửi tiền được phát ra, xác minh giao dịch và khởi tạo giao dịch chuỗi chéo, đến một chuỗi chuyển tiếp phức tạp hơn. Trong trường hợp sau, một loạt các nút chuyển tiếp đồng bộ hóa và giám sát dữ liệu giao dịch của chuỗi khối và các nút đồng thuận của chuỗi chuyển tiếp xác minh tính hợp lệ của các giao dịch chuỗi chéo và kích hoạt việc thực hiện các giao dịch tương ứng. Sau khi chuỗi mục tiêu nhận được tín hiệu để thực hiện giao dịch, tài sản sẽ được gửi đến người dùng.

Trusted vs Trustless Bridges

Cầu đáng tin cậy phụ thuộc vào một thực thể hoặc hệ thống trung tâm cho các hoạt động của họ. Họ có các giả định tin cậy liên quan đến việc lưu ký tiền và bảo mật của cầu. Người dùng chủ yếu dựa vào danh tiếng của nhà điều hành cầu. Các ví dụ bao gồm Binance Bridge và Multichain.

Cầu không tin cậy hoạt động bằng cách sử dụng các hợp đồng và thuật toán thông minh. Chúng không đáng tin cậy, nghĩa là tính bảo mật của cây cầu “giống như” tính bảo mật của chuỗi khối cơ bản. Các ví dụ bao gồm Mạng Connext và Hop Exchange.

Những gì họ kết nối

L1 <> L1 Bridges: kết nối các blockchain L1 với nhau. Ví dụ: Cầu Avalanche kết nối Ethereum và Avalanche. Cầu L1/L2 <> L2: kết nối một lớp cơ sở nhất định với các giải pháp L2 khác nhau và các L2 với nhau. Ví dụ, Across là cầu nối Ethereum Mainnet với các L2 như Arbitrum và Optimism. Giao thức Hop kết nối các L2 khác nhau với nhau ngoài việc kết nối Ethereum Mainnet với chúng.

Cách họ di chuyển tài sản

Lock & Mint: khóa tài sản trên chuỗi nguồn và đúc tài sản trên chuỗi đích. Ví dụ: Cầu PoS của Polygon, Cầu Avalanche, BTC bao bọc, wMonero. Nhóm thanh khoản: Nhóm thanh khoản trên mỗi chuỗi. Người dùng nhận tài sản của họ từ nhóm thanh khoản trên chuỗi đích. Ví dụ: Hop, Across.Atomic Swaps: hoán đổi tài sản trên chuỗi nguồn lấy tài sản trên chuỗi đích. Nói chung là không đáng tin cậy hơn vì chúng dựa vào hợp đồng thông minh để hoán đổi và loại bỏ bên thứ ba đáng tin cậy cần thiết trong lock&mint hoặc Liquidity Pools. Ví dụ: cBridge, Connext.

Cách chúng hoạt động

Cầu nối chuỗi: hỗ trợ di chuyển tài sản giữa hai chuỗi khối. Nói chung, những cây cầu như vậy sử dụng cơ chế lock&mint. Ví dụ: Các cầu bản địa như Cầu PoS của Polygon hoặc Cầu Avalanche. Cầu đa chuỗi: chuyển tài sản qua nhiều chuỗi khối. Chúng được xây dựng sao cho chúng có thể được triển khai cho bất kỳ chuỗi khối L1 hoặc L2 nào. Ví dụ: Connext và cBridge. Cầu chuyên dụng: tập trung vào các hệ sinh thái cụ thể và được thiết kế để hỗ trợ chuyển động của tài sản. Do chuyên môn hóa, chúng thường là các giao dịch nhanh hơn và rẻ hơn. Cầu nối tài sản được bao bọc: chuyển tài sản không bản địa sang các chuỗi khối khác nhau. Tạo nội dung được bao bọc trên đích đại diện cho nội dung ban đầu trên nguồn. Ví dụ: BTC được bao bọc, cầu nối cụ thể của wMonero.Data: các giao thức có khả năng tương tác được thiết kế đặc biệt để truyền dữ liệu tùy ý trên các chuỗi khối. Nói chung, các giao thức này trở thành lớp cơ sở cho dApps và giúp chúng có thể đạt được khả năng kết hợp chuỗi chéo. Ví dụ: Khung thông báo liên chuỗi của Celer, IBC, Cầu nối cụ thể của Nomad.dApp: Từ góc độ kỹ thuật, đây không phải là cầu nối. Bằng cách kết nối với các chuỗi khối khác nhau, các dApp này đã xây dựng một hệ sinh thái cho phép giá trị được chuyển qua các chuỗi khối tương tự như cầu nối. Ví dụ: Thorchain là một AMM chuỗi chéo phi tập trung cung cấp các tính năng thanh khoản chuỗi chéo cho phép trao đổi tài sản trên các chuỗi khối. Khác: Anyswap, Wanchain và Synapse.

So với các loại ứng dụng phi tập trung (dApp) khác, các cầu nối chuỗi khối phức tạp hơn do có nhiều thành phần liên quan hơn dẫn đến bề mặt tấn công lớn hơn. Hơn nữa, hợp đồng cầu nối thường nắm giữ một lượng tài sản đáng kể do tiền gửi của người dùng được lưu trữ trong hợp đồng. Do đó, các tác nhân độc hại có động cơ cao nhắm mục tiêu vào các ứng dụng chuỗi chéo để đánh cắp số tiền lớn. Khai thác cầu nối có thể có ý nghĩa quan trọng đối với mã thông báo được bao bọc vì việc mất tiền gửi có thể khiến mã thông báo nợ trở nên vô giá trị trong những trường hợp cực đoan. Trong bài viết này, chúng tôi đang kiểm tra một số lỗ hổng phổ biến đã bị khai thác hoặc chúng tôi đã gặp phải trong quá trình kiểm tra của mình.

Lỗ hổng bảo mật cầu chung

Xác minh không đầy đủ

Quy trình quan trọng nhất và bắt buộc phải có trong một hệ thống cầu nối là xác nhận. Chúng ta có thể chia xác thực thành xác thực trên chuỗi và xác thực ngoài chuỗi.

Xác thực trên chuỗi

Đối với các cầu nối đơn giản, đặc biệt là những cầu nối được thiết kế cho các dApp cụ thể, việc xác thực trên chuỗi được giữ ở mức tối thiểu. Những cầu nối này dựa vào phần phụ trợ tập trung để thực hiện các hoạt động cơ bản như đúc, đốt hoặc chuyển mã thông báo, trong khi tất cả các xác minh được thực hiện ngoài chuỗi. Ngược lại, các loại cầu nối khác sử dụng hợp đồng thông minh để xác thực thông điệp. Trong trường hợp này, khi người dùng gửi tiền vào một chuỗi, hợp đồng thông minh sẽ tạo một thông báo đã ký và trả lại chữ ký trong giao dịch. Chữ ký này đóng vai trò là bằng chứng gửi tiền và được sử dụng để xác minh yêu cầu rút tiền của người dùng trên chuỗi khác. Quá trình này ngăn chặn các cuộc tấn công bảo mật khác nhau, bao gồm tấn công phát lại và người dùng giả mạo hồ sơ tiền gửi. Nếu có lỗ hổng trong quá trình xác thực, kẻ tấn công có thể gây ra thiệt hại khá nghiêm trọng. Vụ hack trung tâm mã thông báo BNB xảy ra do lỗ hổng như vậy. Kẻ tấn công đã khai thác một lỗ hổng trong hợp đồng được biên dịch trước để xác thực bằng chứng IAVL. Kẻ tấn công đã tạo bằng chứng giả mạo bằng cách thêm các lá chứa hàm băm tải trọng của kẻ tấn công vào cây IAVL và các nút bên trong để hoàn tất sớm quá trình xác minh bằng chứng. Kẻ tấn công đã bỏ qua xác thực bằng chứng IAVL và đúc thành công hai triệu BNB vào tài khoản của chúng.

Người dùng được yêu cầu cung cấp thông tin cơ bản về chuyển giao chuỗi chéo mà họ muốn thực hiện, chẳng hạn như mã thông báo họ muốn trao đổi và chuỗi mục tiêu. Nếu không có xác thực thích hợp, các hoạt động không mong muốn có thể xảy ra.

Vào tháng 1 năm 2022, Multichain (trước đây gọi là Anyswap) đã bị khai thác do bỏ qua xác thực. Multichain là một giao thức bộ định tuyến xuyên chuỗi khối được thiết kế để cho phép người dùng hoán đổi và trao đổi mã thông báo kỹ thuật số trên các chuỗi đồng thời giảm phí và hợp lý hóa quy trình tổng thể. Bộ định tuyến bọc mã thông báo thực tế bằng “anyToken '' được bọc để đạt được điều này. Ví dụ: mã thông báo DAI được bao bọc dưới dạng anyDAI. Ngược lại, DAI là tài sản cơ bản của bất kỳ DAI nào. Mã thông báo được bao bọc được sử dụng cho kế toán nội bộ và khi người dùng “chuyển'' DAI từ Ethereum sang BSC, bất kỳ DAI nào sẽ được thêm vào hợp đồng Multichain bất kỳ DAI BSC nào và được trừ vào bất kỳ hợp đồng DAI Ethereum nào.

Hàm dễ bị tấn công là anySwapOutUnderlyingWithPermit, được sử dụng để hoán đổi mã thông báo cơ bản bằng cách sử dụng hàm permission ERC20. Chức năng giấy phép cho phép người dùng cung cấp một giao dịch đã ký phê duyệt hợp đồng để chi tiêu tiền của họ mà không thực sự gửi nó tới chuỗi khối, do đó giảm thiểu chi phí gas của họ. Giao dịch đã ký được thể hiện bằng (v, r, s).

Kẻ tấn công đã chuyển các đối số sau cho hàm: 'từ' đại diện cho địa chỉ của nạn nhân, trong khi 'mã thông báo' và 'đến' tương ứng đại diện cho hợp đồng đã triển khai của kẻ tấn công và địa chỉ đích. Tuy nhiên, kẻ tấn công đã không cung cấp chữ ký hợp lệ cho các tham số 'v', 'r' và 's'.

Trong hàm dễ bị tấn công, dòng đầu tiên ghi địa chỉ _underlying = AnyswapV1ERC20(token).underlying();. Mục đích là để mở mã thông báo cơ bản, "DAI" khỏi gói AnyToken của nó, "anyDAI". Tuy nhiên, trong trường hợp này, địa chỉ mã thông báo bị kẻ tấn công kiểm soát và hợp đồng trả lại WETH làm "tài sản cơ sở" của nó. WETH không phải là mã thông báo được bao bọc được xác định trong dự án.

Dòng thứ hai có nội dung IERC20(_underlying).giấy phép(từ, địa chỉ(này), số tiền, thời hạn, v, r, s);. Hợp đồng WETH không thực hiện chức năng giấy phép. Thay vào đó, WETH có chức năng dự phòng được gọi là tiền gửi, chức năng này không thực hiện bất kỳ hành động nào nhưng cho phép chức năng gọi điện thực thi mà không gặp lỗi.

Dòng TransferHelper.safeTransferFrom(_underlying, from, token,mount); sẽ chuyển mã thông báo từ nạn nhân sang hợp đồng do kẻ tấn công kiểm soát. Để thực hiện chuyển khoản này, người dùng phải phê duyệt hợp đồng bộ định tuyến để chi tiêu không giới hạn số lượng mã thông báo của họ. Trong trường hợp này, dApp của Multichain đã yêu cầu tổng số phê duyệt thực tế vô hạn từ tất cả người dùng, một phương pháp phổ biến nhưng không an toàn trong dApps để tiết kiệm chi phí gas cho người dùng.

Bằng cách khai thác sự chấp thuận quá mức này và thiếu xác thực đầu vào, kẻ tấn công đã có thể chuyển số lượng WETH từ tài khoản của nạn nhân sang hợp đồng được kiểm soát của họ.

Xác thực ngoài chuỗi

Trong một hệ thống cầu nối, máy chủ phụ trợ ngoài chuỗi thường đảm nhận vai trò tập trung trong việc xác minh tính hợp pháp của các thông báo được gửi từ chuỗi khối. Quá trình xác thực này thường tập trung vào việc xác minh các giao dịch gửi tiền. Máy chủ phụ trợ phải đảm bảo rằng giao dịch gửi tiền mà nó xử lý đã thực sự xảy ra và chưa được sử dụng để rút tiền trên chuỗi mục tiêu. Vì máy chủ phụ trợ thường giữ đặc quyền xác định xem người dùng có thể rút tiền trên chuỗi mục tiêu hay không, nên đây là mục tiêu có giá trị cao cho những kẻ tấn công. Hai dự án QANX và Cennznet đều đã bị khai thác do các cuộc tấn công vào máy chủ phụ trợ của họ.

QANX đóng vai trò là cầu nối giữa mạng Ethereum (ETH) và Chuỗi thông minh Binance (BSC), với biểu đồ bên dưới minh họa quy trình làm việc của cầu nối.

Ở mức cao, cây cầu hoạt động như sau:

Người dùng tương tác với giao diện người dùng để gửi tiền vào hợp đồng thông minh trên chuỗi nguồn. Sau đó, giao diện người dùng sẽ gửi hàm băm giao dịch tiền gửi đến máy chủ phụ trợ thông qua API. Hàm băm giao dịch phải tuân theo một số xác thực trên máy chủ và nếu nó được coi là hợp pháp, người ký sẽ ký một tin nhắn và gửi lại chữ ký cho giao diện người dùng thông qua API. Khi nhận được chữ ký, giao diện người dùng sẽ xác minh chữ ký đó và cho phép người dùng rút tiền trên chuỗi mục tiêu.

Vấn đề ở đây là khi máy chủ phụ trợ xác minh giao dịch, nó chỉ xác thực cấu trúc của sự kiện phát ra của giao dịch. Nó không xác minh địa chỉ hợp đồng đã phát ra sự kiện. Do đó, kẻ tấn công có thể triển khai một hợp đồng độc hại và tạo một giao dịch để giả mạo một sự kiện gửi tiền có cấu trúc giống như một sự kiện gửi tiền hợp pháp. Sau đó, kẻ tấn công có thể gửi hàm băm giao dịch đến phần phụ trợ, bỏ qua xác minh và cho phép họ rút tiền khỏi chuỗi mục tiêu.

Vụ hack trên cầu Cennznet rất giống với vụ hack QANX. Trong trường hợp này, kẻ tấn công đã triển khai một hợp đồng để tạo ra một sự kiện gửi tiền mà máy chủ phụ trợ đã chọn, cho phép kẻ tấn công rút tiền từ hợp đồng cầu nối.

Xác thực là một khía cạnh quan trọng của hệ thống cầu nối và việc bỏ qua nó có thể dẫn đến tổn thất tài chính đáng kể, như minh họa ở trên. Vì mỗi cây cầu có các yêu cầu xác minh riêng, nên rất khó để cung cấp hướng dẫn chung về việc đảm bảo quy trình xác minh không có lỗi. Cách tiếp cận hiệu quả nhất để ngăn chặn bỏ qua xác minh là kiểm tra kỹ lưỡng cây cầu chống lại tất cả các hướng tấn công có thể xảy ra và đảm bảo rằng logic xác minh hợp lý.

Xử lý mã thông báo gốc không đúng cách

Các cầu nối thực hiện các cách tiếp cận khác nhau để quản lý sự khác biệt giữa mã thông báo gốc và mã thông báo tiện ích. Ví dụ: trên mạng Ethereum, mã thông báo gốc là ETH và hầu hết các mã thông báo tiện ích đều tuân thủ tiêu chuẩn ERC-20. Khi người dùng có ý định chuyển ETH của họ sang một chuỗi khác, trước tiên họ phải gửi nó vào hợp đồng cầu nối. Để đạt được điều này, người dùng chỉ cần đính kèm ETH vào giao dịch và số lượng ETH có thể được lấy bằng cách đọc trường msg.value của hợp đồng.

Gửi mã thông báo ERC-20 khác đáng kể so với gửi ETH. Để gửi mã thông báo ERC-20, trước tiên người dùng phải phê duyệt hợp đồng cầu nối để chi tiêu mã thông báo của họ. Sau đó, khi gửi mã thông báo vào hợp đồng bắc cầu, hợp đồng sẽ ghi mã thông báo của người dùng bằng chức năng burnFrom hoặc chuyển mã thông báo của người dùng sang hợp đồng bằng cách sử dụng chức năng transferFrom. Do sự khác biệt này, hợp đồng bắc cầu phải xử lý hai loại tiền gửi này một cách riêng biệt. Một cách tiếp cận là sử dụng câu lệnh if-else trong cùng một hàm, trong khi một phương pháp khác là tạo hai hàm riêng biệt để xử lý từng tình huống. Điều quan trọng là phải xem xét điều gì sẽ xảy ra nếu người dùng cố gắng sử dụng sai chức năng, chẳng hạn như cố gắng gửi ETH bằng chức năng gửi tiền ERC-20, như đã thấy trong vụ hack Qubit.

Cầu Qubit có chức năng xử lý tiền gửi của người dùng thông qua hai phương pháp: ký gửi đối với các yêu cầu chuỗi chéo mã thông báo ERC-20 và ký gửi ETH để xử lý các giao dịch ETH. Trong cuộc tấn công vào cầu nối, kẻ tấn công đã khai thác lỗ hổng bằng cách gọi hàm ký gửi với các tham số cụ thể.

Điểm quan trọng cần lưu ý là resourceID được đặt thành "0x00000000000000000000002f422fe9ea622049d6f73f81a906b9b8cff03b7f01". Hợp đồng sử dụng resourceID để xác định loại mã thông báo mà người dùng muốn chuyển chuỗi chéo. Có thể truy cập địa chỉ mã thông báo thông qua ánh xạ resourceIDToTokenContractAddress. resourceID được sử dụng trong chức năng gửi tiền ánh xạ tới địa chỉ 0, tương ứng với ETH trong hợp đồng. Do đó, kẻ tấn công đã cố gắng khai thác chức năng gửi tiền để xử lý tiền gửi ETH, đây là một hành vi ngoài ý muốn. Quá trình xác minh được thực hiện trong chức năng gửi tiền trong hợp đồng QBridgeHandler, như được mô tả bên dưới:

Chức năng ký gửi trong cầu nối Qubit, được thiết kế để xử lý các yêu cầu chuỗi chéo mã thông báo ERC-20, có hai bước kiểm tra. Thứ nhất, nó yêu cầu địa chỉ mã thông báo phải được đưa vào danh sách trắng (dòng 128). Thứ hai, nó yêu cầu người dùng chuyển mã thông báo vào hợp đồng (dòng 135). Trong cuộc tấn công, resourceID được chuyển vào chức năng gửi tiền ánh xạ tới địa chỉ số 0, đại diện cho ETH trong hợp đồng. Không có chức năng safeTransferFrom nào được triển khai trong địa chỉ số không. Khi người dùng cố gắng chuyển mã thông báo sang hợp đồng, lệnh gọi bên ngoài trả về sai, nhưng giao dịch có thể tiếp tục thực hiện. Thật không may, ngay cả khi dòng 135 trả về false, hợp đồng không xử lý trường hợp này, cho phép giao dịch được thực hiện thành công.

cấu hình sai

Trong hầu hết các cầu nối chuỗi khối, có một vai trò đặc quyền chịu trách nhiệm quản lý mã thông báo và địa chỉ danh sách trắng/danh sách đen, chỉ định/thay đổi người ký và các cấu hình quan trọng khác. Điều quan trọng là phải đảm bảo rằng tất cả các cấu hình đều chính xác, vì ngay cả những sai sót tưởng chừng như nhỏ nhặt cũng có thể dẫn đến các vụ hack nghiêm trọng. Trên thực tế, một số vụ hack quan trọng nhất trong những năm gần đây là do sơ suất như vậy.

Chẳng hạn, vào tháng 8 năm 2022, cây cầu Nomad đã bị khai thác, dẫn đến thiệt hại tài sản trị giá khoảng 190 triệu USD. Hợp đồng cầu nối chứa chức năng quy trình xác thực xem thông báo chuyển có được liên kết với gốc hợp lệ hay không. Tuy nhiên, theo mặc định, thư mục gốc của thư chưa được kiểm chứng sẽ là 0x00.

Một vài ngày trước khi xảy ra vụ hack, một bản nâng cấp giao thức đã diễn ra trong đó giá trị của gốc đáng tin cậy được khởi tạo thành 0x00. Mặc dù đây là một thực tế phổ biến, nhưng trong trường hợp cụ thể này, nó cũng khớp với giá trị của một gốc không đáng tin cậy. Do đó, tất cả các tin nhắn sẽ tự động được coi là đã được chứng minh, cho phép mọi người gửi một tin nhắn tùy ý và vượt qua quá trình xác minh.

Xây dựng những cây cầu tốt hơn

Do giá trị cao của chúng, các cầu xuyên chuỗi từ lâu đã trở thành tâm điểm của những kẻ tấn công. Chúng tôi mong đợi nhiều cuộc tấn công của bản chất này trong tương lai. Tuy nhiên, các nhóm có thể tăng cường các biện pháp bảo mật của mình bằng cách tiến hành thử nghiệm kỹ lưỡng và tham gia vào các cuộc kiểm tra của bên thứ ba, giảm nguy cơ xảy ra các vụ tấn công tàn khốc đã gây khó khăn cho các cây cầu trong vài năm qua. Cầu nối rất quan trọng trong thế giới đa chuỗi, nhưng bảo mật phải là mối quan tâm hàng đầu khi thiết kế và xây dựng cơ sở hạ tầng Web3 hiệu quả.