Hợp đồng thông minh (Smart Contract) là một thiết kế cách mạng, cho phép triển khai mọi giao dịch mà không cần bên thứ ba xác nhận. Thiết kế này là một ứng dụng rất hữu ích trên nền tảng Blockchain. Tuy nhiên, nó sẽ hoàn hảo hơn nếu không bị vướng mắc phải các vấn đề về an ninh. Do đó, chúng tôi sẽ chỉ ra các vấn đề an ninh trong việc triển khai hợp đồng thông minh, giúp cho các lập trình viên tránh được các vấn đề này.
Như chúng ta đã biết, hợp đồng thông minh thực chất là các đoạn mã BYTECODE được viết và dịch bằng ngôn ngữ Solidity. Đoạn mã này sau đó được chuyển tới tất cả các Node của Blockchain và sẽ thực thi hợp đồng trên máy ảo EVM (trong trường hợp của Ethereum). Chính việc là các đoạn mã nên rất dễ có những lỗ hổng của Hợp đồng thông minh dẫn đến việc bị Hacker kiểm soát.
Sau đây, chúng tôi sẽ mô tả các lỗ hổng an ninh phổ biến trong việc thiết kế các hợp đồng thông minh và cách thức Hacker có thể khai thác nó.
Để hiểu được nội dung của bài viết này, người đọc cần có kiến thức về:
Blockchain, Ethereum, Hợp đồng thông minh.
Ngôn ngữ Solidity và lập trình Hợp đồng thông minh.
1. LỖ HỔNG REENTRANCY ( TẤN CÔNG REENTRANCY) LÀ GÌ?
Để dễ hiểu, chúng ta mô tả dạng lỗ hổng và cách tấn công này như sau: giả sử bạn có 100 triệu đồng trong tài khoản Ngân hàng. Bạn muốn rút tiền, bạn ra Lệnh rút 100 triệu đồng, tài khoản của bạn tại Ngân hàng về 0 đồng. Nếu Lệnh rút bị lỗi Reentrance, bạn có thể rút nhiều lần 100 triệu đồng mà tài khoản của các bạn vẫn không thay đổi về 0. Với lỗi này, bạn sẽ rút hết tiền của Ngân hàng với nhiều lần rút như vậy.
pragma solidity ^0.4.18; contract Reentrancy { mapping(address => uint) public balances; function withdraw(uint _amount) public { if(balances[msg.sender] >= _amount) { if(msg.sender.call.value(_amount)()) { // ==> Khai thác lỗ hổng Reentrancy tại đây: rút tiền khỏi tài khoản ngân hàng _amount; } balances[msg.sender] -= _amount; // ==> Trừ số tiền đã rút trong tài khoản. Nếu khai thác lỗi trên thành công, hàm này sẽ không bao giờ được thực thi. } } }
Hình 01: Hợp đồng thông minh bị lỗi Reentrancy
Lỗi trên là do Hacker kết hợp cơ chế của một số hàm trong Hợp đồng thông minh khiến cho hàm rút tiền withdraw() chạy vào vòng lặp đệ quy tại vị trí call.value(). Việc này rõ ràng khiến tiền bị rút hết mà số tiền trong tài khoản của Hacker vẫn không thay đổi.
Ví dụ, với kết hợp cơ chế của hàm call.value() và hàm Fallback, Hacker sẽ thực hiện cuộc tấn công Reentrancy như sau:
Hình 02: Quy trình tấn công lỗ hổng Reentrancy
Đây là mô tả mã khai thác của Hacker:
//Write your own contracts here. Currently compiles using solc v0.4.15+commit.bbb8e64f. pragma solidity ^0.4.18; contract ExploitReentrancy { function attack(target) payable{ Reentrancy(target).withdraw(0.1 ether); } // Khi hợp đồng này nhận được tiền của Hợp đồng Reentrancy, nó sẽ tự động gọi hàm Fallback này, đây là điểm thực hiện khai thác lỗ hổng trên function () payable { Reentrancy(target).withdraw(0.1 ether); } }
Hình 03: Phương pháp tấn công lỗi Reentrancy
Ngoài ví dụ trên, Hacker có thể tận dụng lỗi Reentrancy này trong rất nhiều tình huống tùy thuộc vào kịch bản của Hợp đồng thông minh.
2. LỖ HỔNG TRANSACTION-ORDERING DEPENDENCE (TOD) LÀ GÌ?
Trên nền tảng Ethereum, bất cứ giao dịch nào trước khi được xác minh bởi các Node đều được đẩy vào hàng đợi (pool). Hàng đợi này không có thứ tự rõ ràng, việc giao dịch nào được hệ thống xác minh trước phụ thuộc vào nhiều yếu tố.
Lợi dụng việc này, Hacker có thể tiến hành tấn công theo kịch bản như sau: Giả sử bạn thi một cuộc thi giải toán, nếu kết quả bạn đưa lên hệ thống lớn hơn 100 điểm thì bạn sẽ nhận giải. Vấn đề ở đây là ngay trước khi đưa kết quả lên hệ thống, Hacker có thể thực hiện lệnh thay đổi ngưỡng điểm 100 trước đó và khiến cho hoặc bạn không thể nhận giải hoặc luôn luôn nhận giải thưởng.
Đây là ví dụ về Hợp đồng thông minh có thể dính lỗi TOD:
pragma solidity ^0.4.18; contract Math { function Math(){ reward = 100; } function SubmitSolution(solution) public constant returns (uint) { if isCorrect(solution){ // Việc kiểm tra kết quả này có thể bị Hacker can thiệp trước đó Send(reward) } } function Update(newreward) public constant returns (uint) { reward = newreward; } }
Hình 04: Hợp đồng thông minh bị lỗi TOD
Nếu hợp đồng trên thực hiện đúng ý đồ của người thiết kế, thì giao dịch triển khai trên Blockchain Ethereum sẽ như sau:
Và đây là cách Hacker có thể can thiệp vào giao dịch:
3. LỖ HỔNG TIMESTAMP DEPENDENCE LÀ GÌ?
Mã lệnh của hợp đồng thông minh thực thi trên máy ảo của các Miner (thợ đào) là lý do xảy ra lỗ hổng này. Tức là bất cứ mã lệnh nào trong Hợp đồng thông minh cần đến Miner quyết định kết quả đều có thể bị can thiệp và điều hướng. Kiểu lỗ hổng này được phát hiện trong các mã lệnh sử dụng thời gian của hệ thống đào.
Ví dụ hợp đồng thông minh được thiết kế như sau: Nếu thời điểm hiện tại (now) là ngày 08/01/2018, lãi suất tiền gửi sẽ chuyển về hệ thống của khách hàng. Rõ ràng, now cần sự quyết định của Miner khi thực thị hợp đồng trên nên Miner có thể can thiệp để hợp đồng này không bao giờ được thực hiện đúng.
pragma solidity ^0.4.18; contract WithdrawInterestRate { function withdraw() public payable returns (bool) { if (now == 08/01/2018) { // Hàm thời gian now có thể được điều khiển bởi Miner transferInterestRate(); } } }
Hình 07: Hợp đồng thông minh bị lỗi Timestamp Dependence
4. LỖ HỔNG INTEGER OVERFLOW LÀ GÌ?
Đây là dạng lỗ hổng kinh điển gặp phải ở hầu hết các hệ thống trước đây. Lợi dụng việc khai báo giới hạn bộ nhớ lưu trữ trong khi lập trình của lập trình viên, Hacker tìm cách làm tràn khả năng lưu trữ này dẫn đến thay đổi giá trị thật. Ví dụ: tài khoản ngân hàng được thiết kế chỉ lưu số to nhất là 999, nếu tăng thêm 1 giá trị, số này sẽ thành 1000, tuy nhiên khả năng phần mềm chỉ lưu chữ được ba số nên số 1 bị bỏ đi dẫn đến giá trị của tài khoản này trở thành 000.
Đây là đoạn mã bị lỗi dẫn đến Hacker có thể thao túng được số liệu tài khoản:
pragma solidity ^0.4.18; contract IntegerOverflow { mapping (address => uint256) public balanceOf; function transfer(address _to, uint256 _value) { require(balanceOf[msg.sender] >= _value); balanceOf[msg.sender] -= _value; balanceOf[_to] += _value; // Tài khoản BalanceOf[_to] chỉ có khả năng lưu trữ với giá trị cao nhất là 2^256, nếu cao hơn sẽ bị reset về 0. } }
Hình 08: Hợp đồng thông minh bị lỗi Integer Overflow
Có rất nhiều dạng lỗ hổng Integer Overflow cần tránh khi lập trình Hợp đồng thông minh, đây là một số dạng cơ bản:
Hình 09: Một số lỗ hổng Integer Overflow cơ bản
5. LỖ HỔNG SELFDESTRUCT LÀ GÌ?
Giả sử chúng ta có một Hợp đồng thực hiện nhiệm vụ nào không liên quan đến tiền. Quy định đặt ra là nếu bạn chuyển tiền vào hợp đồng, hợp đồng sẽ bị huỷ bỏ và các bên liên quan sẽ bị truy tố. Người thiết kế Hợp đồng thông minh sẽ kiểm soát việc này bằng cách: nếu ai đó chuyển tiền vào ví của hợp đồng, số tiền sẽ bị chuyển ngược lại hoặc cấm không cho chuyển tiền.
pragma solidity ^0.4.18; contract Vulnerable { function () payable { revert(); // Nếu ai đó chuyển tiền, chuyển ngược lại hoặc cấm } function somethingBad() { require(this.balance > 0); // Nếu có tiền trong hợp đồng, hợp đồng này sẽ huỷ và các bên sẽ bị truy tố. } }
Hình 10: Hợp đồng thông minh bị lỗi SelfDestruct
Cách dễ dàng nhất để huỷ hợp đồng này là chuyển tiền vào hợp đồng, nhưng khi chuyển tiền vào hợp đồng, hàm Fallback sẽ được gọi và huỷ lệnh chuyển tiền này. Tuy nhiên, Hacker đã phát hiện ra một cơ chế của hợp đồng thông minh đó là hàm SelfDestruct. Hàm này có tác dụng tự huỷ hợp đồng và chuyển toàn bộ số tiền của hợp đồng sang một địa chỉ ví nào đó. Như vậy Hacker có thể tự tạo ra một hợp đồng mới, chuyển tiền vào hợp đồng này, gọi hàm SelfDestruct để huỷ hợp đồng vừa tạo. Toàn bộ số tiền của hợp đồng mới sẽ chuyển sang hợp đồng trên mà không kích hoạt hàm Fallback:
pragma solidity ^0.4.18; contract Suicide { function Suicide() payable { selfdestruct(target); // Phá huỷ và chuyển tiền từ hợp đồng này sang hợp đồng Vunerable Vulnrable(target).somethingBad(); // Gọi hàm Phá hoại } }
Hình 11: Mã tấn công lỗi SelfDestruct
Quy trình tấn công cụ thể như sau:
Hình 12: Cách thức tấn công sử dụng hàm SeflDefence()
6. LỖ HỔNG DOS LÀ GÌ?
Một lỗi xảy ra trong quá trình thực hiện hợp đồng có thể khiến hợp đồng không bao giờ được thực hiện đúng nữa. Có hai ví dụ cho lỗ hổng này:
Một là, Chúng ta có một Hợp đồng thông minh đấu giá mua sản phẩm nào đó, ai trả giá cao hơn và chuyển tiền vào địa chỉ của Hợp đồng thì sẽ thành người sở hữu sản phẩm. Số tiền của người sở hữu trước đó sẽ được chuyển trả lại cho người đó. Sau khi chuyển lại số tiền cho người trước, người trả giá cao nhất sẽ chính thức được sở hữu sản phẩm. Vấn đề là nếu lỗi xảy ra ở bước chuyển trả tiền cho người sử hữu cũ, hệ thống sẽ dừng. Vậy thì Hacker có thể can thiệp khéo léo để trở thành người sở hữu sản phẩm này vĩnh viễn.
pragma solidity ^0.4.18; contract Auction { address currentOwner; uint highestBid; function bid() payable { require(msg.value > highestBid); require(currentOwner.send(highestBid)); // Nếu chuyển trả tiền thất bại, không thực thi các lệnh tiếp theo currentOwner = msg.sender; highestBid = msg.value; } }
Hình 13: Hợp đồng thông minh bị lỗi DoS
Hai là, Giả sử bạn phát hành cổ phiếu (Token) trong quá trình kêu gọi vốn cho một dự án (ICO). Không may sau đó dự án của bạn thất bại, Hợp đồng thông minh sẽ thực hiện trả lại tiền cho tất cả các nhà đầu tư. Tuy nhiên, việc thiết kế quá trình gửi lại tiền cho tất cả các nhà đầu tư được thiết kế sai dẫn đến việc chuyển tiền cho một nhà đầu tư bị lỗi, quá trình thực hiện này sẽ dừng lại và vĩnh viễn không thể chuyển lại tiền nữa.
//Write your own contracts here. Currently compiles using solc v0.4.15+commit.bbb8e64f. pragma solidity ^0.4.18; address[] private refundAddresses; mapping (address => uint) public refunds; // bad function refundAll() public { for(uint x; x < refundAddresses.length; x++) { // Vòng lặp chuyển tiền cho từng nhà đầu tư require(refundAddresses[x].send(refunds[refundAddresses[x]])) // Vấn đề là nếu việc chuyển tiền cho một nhà đầu tư cụ thể, hệ thống sẽ dừng lại. } }
Hình 14: Hợp đồng thông minh bị lỗi DoS
TỔNG KẾT CÁC LỖI TRONG BLOCKCHAIN
Trên đây là mô tả về những lỗ hổng thường xảy ra trong việc phát triển các Hợp đồng thông minh. Trên thực tế, tồn tại rất nhiều lỗ hổng xuất hiện do lập trình sai hoặc do thực thi sai lệch với quy trình làm việc thực tế.
Bài viết này được viết dựa trên kinh nghiệm làm với với rất nhiều với hệ thống Blockchain và Hợp đồng thông minh của SecurityBox.
Xem thêm: Hard Fork Ethereum sẽ tiếp tục vào ngày 27 tháng 2 năm 2019
Nguồn: TapchiBitcoin.vn/ Securitybox
