Việc phát minh ra hợp đồng thông minh Ethereum cho phép người dùng blockchain tùy chỉnh logic tính toán trong các giao dịch. Tuy nhiên, tương tự như các chương trình máy tính truyền thống, hợp đồng thông minh cũng có những kẽ hở, có thể bị lợi dụng để gây thiệt hại tài chính cho chủ sở hữu hợp đồng. Mặc dù có nhiều công cụ phần mềm để phát hiện lỗ hổng trong mã byte hợp đồng thông minh, nhưng rất ít công cụ tập trung vào giao dịch. Trong bài viết này, TXSPECTOR được đề xuất, đây là một khuôn khổ có mục đích chung, hướng logic để nghiên cứu các giao dịch Ethereum nhằm phát hiện tấn công. Ở cấp độ cao hơn, TXSPECTOR phát lại các giao dịch lịch sử và ghi lại dấu vết ở cấp độ bytecode EVM, sau đó mã hóa điều khiển và các phụ thuộc dữ liệu thành các mối quan hệ logic. TXSPECTOR không cần thiết lập bộ tính năng được xác định trước, nhưng cho phép người dùng chỉ định các quy tắc tùy chỉnh để phát hiện ra nhiều loại tấn công khác nhau trong giao dịch.
Một nguyên mẫu của TXSPECTOR đã được xây dựng và đánh giá để phát hiện ba cuộc tấn công Ethereum khai thác lỗ hổng này: (i) Lỗ hổng Re-entrancy, (ii) Lỗ hổng Cuộc gọi không được kiểm tra và ( iii) Sơ hở tự sát.
Kết quả cho thấy TXSPECTOR có thể phát hiện hiệu quả các cuộc tấn công trong các giao dịch và như một sản phẩm phụ để phát hiện các lỗ hổng tương ứng trong các hợp đồng thông minh. Nó cũng cho thấy cách TXSPECTOR có thể được sử dụng để phân tích pháp y các giao dịch và các quy tắc phát hiện được đề xuất để phát hiện các loại tấn công khác ngoài ba cuộc tấn công Ethereum.
0x01 Giới thiệu
Ethereum là một trong những nền tảng máy tính phi tập trung công cộng lớn nhất được xây dựng trên công nghệ blockchain. So với mạng Bitcoin, Ethereum không chỉ hỗ trợ các giao dịch đơn giản mà còn cung cấp các chức năng tính toán hoàn chỉnh của Turing dưới dạng hợp đồng thông minh. Giống như nhiều chương trình phần mềm khác, một ngôn ngữ lập trình cấp cao như Solidity có thể được sử dụng để phát triển các hợp đồng thông minh, sau đó được biên dịch thành bytecode và sau đó được thực thi trong Máy ảo Ethereum (EVM) cho mỗi nút của nút ngang hàng Mạng ngang hàng (P2P). So với mạng blockchain thế hệ đầu tiên, khả năng thực thi các hợp đồng thông minh phức tạp đã trở thành một chức năng chính của Ethereum.
Tuy nhiên, tính khả dụng cao hơn cũng mang lại rủi ro lớn hơn. Hai chức năng làm cho các hợp đồng thông minh dễ bị tấn công phần mềm hơn các chương trình phần mềm truyền thống.
(I) Hợp đồng thông minh không thay đổi sau khi được triển khai. Bất kỳ sổ cái phân tán bất biến nào cũng cần tính năng này. Do đó, các lỗ hổng trong hợp đồng thông minh không thể được vá, vì vậy chúng không thể dễ dàng được vá.
(Ii) Ethereum được thúc đẩy bởi tiền điện tử; nhiều hợp đồng thông minh phổ biến cũng liên quan đến việc chuyển đổi cryp thành tiền tệ. Do đó, việc sử dụng các hợp đồng thông minh thường dẫn đến tổn thất tài chính lớn.
Ví dụ, trong vụ tấn công DAO khét tiếng, kẻ tấn công đã khai thác một lỗ hổng bảo mật trong hợp đồng DAO và đánh cắp hơn 50 triệu đô la. Một ví dụ khác, một lỗ hổng trong Parity MultisigWallet đã gây ra thiệt hại hơn 30 triệu đô la. Nhiều trường hợp tấn công như vậy đã gây ra những lo ngại nghiêm trọng về tính bảo mật của các hợp đồng thông minh Ethereum.
Do sự phổ biến của Ethereum, mọi người đã làm việc chăm chỉ để hiểu và phát hiện các lỗ hổng hợp đồng thông minh này, chẳng hạn như nhập lại và tràn số nguyên, đồng thời sử dụng các kỹ thuật như thực thi biểu tượng để phân tích hợp đồng thông minh hoặc xác minh chính thức để xác minh tính đúng đắn của chúng. Tuy nhiên, việc sử dụng phân tích tĩnh hoặc biểu tượng trên các hợp đồng thông minh để xác định các lỗ hổng có hai hạn chế. Đầu tiên, rất khó để các công cụ này đạt được sự hoàn chỉnh và chính xác cùng một lúc.
Ví dụ: các công cụ sử dụng thực thi tượng trưng sẽ gặp phải sự cố bùng nổ đường dẫn và các công cụ hiện có không thể phát hiện các lỗ hổng liên quan đến nhiều hợp đồng thông minh. Thứ hai, các công cụ này không thể được sử dụng để kiểm tra và hiểu các cuộc tấn công Ethereum trong thế giới thực. Thông tin pháp lý, chẳng hạn như phương pháp tấn công và số liệu thống kê, địa chỉ được sử dụng bởi kẻ tấn công và địa chỉ của nạn nhân, chỉ có thể được biết từ giao dịch. Bằng cách này, các công cụ có thể thực hiện phân tích mức bytecode đối với các giao dịch có thể kết hợp những ưu điểm của hai khía cạnh, để phát hiện và phân tích hiệu quả các cuộc tấn công và lỗ hổng trong Ethereum.
Trong bài viết này, tôi đã giới thiệu TXSPECTOR, một khung phân tích chung cho các giao dịch Ethereum, được sử dụng để xác định các cuộc tấn công thực sự chống lại các hợp đồng thông minh trong các giao dịch và tiến hành phân tích pháp y. Ý tưởng chính của TXSPECTOR là phát hiện các cuộc tấn công vào các hợp đồng thông minh thông qua phân tích chương trình dựa trên logic của các giao dịch Ethereum. Thiết kế được lấy cảm hứng từ VANDAL, là một công cụ phân tích tĩnh cho EVM bytecode dựa trên Soufflé. Tuy nhiên, có hai thách thức đối với việc phân tích theo hướng logic của việc thực hiện giao dịch: Thứ nhất, các phương pháp mới cần được phát triển để trích xuất dữ liệu và kiểm soát các yếu tố phụ thuộc trong các giao dịch Ethereum và mã hóa chúng thành các mối quan hệ logic. Thứ hai, mặc dù số lượng hợp đồng thông minh ít nhưng khối lượng giao dịch là rất lớn. Do đó, theo dõi và phân tích các giao dịch Ethereum đòi hỏi các phương pháp sáng tạo để tối ưu hóa hiệu suất.
TXSPECTOR giải quyết những thách thức này: Đầu tiên, nó phát lại các giao dịch trên blockchain và ghi lại các dấu vết cấp bytecode của việc thực hiện giao dịch. Khi các giao dịch mới được thêm vào blockchain, việc phát lại giao dịch có thể được thực hiện đầy đủ ngay lập tức hoặc dần dần. Để tránh công việc lặp đi lặp lại, một cơ sở dữ liệu theo dõi thực thi cấp bytecode được thiết lập, có thể được sử dụng lại. Thứ hai, nó xây dựng một biểu đồ luồng thực thi (EFG) để mã hóa điều khiển và các phụ thuộc dữ liệu. Thứ ba, nó trích xuất các mối quan hệ logic từ EFG và lưu trữ chúng trong cơ sở dữ liệu. Thứ tư, nó sử dụng các quy tắc logic dành riêng cho người dùng (được gọi là “quy tắc phát hiện”) để truy vấn cơ sở dữ liệu. TXSPECTOR hỗ trợ các quy tắc phát hiện tùy ý do người dùng xác định, cho phép họ nghiên cứu bất kỳ khía cạnh nào họ quan tâm. TXSPECTOR là khuôn khổ chung đầu tiên thực hiện phân tích mức bytecode, theo hướng logic của các giao dịch Ethereum. Để đơn giản hóa việc nghiên cứu tiếp theo phân tích liên quan đến giao dịch, TXSPECTOR được cung cấp cho cộng đồng nghiên cứu theo giấy phép nguồn mở của https://github.com/OSUSecLab/TxS Inspector.
Nền 0x02
Hợp đồng thông minh là một chương trình toàn cầu được thực thi trên blockchain. Nó có thể sử dụng ba vùng nhớ để thực hiện các thao tác dữ liệu trong quá trình thực thi: ngăn xếp, bộ nhớ và lưu trữ. Ngăn xếp (dữ liệu) là một ngăn xếp ảo có thể được sử dụng để lưu trữ dữ liệu. Xin lưu ý rằng EVM cũng có ngăn xếp cuộc gọi, khác với ngăn xếp dữ liệu. Bộ nhớ là một vùng địa chỉ byte được cấp phát trong thời gian chạy. Bộ nhớ là bộ lưu trữ khóa-giá trị ánh xạ các từ 256 bit thành các từ 256 bit. Cả ngăn xếp và bộ nhớ đều dễ bay hơi, có nghĩa là dữ liệu được lưu trữ sẽ bị xóa sau mỗi lần thực thi. Tuy nhiên, việc lưu trữ liên tục và có thể được sử dụng để lưu trữ dữ liệu giữa các giao dịch. Do đó, giá khí đốt tự nhiên được sử dụng cho hoạt động lưu trữ cao hơn nhiều so với hoạt động chất xếp và lưu trữ.
Hiện tại, EVM hỗ trợ hơn 150 OPCODE. Theo mục tiêu của hoạt động hướng dẫn, chúng có thể được chia thành năm loại:
• Loại 1: OPCODE không hoạt động trên bất kỳ cấu trúc dữ liệu nào (chẳng hạn như JUMPDEST).
• Loại 2: OPCODE thực hiện các hoạt động ngăn xếp (chẳng hạn như PUSHx) hoặc hoạt động trên các giá trị hiện có trong ngăn xếp (chẳng hạn như ADD).
• Loại 3: OPCODE để lấy thông tin từ blockchain (ví dụ: TIMESTAMP) hoặc giao dịch hiện tại (ví dụ: ORIGIN).
• Loại 4: OPCODE cho bộ nhớ đọc / ghi (chẳng hạn như MSTORE).
• Loại 5: Đọc / ghi OPCODE được lưu trữ (chẳng hạn như SSTORE).
Tương tự như Bitcoin, Ethereum cũng có một mạng P2P được duy trì bởi các nhân viên Ethereum (các nút). Để gửi một giao dịch, người dùng cần phải trả một khoản phí gọi là gas để khuyến khích nhân viên Ethereum thực hiện giao dịch. Gas được đo bằng Ether (một loại tiền điện tử liên quan đến Ethereum). Lượng gas cần thiết cho mỗi giao dịch được tính toán dựa trên các mã opcodes mà nó chứa. Nếu không có đủ tiền để thực hiện giao dịch, việc thực hiện sẽ bị hủy bỏ và tất cả các thay đổi sẽ được hoàn nguyên. Tuy nhiên, ether được sử dụng trong quá trình này sẽ không được hoàn lại. Việc sử dụng Gas cũng có thể ngăn chặn các giao dịch độc hại (ví dụ: giao dịch có vòng lặp vô hạn) gây hại cho mạng.
Ethereum có hai loại tài khoản: tài khoản sở hữu bên ngoài (EOA) và tài khoản hợp đồng (tức hợp đồng thông minh). Cả hai loại tài khoản đều có thể thực hiện chuyển ether. Sự khác biệt chính giữa chúng là các hợp đồng thông minh có các mã byte liên kết có thể được thực thi, trong khi EOA không có bất kỳ mã nào. Trong Ethereum, các giao dịch được kích hoạt bởi EOA. Có ba loại giao dịch:
• Loại 1: Chuyển Ether giữa EOA;
• Loại 2: Triển khai các hợp đồng thông minh mới trên Ethereum;
• Loại 3: Thực hiện các chức năng của hợp đồng đã triển khai.
Các giao dịch chuyển Ethereum không liên quan đến hợp đồng thông minh; nghĩa là không có mã nào sẽ được thực thi khi các giao dịch này được xử lý. Tuy nhiên, để triển khai các hợp đồng thông minh mới hoặc thực thi các chức năng của hợp đồng thông minh, EVM cần thực thi các mã byte liên quan.
Tương tự như các chương trình máy tính truyền thống, hợp đồng thông minh cũng có lỗi. Một số trong số chúng có thể bị khai thác bởi những kẻ tấn công ác ý. Những lỗi này được gọi là lỗ hổng. Nhiều lỗ hổng đã được phát hiện trong các hợp đồng thông minh. Để khai thác các lỗ hổng này, những kẻ tấn công cần phát triển các hợp đồng thông minh và giao dịch với các hợp đồng dễ bị tấn công. Do đó, cuộc tấn công có liên quan đến một giao dịch cụ thể, và nguyên nhân sâu xa của cuộc tấn công là lỗ hổng của hợp đồng thông minh.
Tổng quan về TXSPECTOR 0x03
Mục tiêu: TXSPECTOR là một khung phần mềm được sử dụng để thực hiện phân tích theo hướng logic của các giao dịch Ethereum nhằm phát hiện ra các cuộc tấn công và lỗ hổng bảo mật với ba mục tiêu. Đầu tiên, nó được thiết kế như một khung phân tích chung cho các giao dịch Ethereum, không được thiết kế để phát hiện các cuộc tấn công cụ thể trong Ethereum. Vì lý do này, nó dần dần biến giao dịch thành trừu tượng mà không làm mất thông tin quan trọng của giao dịch ban đầu. Thứ hai, nó linh hoạt và có thể được mở rộng sang nhiều khía cạnh của phân tích giao dịch thông qua các quy tắc phát hiện tùy chỉnh, thậm chí bao gồm cả phân tích không liên quan đến bảo mật. Thứ ba, TXSPECTOR cũng được thiết kế với hiệu suất cao. Mặc dù không thể thực hiện phát hiện cuộc tấn công chung trong thời gian thực bằng cách sử dụng khuôn khổ theo hướng logic, nhưng các nỗ lực đã được thực hiện để giảm đáng kể chi phí lưu trữ và hiệu suất của phân tích bằng TXSPECTOR.
Phạm vi: Trọng tâm của TXSPECTOR là phát hiện các cuộc tấn công vào các giao dịch Ethereum dựa trên các quy tắc phát hiện đã cho. Vì việc thực thi giao dịch về cơ bản thực hiện các đoạn mã bytecode từ nhiều hợp đồng thông minh, TXSPECTOR cũng có thể hiển thị các lỗ hổng hợp đồng thông minh dưới dạng sản phẩm phụ. Do đó, TXSPECTOR có thể xác định các cuộc tấn công xảy ra trong blockchain thông qua các giao dịch và các hợp đồng thông minh dễ bị tổn thương liên quan đến giao dịch. Tuy nhiên, TXSPECTOR không được thiết kế để phát hiện các lỗ hổng trong các hợp đồng thông minh, vốn được nhắm mục tiêu bởi hầu hết các công cụ phân tích tĩnh.
Tổng quan: TXSPECTOR bao gồm bốn thành phần (ở trên). Trình trích xuất dấu vết thực hiện các giao dịch Ethereum và tạo dấu vết cấp bytecode, được lưu trữ trong cơ sở dữ liệu theo dõi (DB) để xử lý thêm. Sau đó, trình tạo đồ thị luồng thực thi phân tích cú pháp thông tin theo dõi mức bytecode để xây dựng một đồ thị luồng thực thi (EFG). Trình tạo quan hệ logic truyền qua EFG này để trích xuất dữ liệu và điều khiển các phần phụ thuộc, sau đó biểu thị chúng dưới dạng quan hệ logic, được lưu trữ trong cơ sở dữ liệu quan hệ logic. Cuối cùng, bộ phát hiện tấn công lấy các quy tắc phát hiện được người dùng chỉ định làm đầu vào để truy vấn cơ sở dữ liệu quan hệ logic và xuất báo cáo tấn công cuối cùng.
0x04 Trace Extractor
Công cụ trích xuất dấu vết thực hiện các giao dịch Ethereum trong Máy ảo Ethereum (EVM) và ghi lại các dấu vết cấp bytecode trong quá trình thực thi. Theo dõi mức bytecode là một chuỗi gồm ba lần. Đối với mỗi OPCODE của mã bytecode được EVM thực thi, Trace Extractor ghi lại bộ đếm chương trình (PC), OPCODE và các đối số của nó (ARGS) trong EVM thành một bộ ba {<PC>; <OPCODE>; Trong <ARGS>}, PC được sử dụng để xác định OPCODE theo vị trí tương đối trong bytecode. Để giảm dư thừa dữ liệu, Trace Extractor chỉ ghi lại các tham số không được tạo ra từ ngăn xếp. Bởi vì một giao dịch có thể gián tiếp gọi nhiều hợp đồng thông minh, nên có thể tạo ra một dấu vết thực thi cấp bytecode duy nhất từ việc thực hiện một hoặc nhiều hợp đồng thông minh. Siêu dữ liệu của giao dịch cũng được ghi lại, chẳng hạn như địa chỉ của người nhận giao dịch và dấu thời gian của giao dịch.
Để phát lại các giao dịch Ethereum và thu thập dấu vết, Go-Ethereum EVM (phiên bản 1.8.0) đã được sửa đổi để trích xuất dấu vết giao dịch và lưu trữ chúng trong Trace DB cùng với siêu dữ liệu có liên quan. Không phải tất cả các mã opcodes đều cần được ghi lại. Các giao dịch loại 1 là các giao dịch giữa các EOA và không có mã bytecode nào được liên kết với nó. Do đó, công cụ trích xuất dấu vết chỉ ghi lại các giao dịch loại 2 và loại 3.
Sửa đổi Go-Ethereum EVM: Để ghi lại theo dõi giao dịch, Go Ethereum EVM được sửa đổi để ghi lại thông tin liên quan đến OPCODE. Cụ thể hơn, EVM được sửa đổi ghi lại ba thông số OPCODE sau:
• Hoạt động liên quan đến blockchain / giao dịch (loại 3). Loại này bao gồm OPCODE cần lấy dữ liệu từ blockchain hoặc giao dịch hiện tại. Ví dụ: TIMESTAMP lấy dấu thời gian Unix của khối hiện tại; CALLER truy xuất địa chỉ của người gọi.
• Hoạt động liên quan đến bộ nhớ / lưu trữ (loại 4 và 5). Ở đây, trình trích xuất dấu vết chỉ ghi lại các OPCODE đọc dữ liệu từ bộ nhớ / lưu trữ, cụ thể là MLOAD và SLOAD. Xin lưu ý rằng không cần ghi lại các tham số của MSTORE và SSTORE, vì chúng chỉ cần dữ liệu từ ngăn xếp và những dữ liệu này có thể được lấy từ các phần khác của dấu vết.
• Hoạt động PUSH. Loại này bao gồm tất cả PUSH OP CODE, cụ thể là PUSHi, i = 1, ···, 32.
Đối với OPCODE còn lại, nó chỉ ghi giá trị PC và OPCODE, vì không cần ghi tham số.
Dấu vết mẫu: Dấu vết được ghi lại bởi bộ trích xuất dấu vết tương tự như mã bytecode EVM được tháo rời. Cụ thể, dấu vết là một chuỗi bộ ba, {<PC>; <OPCODE>; <ARGS>}. Đoạn mã theo dõi giao dịch được hiển thị trong Danh sách 1. Sự khác biệt chính giữa mã bytecode được truy tìm và tháo rời là dấu vết được ghi lại cũng chứa các giá trị thực tế được sử dụng trong giao dịch.
Cơ sở dữ liệu theo dõi: Cơ sở dữ liệu theo dõi lưu trữ theo dõi mức bytecode và siêu dữ liệu liên quan khi thực hiện các giao dịch. Cụ thể, mỗi dấu vết của giao dịch có thể liên quan đến nhiều hợp đồng thông minh, vì nhiều hợp đồng thông minh có thể được gọi và siêu dữ liệu bao gồm thông tin sau:
(I) Người gửi giao dịch (tức là người gửi giao dịch),
(Ii) Người nhận giao dịch (tức là người nhận),
(Iii) Dấu thời gian của giao dịch (tức là ngày và giờ giao dịch được chứa trong một khối).
Trình tạo biểu đồ luồng thực thi 0x05
Để thể hiện luồng điều khiển rõ ràng hơn, trình tạo đồ thị luồng thực thi sẽ xây dựng một đồ thị luồng thực thi (EFG) để mã hóa thông tin luồng điều khiển và dữ liệu của quỹ đạo thành một đồ thị. Vì theo dõi cấp bytecode được tạo từ các giao dịch, không có chi nhánh nào chưa được giải quyết trong EFG. Do đó, quá trình thực thi trong mỗi hợp đồng thông minh là tuần tự. Một nút trong EFG đại diện cho việc thực hiện hợp đồng thông minh, chứa theo dõi thực thi cấp bytecode do hợp đồng tạo ra. Cạnh trong EFG đại diện cho việc chuyển luồng kiểm soát từ hợp đồng thông minh này sang hợp đồng thông minh khác.
Trình tạo biểu đồ luồng thực thi phân tích các dấu vết mức bytecode để xây dựng đồ thị luồng thực thi (EFG). Vì dấu vết được tạo động nên không có nhánh nào chưa được giải quyết và mỗi JUMP chỉ có một mục tiêu. Các nút và cạnh trong EFG được tạo theo cách sau:
• Nút: Khi quá trình thực thi được thay đổi từ hợp đồng thông minh này sang hợp đồng thông minh khác, trình tạo lưu đồ thực thi sẽ tạo ra một nút mới. Cụ thể, khi gặp các mã opc liên quan đến CALL, cụ thể là CALL / DELEGATECALL / CALLCODE / STATICCALL hoặc các mã liên quan đến STOP, cụ thể là STOP / REVERT / RETURN, một nút mới sẽ được tạo.
• Cạnh: Khi luồng thực thi được chuyển từ hợp đồng thông minh này sang hợp đồng thông minh khác, trình tạo biểu đồ luồng thực thi sẽ tạo ra một cạnh đại diện cho luồng kiểm soát giữa hai nút. Có hai loại cạnh: Cạnh loại I là một cạnh từ hợp đồng người gọi đến hợp đồng callee. Cạnh loại II là một cạnh từ hợp đồng người gọi đến hợp đồng người gọi.
Ví dụ EFG liên quan đến ba hợp đồng thông minh được hiển thị trong hình trên: Hợp đồng thông minh A (nút a) lần đầu tiên gọi hợp đồng thông minh B (nút b), tạo các cạnh loại I và chuyển luồng thực thi sang hợp đồng thông minh B. Khi hợp đồng thông minh B hoàn thành việc thực thi, nó quay trở lại hợp đồng thông minh A (nút c) để tạo các cạnh loại II. EFG kết thúc ở nút c.
Để phân tích dấu vết thực thi liên quan đến nhiều hợp đồng thông minh, mỗi 3 bộ trong dấu vết ban đầu được tăng lên thành 6 bộ: {<PC>; <OPCODE>; <ARGS>; <idx>; <depth>; <callnum >}. Xác định idx, độ sâu và callnum như sau:
• Idx: Vì các hợp đồng khác nhau có cùng giá trị PC, nên không thể đánh giá OPCODE nào được thực thi đầu tiên từ giá trị PC của nó. Do đó, tham số idx được giới thiệu cho mỗi opcode để chỉ ra chỉ mục của opcode hiện tại trong EFG.
• độ sâu: Khi xử lý các dấu vết với một số lượng lớn các cuộc gọi bên ngoài, điều quan trọng là phải biết mỗi OPCODE đang ở cấp độ cuộc gọi nào. Vì lý do này, độ sâu được giới thiệu, mô tả độ sâu gọi của mỗi OPCODE trong EFG. Khi nó gặp OPCODE liên quan đến cuộc gọi, độ sâu tăng lên 1; khi nó quay trở lại, độ sâu giảm đi 1.
• Callnum: Số cuộc gọi biểu thị số lượng cuộc gọi đã xảy ra trước mỗi OPCODE trong EFG. Nó là một giá trị không giảm: nó sẽ tăng 1 khi nó gặp OPCODE liên quan đến cuộc gọi.
0x06 Trình tạo mối quan hệ logic
Trình tạo quan hệ logic trước tiên phân tích cú pháp EFG để xây dựng một biểu diễn trung gian (IR) phù hợp cho phân tích, và sau đó trích xuất các quan hệ logic thể hiện ngữ nghĩa giao dịch bằng cách xác định các quy tắc logic. Sau đó, mối quan hệ logic được lưu trữ trong cơ sở dữ liệu. Đặc biệt, các quy tắc logic được định nghĩa để thể hiện luồng điều khiển và thông tin luồng dữ liệu nhằm đạt được sự phụ thuộc dữ liệu và điều khiển trong các giao dịch. Ví dụ, một số quy tắc quy định thứ tự thực thi của các mã quang, có liên quan đến luồng điều khiển. Một số quy tắc theo dõi cách xác định và sử dụng các tham số OPCODE, có liên quan đến luồng dữ liệu. Để đạt được mục đích này, Logic RelationBuilder tạo ra các quan hệ logic cho mỗi OPCODE, chẳng hạn như thanh ghi đại diện cho toán hạng và giá trị PC của nó, đồng thời liên kết giá trị thực trong giao dịch với thanh ghi để nắm bắt thông tin động. Điều khiển và phụ thuộc dữ liệu được mã hóa thành các mối quan hệ logic, sau đó được tổ chức và lưu trữ trong cơ sở dữ liệu.
Chuyển đổi EFG dựa trên theo dõi thành IR: TXSPECTOR sử dụng đặc tả IR trong VANDAL. IR này là một ngôn ngữ dựa trên thanh ghi, là một dạng khác để thể hiện mối tương quan giữa dữ liệu và điều khiển. IR sử dụng các thanh ghi thay vì các hoạt động ngăn xếp. Ví dụ: Danh sách 2 hiển thị IR tương ứng của phân đoạn theo dõi mẫu trong Danh sách 1. Vì vậy, VANDAL đã được mở rộng ở hai khía cạnh sau: Thứ nhất, cần phải xử lý các giá trị thực hơn là các giá trị biểu tượng. Điều này đạt được trong Logic Relation Builder bằng cách sử dụng các thanh ghi có giá trị thực để mô phỏng hoạt động ngăn xếp EVM, để các giá trị của các thanh ghi được cập nhật tương ứng và tất cả các giá trị trung gian được ghi lại một cách chính xác. Đây là bước then chốt để nắm bắt mọi thông tin động trong quá trình thực hiện giao dịch mà các công cụ phân tích tĩnh không thể thực hiện được. Ví dụ, khi xử lý TIMESTAMP, giá trị dấu thời gian thực được ghi trong dấu vết mức bytecode sẽ được đẩy lên ngăn xếp và được gán cho các thanh ghi liên quan của nó. Thứ hai, bạn cần xử lý các cuộc gọi giữa các hợp đồng. Đối với cạnh hình chữ I trong EFG, ngăn xếp hiện tại sẽ được niêm phong và ngăn xếp trống sẽ được tạo. Đối với các cạnh loại II trong EFG, ngăn xếp hiện tại sẽ bị xóa và ngăn xếp được niêm phong cuối cùng sẽ được khôi phục.
Tạo mối quan hệ logic từ IR: Lấy cảm hứng từ VANDAL, TXSPECTOR áp dụng và mở rộng các quy tắc logic của nó để xử lý giá trị thực và theo dõi nhiều hợp đồng thông minh. Các quy tắc được sử dụng trong TXSPECTOR được hiển thị trong hình trên. Ví dụ, quan hệ op liên kết OPCODE với pc và idx của nó. Giá trị thực tế được sử dụng trong giao dịch được trích xuất thông qua mối quan hệ giá trị, nó ghi lại sổ đăng ký và các giá trị liên quan. Mỗi opcode và các thanh ghi liên quan của nó cũng được trích xuất thành các mối quan hệ logic. Ví dụ: mối quan hệ logic của SSTORE ghi lại tất cả các SSTORE trong EFG và các bộ giá trị liên quan của chúng ({pc, register, idx, depth, callnum}).
Một ví dụ về mối quan hệ logic được liệt kê trong bảng trên. Ví dụ này đại diện cho PUSH1 OPCODE của EFG được thể hiện trong Hình 2. Dòng 3 và 4 là từ nút b, có độ sâu đã được thay đổi từ 1 thành 2 và callnum đã được thay đổi từ 0 thành 1. Dòng 5 xuất phát từ nút c. Kể từ khi cuộc gọi quay trở lại, độ sâu của nó đã thay đổi từ 2 thành 1, nhưng callnum của nó vẫn giữ nguyên và số lượng cuộc gọi không thay đổi.
Máy dò tấn công 0x07
Bộ phát hiện tấn công là thành phần chính của TXSPECTOR. Nó lấy các quy tắc truy vấn do người dùng chỉ định (được gọi là “quy tắc phát hiện”) làm đầu vào và truy vấn DB quan hệ logic được tạo bởi Logic RelationBuilder để suy ra tính bảo mật cụ thể của giao dịch. Khi cơ sở dữ liệu quan hệ lôgic được tạo, nó có thể được sử dụng cho các kiểu phân tích khác nhau. Không cần phải xây dựng lại cơ sở dữ liệu mới cho mỗi quy tắc phát hiện. Đối với một truy vấn cụ thể, đầu ra không phải là câu trả lời có hoặc không đơn giản. Thay vào đó, thông tin chi tiết về cuộc tấn công (nếu bị phát hiện) cũng được cung cấp để phân tích thêm.
Chọn sử dụng Soufflé để xây dựng bộ phát hiện tấn công, đây là công cụ truy vấn Datalog mới nhất có hiệu suất cao. Do đó, trong TXSPECTOR, các quy tắc phát hiện được viết bằng Soufflé, là một biến thể của ngôn ngữ Datalog. Trong phần này, chúng tôi sẽ giải thích cách xây dựng các quy tắc phát hiện để sử dụng ba ví dụ để phát hiện các cuộc tấn công trong giao dịch: lần truy cập gần đây, cuộc gọi không được kiểm tra và tự sát.
1) Quy tắc tấn công vào lại
Mô tả: Cuộc tấn công reentry là một trong những cuộc tấn công nghiêm trọng nhất. Nó nhắm vào các hợp đồng thông minh Ethereum vì hợp đồng thông minh đầu vào có thể chuyển Ether nhiều lần. Khi hợp đồng A gọi hợp đồng B, hợp đồng B có thể tái ký hợp đồng A một lần nữa trong cùng một giao dịch. Nếu hợp đồng B là độc hại, nó có thể sử dụng trạng thái trung gian của hợp đồng A (ví dụ: số dư tài khoản đã hết hạn) để đánh cắp Ether từ A. Các cuộc tấn công như vậy được gọi là các cuộc tấn công vào lại bởi vì chúng được gây ra bởi việc nhập lại hợp đồng của người gọi (hợp đồng A) trong cùng một giao dịch. Cuộc tấn công reentry khét tiếng nhất là cuộc tấn công DAO, trong đó kẻ tấn công đánh cắp một lượng lớn Ether (trị giá hơn 50 triệu đô la) từ hợp đồng DAO.
Mục đích là thiết kế các quy tắc phát hiện để phát hiện các cuộc tấn công thử lại nâng cao được đề cập trong SEREUM. Nếu trạng thái thay đổi sau khi nhập lại và quay trở lại hợp đồng nạn nhân (tức là cập nhật biến lưu trữ) và biến lưu trữ này ảnh hưởng đến quyết định luồng điều khiển khi vào lại hợp đồng nạn nhân, nó sẽ gây ra trạng thái không nhất quán.
Yêu cầu: Giả sử hợp đồng A là nạn nhân và hợp đồng B là kẻ tấn công. Bốn giai đoạn được xác định:
• Giai đoạn 1: A thực hiện mã của nó (giai đoạn 1.1) và gọi B (giai đoạn 1.2); B gọi A một lần nữa để nhập lại A (giai đoạn 1.3). A được nhập lại được biểu diễn là A ‘;
• Giai đoạn 2: A’thực thi mã của nó trước khi quay trở lại B;
• Giai đoạn 3: A quay trở lại B (giai đoạn 3.1), B quay trở lại A (giai đoạn 3.2);
• Giai đoạn 4: A tiếp tục thực hiện.
Một giao dịch phải có ít nhất tất cả bốn giai đoạn này để thực hiện một cuộc tấn công thử lại và có ít nhất một trạng thái không nhất quán là điều kiện cần thiết cho một cuộc tấn công thử lại. Một ví dụ về bốn giai đoạn được hiển thị trong hình trên. Với bốn giai đoạn, có hai yêu cầu cho trạng thái không nhất quán:
(I) Phụ thuộc SLOAD-JUMPI: Trong giai đoạn 2, A sử dụng SLOAD để tải (sử dụng SLOAD) để lưu trữ quyết định luồng điều khiển biến (V) (tức là điều kiện của lệnh JUMPI);
(Ii) Sự phụ thuộc vào SLOAD-SSTORE: Trong giai đoạn 4, A cập nhật (sử dụng SSTORE) biến lưu trữ V. Nếu giao dịch thỏa mãn cả hai yêu cầu, rõ ràng là trong giai đoạn 2, A’load V từ trạng thái không nhất quán đối với quyết định luồng điều khiển. Do đó, B có thể thao túng luồng điều khiển bằng cách nhập lại A, do đó phát động một cuộc tấn công nhập lại.
Quy tắc phát hiện: Xác định quy tắc phát hiện theo yêu cầu của các trạng thái không nhất quán. Cụ thể hơn, hãy xác định các quy tắc phát hiện sau (như trong hình trên):
Quy tắc phát hiện trước tiên sẽ kiểm tra sự phụ thuộc SLOAD-JUMPI. Nếu giá trị được tải bởi SLOAD (sloadVal) được sử dụng trong trường hợp JUMPI, địa chỉ SLOAD (sloadAddr) sẽ được lấy. SLOAD và JUMPI phải có cùng độ sâu và callnum (được định nghĩa trong §5), và điều kiện của JUMPI (jumpiCond) phải phụ thuộc vào giá trị của SLOAD (sloadVal), được thực thi bởi “quy tắc phát hiện phụ thuộc”. Quy tắc phát hiện Phụ thuộc (A, B) kiểm tra xem có luồng dữ liệu từ A đến B.
Tiếp theo, “quy tắc phát hiện” kiểm tra sự phụ thuộc SLOAD-SSTORE. Trước tiên, hãy kiểm tra xem SSTORE có tồn tại trên địa chỉ (sloadAddr) hay không. Nếu vậy, sẽ kiểm tra
(I) Kiểm tra xem SLOAD có đáp ứng điều kiện đầu tiên hay không thông qua checkSameAddr đã sử dụng địa chỉ,
(Ii) Liệu SSTORE có được thực thi sau SLOAD và được thực thi sau khi lệnh gọi bên ngoài trả về hay không (kiểm tra idx và độ sâu thông qua các quy tắc phát hiện ByDepth bộ lọc và các quy tắc phát hiện filterByIdx tương ứng).
Quy tắc checkSameAddr kiểm tra xem SSTORE và SLOAD có cùng địa chỉ hay không. Quy tắc phát hiện filByDepth giữ lại các cặp SLOAD và SSTORE có sloadDp lớn hơn sstoreDp. Quy tắc phát hiện filterByIdx dự trữ các cặp SLOAD và SSTORE có sloadIdx nhỏ hơn sstoreIdx. Ngoài ra, hãy kiểm tra xem SLOAD, SSTORE và JUMPI có trong cùng một hợp đồng hay không (bằng cách kiểm tra Quy tắc phát hiện cùng một hợp đồng). Nếu vậy, trạng thái không nhất quán được phát hiện, điều này cho thấy một cuộc tấn công thử lại.
2) Các quy tắc tấn công cuộc gọi không được chọn
Mô tả: Do thiếu kiểm tra giá trị trả về của các lệnh gọi bên ngoài, cuộc tấn công UncheckedCall có thể được sử dụng để ăn cắp ether. Cụ thể, trong các hợp đồng thông minh Ethereum, CALL OPCODE thường được sử dụng để giao tiếp giữa các hợp đồng và chuyển tiền mã hóa (tức là chức năng gửi).
Trong cuộc gọi bên ngoài, một ngoại lệ có thể xảy ra, điều này sẽ khiến hợp đồng callee tiếp tục thực thi và quay trở lại. Tốt nhất, người gọi nên kiểm tra giá trị trả về của cuộc gọi. Nếu nó bằng 0 (ví dụ: do một ngoại lệ gây ra trong khi gọi), cần thực hiện các biện pháp (ví dụ: để tiếp tục thực thi nó) để xử lý ngoại lệ đúng cách. Tuy nhiên, nhiều nhà phát triển không thực hiện kiểm tra như vậy. Do đó, các hợp đồng này có lỗ hổng UncheckedCall và dẫn đến việc đánh cắp tiền.
Yêu cầu: Sử dụng các tiêu chuẩn phát hiện của công cụ phân tích bytecode BẢO MẬT để xác định các yêu cầu của cuộc tấn công UncheckedCall. Các giao dịch có chứa các cuộc tấn công UncheckedCall phải đáp ứng các yêu cầu sau:
(I) Cuộc gọi bên ngoài: Có ít nhất một cuộc gọi bên ngoài (OPCODE liên quan đến CALL) trong giao dịch.
(Ii) Giá trị trả về cuộc gọi không được chọn: Giá trị trả về của ít nhất một lệnh gọi bên ngoài không được sử dụng bởi bất kỳ JUMPI nào.
Có ít nhất một giá trị trả về không được kiểm tra là điều kiện cần thiết cho cuộc tấn công UncheckedCall. Cụ thể hơn, ở mức bytecode, JUMPI được sử dụng để kiểm tra giá trị trả về isdone dựa trên giá trị trả về của CALL. Do đó, nếu có bất kỳ giá trị trả về cuộc gọi nào không được JUMPI sử dụng trong giao dịch, điều đó có nghĩa là giá trị đó không được chọn. Giao dịch đang bị tấn công bởi UncheckedCall.
Quy tắc phát hiện: Để phát hiện các cuộc tấn công UncheckedCall, các quy tắc phát hiện được xác định trong hình trên. Quy tắc phát hiện UncheckedCall đầu tiên trích xuất tất cả các giá trị trả về cuộc gọi trong giao dịch (dòng 7), sau đó kiểm tra xem có JUMPI hay không theo từng yêu cầu trong mỗi yêu cầu. Gọi giá trị trả về, sử dụng quy tắc phát hiện jumpiDep. Nếu không có JUMPI nào sử dụng giá trị trả về cuộc gọi, giao dịch sẽ được đánh dấu là UncheckedCall. Xin lưu ý rằng các giao dịch có thể bao gồm OPCODE từ nhiều hợp đồng. Độ sâu của CALL và JUMPI trong “quy tắc phát hiện” đều được đặt thành 1, vì vậy chỉ các cuộc tấn công UncheckedCall chống lại hợp đồng người nhận mới được phát hiện.
3) Các quy tắc tấn công tự sát
Mô tả: Do thiếu kiểm tra quyền thích hợp, các cuộc tấn công “tự sát” có thể khiến hợp đồng thông minh bị giết bởi bất kỳ ai khác ngoài chủ sở hữu hợp đồng. Cụ thể, Ethereum cung cấp các hợp đồng thông minh có thể xóa chính nó khỏi chuỗi khối thông qua opcode SELFDESTRUCT. Mặc dù SELFDE STRUCT được thiết kế để chủ sở hữu hợp đồng quản lý vòng đời của hợp đồng thông minh của họ, một số hợp đồng thông minh không thể thêm kiểm tra quyền thích hợp trước khi gọi SELFDE STRUCT. Vì TXSPECTOR kiểm tra các giao dịch thay vì hợp đồng thông minh, nó sẽ phát hiện các cuộc tấn công của người dùng trái phép kích hoạt hợp đồng thông minh SELFDESTRUCT. Mỗi hợp đồng chỉ có thể được phát hiện tối đa một lần, vì nó đã bị phá hủy.
Yêu cầu: Cuộc tấn công tự sát có thể được phát hiện bằng cách kiểm tra xem có kiểm tra quyền (tức là, JUMPI) trước khi thực hiện SELFDESTRUCT hay không. Có hai yêu cầu:
(I) TỰ KHAI THÁC: Có ít nhất một lệnh TỰ THỬ trong giao dịch.
(Ii) Không có kiểm tra quyền nào được thực hiện trên CALLER: không có JUMPI nào dựa vào CALLER.
Nếu không có sự phụ thuộc CALLER-JUMPI trong giao dịch, điều đó có nghĩa là nó không kiểm tra msg.sender (CALLER) trước khi thực hiện SELFDESTRUCT, điều này cho thấy thêm rằng hợp đồng có thể bị giết bởi bất kỳ ai, tức là một cuộc tấn công tự sát.
Quy tắc phát hiện. Hình trên cho thấy các quy tắc phát hiện được sử dụng để phát hiện tự tử. Quy tắc phát hiện trước tiên đảm bảo rằng có ít nhất một SELFDESTRUCT trong giao dịch, sau đó kiểm tra xem msg.sender đã được kiểm tra trước khi SELFDESTRUCT thông qua quy tắc phát hiện jumpiDep hay chưa. (Dòng 3-4).
0x08 Đánh giá
1) Cài đặt thử nghiệm
Thu thập dấu vết : Dấu vết được thu thập trên L8s v2instance trên đám mây Microsoft Azure. Phiên bản này có 8 VCPU, RAM 64GB và SSD 2TB, chạy Ubuntu 18.04. Trace Ex đã chạy một nút Ethereum đầy đủ để thu thập các dấu vết cấp bytecode, từ khối thứ 0 đến khối thứ 7.200.000. Xin lưu ý rằng Ethereum có khoảng 10180000 khối (tính đến ngày 1 tháng 6 năm 2020) và nó đang phát triển theo cấp số nhân. Không thể thu thập tất cả các dữ liệu này để thử nghiệm, vì nó đòi hỏi nhiều không gian lưu trữ và thời gian xử lý. Do đó, việc thu thập bị dừng lại ở khối dữ liệu thứ 7.200.000, dẫn đến kích thước là 1.577 GB, chứa tổng cộng 397.269.533 giao dịch. Lưu trữ chúng trong Trace DB (được triển khai bởi atopMongoDB) thông qua Trace Extractor.
Tập dữ liệu: Sau khi thu thập dấu vết của các giao dịch khối, hãy xuất các giao dịch từ chúng. Các giao dịch này là đầu vào của TXSPECTOR. Với số lượng lớn các khối, không thể sử dụng tất cả chúng cho các giao dịch, vì một khối có thể chứa nhiều giao dịch. Do đó, nó đã được quyết định chỉ tập trung vào các giao dịch bắt đầu từ khối thứ 7 triệu, vì nó chứa 16.485.279 giao dịch, bao gồm các giao dịch từ tháng 1 năm 2019 đến tháng 2 năm 2019. Thông qua 16 triệu giao dịch như vậy, tôi tin rằng nó có nhiều thử nghiệm đại diện.
Tạo mối quan hệ logic: Tập dữ liệu liên quan đến việc tạo mối quan hệ logic chứa 9,661,593 giao dịch, được thu thập trong hai bước. Đầu tiên, tập dữ liệu ban đầu chứa 16.485.279 giao dịch. Tuy nhiên, không phải tất cả các giao dịch đều được theo dõi. Đó là, họ không gọi việc thực hiện hợp đồng thông minh. Chúng phải được lọc ra vì quá trình tạo mối quan hệ logic chỉ lấy các giao dịch có dấu vết đầu vào. Sau khi lọc, còn lại 9,662,675 giao dịch. Thứ hai, xử lý dữ liệu thô để tạo ra các mối quan hệ logic. Tuy nhiên, do hết thời gian chờ, không phải tất cả các giao dịch đều có thể được xử lý. Do đó, ngưỡng thời gian chờ được đặt thành 60 giây và mỗi dấu vết này được xử lý bằng cách thực thi trình tạo biểu đồ luồng và trình tạo mối quan hệ logic để tạo ra mối quan hệ logic. Thật không may, 1.082 giao dịch (0,01%) đã không hoàn thành việc tạo mối quan hệ logic đúng hạn. Do đó, tập dữ liệu cuối cùng chứa 9,661,593 giao dịch. Cơ sở dữ liệu quan hệ logic chiếm 2,949 GB dung lượng.
Hầu hết các mối quan hệ logic được tạo ra trong một khung thời gian ngắn. Cụ thể, chỉ có 94.277 (1,0%) giao dịch có thời gian xử lý lớn hơn 4 giây. Trong hình trên, phân bố thời gian xử lý của các giao dịch được hoàn thành trong vòng 4 giây (99,0% trong số 9,662,675 giao dịch) được vẽ. Khoảng 60% giao dịch đã hoàn thành việc tạo ra các mối quan hệ logic trong vòng 1 giây. Nếu ngưỡng thời gian chờ được đặt thành 2 giây, mối quan hệ logic của khoảng 90% giao dịch có thể được tạo. Trung bình mất 1,03 giây để tạo ra mối quan hệ logic của một giao dịch. Xin lưu ý rằng đối với mỗi giao dịch, bất kể có bao nhiêu quy tắc phát hiện được áp dụng trong bộ phát hiện tấn công, mối quan hệ logic chỉ cần được tạo một lần, vì các quy tắc phát hiện khác nhau sử dụng cùng một mối quan hệ logic.
Sau khi mối quan hệ logic được tạo ra, các “quy tắc phát hiện” được áp dụng để phát hiện các cuộc tấn công và lỗ hổng trong giao dịch. Đặt ngưỡng thời gian chờ thành 1 giây trong “trình phát hiện tấn công”.
Các bước và tiêu chí đánh giá: Một số bước đã được thực hiện trong quá trình đánh giá và so sánh kết quả của các công cụ phân tích tĩnh khác. Đầu tiên hãy áp dụng TXSPECTOR để đánh dấu giao dịch theo các quy tắc phát hiện. Đối với các giao dịch được đánh dấu, nếu mã nguồn của hợp đồng thông minh của người nhận có sẵn, việc kiểm tra thủ công sẽ được thực hiện để kiểm tra xem chúng có dễ bị tấn công cụ thể hay không. Tiếp theo, nếu các hợp đồng thông minh dễ bị tấn công, các giao dịch mã thông báo liên quan đến các hợp đồng này được coi là đúng và tích cực. Nếu không, giao dịch liên quan được coi là dương tính giả. Do khối lượng giao dịch lớn nên không thể phân tích kết quả tiêu cực. Các tác phẩm liên quan khác (chẳng hạn như SEREUM) cũng gặp phải vấn đề tương tự. Cuối cùng, nếu các công cụ này có thể phát hiện các lỗ hổng cụ thể, hãy so sánh TXSPECTOR với ba công cụ phân tích tĩnh dựa trên Datalog: SECURIFY, VANDAL và GIGAHORSE.
2) Kết quả của cuộc tấn công thử lại
Đầu tiên, kết quả phát hiện của các cuộc tấn công thử lại được giới thiệu và các quy tắc phát hiện thử lại được áp dụng cho 9,661,593 giao dịch trong tập dữ liệu. Do hết thời gian chờ, 336.909 giao dịch (3,5%) không được hoàn thành. Đối với 9.321.684 giao dịch có đánh giá, TXSPECTOR đã đánh dấu 3.357 giao dịch (0,04%) là các cuộc tấn công vào lại. 3.357 giao dịch này liên quan đến 30 hợp đồng thông minh, 22 trong số đó là mã nguồn mở. 8 hợp đồng mã nguồn đóng đã được dịch ngược bằng trình dịch ngược Solidity trực tuyến. Sau khi kiểm tra thủ công, người ta xác nhận rằng 10 trong số 22 hợp đồng mã nguồn mở và 7 trong số 8 hợp đồng mã nguồn đóng có chứa các lỗ hổng đăng nhập lại. Có hai lý do chính khiến TXSPECTOR gắn nhãn sai cho 13 hợp đồng thông minh:
(I) Không thể phát hiện ra khóa cấm nhập lại trái phép chức năng reentrant;
(Ii) Có thể nhập lại các hợp đồng được đánh dấu không chính xác, nhưng không thể ăn cắp ether hoặc token từ chúng.
Một ví dụ về dương tính giả là giao dịch 0xd32496. Danh sách 3 hiển thị đoạn mã của chức năng có liên quan, sử dụng một khóa để ngăn các nỗ lực nhập lại trái phép. Kiểm tra biến khóa (reentrancyLock) trước cuộc gọi và cập nhật ngày sau cuộc gọi, cho phép hợp đồng chỉ được nhập lại một lần. Bằng cách này, các cuộc tấn công thực tế có thể được ngăn chặn, nhưng việc thực hiện giao dịch đáp ứng các yêu cầu của các cuộc tấn công lại. Kết quả là, đây là một báo động sai.
Kết quả phát hiện có thể so sánh với SEREUM, với 49.080 giao dịch (trong tổng số 77.987.922 giao dịch) được gắn cờ sai 46.743, với tỷ lệ báo động sai là 0,06%. Theo cùng một tiêu chuẩn, TXSPECTOR đã gắn cờ sai 3.072 giao dịch (liên quan đến 13 hợp đồng thông minh), với tỷ lệ báo động sai là 0,03%. Tuy nhiên, người ta coi các giá trị này chỉ là giá trị gần đúng của độ chính xác phát hiện, vì không thể tính được giá trị âm thực sự.
Để so sánh kết quả phát hiện của TXSPECTOR với các công cụ khác hoặc liên hệ với các chuyên gia tương ứng để được trợ giúp và giải thích, hoặc sử dụng cùng một bộ dữ liệu để chạy công cụ nguồn mở. Kết quả được tóm tắt trong bảng dưới đây. Phần so sánh được trình bày chi tiết dưới đây.
So với SEREUM: Không có hợp đồng cho thuê mã nguồn mở nào của SEREUM; nhưng các tác giả của SEREUM đã được liên hệ và thu được kết quả đánh giá của họ cho mục đích so sánh. Đối với cùng một tập dữ liệu, SEREUM đã đánh dấu 10.278 giao dịch là các cuộc tấn công trở lại, trong đó 2.732 cũng được TXSPECTOR đánh dấu. Đối với 7.546 giao dịch còn lại, có 7.271 giao dịch trong số đó không có kết quả trong tập dữ liệu do hết thời gian chờ. TXSPECTOR đã đánh dấu 625 giao dịch, nhưng SEREUM thì không. Mặc dù việc kiểm tra thủ công cho thấy chúng gây ra các trạng thái không nhất quán, nhưng tôi không hiểu tại sao SEREUM không thể nhận ra chúng.
So sánh với SECURIFY: Công cụ phân tích tĩnh SECURIFY đã được sử dụng để so sánh. Xin lưu ý rằng SECURIFY nhằm mục đích phát hiện các lỗ hổng trong hợp đồng thông minh và nghiên cứu này tập trung vào các giao dịch. Trước tiên, trích xuất tất cả các hợp đồng thông minh của người nhận của giao dịch trong tập dữ liệu, sau đó áp dụng BẢO MẬT cho các hợp đồng thông minh này. Tổng số hợp đồng thông minh của người nhận trong tập dữ liệu là 105.535. Trong số 3327 giao dịch được TXSPECTOR đánh dấu, chỉ có 30 hợp đồng thông minh nhận. Phiên bản mã nguồn mở của SECURIFY đã được chạy trên 105.535 hợp đồng thông minh của người nhận. Ngưỡng thời gian chờ được đặt thành 60 giây để phân tích từng hợp đồng. Trong số này, 1.315 không thể hoàn thành do hết thời gian chờ; 6.226 trong số đó không có kết quả do lỗi thời gian chạy. Đối với 97.994 hợp đồng thông minh còn lại, SECURIFY đã đánh dấu 1.196 trong số đó là bất hợp pháp và TXSPECTOR đã không đánh dấu chúng.
Sau khi đọc mã nguồn của SECURIFY, tôi thấy rằng nó định nghĩa hai hình thức tái xuất, “nạp khí liên quan đến khí” và “nạp khí liên tục”. Nhưng trạng thái không nhất quán được kiểm tra trong định nghĩa của nghiên cứu này, yêu cầu trạng thái phải được cập nhật sau cuộc gọi. Do đó, kết luận rằng TXSPECTOR dẫn đến kết quả phát hiện khác với SECU RIFY vì chúng có các tiêu chuẩn tái nhập phát hiện khác nhau. Cũng có thể xác định các quy tắc phát hiện để sử dụng TXSPECTOR để phát hiện các loại tấn công thử lại này (. Điều đáng chú ý là SEREUM cũng đã đề cập rằng “Securify xác định một quy mô vi phạm rất thận trọng để phát hiện lại mục nhập. Chế độ này cấm mọi thực thi sau các cuộc gọi bên ngoài. Cập nhật trạng thái ”, dẫn đến“ tỷ lệ báo động sai rất cao ”.
So sánh với VANDAL: Sử dụng phiên bản mã nguồn mở của VANDAL để so sánh. Ngưỡng thời gian chờ được đặt thành 60 giây để phân tích từng hợp đồng. Khi phân tích 105.535 hợp đồng thông minh của người nhận, 1.206 (1,1%) trong số đó không được hoàn thành trong vòng 60 giây; 225 (0,2%) không có kết quả do một số lỗi thời gian chạy. Đối với 104.104 hợp đồng thông minh còn lại, VANDAL đánh dấu 85.721 (82,3%) là hợp đồng gia nhập lại, điều này rõ ràng là không hợp lý. Chọn ngẫu nhiên một số hợp đồng thông minh được phát hiện và thấy rằng chúng đều sai. Do số lượng hợp đồng đã đánh dấu rất lớn, không thể kiểm tra thủ công tất cả các hợp đồng.
Bằng cách kiểm tra các quy tắc do VANDAL cung cấp, người ta thấy rằng các quy tắc này lỏng lẻo hơn nhiều so với các quy tắc của nghiên cứu này. Theo kết luận của họ, “Nếu đủ lượng khí được gọi và nó không được bảo vệ bởi mutex, nó được đánh dấu là reentrant.” Do đó, tất cả các cuộc gọi có đủ gas và không bị khóa sẽ được VANDAL đánh dấu là trở lại, đây là một tiêu chuẩn rất lỏng lẻo. Trong số 30 hợp đồng thông minh được TXSPECTOR đánh dấu, VANDAL cũng có 27 hợp đồng. Đối với 3 người còn lại, VANDAL đã không hoàn thành phân tích của họ do hết thời gian. Do đó, TXSPECTOR tốt hơn VANDAL vì nó dẫn đến tỷ lệ FP thấp hơn.
So sánh với GIGAHORSE: Không có phiên bản mã nguồn mở của GIGAHORSE, nhưng có một trang web để người dùng truy vấn kết quả của GIGAHORSE. Tất cả các kết quả của “mục nhập lại” được trích xuất từ trang web của họ. Trong số 105.535 hợp đồng thông minh của người nhận trong tập dữ liệu, 3.310 (3,1%) đã được GIGAHORSE đánh dấu là trở lại. GI GAHORSE cũng đánh dấu 18 trong số 30 hợp đồng thông minh được TXSPECTOR phát hiện; GIGAHORSE tin rằng 12 hợp đồng còn lại không có sơ hở. Theo giải thích trên trang FAQ, GIGA HORSE coi hợp đồng thông minh chỉ được đăng nhập lại khi “hợp đồng đã thực hiện cuộc gọi bên ngoài và bản thân hợp đồng có thể được nhập lại trước cuộc gọi đầu tiên để cập nhật bộ nhớ”. Do đó, nó có các tiêu chuẩn khắt khe hơn so với sự không nhất quán được xác định bởi TXSPECTOR. Đối với 3.292 hợp đồng thông minh được GIGAHORSE đánh dấu thay vì TXSPEC TOR, lý do chính là không có giao dịch nào hiển thị trạng thái không nhất quán trong tập dữ liệu.
Nghiên cứu điển hình về hợp đồng DAO: Mặc dù TXSPECTOR không đạt yêu cầu trong việc phát hiện một số kiểu tấn công lại (so với SEREUM), nhưng nó chứng minh rằng nó vẫn hiệu quả trong việc phát hiện các cuộc tấn công nổi bật nhất (chẳng hạn như các cuộc tấn công DAO). Hợp đồng DAO là nơi xảy ra cuộc tấn công tái nhập lần đầu tiên và nó là nạn nhân đầu tiên của cuộc tấn công tái nhập. DAO đã đánh cắp Ether trị giá hơn 50 triệu đô la Mỹ. Để tránh thua lỗ, cộng đồng Ethereum đã quyết định hard fork blockchain để trả lại số tiền bị đánh cắp, điều này dẫn đến sự phân tách của blockchain Ethereum.
Để kiểm tra các giao dịch có thể đã tấn công hợp đồng DAO, chỉ cần sử dụng DAO để rút giao dịch vì người nhận không hoạt động vì hợp đồng độc hại không phải là người nhận. Thay vào đó, dấu vết ban đầu được thu thập bởi trình trích xuất dấu vết đã được quét để hiểu mọi giao dịch từ khối 0 đến khối 7.200.000 và chỉ giao dịch chứa địa chỉ hợp đồng DAO được lưu giữ. Sau khi quá trình lọc này hoàn tất, còn lại 98,914 giao dịch.
TXSPECTOR với các quy tắc phát hiện lần truy cập gần đây đã được áp dụng cho 98,914 giao dịch để kiểm tra số lượng các cuộc tấn công vào hợp đồng DAO. Sử dụng cùng một quy trình đã đề cập trước đó để tạo mối quan hệ logic và áp dụng các quy tắc phát hiện lần truy cập gần đây. Vì giao dịch thử lại phức tạp hơn giao dịch thông thường nên ngưỡng thời gian chờ của mối quan hệ lôgic được tăng lên 200 giây và ngưỡng thời gian chờ của quy tắc phát hiện được tăng lên 60 giây. Sau quá trình này, vẫn còn 3.665 giao dịch không có kết quả do hết thời gian. Trong số 95.249 giao dịch còn lại, TXSPECTOR đã đánh dấu 2.108 giao dịch trong số đó là các cuộc tấn công tái nhập.
Để so sánh TXSPECTOR với SEREUM, chúng tôi đã kiểm tra xem có bao nhiêu trong số 98,914 giao dịch được đánh dấu SEREUM. Đặc biệt, SEREUM đánh dấu 2.112 giao dịch, trong đó TXSPECTOR cũng đánh dấu 2.108 giao dịch. Nói cách khác, tất cả các cuộc tấn công được phát hiện bởi TXSPECTOR cũng được đánh dấu bằng SEREUM. SEREUM đã đánh dấu 4 giao dịch, TXSPECTOR thì không. Kiểm tra thủ công 4 giao dịch này để hiểu tại sao TXSPECTOR không đánh dấu chúng. Kiểm tra mối quan hệ logic của SSTORE, SLOAD và JUMPI để xem có bất kỳ phụ thuộc nào mà TXSPECTOR đã bỏ qua hay không. Sau khi kiểm tra, xác nhận rằng trong 4 giao dịch này, có các cặp (SLOAD, SSTORE) hoạt động cùng một địa chỉ lưu trữ. Tuy nhiên, các cặp này có cùng độ sâu, có nghĩa là chúng không thỏa mãn điều kiện của trạng thái không nhất quán. Do đó, TXSPECTOR đã không đánh dấu nó là một cuộc tấn công vào lại.
3) Kết quả của cuộc tấn công cuộc gọi không được kiểm tra
Tiếp theo, kết quả phát hiện của cuộc tấn công UncheckedCall được giới thiệu. Sau khi áp dụng quy tắc phát hiện Cuộc gọi không kiểm tra cho tập dữ liệu, 323.772 giao dịch (3,4%) đã không được hoàn thành do hết thời gian chờ. Trong số 9.337.821 giao dịch tạo ra kết quả, TXSPECTOR đã đánh dấu 178.303 giao dịch là UncheckedCall và có 1.430 hợp đồng người nhận có liên quan. Trong số này, 216 là mã nguồn mở và có liên quan đến 28.377 giao dịch. Đã kiểm tra thủ công 216 hợp đồng thông minh và phát hiện ra rằng 213 hợp đồng trong số đó có lỗ hổng UncheckedCall. Chúng tôi đã tìm hiểu thêm tại sao TXSPECTOR lại đánh dấu 3 hợp đồng còn lại. Xét thấy 3 hợp đồng này đều kiểm tra các cuộc gọi bên ngoài, nhưng trong giao dịch không thực hiện kiểm tra do “hết xăng” nên TXSPECTOR đã chấm. 3 hợp đồng thông minh được đánh dấu không chính xác chỉ liên quan đến 4 giao dịch. Điều đáng chú ý là đối với 1.214 hợp đồng thông minh nguồn đóng còn lại, không thể thực hiện phân tích thủ công các hợp đồng. Nhưng người ta xác nhận rằng ít nhất một {CALL POP} đã được tìm thấy trong quá trình theo dõi của họ hoặc họ không sử dụng ít nhất một giá trị cuộc gọi, điều này cho thấy rằng chúng thực sự là các cuộc tấn công dựa trên các quy tắc phát hiện của nghiên cứu này. Kết quả cũng được so sánh với SECURIFY và VANDAL. Kết quả so sánh được tóm tắt trong bảng trên.
So sánh với SECURIFY: Sử dụng SECURIFY để phát hiện các cuộc tấn công lạm dụng lỗ hổng UncheckedCall của 105.535 hợp đồng thông minh của người nhận trong tập dữ liệu. Khi phân tích các hợp đồng thông minh này, 2.993 trong số đó (2,8%) đã không được hoàn thành trong vòng 60 giây. Ngoài ra, do một số lỗi thời gian chạy (ví dụ: chỉ mục nằm ngoài phạm vi), việc phân tích 3,501 hợp đồng thông minh khác (3,3%) không thể hoàn thành nên không có kết quả. Sau khi xử lý, SECURIFY đã tạo ra 99.041 (93,9%) kết quả hợp đồng thông minh và đánh dấu 2.380 kết quả trong số đó là có lỗ hổng UncheckedCall.
Nghiên cứu sâu hơn đã được thực hiện trên 178.303 giao dịch được TXSPECTOR đánh dấu. Các hợp đồng người nhận của các giao dịch này (tổng cộng 1.404) đã được trích xuất và so sánh với kết quả phát hiện của SECURIFY. TXSPECTOR đã đánh dấu 1.183 (84,3%) hợp đồng người nhận, cũng được đánh dấu bằng SECURIFY; TXSPECTOR đánh dấu 142 (10,1%) khác, nhưng SECURIFY đã không hoàn thành việc thực thi do lỗi thời gian chờ hoặc thời gian chạy; TXSPECTOR đã đánh dấu 79 hợp đồng thông minh Hợp đồng nhưng được SECURIFY đánh dấu là “an toàn”. Trong theo dõi mức bytecode được tạo ra bởi việc thực hiện 79 hợp đồng này, hợp đồng người gọi sẽ bật lên giá trị gọi lại, do đó, không có sự phụ thuộc JUMPI-CALL trong việc theo dõi. Người ta suy đoán rằng lý do tại sao SECURIFY không đánh dấu các hợp đồng này có thể liên quan đến phương pháp thực thi tượng trưng mà nó sử dụng.
Khoảng 1.200 hợp đồng thông minh chỉ được đánh dấu bởi SECURIFY thay vì TXSPECTOR. Sau khi kiểm tra một số trong số chúng, người ta thấy rằng có lỗ hổng UncheckedCall trong hợp đồng thông minh, nhưng giao dịch không chứa chức năng dễ bị tấn công. Do đó, TXSPECTOR đã không phát hiện ra chúng.
So sánh với VANDAL: Khi sử dụng VANDAL để phân tích 105.535 hợp đồng thông minh của người nhận, 1.151 (1,1%) trong số đó đã không được hoàn thành trong vòng 60 giây. Đối với 1.403 hợp đồng thông minh được TXSPECTOR đánh dấu, VANDAL cũng đã đánh dấu 1.367 (97,4%) trong số đó; 36 hợp đồng còn lại không được VANDAL công nhận. Qua kiểm tra thủ công, người ta thấy rằng 36 hợp đồng thông minh này có lỗ hổng UncheckedCall. Một ví dụ là hợp đồng 0x99ECA3. Trong hợp đồng này, giá trị trả về của hàm transfer () không được kiểm tra, điều này cho thấy rằng có lỗ hổng UncheckedCall. Do đó, TXSPECTOR có thể xác định các hợp đồng thông minh dễ bị tấn công bởi VANDAL.
VANDAL đã đánh dấu 91.012 hợp đồng thông minh khác là lỗ hổng UncheckedCall. Do phạm vi bảo hiểm, TXSPECTOR không phát hiện ra các hợp đồng thông minh này: các chức năng dễ bị tấn công không được bao gồm trong giao dịch tập dữ liệu.
4) Kết quả của cuộc tấn công tự sát
Cuối cùng, kết quả phát hiện các cuộc tấn công tự sát được giới thiệu. Sau khi áp dụng quy tắc phát hiện tự tử cho tập dữ liệu, 327.208 giao dịch (3,4%) đã không được hoàn thành do hết thời gian chờ. Trong số 9.334.385 giao dịch có kết quả (96,6%), TXSPECTOR đánh dấu 23 giao dịch tự tử. Trong số đó, chỉ có 18 hợp đồng thông minh người nhận, vì địa chỉ người nhận của 5 giao dịch là 0x0, có nghĩa là chúng bị giết ngay sau khi tạo. Không thể nghiên cứu mã nguồn của chúng vì chúng đã xóa mã bytecode và thời gian lưu trữ khỏi chuỗi khối khi chúng bị khai tử. Từ việc theo dõi 23 giao dịch, nó được xác nhận rằng không có kiểm tra quyền đối với người gọi (msg.sender). Do đó, TXSPECTOR sẽ không tạo ra các cảnh báo sai. Kết quả cũng được so sánh với VANDAL và GIGAHORSE, và kết quả so sánh được tóm tắt trong bảng trên.
So sánh với VANDAL: VANDAL được chạy trên tất cả 105.535 hợp đồng thông minh trong tập dữ liệu để kiểm tra xem có bao nhiêu hợp đồng trong số đó có lỗ hổng tự sát. VANDAL đánh giá 349 trong số đó là yếu. 13 trong số 18 hợp đồng thông minh được TXSPEC TOR đánh dấu cũng được đánh dấu bằng VANDAL. Đối với 5 hợp đồng thông minh không được VANDAL đánh dấu, VANDAL không thể phân tích chúng do lỗi thời gian chạy và thời gian chờ. Chỉ đối với 336 hợp đồng thông minh được VANDAL đánh dấu, nguyên nhân chính là các hợp đồng thông minh này có lỗ hổng tự sát nhưng vẫn chưa bị khai tử (tức là chức năng chưa được gọi). Do đó, TXSPECTORdid không thể phát hiện ra chúng.
So sánh với GIGAHORSE: Để so sánh với GIGA HORSE, kết quả “tự hủy có thể truy cập được” của họ được lấy từ trang web của họ. Trong số 105.535 hợp đồng thông minh bộ thu trong tập dữ liệu, GIGAHORSE đánh dấu 383 hợp đồng thông minh và chỉ một trong số đó có kết quả tương tự như TXSPEC TOR.
Lý do tại sao GIGAHORSE không đánh dấu 17 hợp đồng còn lại là khi GIGAHORSE được triển khai, mã bytecode của họ đã bị mất sau khi bị khai tử, vì vậy GIGAHORSE không thể phân tích chúng. Đối với các hợp đồng thông minh được GIGAHORSE chỉ đánh dấu, người ta thấy rằng chúng có một tiêu chuẩn lỏng lẻo: miễn là có thể đạt được SELFDESTRUCT từ điểm nhập công khai, ngay cả khi có kiểm tra, nó sẽ được đánh dấu là Đúng. Tuy nhiên, TXSPECTOR chỉ phát hiện sơ hở mà việc tự tử chưa được kiểm tra, quy trình này nghiêm ngặt hơn GIGAHORSE.
5) So sánh với các công cụ khác
Ngoài ba công cụ dựa trên Datalog, nó còn được so sánh với ba công cụ phân tích tĩnh khác: MYTHRIL, OYENTE và MAIAN. Đối với MYTHRIL, hãy so sánh nó với TXSPECTOR trên cả ba lỗ hổng; so sánh lần lượt của OYENTE trở lại và lần tự tử của MAIAN. Kết quả được tổng hợp và hiển thị trong bảng dưới đây. Nói chung, kết quả thử nghiệm của các công cụ khác nhau rất khác nhau. Lý do chính là không có quy tắc vàng để phát hiện các lỗ hổng này và các công cụ khác nhau sử dụng các quy tắc phát hiện khác nhau. Ngoài mã nguồn mở, kết quả so sánh cũng được công bố để những người khác trong cộng đồng có thể sử dụng dữ liệu cho nghiên cứu của họ.
6) Phân tích thời gian chờ
Hết thời gian chờ do logic thế hệ. Khi mối quan hệ logic được tạo, 6.082 giao dịch không được hoàn thành. Kiểm tra thủ công các giao dịch này để hiểu lý do hết thời gian. Người ta thấy rằng hầu hết các giao dịch này đều bị mắc kẹt trong trình tạo mối quan hệ logic, trình này sẽ chuyển đổi EFG thành IR và thực hiện các phép toán số học với các giá trị thực. Các phép toán số học đôi khi có thể quá phức tạp để có thể tính toán ngay lập tức (ví dụ, exp (a, b)). Đây là lý do chính dẫn đến thời gian chờ do tạo ra các quan hệ logic. Một ví dụ là giao dịch 0xf9de18, có 6.945 opcodes. Ngoài ra, nó có một số lượng lớn các phép toán exp dưới dạng số mũ, có thể gây ra thời gian chờ.
Hết thời gian chờ do áp dụng các quy tắc phát hiện. Phân tích các giao dịch vượt quá ngưỡng thời gian chờ khi áp dụng quy tắc phát hiện Cuộc gọi không kiểm tra. Người ta thấy rằng khi tìm ra sự phụ thuộc giữa giá trị trả về của cuộc gọi và JUMPI, hầu hết các giao dịch đều bị mắc kẹt. Giả sử rằng số lượng JUMPI trong dấu vết giao dịch là m và số lượng CALL là n, sẽ có m * n cặp (CALL, JUMPI). Đối với mỗi cặp, TXSPECTOR có thể sử dụng nhiều biến trung gian để tìm sự phụ thuộc giữa chúng, nhằm kiểm tra xem JUMPI có sử dụng giá trị trả về cuộc gọi hay không. Khi m ∗ n lớn và quỹ đạo dài, sẽ mất rất nhiều thời gian để xác minh sự phụ thuộc của tất cả các cặp m ∗ n. Một ví dụ là giao dịch 0xb513f5, có 11.664 JUMPI và 299 CALL. Đối với khoảng 3,5 triệu cặp (CALL, JUMPI), TXSPECTOR cần duyệt qua tất cả các biến trung gian tiềm năng để xác nhận xem có phụ thuộc hay không.
Tối ưu hóa: Để tối ưu hóa việc tạo ra các quan hệ logic, các kết quả trung gian này có thể thu được từ nút Ethereum vì chúng sẽ xuất hiện trong quá trình thực hiện giao dịch. Để tăng tốc quá trình áp dụng “quy tắc phát hiện”, bạn có thể thêm các quy tắc cắt tỉa chặt chẽ hơn để lọc ra các cặp có thể không có phụ thuộc và sau đó cố gắng tìm chúng. Ngoài ra, một số chức năng phụ có thể được thêm vào để lưu trữ các phụ thuộc của các nút nhất định, để không phải tính toán lại mỗi lần, để lại những tối ưu hóa này cho công việc sau này.
Thảo luận 0X09
Chi phí thời gian: Trung bình mất 1,03 giây để tạo mối quan hệ logic cho một giao dịch. Xem xét khối lượng giao dịch trong Ethereum, việc xử lý chúng trong thời gian thực sẽ rất khó khăn. TXSPECTOR được thiết kế như một khuôn khổ phân tích pháp lý cho các giao dịch, nhưng nó không nhằm mục đích được sử dụng làm công cụ phát hiện tấn công thời gian thực cho Ethereum. Tuy nhiên, có nhiều cách để cải thiện hiệu suất của TXSPECTOR khi tạo các mối quan hệ logic. Ví dụ: vì không có sự phụ thuộc giữa các giao dịch, đa luồng có thể được áp dụng cho mối quan hệ logic tạo ra nhiều giao dịch song song.
Chi phí lưu trữ: RelationDB yêu cầu nhiều không gian để lưu trữ logic. Để tiết kiệm dung lượng, TXSPECTOR có thể thực hiện các biện pháp để giảm kích thước của cơ sở dữ liệu quan hệ logic. Ví dụ, khi tạo các mối quan hệ logic, có thể sử dụng tuần tự hóa tiêu chuẩn hoặc thư viện nén (ví dụ: gzip). Ngoài ra, nếu OPCODE quan tâm được biết trước khi chuyển qua trình tạo mối quan hệ logic, TXSPECTOR có thể chọn một tập con các OPCODE và chỉ tạo các mối quan hệ logic cho các OPCODE này thay vì tạo mối quan hệ logic cho tất cả các OPCODE.
Giao dịch và mã bytecode: Ưu điểm của việc nghiên cứu các giao dịch là các giao dịch chứa thông tin về cách các hợp đồng thông minh tương tác. Tuy nhiên, theo dõi mức bytecode của giao dịch chỉ chứa một phần thông tin của hợp đồng thông minh; nó chỉ liên quan đến các chức năng được gọi trong giao dịch này. Nếu một chức năng trong hợp đồng thông minh chưa bao giờ được người khác gọi, thì sẽ không có giao dịch nào được liên kết với nó. Trong trường hợp này, giao dịch không thể tiết lộ bất kỳ lỗ hổng nào liên quan đến tính năng này của hợp đồng thông minh. Tuy nhiên, nếu hợp đồng thông minh chưa bao giờ liên quan đến bất kỳ giao dịch nào, các lỗ hổng này sẽ không bị khai thác. Do đó, đối với phân tích dự đoán, phân tích giao dịch có ý nghĩa hơn việc nghiên cứu mã bytecode của hợp đồng thông minh.
Phương pháp phản ứng và chủ động: Là một công cụ phát hiện tấn công và phân tích pháp y, TXSPECTOR kiểm tra các giao dịch có bản chất phản ứng, có nghĩa là một cuộc tấn công chỉ có thể được phát hiện sau khi một cuộc tấn công xảy ra trên chuỗi khối Ethereum. Không giống như các phương pháp chủ động (chẳng hạn như phân tích tĩnh) không thể phát hiện lỗ hổng trong các hợp đồng thông minh có thể không bao giờ được kích hoạt, nghiên cứu các giao dịch có thể tiết lộ các cuộc tấn công thực sự đã xảy ra trong quá khứ và học hỏi từ chúng từ góc độ pháp y. Mặt khác, vì TXSPECTOR chỉ có thể xem một phần của mã byte hợp đồng thông minh, các công cụ phân tích tĩnh bổ sung cho TXSPECTOR. Sau khi TXSPECTOR bao gồm các cuộc tấn công từ các giao dịch, các công cụ phân tích tĩnh có thể được sử dụng để nghiên cứu các hợp đồng thông minh của nạn nhân để xác định các bề mặt tấn công tiềm năng khác và các hợp đồng thông minh của kẻ tấn công để hiểu cơ chế tấn công.
Cần làm việc chăm chỉ để thiết kế các quy tắc mới: TXSPECTOR chỉ có thể được sử dụng để phân tích pháp y về các cuộc tấn công / lỗ hổng đã biết. Để đề xuất các quy tắc phát hiện, người dùng cần biết một số kiến thức về các cuộc tấn công / lỗ hổng mà họ muốn phát hiện và hiểu biết cơ bản về việc xây dựng các quy tắc phát hiện. Trong phiên bản mã nguồn mở của TXSPECTOR, các quy tắc về lỗ hổng bảo mật hiện có được cung cấp cho người dùng lựa chọn để họ không phải phát minh lại bánh xe. Ngoài ra, để giảm thiểu khối lượng công việc yêu cầu người dùng phát triển các quy tắc phát hiện tùy chỉnh, danh sách API và tệp tài liệu / readme cũng được cung cấp để giúp người dùng bắt đầu.
Các ứng dụng khác: Bài viết này cho thấy rằng TXSPECTOR có thể được sử dụng để phát hiện 6 kiểu tấn công khác nhau. Tuy nhiên, phạm vi ứng dụng của TXSPECTOR không chỉ để phát hiện các cuộc tấn công và lỗ hổng. Nó có thể được sử dụng để phân tích pháp y trong nhiều khía cạnh khác của giao dịch. Ví dụ: TXSPECTOR có thể được sử dụng để kiểm tra xem một địa chỉ cụ thể có liên quan đến giao dịch hay không và nếu có, hãy thực hiện phân tích cụ thể về giao dịch. Ngoài ra, nó cũng có thể được sử dụng để lấy một số kết quả trung gian để hiểu lý do tại sao giao dịch không thành công.
0x0A Kết luận
Bài viết này giới thiệu TXSPECTOR, là khung công tác dựa trên logic, mã nguồn mở, mục đích chung đầu tiên để nghiên cứu các giao dịch Ethereum ở cấp bytecode. TXSPECTOR hỗ trợ các quy tắc phát hiện tùy chỉnh do người dùng xác định để phát hiện các cuộc tấn công Ethereum. Bài viết này giới thiệu thiết kế và triển khai TXSPECTOR và trình bày các quy tắc phát hiện để phát hiện các cuộc tấn công trong giao dịch. Đánh giá cho thấy TXSPECTOR có hiệu quả và cũng thể hiện cách sử dụng TXSPECTOR để phân tích pháp y các giao dịch.
