Phân tích cốt lõi của các nguyên tắc dễ bị tổn thương trong hợp đồng thông minh

Tiêu đề gốc: "Báo cáo nghiên cứu丨Phân tích cốt lõi về nguyên tắc của các lỗ hổng hợp đồng thông minh"

Bản gốc nguồn ：Binance Research

Giới thiệu những kiến thức cơ bản về hợp đồng thông minh

Trước khi thảo luận về việc phân tích các lỗ hổng hợp đồng thông minh, trước tiên chúng ta hãy hiểu một hợp đồng thông minh sẽ có những yếu tố gì từ một ví dụ cơ bản.

● Biến: số dư trong ví dụ này, trong hợp đồng này có trách nhiệm lưu trữ số dư tiền gửi tương ứng với địa chỉ người dùng trong hợp đồng

● Chức năng: cụ thể là getBalance trong ví dụ này. Khi người dùng gọi hàm này, số dư tiền gửi của người dùng trong hợp đồng sẽ được trả về

● Hàm nhận: hàm nhận trong ví dụ này, đây là hàm được tích hợp sẵn. Nó sẽ được kích hoạt khi hợp đồng nhận ETH từ người dùng và không gọi các hướng dẫn khác. Trong ví dụ này, khi chức năng nhận được kích hoạt, trạng thái của số dư biến sẽ được thay đổi và msg.sender trong hàm đại diện cho người gửi địa chỉ của giao dịch

● Hàm dự phòng: Dự phòng trong ví dụ này, cũng là một hàm tích hợp. Được kích hoạt khi người dùng gọi một hàm không tồn tại, nó có thể hiểu là một hàm xử lý ngoại lệ. Trong ví dụ này, khi được kích hoạt, giao dịch sẽ được khôi phục, nghĩa là giao dịch bị vô hiệu.

Phân tích lỗ hổng phổ biến

Hiểu được nguyên nhân của sự cố và phân loại chúng có thể giúp Chúng tôi xử lý tốt hơn các biện pháp phòng ngừa. DASP (Dự án bảo mật ứng dụng phi tập trung) đã bao gồm mười loại lỗ hổng hợp đồng thông minh. Dưới đây chúng tôi đã tổng hợp các lỗ hổng hợp đồng phổ biến nhất và các phương thức tấn công mới.

1. Lỗ hổng Reentrancy

Lỗ hổng Reentrancy là lỗ hổng hợp đồng thông minh nổi tiếng nhất. Như đã đề cập Trước đó, sự cố DAO cũng bị hacker tấn công vì lý do này, nguyên lý của lỗ hổng này là nhằm đạt được mục đích tấn công bằng cách gọi một hàm trong một vòng lặp.

Những gì được hiển thị ở đây là một chức năng rút tiền đơn giản. Cho phép người dùng để rút tiền gửi dựa trên số dư trong hợp đồng (userBalances). Có thể lưu ý rằng khi người gọi chức năng này là hợp đồng thông minh, thao tác rút tiền (msg.sender.call) sẽ kích hoạt chức năng nhận của hợp đồng thông minh và chuyển lượng gas còn lại vào. Tại thời điểm này, số dư của người dùng được ghi trong hợp đồng thông minh ban đầu chưa được đặt lại về 0 (userBalances[msg.sender] = 0). Kẻ tấn công có thể gọi lại chức năngrút tiền trong chức năng nhận và vượt qua lỗ hổng mà trạng thái số dư chưa được sửa đổi Mục đích của việc rút tiền nhiều lần đạt được cho đến khi hết gas hoặc hợp đồng trống.

Hiển thị biểu đồ luồng tấn công

Các phương pháp phòng ngừa là cũng rất đơn giản, miễn là số dư ghi trong hợp đồng thông minh được xóa trước và sau đó hành động chuyển tiền được thực hiện thì có thể tránh được cuộc tấn công.

2. Lỗ hổng tràn số nguyên

Trong hợp đồng thông minh Ethereum, uint256 là loại số nguyên phổ biến, có nghĩa là phạm vi số nguyên mà biến này có thể lưu trữ là 0 ~ 2^256 - 1. Giới hạn lưu trữ trên là khoảng giá trị 78 bit. Bạn có thể nghĩ rằng con số này đủ lớn, nhưng nó vẫn có thể được sử dụng để đạt được tình trạng tràn. Tức là khi giá trị của một biến là 2^256 - 1 và khi giá trị của biến này được thêm vào một, giá trị của nó sẽ trở thành 0 vì nó vượt quá giới hạn lưu trữ trên. Để tránh lỗ hổng này, chúng ta cần kiểm tra phạm vi số nguyên trước khi thực hiện các phép tính số nguyên và đưa ra một ngoại lệ ngay lập tức khi phát hiện thấy thao tác tràn.

3. Tấn công từ chối dịch vụ

Gián đoạn dịch vụ hợp đồng thông minh là một vấn đề nghiêm trọng vì một số lỗ hổng gây ra Dịch vụ mất điện là vĩnh viễn và không thể khôi phục được. Các nguyên tắc tấn công bao gồm: vô tình thực thi lệnh SELFDESTRUCT, lỗi cấp phép kiểm soát truy cập, giới hạn gas đạt đến giới hạn khối, khiến hợp đồng không hoạt động bình thường và ngoại lệ khai thác mà chúng tôi trình bày ở đây ném ra, khiến hợp đồng bị tê liệt vĩnh viễn .

Đây là một ví dụ đơn giản về hợp đồng đấu giá. Người trả giá cao có thể trở thành Người dẫn đầu hiện tại và ghi giá thầu là Giá thầu cao nhất. Đồng thời, số tiền đấu thầu trước đó được trả lại cho người đứng đầu đấu thầu trước đó. Kẻ tấn công có thể triển khai hợp đồng thông minh, biến hợp đồng trở thành Người dẫn đầu hiện tại sau khi đặt giá thầu thông thường và sử dụng chức năng hoàn nguyên trong chức năng nhận chịu trách nhiệm thu tiền thanh toán để đưa ra một ngoại lệ nhằm vô hiệu hóa giao dịch. Khi những người dùng khác muốn đặt giá thầu, giao dịch sẽ không thành công do hợp đồng không thể chuyển tiền cho Thủ lĩnh hiện tại (tức là hợp đồng đã được kẻ tấn công triển khai trước đó). Do đó, chức năng của hợp đồng đấu giá sẽ bị vô hiệu hóa vĩnh viễn và kẻ tấn công sẽ có thể để thắng cuộc đấu giá.

Ví dụ về hợp đồng của kẻ tấn công

4. Tx Cuộc tấn công vào lỗ hổng gốc

Khi các nhà phát triển sử dụng biến tx.origin tích hợp sẵn một cách chắc chắn để xác minh quyền, điều đó sẽ tạo cơ hội cho kẻ tấn công tấn công. Trước khi vào ví dụ, trước tiên bạn phải hiểu rằng tx.origin trả về địa chỉ của giao dịch ban đầu, trong khi msg.sender trả về người gửi của giao dịch hiện tại. Tình huống sơ đồ sau đây là:

Người dùng A gọi một hàm bên trong hợp đồng B, sau đó gọi hợp đồng C bên trong hàm đó. Bạn có thể quan sát sự khác biệt giữa tx.origin và msg.sender.

Chúng ta hãy xem kịch bản tấn công thực tế. Hàm sendTo trong hợp đồng thông minh ở trên phải đáp ứng các điều kiện là tx.origin và owner bằng nhau trước khi có thể thực thi. Tuy nhiên, kẻ tấn công có thể Hợp đồng thông minh trong hình bên dưới sử dụng sự khác biệt giữa tx.origin và msg.sender được đề cập ở trên để khéo léo bỏ qua xác minh và kích hoạt chức năng sendTo. Chi tiết cụ thể là khi kẻ tấn công xúi giục chủ sở hữu hợp đồng trong hình trên kích hoạt chức năng dự phòng của hợp đồng trong hình bên dưới, nếu hợp đồng tấn công gọi hàm sendTo trong chức năng dự phòng thì nó có thể nhận được sự cho phép của chủ sở hữu để thực thi.

5. Không xử lý đúng cách các cuộc gọi bên ngoài Giá trị trả về

Trong hợp đồng thông minh, khi sử dụng các hướng dẫn chức năng gọi cấp thấp, chẳng hạn như: address.call(), address.callcode(), address. delegatecall() và address.send(), v.v., nếu cuộc gọi không thành công, sẽ không có ngoại lệ nào được đưa ra, chỉ trả về giá trị Boolean của kết quả cuộc gọi và hợp đồng sẽ tiếp tục được thực thi. Nếu giá trị trả về của kết quả cuộc gọi không được kiểm tra, hợp đồng thông minh có thể không hoạt động bình thường.

Chúng ta lấy một hàm rút tiền đơn giản làm ví dụ. Khi sử dụng một hợp đồng để gọi hàm rút tiền trong hình trên, và nếu hợp đồng Khi không thể nhận được chuyển khoản ETH (ví dụ: khoản thanh toán không được đặt), người gọi sẽ không thể nhận ETH, nhưng vì hợp đồng sẽ tiếp tục được thực hiện nên bản ghi trạng thái số dư trong hợp đồng sẽ được thay đổi . Nội dung sửa đổi như sau:

6. Tấn công địa chỉ ngắn

Phương thức tấn công này xuất hiện chủ yếu Trong hợp đồng thông minh ERC-20 (Thỏa thuận tiêu chuẩn mã thông báo), trước tiên chúng ta phải hiểu rằng khi chúng ta gọi một hàm, EVM (Máy ảo Ethereum) thực sự đang phân tích cú pháp một loạt ký tự ABI (Giao diện nhị phân ứng dụng). Thông thường, token tiêu chuẩn ERC-20 sẽ thực hiện chức năng chuyển để chuyển, khi chúng ta gọi hàm chuyển, nội dung lệnh gọi giao dịch gồm 3 phần:

● 4 byte, giá trị băm của tên hàm, ví dụ: a9059cbb

● 32 byte, địa chỉ Ethereum (địa chỉ là 20 byte, phần đệm Zero bit cao), ví dụ:

0000000000000000000000011223344556677889900aabbccddeeff11223344

● 32 byte, biểu thị dữ liệu cần được chuyển Số lượng mã thông báo :

901234567800 (kết thúc số 0) và cố tình loại bỏ số 0 ở cuối khi gọi chuyển. Nếu định dạng nội dung không được kiểm tra trong hợp đồng, EVM sẽ bổ sung 00 từ bit cao của tham số thứ ba (số lượng mã thông báo), điều này sẽ gây ra Số lượng mã thông báo thực tế cần chuyển bị thiếu một byte, nghĩa là nó bị dịch sang trái 8 bit và giá trị ngay lập tức được mở rộng gấp 256 lần. Kẻ tấn công đã đánh cắp thành công các mã thông báo trong hợp đồng mã thông báo.

7. Tấn công cho vay nhanh

Cho vay nhanh, như tên cho thấy, là một cách nhanh chóng vay thì nhanh thế nào?Nhanh thế nào? Lời giải thích chính thức là các giao dịch phát hành và trả nợ phải được hoàn thành trong cùng một khối trên Ethereum. Có thể nói, flash loan là một sự đổi mới mang tính đột phá với sự trợ giúp của công nghệ blockchain, nó có hai điểm khác biệt chính so với cho vay truyền thống, một là không yêu cầu tài sản thế chấp, hai là yêu cầu khoản vay phải được thực hiện tại địa điểm cùng thời gian.Hoạt động trả nợ được thực hiện trong một giao dịch nên bên cho vay không phải chịu rủi ro vỡ nợ, bởi vì chỉ khi hoạt động cho vay và trả nợ do người đi vay thực hiện trên blockchain thực sự được thực hiện thì giao dịch mới được thực hiện. hiệu quả. Nói cách khác, chúng ta có thể thiết kế một hợp đồng thông minh để cho vay tiền, sau đó thực hiện một số hoạt động quỹ và cuối cùng trả lại tiền và các hoạt động này sẽ được hoàn thành trong cùng một giao dịch. Điều này tạo cơ hội cho tin tặc sử dụng các khoản vay flash để thực hiện các cuộc tấn công vì nó giúp giảm đáng kể chi phí cho các cuộc tấn công của tin tặc. sự khác biệt trong thỏa thuận và chênh lệch giá, rồi bỏ trốn với số lợi nhuận bất chính sau khi hoàn trả. Chúng ta tìm hiểu ý tưởng tấn công của hacker từ vụ tấn công bZx:

1. Tin tặc đã vay 10.000 ETH từ nền tảng giao dịch phái sinh tài sản kỹ thuật số phi tập trung dYdX thông qua khoản vay nhanh

2. Sử dụng 5.000 ETH để thế chấp trên nền tảng cho vay phi tập trung Hợp chất để cho vay 112 wBTC (BTC được bọc, tài sản chuỗi chéo BTC trên Ethereum)

3. 5.000 ETH còn lại được sử dụng để mở lệnh bán wBTC trên nền tảng cho vay phi tập trung bZx

4. Sử dụng 112 wBTC cho vay để bán trên sàn giao dịch phi tập trung Uniswap, khiến giá wBTC giảm nhanh

Hàng loạt hoạt động này đã khiến hacker kiếm được lợi nhuận khổng lồ từ vị thế bán khống mở trên bZx, sau đó trả lại 10.000 ETH đã cho vay bằng khoản vay nhanh và trong quá trình đó đã nhận được khoản lợi nhuận trị giá 350.000 USD. Nguyên nhân chính của cuộc tấn công này là do sự thay đổi mạnh mẽ về giá của Uniswap cuối cùng đã dẫn đến việc mất tài sản, lẽ ra đây là hành vi bình thường của thị trường nhưng tin tặc đã thao túng thị trường một cách ác ý, gây thiệt hại cho phía dự án. Việc thao túng hợp đồng bZx đã thu hút sự chú ý của nhiều nhà phát triển hơn. Một mặt, nhiều nhà phát triển thông minh đã phát triển các ứng dụng tài chính phi tập trung mới, đồng thời, nó cũng khiến các nhà phát triển cảnh giác hơn với các cuộc tấn công logic có thể xảy ra.

Kết luận

Hoạt động của hợp đồng thông minh là thụ động và mọi hành động theo hợp đồng phải được thực hiện bởi Chỉ khi người dùng thực hiện giao dịch và gọi chức năng trong hợp đồng thì hành động đó mới được thực thi. Việc thực hiện hợp đồng là không thể đảo ngược dựa trên đặc điểm của blockchain. Khi hợp đồng được triển khai trên blockchain, mọi thông tin đều được mở và minh bạch, ngay cả khi mã không phải là Nguồn mở, bạn cũng có thể sử dụng các công cụ tháo gỡ để đẩy lùi nội dung hợp đồng. Do đó, các nhà phát triển cần phải làm quen với các nguyên tắc về lỗ hổng và tránh chúng, đồng thời người dùng cũng nên hiểu các vấn đề bảo mật hợp đồng và bảo vệ quyền và lợi ích của chính mình.

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia