Những lỗ hổng bảo mật phổ biến trong cầu nối chuỗi chéo là gì?

Tóm tắt

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

Giới thiệu

Cầu blockchain là giao thức kết nối hai blockchain, cho phép chúng tương tác với nhau. Thông qua cầu blockchain, người dùng muốn tham gia hoạt động DeFi trên mạng Ethereum chỉ cần sở hữu Bitcoin mà không cần bán để đạt mục đích.

Cầu blockchain là nền tảng để đạt được khả năng tương tác trong lĩnh vực blockchain. Chúng sử dụng nhiều phương pháp xác thực trên chuỗi và ngoài chuỗi, do đó cũng có thể tồn tại các lỗ hổng bảo mật khác nhau.

Tại sao an toàn của cầu blockchain lại quan trọng?

Cầu blockchain thường giữ các token mà người dùng muốn chuyển từ chuỗi này sang chuỗi khác. Cầu blockchain thường được triển khai dưới dạng hợp đồng thông minh, và khi các giao dịch chuyển chuỗi liên tục tích lũy, cầu sẽ nắm giữ một lượng lớn token, số tài sản khổng lồ này trở thành mục tiêu của hacker.

Ngoài ra, do liên quan đến nhiều thành phần, bề mặt tấn công của cầu blockchain thường rất lớn. Vì vậy, các phần tử xấu có động cơ mạnh mẽ để nhắm mục tiêu ứng dụng liên chuỗi nhằm chiếm đoạt nhiều tiền hơn.

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

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

Để nâng cao an toàn của cầu blockchain, việc hiểu rõ các lỗ hổng bảo mật phổ biến và kiểm thử cầu trước khi triển khai là rất quan trọng. Các lỗ hổng này chủ yếu xuất phát từ bốn khía cạnh sau:

Xác thực trên chuỗi không đủ

Đối với các cầu blockchain đơn giản, đặc biệt là cầu dành riêng cho các dApp nhất định, thường chỉ có xác thực trên chuỗi tối thiểu. Các cầu này dựa vào backend tập trung để thực hiện các thao tác cơ bản như đúc token, đốt token và chuyển token, tất cả các xác thực đều diễn ra ngoài chuỗi.

Các loại cầu khác thì sử dụng hợp đồng thông minh để xác thực tin nhắn và xác thực 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 tin nhắn có chữ ký và trả về chữ ký trong giao dịch. Chữ ký này sẽ được dùng làm bằng chứng nạp tiền, để xác thực yêu cầu rút tiền của người dùng trên chuỗi khác. Quy trình này cần phòng tránh các cuộc tấn công như tấn công lặp lại và giả mạo hồ sơ nạp tiền.

Tuy nhiên, nếu quá trình xác thực trên chuỗi có lỗ hổng, các cuộc tấn công có thể gây thiệt hại nghiêm trọng. Ví dụ, nếu blockchain sử dụng cây Merkle để xác thực hồ sơ giao dịch, hacker 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 thực có lỗ hổng, hacker có thể bỏ qua xác thực bằng chứng và đúc token mới trong tài khoản của mình.

Một số cầu liên chuỗi sẽ áp dụng khái niệm “đóng gói token(wrapped tokens)”. Ví dụ, khi người dùng chuyển DAI từ Ethereum sang BNB Chain, DAI của họ sẽ bị rút khỏi hợp đồng Ethereum và phát hành DAI đóng gói tương ứng trên BNB Chain.

Tuy nhiên, nếu giao dịch này không được xác thực đúng cách, hacker có thể triển khai hợp đồng độc hại, thao túng chức năng này để chuyển token đóng gói từ route liên chuỗi đến địa chỉ sai.

Hacker còn cần người dùng phê duyệt hợp đồng cầu liên chuỗi trước, để có thể sử dụng chức năng “TransferFrom” chuyển token, từ đó lấy cắp tài sản từ hợp đồng cầu liên chuỗi.

Điều phức tạp là nhiều cầu liên chuỗi yêu cầu người dùng dApp cấp phép vô hạn cho token, cách làm này phổ biến để giảm phí gas, nhưng cho phép hợp đồng thông minh truy cập không giới hạn vào ví của người dùng, gây rủi ro bổ sung. Hacker có thể lợi dụng xác thực không đầy đủ và cấp phép quá mức này để chuyển token từ các người dùng khác sang tài khoản của mình.

Xác thực ngoài chuỗi không đủ

Trong một số hệ thống cầu liên chuỗi, server backend ngoài chuỗi đóng vai trò quan trọng trong việc xác thực tính hợp lệ của các tin nhắn gửi từ blockchain. Trong trường hợp này, chúng ta cần đặc biệt chú ý đến xác thực giao dịch nạp tiền.

Cơ chế hoạt động của cầu blockchain có xác thực ngoài chuỗi như sau:

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

Sau đó, dApp gửi hash giao dịch nạp tiền qua API đến server backend.

Hash giao dịch cần trải qua nhiều lần xác thực của server. Nếu được xác nhận hợp lệ, người ký sẽ ký một tin nhắn và gửi lại chữ ký qua API về giao diện người dùng.

Sau khi nhận được chữ ký, dApp sẽ xác thực và cho phép người dùng rút token trên chuỗi đích.

Server backend phải đảm bảo rằng các giao dịch nạp tiền mà nó xử lý là thật, không phải giả mạo. Server này quyết định xem người dùng có thể rút token trên chuỗi đích hay không, do đó trở thành mục tiêu tấn công hàng đầu.

Server cần xác thực cấu trúc của sự kiện khởi tạo giao dịch và địa chỉ hợp đồng đã kích hoạt sự kiện đó. Nếu bỏ qua bước này, hacker có thể triển khai hợp đồng độc hại, giả mạo các sự kiện nạp tiền có cấu trúc giống hợp lệ.

Nếu server không xác thực địa chỉ đã kích hoạt sự kiện, nó sẽ coi đó là giao dịch hợp lệ và ký tin nhắn. Hacker có thể gửi hash giao dịch đến server, bỏ qua xác thực, và lấy token từ chuỗi đích.

Xử lý token gốc không đúng cách

Cầu liên chuỗi sử dụng các phương pháp khác nhau để xử lý token gốc và token tiện ích. Ví dụ, trên mạng Ethereum, token gốc là ETH, còn phần lớn token tiện ích tuân theo tiêu chuẩn ERC-20.

Nếu người dùng muốn chuyển ETH sang chuỗi khác, họ phải gửi ETH vào hợp đồng cầu liên chuỗi. Để làm điều này, người dùng chỉ cần đính kèm ETH vào giao dịch, và có thể lấy số lượng ETH bằng cách đọc trường “msg.value” trong giao dịch.

Việc gửi token ERC-20 khác biệt lớn so với gửi ETH. Để gửi ERC-20, người dùng phải cho phép hợp đồng cầu liên chuỗi sử dụng token của họ. Sau khi phê duyệt và gửi token vào hợp đồng, hợp đồng sẽ dùng hàm “burnFrom()” để đốt token của người dùng hoặc dùng hàm “transferFrom()” để chuyển token của người dùng vào hợp đồng.

Để phân biệt các thao tác này, có thể 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 trường hợp. Do cách xử lý khác nhau, nếu người dùng cố gắng dùng hàm nạp ERC-20 để gửi ETH, thì ETH đó có thể bị mất.

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

Tuy nhiên, khi cầu liên chuỗi xử lý chuyển token gốc liên chuỗi, cũng có vấn đề vì token gốc không có địa chỉ. Token gốc có thể dùng một địa chỉ đặc biệt để đại diện, ví dụ “địa chỉ zero(0x000… 0)”. Nhưng cách này có vấn đề, nếu không thực hiện đúng xác thực danh sách trắng, việc truyền địa chỉ zero vào hàm có thể bỏ qua xác thực danh sách trắng.

Khi hợp đồng cầu liên chuỗi gọi “TransferFrom” để chuyển tài sản của người dùng vào hợp đồng, cuộc gọi ngoài địa chỉ zero sẽ trả về false vì địa chỉ zero không có hàm “transferFrom”. Tuy nhiên, nếu hợp đồng không xử lý đúng giá trị trả về, giao dịch vẫn có thể tiếp tục. Điều này tạo cơ hội cho hacker, để họ thực hiện giao dịch mà không cần chuyển token vào hợp đồng.

Cấu hình sai

Trong hầu hết các cầu liên chuỗi, có một vai trò đặc quyền chịu trách nhiệm đưa token và địa chỉ vào danh sách trắng hoặc đen, phân bổ hoặc thay đổi người ký, cùng các cấu hình quan trọng khác. Đảm bảo tất cả các cấu hình chính xác là rất quan trọng, vì những sơ suất nhỏ cũng có thể gây ra thiệt hại lớn.

Thực tế đã từng xảy ra các vụ hacker thành công vượt qua xác thực hồ sơ giao dịch do cấu hình sai. Nhóm dự án đã thực hiện nâng cấp giao thức vài ngày trước khi bị tấn công, trong đó thay đổi một biến dùng để biểu thị giá trị mặc định của tin nhắn đáng tin cậy. Thay đổi này khiến tất cả các tin nhắn đều tự động được coi là đã xác thực, giúp hacker dễ dàng gửi một tin nhắn bất kỳ để qua mặt xác thực.

Làm thế nào để nâng cao an toàn của cầu liên chuỗi

Bốn lỗ hổng phổ biến nêu trên cho thấy rằng, trong hệ sinh thái blockchain liên kết, các thách thức về an toàn không thể xem nhẹ. Để đối phó với các lỗ hổng này, cần có các biện pháp “tùy theo tình hình”, không có phương pháp nào có thể toàn diện để xử lý tất cả các lỗ hổng.

Ví dụ, vì mỗi cầu liên chuỗi đều có yêu cầu xác thực riêng biệt, việc chỉ cung cấp các hướng dẫn chung để đảm bảo quá trình xác thực không có lỗi là rất khó. Phương pháp hiệu quả nhất để ngăn chặn bỏ qua xác thực là kiểm thử toàn diện cầu liên chuỗi đối với tất cả các vector tấn công có thể, và đảm bảo logic xác thực hợp lý.

Tóm lại, cần kiểm thử nghiêm ngặt các khả năng tấn công tiềm ẩn và đặc biệt chú ý đến các lỗ hổng bảo mật phổ biến nhất của cầu liên chuỗi.

Kết luận

Do lượng vốn lớn, cầu liên chuỗi từ lâu đã trở thành mục tiêu của các hacker. Các nhà xây dựng có thể tăng cường an toàn của cầu liên chuỗi bằng cách thực hiện kiểm thử toàn diện trước khi triển khai và đưa vào kiểm toán của bên thứ ba, từ đó giảm thiểu rủi ro các cuộc tấn công hacker thảm khốc trong những năm gần đây. Cầu liên chuỗi đóng vai trò quan trọng trong thế giới đa chuỗi, nhưng khi thiết kế và xây dựng hạ tầng Web3 hiệu quả, yếu tố an toàn phải được đặt lên hàng đầu. **$STORJ **$STO