LỖ HỔNG AN NINH TRONG ỨNG DỤNG HỢP ĐỒNG THÔNG MINH

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 đó, SecurityBox 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, SecurityBox 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.

Để dễ hiểu, SecurityBox 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.

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:

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.

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:

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:

Hình 05: Máy đào Miner sẽ xác minh các giao dịch và đưa vào BlockChain

Và đây là cách Hacker có thể can thiệp vào giao dịch:

Hình 06: Hacker sẽ can thiệp bằng cách đưa giao dịch khác lên trước trong BlockChain

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.

Đâ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:

Hình 09: Một số lỗ hổng Integer Overflow cơ bản

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.

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:

Hình 12: Cách thức tấn công sử dụng hàm SeflDefence()

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.

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.

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. Ngoài ra, chúng tôi có tham khao một số website sau:

[1] Ethereum Smart Contract Security Best Practices

[2] The Ethernaut

[3] Oyente: Making Smart Contracts Smarter

—–