Những thách thức về bảo mật hợp đồng thông minh

Reading Time: 5 minutes

Với tư cách là một chuyên gia đã chứng kiến sự trỗi dậy mạnh mẽ của công nghệ blockchain, tôi có thể khẳng định rằng hợp đồng thông minh là một trong những phát minh mang tính đột phá nhất. Tuy nhiên, đi kèm với tiềm năng to lớn đó là những thách thức không nhỏ về mặt bảo mật. Vì vậy, hy vọng bài viết này sẽ giúp bạn nhận biết các dạng tấn công phổ biến trên mạng blockchain.

Khác với phần lớn các trường hợp sử dụng của các ngôn ngữ lập trình truyền thống, hợp đồng Solidity thường thực hiện chức năng cốt lõi là chuyển giao một lượng giá trị đáng kể, và do đó, chúng chịu rủi ro dễ bị tấn công từ các tác nhân xấu tìm cách rút tiền từ các tác nhân bất biến này.

Do đó, các nhà phát triển nên tiến hành kiểm toán hoặc thuê một cơ quan kiểm toán trước khi triển khai hợp đồng thông minh lên mainnet – một khi hợp đồng đã được công khai, việc khắc phục các lỗ hổng bảo mật một cách hồi tố có thể rất khó khăn!

Các loại lỗ hổng tiềm ẩn và cách thức thực hiện các cuộc tấn công này là một khóa học riêng biệt. Hãy cùng điểm qua nhanh các lỗ hổng chính để bạn hiểu về những gì cần lưu ý:

Tấn Công Tái Nhập (Reentrancy Attacks)

Loại tấn công này vừa cực kỳ nguy hiểm, khiến một hợp đồng thông minh có lỗ hổng bảo mật bị rút hết ether, vừa cực kỳ dễ mắc phải một cách vô tình. Tấn công tái nhập xảy ra do hai tính năng quan trọng của Solidity:

• Hợp đồng thông minh thực thi theo kiểu mệnh lệnh – nghĩa là chúng đợi từng dòng hoàn thành trước khi thực thi dòng tiếp theo.
• Hợp đồng thông minh có thể gọi các hợp đồng bên ngoài, không đáng tin cậy và đợi kết quả trước khi tiếp tục.

Do đó, khi hợp đồng A có lỗ hổng bảo mật thực hiện một lệnh gọi bên ngoài đến hợp đồng B không đáng tin cậy khác, có trường hợp mà hợp đồng B khác có thể chứa mã độc để thực hiện lệnh gọi đệ quy trở lại hợp đồng A ban đầu. Nếu lệnh gọi từ hợp đồng A đến B liên quan đến việc gửi bất kỳ lượng Ether nào, vòng lặp vô hạn này có thể rút cạn tất cả tài nguyên của hợp đồng A trước khi hàm kết thúc.

Đây là một ví dụ đơn giản:

Thông thường, msg.sender là một người dùng thông thường, chẳng hạn như tài khoản Metamask. Trong trường hợp này, hàm withdraw() sẽ chỉ rút một số tiền, cập nhật số dư và kết thúc. Tuy nhiên, nếu msg.sender là hợp đồng B chứa mã độc, khi hợp đồng A chạy msg.sender.call, hợp đồng B có thể được thiết lập để ngay lập tức gọi lại hợp đồng A. Trong tình huống đó, hàm withdraw() sẽ được gọi lặp đi lặp lại cho đến khi hợp đồng A không còn tài nguyên hoặc ngăn xếp EVM đầy. Khá nguy hiểm, phải không?

Để xem một số ví dụ về cách ngăn chặn điều này, hãy xem bài viết này tại đây. 

Tấn Công Chạy Trước (Frontrunning)

Điều thú vị là, hợp đồng thông minh và giao dịch trở nên hoàn toàn công khai không phải khi chúng được xác nhận trên blockchain, mà là ngay khi bạn gửi chúng lên mạng dưới dạng giao dịch đang chờ xử lý. Các giao dịch đang chờ xử lý này được chia sẻ trên toàn mạng trong mempool của các nút Ethereum, cho phép người khai thác chọn các giao dịch có phí gas cao nhất.

Một tác dụng phụ của thiết kế này là kết quả dự kiến của một hợp đồng thông minh hiển thị cho tất cả mọi người trong một khoảng thời gian trước khi nó được xác nhận vào blockchain. Giả sử bạn có một hợp đồng thông minh khi chạy sẽ thực hiện một giao dịch chênh lệch giá kiếm được 1 ETH và chi phí triển khai là 0,05 ETH. Các tác nhân xấu theo dõi mempool có thể thấy giao dịch này, nhận ra cơ hội và sao chép hợp đồng thông minh của bạn, gửi nó với phí gas là 0,06 ETH. Sau đó, họ đã “chạy trước” thành công hợp đồng của bạn, đánh cắp cơ hội chênh lệch giá của bạn bằng cách gửi giao dịch của họ trước.

Trong thực tế, các cuộc tấn công này thường được thực hiện bởi chính những người khai thác, dẫn đến một hiện tượng được gọi là MEV (giá trị có thể trích xuất của người khai thác) trị giá hàng nghìn ETH mỗi ngày. Thật không may, chúng khó tránh khỏi, nhưng bạn có thể sử dụng một số các phương pháp hữu ích được mô tả trong bài viết này tại đây.

Tràn Số Nguyên (Integer Overflow) & Tràn Số Nguyên Âm (Underflow)

Đây là một cuộc tấn công phổ biến trong nhiều ngôn ngữ lập trình! Đây là ý tưởng chung về cách loại tấn công này có thể xảy ra trong Solidity:

1. Hợp đồng thông minh Solidity được xây dựng bằng cách sử dụng 256 bit làm kích thước từ, tương đương với khoảng 4,3 tỷ.
2. Khi giảm giá trị của một số nguyên không dấu 0, nó sẽ vòng trở lại giá trị tối đa.
3. Do đó, một cuộc tấn công tràn số nguyên âm có thể được thực hiện bằng cách có một địa chỉ độc hại được hợp đồng thông minh ghi nhận là có số dư bằng 0 cố gắng gửi 1 đơn vị Ether, buộc số dư của nó quay trở lại giá trị tối đa cho phép: 4,3 tỷ.
4. Sau đó, vì hợp đồng thông minh tin rằng địa chỉ có số dư là 4,3 tỷ ether, nên nó có thể cho phép tiếp tục rút tiền từ tài khoản đó cho đến khi hợp đồng thông minh bị rút hết tiền.

Như bạn có thể thấy, chiêu này dễ dàng khai thác bất kỳ hợp đồng thông minh nào theo dõi số dư địa chỉ nội bộ. Để tránh điều này, chỉ cần đảm bảo bạn đang sử dụng trình biên dịch Solidity phiên bản 0.8, tự động kiểm tra tràn số nguyên và tràn số nguyên âm.

Bí kíp bỏ túi: Lưu ý quan trọng bạn cần biết

Tôi đã điểm qua một số dạng nguy cơ chính. Nhưng thật không may, bạn cần phải để ý về hàng tá khả năng tấn công lớn khác. Như nhiều nhà phát triển đã nói, “Mất một tuần để học Solidity và ba năm để tránh viết các lỗ hổng nghiêm trọng một cách thường xuyên”.

Điều quan trọng là phải nhận ra rằng rất có thể bạn sẽ gặp phải các vấn đề bảo mật đối với bất kỳ hợp đồng thông minh ở mức độ phức tạp vừa phải nào mà bạn viết và nếu bạn định lưu trữ bất kỳ giá trị đáng kể nào trong hợp đồng, bạn chắc chắn nên nhờ một cơ quan chuyên nghiệp kiểm toán mã nguồn.

Chúc bạn code vui vẻ!