Bài viết này là một sự đóng góp của cộng đồng. Tác giả là Minzhi He, kiểm toán viên của CertiK.

Quan điểm thể hiện trong bài viết này là của người đóng góp/tác giả và không nhất thiết phản ánh quan điểm của Binance Academy.

Bản tóm tắt

Cầu nối chuỗi khối là nền tảng để đạt được khả năng tương tác trong không gian chuỗi khối. Do đó, tính bảo mật của công nghệ cầu nối chuỗi chéo là rất quan trọng. Một số lỗ hổng bảo mật cầu blockchain phổ biến bao gồm xác minh không đầy đủ trên chuỗi và ngoài chuỗi, xử lý mã thông báo gốc không đúng cách và cấu hình sai. Để đảm bảo logic xác minh là hợp lý, bạn nên kiểm tra cầu nối chuỗi chéo chống lại tất cả các vectơ tấn công có thể xảy ra.

Giới thiệu

Cầu blockchain là một giao thức kết nối hai blockchain và cho phép chúng tương tác. Thông qua cầu nối blockchain, nếu người dùng muốn tham gia các hoạt động DeFi trên mạng Ethereum, họ chỉ cần giữ Bitcoin và không cần bán nó để đạt được mục tiêu của mình.​

Cầu chuỗi khối là nền tảng cho khả năng tương tác trong lĩnh vực chuỗi khối. Họ sử dụng nhiều xác minh trên chuỗi và ngoài chuỗi để hoạt động, do đó cũng có thể có các lỗ hổng bảo mật khác nhau.

Tại sao tính bảo mật của cầu nối blockchain lại quan trọng?

Cầu chuỗi khối thường chứa các token mà người dùng muốn chuyển từ chuỗi này sang chuỗi khác. Cầu chuỗi khối thường được triển khai dưới dạng hợp đồng thông minh. Khi chuyển khoản xuyên chuỗi tiếp tục tích lũy, một số lượng lớn mã thông báo sẽ được giữ trên cầu. Khối tài sản khổng lồ này sẽ khiến chúng trở thành mục tiêu thèm muốn của tin tặc.

Ngoài ra, bề mặt tấn công của các cầu blockchain có xu hướng lớn do có nhiều thành phần liên quan. Do đó, bọn tội phạm có động lực mạnh mẽ để nhắm mục tiêu vào các ứng dụng xuyên chuỗi nhằm thu được số tiền lớn.

Theo ước tính của CertiK, các cuộc tấn công cầu blockchain đã gây ra thiệt hại hơn 1,3 tỷ USD vào năm 2022, chiếm 36% tổng thiệt hại trong năm đó.

Các lỗ hổng bảo mật bắc cầu xuyên chuỗi phổ biến

Để tăng cường tính bảo mật của cầu blockchain, điều quan trọng là phải hiểu các lỗ hổng bảo mật cầu nối chuỗi chéo phổ biến và kiểm tra cầu blockchain trước khi khởi chạy nó. Những lỗ hổng này chủ yếu đến từ bốn khía cạnh sau:

Xác minh trên chuỗi không đầy đủ

Đối với các cầu nối blockchain đơn giản, đặc biệt là các cầu nối được thiết kế cho một dApp cụ thể, thường chỉ có mức độ xác minh trên chuỗi 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, ghi và chuyển mã thông báo, với tất cả quá trình xác minh diễn ra ngoài chuỗi.

Trong khi các loại cầu nối khác sử dụng hợp đồng thông minh để xác thực tin nhắn và xác minh chúng trên chuỗi. Trong trường hợp này, khi người dùng gửi tiền vào chuỗi, hợp đồng thông minh sẽ tạo ra một thông báo đã ký và trả lại chữ ký trong giao dịch. Chữ ký này sẽ được sử dụng làm 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 sẽ ngăn chặn các cuộc tấn công bảo mật khác nhau, bao gồm các cuộc tấn công lặp lại và các hồ sơ nạp tiền giả mạo.

Tuy nhiên, nếu có lỗ hổng trong quy trình xác minh trên chuỗi, một cuộc tấn công có thể gây ra thiệt hại nghiêm trọng. Ví dụ: nếu blockchain sử dụng cây Merkle để xác minh hồ sơ giao dịch, kẻ tấn công có thể tạo ra bằng chứng giả mạo. Điều này có nghĩa là nếu quá trình xác minh dễ bị tấn công, kẻ tấn công có thể bỏ qua xác minh bằng chứng và đúc mã thông báo mới trong tài khoản của họ.

Một số cầu nối blockchain triển khai khái niệm “mã thông báo được bao bọc”. Ví dụ: khi người dùng chuyển DAI từ Ethereum sang Chuỗi BNB, DAI của họ sẽ bị loại khỏi hợp đồng Ethereum và một lượng DAI được bao bọc tương đương sẽ được phát hành trên Chuỗi BNB.

Tuy nhiên, nếu giao dịch này không được xác thực hợp lệ, kẻ tấn công có thể triển khai một hợp đồng độc hại thao túng chức năng này để định tuyến các mã thông báo được gói từ cầu nối đến địa chỉ sai.​

Kẻ tấn công cũng cần nạn nhân phê duyệt hợp đồng cầu nối chuỗi chéo trước khi sử dụng chức năng "TransferFrom" để chuyển mã thông báo, từ đó lấy đi tài sản khỏi hợp đồng cầu nối chuỗi chéo.

Nhưng điều khó khăn là nhiều cầu nối chuỗi chéo yêu cầu người dùng dApp phê duyệt số lượng mã thông báo không giới hạn. Cách làm này rất phổ biến, có thể giảm phí gas nhưng cho phép các hợp đồng thông minh truy cập vào số lượng mã thông báo không giới hạn từ ví của người dùng. sẽ mang lại rủi ro bổ sung. Những kẻ tấn công sẽ khai thác những xác minh dưới mức và phê duyệt quá mức này để chuyển mã thông báo từ người dùng khác sang chính họ.

Xác minh ngoài chuỗi không đầy đủ

Trong một số hệ thống cầu nối chuỗi chéo, máy chủ phụ trợ ngoài chuỗi đóng vai trò quan trọng trong việc xác minh tính hợp pháp của các tin nhắn được gửi từ chuỗi khối. Trong trường hợp này, chúng ta cần tập trung vào việc xác minh giao dịch nạp tiền.

Cầu nối chuỗi khối với xác minh ngoài chuỗi hoạt động như sau:

1. Người dùng tương tác với dApp và gửi token vào hợp đồng thông minh trên chuỗi nguồn.

2. Sau đó, dApp sẽ gửi hàm băm giao dịch tiền gửi đến máy chủ phụ trợ thông qua API.

3. Băm giao dịch cần được máy chủ xác minh nhiều lần. Nếu được coi là hợp pháp, người ký sẽ ký tin nhắn và gửi chữ ký trở lại giao diện người dùng thông qua API.

4. Sau khi nhận được chữ ký, dApp sẽ xác minh nó và cho phép người dùng rút mã thông báo khỏi chuỗi mục tiêu.

Máy chủ phụ trợ phải đảm bảo rằng các giao dịch nạp tiền mà nó xử lý là có thật và không bị giả mạo. Máy chủ phụ trợ này xác định liệu người dùng có thể rút mã thông báo trên chuỗi mục tiêu hay không, khiến nó trở thành mục tiêu tấn công đầu tiên.

Máy chủ phụ trợ cần xác minh cấu trúc của sự kiện bắt đầu giao dịch và địa chỉ hợp đồng đã bắt đầu sự kiện. Nếu điều sau bị bỏ qua, kẻ tấn công có thể triển khai các hợp đồng độc hại để giả mạo các sự kiện nạp tiền có cấu trúc tương tự như các sự kiện nạp tiền hợp pháp.

Nếu máy chủ phụ trợ không xác minh địa chỉ nào đã khởi tạo sự kiện, nó sẽ cho rằng đó là giao dịch hợp lệ và ký vào tin nhắn. Sau đó, kẻ tấn công có thể gửi hàm băm giao dịch đến máy chủ phụ trợ, bỏ qua xác minh và cho phép nó rút mã thông báo khỏi chuỗi mục tiêu.

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

Cầu nối chuỗi chéo có cách tiếp cận khác với 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.

Nếu người dùng có ý định chuyển ETH của mình sang chuỗi khác, trước tiên anh ta phải gửi số tiền đó vào hợp đồng cầu nối chuỗi chéo. Để thực hiện việc này, người dùng chỉ cần gắn ETH vào giao dịch và có thể lấy số lượng ETH bằng cách đọc trường giao dịch "msg.value".

Gửi mã thông báo ERC-20 rất khác với gửi ETH. Để gửi mã thông báo ERC-20, trước tiên người dùng phải cho phép hợp đồng cầu nối chuỗi chéo sử dụng mã thông báo của họ. Sau khi họ phê duyệt và gửi mã thông báo vào hợp đồng cầu nối chuỗi chéo, hợp đồng sẽ sử dụng chức năng "burnFrom()" để hủy mã thông báo của người dùng hoặc chức năng "transferFrom()" để chuyển mã thông báo của người dùng sang hợp đồng.

Để phân biệt đó là thao tác nào, bạn có thể sử dụng câu lệnh if-else trong cùng một hàm. Hoặc tạo hai hàm riêng biệt để xử lý từng tình huống. Do các phương thức xử lý khác nhau, nếu người dùng cố gắng gửi ETH bằng chức năng gửi tiền ERC-20 thì ETH có thể bị mất.

Khi xử lý yêu cầu gửi tiền ERC-20, người dùng thường cung cấp địa chỉ mã thông báo làm tham số đầu vào cho chức năng gửi tiền. Điều này gây ra rủi ro đáng kể vì các cuộc gọi bên ngoài không đáng tin cậy có thể xảy ra trong quá trình giao dịch. Sử dụng danh sách trắng để chỉ bao gồm các token được hỗ trợ bởi cầu nối chuỗi chéo là cách phổ biến để giảm thiểu rủi ro. Chỉ những địa chỉ trong danh sách trắng mới được chuyển dưới dạng tham số. Điều này ngăn các cuộc gọi bên ngoài vì nhóm dự án đã lọc các địa chỉ mã thông báo.

Tuy nhiên, cũng có một vấn đề xảy ra khi cầu nối chuỗi chéo xử lý việc chuyển mã thông báo gốc xuyên chuỗi, vì mã thông báo gốc không có địa chỉ. Mã thông báo gốc có thể được biểu thị bằng một địa chỉ đặc biệt, "địa chỉ 0" (0x000... 0). Nhưng có một vấn đề với điều này, nếu logic xác minh danh sách trắng không được triển khai chính xác, việc chuyển địa chỉ 0 đến hàm có thể bỏ qua việc xác minh danh sách trắng.

Khi hợp đồng cầu nối chuỗi chéo gọi "TransferFrom" để chuyển tài sản của người dùng sang hợp đồng, lệnh gọi bên ngoài đến địa chỉ 0 sẽ trả về sai vì chức năng "transferFrom" không được triển khai ở địa chỉ 0. Tuy nhiên, nếu hợp đồng không xử lý chính xác giá trị trả lại thì giao dịch vẫn có thể tiếp tục diễn ra. Điều này tạo cơ hội cho kẻ tấn công thực hiện giao dịch mà không chuyển bất kỳ mã thông báo nào vào hợp đồng.

Lỗi cấu hình

Trong hầu hết các cầu nối blockchain, có một vai trò đặc quyền chịu trách nhiệm đưa mã thông báo và địa chỉ vào danh sách trắng hoặc danh sách đen, chỉ định hoặc thay đổi người ký và các cấu hình chính 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ì những sai sót tưởng chừng như nhỏ nhặt có thể dẫn đến thiệt hại đáng kể.

Trên thực tế, đã có những trường hợp kẻ tấn công vượt qua thành công quá trình xác minh hồ sơ chuyển tiền do cấu hình sai. Nhóm dự án đã triển khai nâng cấp giao thức vài ngày trước vụ hack, trong đó một biến nhất định đã bị thay đổi. Biến này là giá trị mặc định được sử dụng để thể hiện các tin nhắn đáng tin cậy. Thay đổi này khiến tất cả các tin nhắn được tự động coi là xác thực, do đó cho phép kẻ tấn công gửi một tin nhắn ngẫu nhiên và vượt qua quá trình xác thực.

Cách cải thiện tính bảo mật của cầu nối chuỗi chéo

Bốn lỗ hổng cầu nối chuỗi chéo phổ biến được mô tả ở trên chứng minh rằng không thể đánh giá thấp những thách thức mà vấn đề bảo mật trong hệ sinh thái chuỗi khối được kết nối phải đối mặt. Để xử lý các lỗ hổng này, chúng ta cần xem xét “theo điều kiện cục bộ”. Không có phương pháp nào có thể là thần dược để xử lý mọi lỗ hổng.

Ví dụ: vì mỗi cầu nối chuỗi có các yêu cầu xác minh duy nhất nên sẽ khó đảm bảo rằng quy trình xác minh không có lỗi chỉ bằng cách cung cấp các nguyên tắc chung. Cách hiệu quả nhất để ngăn chặn việc bỏ qua xác minh là kiểm tra kỹ lưỡng cầu nối chuỗi chéo chống lại tất cả các vectơ tấn công có thể xảy ra và đảm bảo rằng logic xác minh là hợp lý.

Nói chung, việc kiểm tra nghiêm ngặt phải được tiến hành để chống lại các cuộc tấn công tiềm ẩn, đặc biệt chú ý đến các lỗ hổng bảo mật phổ biến nhất trong các cầu nối chuỗi chéo.

Phần kết luận

Do khối lượng tiền khổng lồ, các cầu nối chuỗi chéo từ lâu đã trở thành mục tiêu của những kẻ tấn công. Các nhà xây dựng có thể tăng cường bảo mật của các cầu nối chuỗi chéo bằng cách tiến hành thử nghiệm toàn diện trước khi triển khai và kết hợp kiểm tra của bên thứ ba, từ đó giảm nguy cơ xảy ra các vụ hack thảm khốc đã xảy ra trên các cầu nối chuỗi trong vài năm qua. Cầu nối chuỗi chéo rất quan trọng trong thế giới đa chuỗi, nhưng bảo mật phải được cân nhắc hàng đầu khi thiết kế và xây dựng cơ sở hạ tầng Web3 hiệu quả.

đọc thêm

Cầu blockchain là gì?

Khả năng tương tác chuỗi chéo là gì?

Ba cầu nối tiền điện tử phổ biến và cách chúng hoạt động

Token được bọc là gì?

Tuyên bố miễn trừ trách nhiệm và cảnh báo rủi ro: Nội dung của bài viết này là sự thật và chỉ nhằm mục đích thông tin chung cũng như giáo dục và không cấu thành bất kỳ sự đại diện hay bảo đảm nào. Bài viết này không được hiểu là lời khuyên về tài chính, pháp lý hoặc chuyên môn khác và không khuyến nghị bạn mua bất kỳ sản phẩm hoặc dịch vụ cụ thể nào. Bạn nên tìm kiếm lời khuyên của riêng mình từ các cố vấn chuyên môn phù hợp. Nếu bài viết này được cung cấp bởi cộng tác viên bên thứ ba, xin lưu ý rằng quan điểm thể hiện trong bài viết này thuộc về cộng tác viên bên thứ ba và không nhất thiết phản ánh quan điểm của Binance Academy. Để biết thêm thông tin, vui lòng nhấp vào đây để đọc toàn bộ tuyên bố từ chối trách nhiệm của chúng tôi. Giá tài sản kỹ thuật số có thể dao động. Giá trị khoản đầu tư của bạn có thể giảm cũng như tăng và bạn có thể không lấy lại được số tiền gốc đã đầu tư. Bạn hoàn toàn chịu trách nhiệm về các quyết định đầu tư của mình và Binance Academy không chịu trách nhiệm về bất kỳ tổn thất nào bạn có thể phải gánh chịu. Bài viết này không phải là lời khuyên về tài chính, pháp lý hoặc chuyên môn khác. Để biết thêm thông tin, vui lòng xem Điều khoản sử dụng và Cảnh báo rủi ro của chúng tôi.