WeBlock Abba: Khám phá các lỗ hổng hợp đồng thông minh blockchain DeFi

Tiêu đề gốc: "Khám phá các lỗ hổng trong Hợp đồng thông minh Blockchain tài chính phi tập trung (DeFi)"

Nguồn gốc: Abba Garba, WeBlock CTO

Blockchain là một loại hệ thống phân tán mới sử dụng giao tiếp mạng ngang hàng P2P, lưu trữ khối, đồng thuận thuật toán phân tán và thuật toán mã hóa để ngăn chặn giả mạo. Về bản chất, blockchain có thể được xem như một cơ sở dữ liệu phân tán được duy trì chung bởi tất cả các nút mạng. So với cơ sở dữ liệu phân tán truyền thống, blockchain phù hợp hơn với các ứng dụng có yêu cầu rõ ràng về độ tin cậy phi tập trung nhờ khả năng sao lưu dữ liệu hoàn chỉnh, mạng mở và minh bạch, không giả mạo, truy xuất nguồn gốc thông tin đầy đủ và mô hình độ tin cậy yếu. Đặc biệt, các kịch bản ứng dụng blockchain điển hình bao gồm thanh toán kỹ thuật số, truy xuất nguồn gốc sản phẩm, bảo vệ bản quyền, tài chính chuỗi cung ứng, v.v. Trong các hệ thống blockchain, hợp đồng thông minh đóng vai trò cực kỳ quan trọng trong việc triển khai ứng dụng phi tập trung và mở rộng chức năng của ứng dụng. So với các ứng dụng truyền thống, hệ thống blockchain có các đặc điểm là công khai, minh bạch, thực thi, không bị giả mạo và độc lập với bên thứ ba, đồng thời có thể đáp ứng nhiều ứng dụng phi tập trung khác nhau. .

Kể từ ngày 15 tháng 1 năm 2021, tài chính phi tập trung (DeFi) đã trở thành một ngành thành công với số vốn hơn 4,5 tỷ USD Một mô hình tài chính sử dụng các hợp đồng thông minh dựa trên blockchain để đảm bảo tính toàn vẹn và bảo mật của nó. Tài chính phi tập trung là một lĩnh vực đang phát triển mới để trao đổi, cho vay hoặc vay token. Thông thường, các hướng dẫn này được điều chỉnh bởi các hợp đồng thông minh (chứ không phải một cá nhân hoặc thực thể pháp lý tập trung duy nhất) và/hoặc "sản lượng" hoặc dòng doanh thu được kiểm soát bởi cơ chế quản trị phi tập trung, nhiều bên (chẳng hạn như DAO). Tài chính phi tập trung (DeFi)—xuất hiện trên nền tảng blockchain hiện có. Các thành phần của lĩnh vực mới này bao gồm những thành phần liên quan đến cho vay, giao dịch tài sản và thị trường phái sinh. Là một ứng dụng phi tập trung, hợp đồng thông minh quản lý một số lượng lớn tài sản kỹ thuật số, khiến chúng dễ bị tấn công.

Bài viết này sẽ trình bày chi tiết về vấn đề bảo mật của hợp đồng thông minh từ ba khía cạnh: Thứ nhất, do vấn đề bảo mật của từng lớp kiến trúc Ethereum, bảo mật hợp đồng thông minh do lỗ hổng. Thứ hai, nhiều cuộc tấn công gần đây nhằm vào DeFi và hợp đồng thông minh cũng sẽ được thảo luận. Cuối cùng, chúng ta sẽ khám phá các công cụ sẵn có và các phương pháp hiệu quả khác để giảm thiểu các cuộc tấn công như vậy.

Phần 1: Hợp đồng thông minh ở các lớp khác nhau của kiến trúc Ethereum Tính dễ bị tổn thương

Tổng quan về kiến trúc Ethereum 1.0

Trước khi thảo luận về các lỗ hổng hợp đồng thông minh, trước tiên chúng ta hãy đưa ra một cái nhìn tổng quan ngắn gọn về kiến trúc hợp đồng thông minh Ethereum.

Mạng blockchain có thể triển khai và tự động hóa các tác vụ tập lệnh lập trình. Các chương trình này được gọi là hợp đồng thông minh và được sử dụng để xác định các chức năng và quy tắc tùy chỉnh được gọi trong quá trình giao dịch. Công nghệ blockchain dựa trên hợp đồng thông minh đã được áp dụng cho nhiều ngành công nghiệp khác nhau, như tài chính, quản lý chuỗi cung ứng, năng lượng chăm sóc sức khỏe và dịch vụ chính phủ. Chỉ các nền tảng blockchain cụ thể mới hỗ trợ hợp đồng thông minh: Ethereum là nền tảng đầu tiên làm như vậy. Các nền tảng blockchain khác như EOS, Lisk, Bitcoin và Hyperledger Fabric đều tương thích với việc triển khai và thực hiện các hợp đồng thông minh. Một ngôn ngữ dạng tập lệnh có tên Solidity được sử dụng để phát triển các hợp đồng thông minh trên nền tảng Ethereum. Trong phần này, chúng tôi trình bày các lỗ hổng bảo mật liên quan đến việc triển khai hợp đồng thông minh trên nền tảng Ethereum. Hợp đồng thông minh có thể nắm giữ và quản lý Tín dụng (địa chỉ) chức năng tương ứng {số lượng lớn tiền ảo có thể trị giá hàng nghìn đô la. Kết quả là, kẻ thù liên tục cố gắng thao túng việc thực hiện hợp đồng thông minh để hỗ trợ hoạt động của chúng. Về bản chất, hợp đồng thông minh chạy trên mạng phân tán và không được phép, tồn tại nhiều lỗ hổng. Trong các hệ thống truyền thống, tập hợp nhỏ các ứng dụng tập trung này có thể được phát triển lại hoặc vá lỗi.

Ngược lại, trong mạng blockchain phi tập trung, nó không thể được sửa đổi hoặc sửa đổi trong mạng thời gian thực trừ khi các biện pháp cực đoan được thực hiện . Nâng cấp các hợp đồng thông minh đã triển khai. Các đặc điểm bất biến của hợp đồng thông minh vừa là ưu điểm vừa là nhược điểm về bảo mật. Do tính bất biến này, tin tặc không thể thay đổi hoặc sửa đổi hợp đồng vì lợi ích riêng của mình. Tuy nhiên, nhà phát triển không thể sửa đổi ứng dụng hợp đồng thông minh sau khi triển khai. Họ có thể hủy hoặc chấm dứt hợp đồng và tạo hợp đồng thông minh mới rồi triển khai lại. Vì lý do bảo mật, hợp đồng thông minh cần được thử nghiệm rộng rãi trước khi triển khai. Chúng tôi nêu bật các khối xây dựng cơ bản của kiến trúc hợp đồng thông minh của Ethereum, như trong Hình 1, bao gồm kiến trúc của Ethereum.

Hình 1: Môi trường được sử dụng để chạy chuỗi khối Ethereum thông qua giao diện người dùng web tương tác với bốn lớp dịch vụ kiến trúc Ethereum, lớp ứng dụng và vùng lưu trữ A cơ sở dữ liệu dữ liệu blockchain, cơ chế mã hóa được sử dụng để hỗ trợ các giao thức đồng thuận và dịch vụ Internet cho lớp mạng [20].

a. Lớp ứng dụng: Máy khách Ethereum thực hiện các hợp đồng thông minh trong EVM, nơi các hợp đồng thông minh được liên kết với tài khoản Ethereum. Ethereum hỗ trợ hai loại tài khoản: tài khoản thuộc sở hữu bên ngoài (EOA) và tài khoản hợp đồng. EOA được sử dụng để giữ tiền của người dùng bằng Wei, đây là loại tiền nhỏ nhất của Ether và có giá trị 10-18 Ether. EOA được liên kết và giải quyết bằng khóa chung; quyền truy cập vào EOA được xác minh bằng cách hiển thị quyền sở hữu khóa riêng tương ứng. Thay vào đó, tài khoản hợp đồng được liên kết với một đoạn mã byte thực thi (tức là hợp đồng thông minh), xác định một số logic kinh doanh thú vị. Hợp đồng thông minh là nền tảng của DApps. DApp thường có giao diện người dùng làm giao diện người dùng và một số hợp đồng thông minh làm giao diện phụ trợ. Một số DApp phát hành tiền điện tử của riêng họ được gọi là mã thông báo để sử dụng trong các đợt chào bán tiền xu ban đầu (ICO) và trao đổi. Mã thông báo dựa trên Ethereum là một loại hợp đồng thông minh đặc biệt (ví dụ: ERC-20) [20]. Hợp đồng thông minh được thực thi trong EVM, là những máy hoàn chỉnh gần như Turing sử dụng kiến trúc dựa trên ngăn xếp. Thuật ngữ "gần như" có nghĩa là việc thực thi bị giới hạn bởi khí do giao dịch cung cấp. Trong lớp ứng dụng Ethereum, nhiều lỗ hổng khác nhau xảy ra, dẫn đến nhiều cuộc tấn công, như được hiển thị trong sơ đồ ở lớp ứng dụng.

b.Lớp dữ liệu: Chứa cấu trúc dữ liệu blockchain. Giao dịch là sự tương tác giữa EOA (được gọi là người gửi) và EOA hoặc tài khoản hợp đồng khác (được gọi là người nhận). Các giao dịch được chỉ định bởi:

(i) a nonce, là bộ đếm dùng để theo dõi tổng số giao dịch mà người gửi đã thực hiện;

(ii) Người nhận, người chỉ định EOA mục tiêu hoặc tài khoản hợp đồng của giao dịch;

(iii) Giá trị, là số tiền được chuyển từ người gửi đến người được trả tiền (đơn vị: Wei) (nếu áp dụng);

(iv) Đầu vào là mã byte hoặc dữ liệu tương ứng với mục đích giao dịch;

(v) gasPrice và gasLimit lần lượt chỉ định rằng người gửi sẵn sàng trả Đơn giá và lượng gas tối đa được trả bởi người khai thác chiến thắng của khối chứa giao dịch;

(vi) (v, r, s), là hình elip của người gửi. Chữ ký thuật toán chữ ký số (ECDSA). Việc thực hiện giao dịch sẽ cập nhật trạng thái của các tài khoản liên quan, từ đó cập nhật chuỗi khối.

c. Lớp đồng thuận: Đảm bảo rằng trạng thái của blockchain là nhất quán. Tại thời điểm viết bài, Ethereum mất khoảng 12-14 giây để tạo một khối, điều đó có nghĩa là nhiều thợ mỏ có thể tạo các khối hợp lệ cùng một lúc và có thể là nhiều khối. Ethereum sử dụng một biến thể của giao thức đồng thuận GHOST để chọn nhánh "nặng nhất" làm chuỗi chính, trong đó nhánh "nặng nhất" là cây con bắt nguồn từ nhánh được đề cập và có độ khó khối tích lũy cao nhất, đồng thời lưu ý đến độ cũ của khối không có trên chuỗi chính. Nhưng lưu ý rằng Ethereum thay thế việc sử dụng Proof of Work (PoW) hiện tại bằng Proof of Stake (PoS).

d. Lớp mạng: quản lý mạng lưới các nút hoặc máy khách ngang hàng Ethereum (P2P) để các nút luôn có thể có được các vùng từ một số các nút hoạt động Trạng thái cập nhật của blockchain. Mạng Ethereum là mạng P2P có cấu trúc trong đó mỗi nút (tức là máy khách) lưu trữ một bản sao của toàn bộ chuỗi khối. Để khám phá và định tuyến nút, mỗi nút duy trì một bảng định tuyến động chứa 160 nhóm, mỗi nhóm chứa các mục nhập ID, địa chỉ IP, cổng UDP/TCP của tối đa 16 nút khác. Ethereum sử dụng giao thức RLPx để khám phá các khách hàng mục tiêu và giao thức Ethereum Wired để tạo điều kiện thuận lợi cho việc trao đổi thông tin chuỗi khối Ethereum (ví dụ: giao dịch, khối) giữa các khách hàng.

e.Môi trường chuỗi khối Ethereum: chạy trong môi trường bốn lớp sau: người dùng tương tác với chuỗi khối Ethereum Một giao diện web tương tác; cơ sở dữ liệu dành cho khách hàng Ethereum để lưu trữ dữ liệu blockchain; cơ chế mã hóa vì mục đích bảo mật; và cơ sở hạ tầng internet để hỗ trợ giao tiếp blockchain giữa các nút Ethereum. Chúng tôi phân biệt kiến trúc chuỗi khối Ethereum với môi trường vì các cuộc tấn công chống lại chuỗi khối Ethereum có thể đến từ môi trường và những cuộc tấn công này có thể được xử lý tốt hơn trong môi trường thay vì bởi Ethereum.

1.1 Lỗ hổng hợp đồng thông minh Ethereum

Nó tập trung vào các lỗ hổng hợp đồng thông minh ở mỗi lớp của hệ thống Ethereum, như trong Hình 2.

Hình 2: Phân loại lỗ hổng ở mỗi lớp Ethereum

1.1.1 Lớp ứng dụng Ethereum:

Reentrancy: Lỗ hổng này ban đầu được khai thác từ cuộc tấn công DAO Đã phát hiện trong [1], lỗ hổng này xảy ra khi hợp đồng người được gọi bên ngoài gọi hàm gọi lại trong hợp đồng người gọi trước khi hợp đồng người dùng hoàn thành (tức là, theo một nghĩa nào đó, cuộc gọi vòng tròn). Điều này cho phép kẻ tấn công bỏ qua việc kiểm tra tính hợp lệ thích hợp cho đến khi hợp đồng người gọi hết ether hoặc giao dịch hết.

Chèn lệnh gọi ủy quyền: Lỗ hổng này lần đầu tiên được phát hiện từ một cuộc tấn công vào ví Parity [2]. Để tạo điều kiện thuận lợi cho việc sử dụng lại mã, EVM cung cấp lệnh gọi ủy quyền opcode để chèn mã byte của hợp đồng callee vào mã byte của hợp đồng người gọi. Kết quả là, hợp đồng callee độc hại có thể trực tiếp sửa đổi (hoặc thao túng) các biến trạng thái của hợp đồng callee. Lỗ hổng này xảy ra do hợp đồng callee có thể cập nhật các biến trạng thái của hợp đồng callee. Việc khai báo một hợp đồng không trạng thái nhằm mục đích chia sẻ dưới dạng thư viện thông qua các cuộc gọi đại biểu là hoàn toàn bảo vệ khỏi lỗ hổng này.

Đóng băng Ether: Lỗ hổng này được phát hiện lần đầu tiên sau một cuộc tấn công vào ví Parity [3]. Lỗ hổng xảy ra do người dùng không thể gửi tiền vào tài khoản hợp đồng của họ và không thể tiêu tiền từ các tài khoản này, khiến tiền của họ bị đóng băng.

Nâng cấp hợp đồng: Ý tưởng đưa ra các nâng cấp hợp đồng là để giảm bớt vấn đề là hợp đồng thông minh không thể sửa đổi sau khi triển khai, thậm chí nếu chúng được phát hiện sau đó Có sơ hở. Để cho phép nâng cấp hợp đồng, có hai cách tiếp cận: (i) chia hợp đồng thành hợp đồng proxy và hợp đồng logic để nhà phát triển có thể nâng cấp hợp đồng sau chứ không phải hợp đồng cũ; (ii) sử dụng hợp đồng đăng ký để lưu hợp đồng đã cập nhật. Các phương pháp này, mặc dù hiệu quả nhưng lại gây ra một lỗ hổng mới: khi nhà phát triển hợp đồng trở nên độc hại, hợp đồng cập nhật có thể độc hại. Lỗ hổng này (tức là cập nhật liên hệ không an toàn) vẫn là một vấn đề mở.

DoS khôi phục không mong muốn: Điều này xảy ra do hợp đồng của bên gọi gặp phải lỗi cuộc gọi bên ngoài Giao dịch được hoàn nguyên hoặc bên được gọi hợp đồng cố tình thực hiện thao tác hoàn nguyên để làm gián đoạn việc thực hiện hợp đồng của bên gọi. Lỗ hổng này là do hợp đồng người gọi thực hiện khôi phục hợp đồng người gọi. Lỗ hổng này được ngăn chặn bằng cách yêu cầu người nhận gọi một giao dịch để "rút" số tiền mà người gửi đã dành cho người nhận, ngăn chặn việc hoàn nguyên giao dịch của người gửi một cách hiệu quả.

Tràn số nguyên và tràn số nguyên: Lỗ hổng này lần đầu tiên được phát hiện trong một cuộc tấn công chống lại token BEC [4]. Điều này xảy ra khi kết quả của một hoạt động nằm ngoài phạm vi của loại dữ liệu Solidity, chẳng hạn như dẫn đến thao túng trái phép số dư của kẻ tấn công hoặc các biến trạng thái khác. Lỗ hổng này xảy ra do mã nguồn Solidity không thực hiện xác thực đúng trên các đầu vào số và cả trình biên dịch Solidity lẫn EVM đều không cung cấp khả năng phát hiện tràn/tràn số nguyên. Lỗ hổng này có thể được ngăn chặn bằng cách sử dụng thư viện SafeMath để xử lý các vấn đề này.

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.sol

Thao túng số dư: Lỗ hổng này xảy ra khi các quyết định về luồng kiểm soát của hợp đồng phụ thuộc vào giá trị này. Cân bằng hoặc cân bằng, một trạng thái cân bằng mà kẻ tấn công có thể khai thác để biến mình thành người duy nhất có quyền truy cập vào tiền. Lỗ hổng này có thể được ngăn chặn bằng cách không sử dụng số dư hợp đồng trong bất kỳ câu lệnh điều kiện nào [5]. Xác thực thông qua tx.origin: tx.origin là một biến toàn cục trong Solidity đề cập đến EOA ban đầu đã khởi tạo giao dịch được đề cập. Lỗ hổng này xảy ra khi các hợp đồng sử dụng tx.origin để ủy quyền, điều này có thể bị xâm phạm bởi các cuộc tấn công lừa đảo. Lỗ hổng này được ngăn chặn bằng cách sử dụng msg.sender thay vì tx.origin để xác thực vì msg.sender trả về tài khoản gây ra thông báo.

Mức độ hiển thị không chính xác: Chỉ định không chính xác mức độ hiển thị của một tính năng, cho phép truy cập trái phép.

Tự sát không bảo vệ: Chủ hợp đồng (hoặc bên thứ ba được ủy thác) có thể sử dụng các biện pháp tự sát hoặc tự hủy để phá hủy hợp đồng. hợp đồng . Khi hợp đồng bị hủy, mã byte và bộ nhớ liên quan của nó sẽ bị xóa. Lỗ hổng này xảy ra do xác thực không đầy đủ theo hợp đồng. Lỗ hổng này có thể được giảm thiểu bằng cách thực thi, chẳng hạn như xác thực đa yếu tố, nghĩa là hoạt động tự sát phải được nhiều bên chấp thuận.

Rò rỉ ether đến bất kỳ địa chỉ nào: Lỗ hổng này không xảy ra khi bất kỳ người gọi nào cũng có thể rút tiền của hợp đồng. , người gọi không phải là người chủ sở hữu hợp đồng cũng như nhà đầu tư đã gửi tiền vào hợp đồng. Lỗ hổng này xảy ra do không kiểm tra được danh tính của người gọi khi gọi hàm gửi Ether đến một địa chỉ tùy ý. Lỗ hổng này có thể được ngăn chặn bằng cách xác thực thích hợp các chức năng gửi tiền.

Lỗi về tính bảo mật: Trong blockchain, do tính chất công khai của blockchain (tức là mọi chi tiết giao dịch đều được mọi người biết), Hạn chế khả năng hiển thị của một biến hoặc hàm không đảm bảo rằng biến hoặc hàm đó là bí mật. Một giải pháp khả thi để ngăn chặn lỗ hổng này là sử dụng các kỹ thuật mã hóa như các cam kết theo thời gian [6].

Thông tin chữ ký không đầy đủ: Lỗ hổng này xảy ra khi chữ ký số hợp lệ cho nhiều giao dịch. Khi người gửi (Lỗ hổng này có thể xảy ra khi Alice) gửi tiền cho nhiều người nhận (thay vì thực hiện nhiều giao dịch) thông qua hợp đồng ủy quyền. Lỗ hổng này ban đầu được khai thác trong một cuộc tấn công lặp lại nhằm vào các hợp đồng thông minh. Lỗ hổng này có thể được ngăn chặn bằng cách kết hợp thông tin thích hợp như nonce và dấu thời gian trong mỗi tin nhắn.

DoS với các hoạt động không hạn chế: Lỗ hổng này lần đầu tiên được quan sát thấy trong hợp đồng Govern Mental [7].

Giá trị trả về cuộc gọi không được kiểm tra: Lỗ hổng này còn được gọi là ngoại lệ xử lý sai. Nó có hai biến thể gọi là gửi không cần gas và gửi không được kiểm tra. Điều này xảy ra khi giá trị trả về của lệnh gọi cấp thấp không được kiểm tra và việc thực thi có thể tiếp tục ngay cả khi lệnh gọi hàm đưa ra lỗi [8].

Con trỏ lưu trữ chưa được khởi tạo: Để xem xét, trong Solidity, các biến trạng thái hợp đồng luôn được đặt trong bộ lưu trữ liên tục bắt đầu từ khe 0 ở giữa. Đối với các biến cục bộ tổng hợp (ví dụ: cấu trúc, mảng hoặc ánh xạ), hãy gán tham chiếu đến một vị trí trong bộ lưu trữ đối tượng trống để trỏ đến biến trạng thái.

Tên nhà xây dựng không chính xác: Lỗ hổng này ban đầu được quan sát thấy trong hợp đồng Rubixi [9], trong đó tên nhà xây dựng không chính xác, nó khiến bất kỳ ai chủ hợp đồng. Trước phiên bản Solidity 0.4.22, một hàm được khai báo có cùng tên với hợp đồng được coi là hàm tạo hợp đồng, hàm này chỉ được thực thi khi hợp đồng được tạo.

Chuyển đổi loại: Lỗ hổng này được phát hiện lần đầu tiên vào [10]. , một hợp đồng được viết bằng ngôn ngữ Solidity có thể gọi một hợp đồng khác bằng cách tham chiếu trực tiếp một phiên bản của hợp đồng được gọi.

Phiên bản trình biên dịch lỗi thời: Xảy ra khi một hợp đồng sử dụng một trình biên dịch lỗi thời, có chứa lỗi, do đó khiến bản biên dịch bị tồn tại. Lỗ hổng này có thể được ngăn chặn bằng cách sử dụng trình biên dịch mới nhất.

Địa chỉ ngắn: Lỗ hổng này được triển khai lần đầu tiên vào [11] và được thảo luận rộng rãi.

Ether bị mất vào địa chỉ mồ côi: Ethereum bị mất vào mồ côi xảy ra khi gửi tiền, Ethereum chỉ kiểm tra độ dài của địa chỉ người nhận Không còn nữa hơn 160 bit mà không kiểm tra tính hợp lệ của địa chỉ người nhận. Nếu tiền được gửi đến một địa chỉ mồ côi không tồn tại, Ethereum sẽ tự động đăng ký địa chỉ đó thay vì chấm dứt giao dịch. Vì địa chỉ này không được liên kết với bất kỳ tài khoản EOA hoặc tài khoản hợp đồng nào nên không ai có thể rút số tiền đã chuyển và số tiền này sẽ bị mất. Lỗ hổng này là do EVM không được bảo vệ riêng biệt. Tại thời điểm viết bài, lỗ hổng này chỉ có thể được ngăn chặn bằng cách đảm bảo thủ công rằng địa chỉ người nhận là chính xác.

Giới hạn độ sâu ngăn xếp cuộc gọi: Lỗ hổng này xảy ra do mô hình thực thi EVM không đầy đủ và đã được EIP- cho điểm cứng 150 Hard fork này đã xác định lại các quy tắc tiêu thụ gas cho các cuộc gọi bên ngoài, khiến cho độ sâu ngăn xếp cuộc gọi không thể đạt tới 1.024.

Đánh giá thấp opcodes: Lỗ hổng này lần đầu tiên được phát hiện từ hai cuộc tấn công DoS [12] [13].

Sự phụ thuộc của lệnh giao dịch (hay còn gọi là chạy giao diện người dùng): Điều này đề cập đến các vấn đề tương tranh, trạng thái sắp tới của blockchain Phụ thuộc vào thứ tự thực hiện các giao dịch nhưng được xác định bởi người khai thác.

Phụ thuộc thời gian: khi hợp đồng sử dụng block.timestamp như một phần của điều kiện kích hoạt khi thực hiện một thao tác quan trọng (chẳng hạn như chuyển tiền) hoặc Lỗ hổng này xảy ra khi được sử dụng như một nguồn ngẫu nhiên có thể bị thao túng bởi những kẻ khai thác độc hại. Lỗ hổng này do Ethereum gây ra, chỉ yêu cầu dấu thời gian lớn hơn dấu thời gian của khối gốc và trong vòng 900 giây tính từ đồng hồ hiện tại.

Tạo ra tính ngẫu nhiên: Ví dụ: nhiều hợp đồng cờ bạc và xổ số chọn người chiến thắng một cách ngẫu nhiên, thường dựa trên một số hạt giống A riêng tư ban đầu (ví dụ: block.number, block.timestamp, block.difficulty hoặc blockhash) tạo ra các số giả ngẫu nhiên. Tuy nhiên, những hạt giống này hoàn toàn được kiểm soát bởi những người khai thác, điều đó có nghĩa là những người khai thác độc hại có thể thao túng các biến này để trở thành người chiến thắng. Lỗ hổng này xảy ra do nguồn entropy bị thao túng.

1.1.2 Lỗ hổng lớp dữ liệu

Chuỗi không thể phân biệt được: Lỗ hổng này lần đầu tiên được quan sát thấy từ một cuộc tấn công lặp lại chuỗi chéo khi Ethereum được chia thành hai chuỗi là ETH và ETC [13]. Hãy nhớ lại rằng Ethereum sử dụng ECDSA để ký các giao dịch. Trước hard fork EIP-155 [7], mỗi giao dịch chứa sáu trường (tức là nonce, người nhận, giá trị, đầu vào, gasPrice và gasLimit). Tuy nhiên, chữ ký số không dành riêng cho chuỗi vì thông tin dành riêng cho chuỗi thậm chí còn chưa được biết đến tại thời điểm đó. Do đó, các giao dịch được tạo cho một chuỗi có thể được sử dụng lại bởi chuỗi khác. Lỗ hổng này đã được loại bỏ bằng cách kết hợp chainID vào trường.

"Tài khoản trống" ở State Trie: Lỗ hổng này được báo cáo lần đầu tiên trong các cuộc tấn công DoS trong các tài liệu tham khảo [12] [13] được tìm thấy trong .

1.1.3 Các lỗ hổng trong lớp đồng thuận

Các vấn đề có thể thuê ngoài: Hãy nhớ lại rằng Ethereum đã áp dụng một vấn đề PoW có tên là Ethash, được thiết kế để chống lại ASIC và có thể hạn chế việc sử dụng tính toán song song (do thực tế là rằng, hầu hết công việc của người khai thác sẽ là đọc tập dữ liệu (thông qua băng thông bộ nhớ hạn chế). Tuy nhiên, một người khai thác xảo quyệt vẫn có thể chia nhiệm vụ tìm kiếm lời giải cho câu đố thành nhiều nhiệm vụ nhỏ hơn và sau đó thuê ngoài. Lỗ hổng này do Ethash gây ra, chỉ khiến lời giải câu đố tuần tự một phần trong tìm kiếm hình ảnh gốc, thay vì dựa vào PoW tuần tự.

Tính xác suất cuối cùng: Lỗ hổng này là do thiết kế của chuỗi khối Ethereum thiên về tính khả dụng hơn tính nhất quán, theo định lý CAP [ 14] Selected.

DoS với tính năng nhồi khối: Lỗ hổng này lần đầu tiên được quan sát thấy trong hợp đồng Fomo3D [15]. Lỗ hổng này chỉ dẫn đến việc các giao dịch của kẻ tấn công được đưa vào các khối mới được khai thác, trong khi các giao dịch khác bị thợ mỏ bỏ qua trong một khoảng thời gian. Điều này có thể xảy ra khi kẻ tấn công đưa ra mức giá gasPrice cao hơn để khuyến khích người khai thác chọn giao dịch của kẻ tấn công. Lỗ hổng này là do các động cơ khai thác tham lam gây ra. Tại thời điểm viết bài, không có giải pháp nào để ngăn chặn lỗ hổng này.

Kịch bản khai thác trung thực: Lỗ hổng này là do giao thức đồng thuận gây ra vì nó không tương thích với các biện pháp khuyến khích, xem [16] . Tại thời điểm viết bài này, lỗ hổng này vẫn là một vấn đề mở.

Phần thưởng khối chú: Nó đề cập đến cơ chế thưởng khối chú, được sử dụng để giải quyết sự gia tăng của các khối cũ do tạo khối nhanh chóng. . Tuy nhiên, cơ chế này có tác dụng phụ là cho phép những người khai thác ích kỷ biến các khối cũ thành khối chú và nhận phần thưởng, khuyến khích việc khai thác ích kỷ và chi tiêu gấp đôi một cách hiệu quả.

Vấn đề nan giải của Người xác minh: Lỗ hổng này được báo cáo lần đầu tiên trong tài liệu tham khảo [17] và đề cập đến vấn đề khi xác thực các giao dịch mới không yêu cầu Người khai thác sẽ có thể dễ bị tấn công bất kể họ có chọn xác minh giao dịch hay không khi thực hiện tính toán tốn nhiều công sức. Nếu người khai thác xác minh các giao dịch tốn kém về mặt tính toán, họ sẽ mất một lượng thời gian đáng kể và mang lại lợi thế cho kẻ tấn công trong cuộc đua giành khối tiếp theo; nếu người khai thác chấp nhận giao dịch mà không cần xác minh, chuỗi khối có thể chứa các giao dịch không chính xác. Lỗ hổng này xảy ra do chi phí xác minh các giao dịch yêu cầu tài nguyên trong Ethereum cao. Lỗ hổng này có thể được giảm thiểu bằng cách giới hạn số lượng tính toán cần thiết để xác minh tất cả các giao dịch trong một khối [17]. Tuy nhiên, vẫn chưa rõ làm thế nào để loại bỏ lỗ hổng này.

4. Lỗ hổng lớp mạng

4.1 Tạo nút không giới hạn : Lỗ hổng này nhắm vào các phiên bản máy khách Geth trước 1.8. Trong mạng Ethereum, mỗi nút được xác định bằng một ID duy nhất, đó là khóa công khai ECDSA 64 byte. Kẻ tấn công có thể tạo số lượng nút không giới hạn (tức là có cùng địa chỉ IP) trên một máy tính và sau đó sử dụng các nút này để độc quyền kết nối đến và đi tới các nút nạn nhân nhất định, liên kết nạn nhân với những nút khác trong mạng một cách hiệu quả. các nút ngang hàng. Lỗ hổng này xảy ra do hạn chế yếu trong quá trình tạo nút. Lỗ hổng này có thể được loại bỏ bằng cách sử dụng kết hợp địa chỉ IP và khóa chung làm ID nút. Các nhà phát triển Geth vẫn chưa áp dụng biện pháp đối phó này vì tin rằng nó có tác động tiêu cực đến khả năng sử dụng của khách hàng.

4.2 Kết nối đến không hạn chế: Lỗ hổng này tồn tại trong ứng dụng khách Geth trước phiên bản 1.8 [18]. Mỗi nút có thể có tổng số kết nối maxpeers tại bất kỳ thời điểm nào (mặc định là 25) và có thể bắt đầu tối đa 1 (1 + maxpeers)/2⌋ kết nối TCP gửi đi với các nút khác. Tuy nhiên, không có giới hạn trên về số lượng kết nối TCP đến được khởi tạo bởi các nút khác. Bằng cách thiết lập nhiều kết nối đến cho maxpeer tới nút nạn nhân mà không có kết nối ra bên ngoài, kẻ tấn công có cơ hội làm lu mờ nạn nhân. Trong Geth v1.8, lỗ hổng này được loại bỏ bằng cách thực thi giới hạn về số lượng kết nối TCP đến một nút, với giá trị mặc định là ⌊maxpeers/3⌋= 8.

4.3 Lựa chọn ngang hàng công khai: Lỗ hổng này được phát hiện trong các phiên bản máy khách Geth trước 1.8[18] .

4.4 Lựa chọn ngang hàng: Lỗ hổng này đề cập đến bảng định tuyến của máy khách Geth Khi chọn nút để thiết lập một kết nối ra ngoài, luôn lấy phần đầu của nhóm được chọn ngẫu nhiên. Vì các nút trong mỗi nhóm được sắp xếp theo hoạt động nên kẻ tấn công có thể giữ nút của chúng dẫn trước các nút khác bằng cách gửi tin nhắn định kỳ đến máy khách Geth. Lỗ hổng này đã được loại bỏ trong Geth v1.9 bằng cách chọn ngẫu nhiên một nút thống nhất từ tập hợp tất cả các nút trong bảng định tuyến, thay vì chỉ chọn ngẫu nhiên một nút từ đầu mỗi nhóm.

4.5 Đồng bộ hóa khối độc lập: Nó cho phép kẻ tấn công phân vùng mạng Ethereum P2P mà không độc quyền kết nối của máy khách nạn nhân. Hãy nhớ lại rằng mỗi tiêu đề khối chứa một trường độ khó ghi lại độ khó khi khai thác khối đó. Tổng độ khó của chuỗi khối được thể hiện bằng tổng độ khó, là tổng độ khó của khối hiện tại.

4.6 Lộ diện API RPC: Lỗ hổng này ban đầu được phát hiện thông qua các cuộc tấn công vào ứng dụng khách Geth và Parity [19].

Trích dẫn:

[1] https://www.coindesk.com/ sự hiểu biết-dao-hack-nhà báo

[2]https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it- đã xảy ra và điều đó có nghĩa là gì-for-ethereum-9e5dc29e33ce/

[3] https://medium.com/blockcat/on-the-parity-multi-sig-wallet-Attack-83fb5e7f4b8c

[4 ] https://nvd.nist.gov/vuln/detail/CVE-2018-10299

[5]https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid- they-part-2-730db0aa4834

[6] https://eprint.iacr .org/2016/1007.pdf

[7]https ://www.reddit.com/r/ethereum/comments/4ghzhv/ Governments_1100_eth_jackpot_payout_is_stuck/

[8]https://github.com/KadenZipfel/smart-contract-Attack-vectors/blob/master/vulnerabilities/unchecked-call -return-value.md

[9]https://medium.com/hackernoon/hackpedia-16-solidity-hacks-vulnerabilities-their-fixes-and-real-world-examples-f3210eba5148

[10]https://medium.com /golem-project/how-to-find-10m-by-just-reading-blockchain-6ae9d39fcd95

[11]https://medium.com/loom-network/ cách bảo mật-hợp đồng thông minh của bạn-6-sự vững chắc-vulnerabilities-và-cách-tránh-chúng-part-2-730db0aa4834

[12] https://blog.ethereum.org/2016/09/22/transaction-spam- attack-next-steps/

[13] https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513?gi=3b0603be9186

[14] https://dl.acm.org/doi/10.1145/3149.214121

[15]https://medium.com/coinmonks/how-the-winner-got-fomo3d-prize-a-detailed- lời giải thích-b30a69b7813f

[16] https://dl.acm.org/doi /10.1145/3212998

[17] https://dl.acm.org/ doi/10.1145/2810103.2813659

[18]https://ljk.imag.fr/membres/Jean-Guillaume.Dumas/Enseignements/ProjetsCrypto/Ethereum/236.pdf

[19] https://mp.weixin.qq.com/s/ia9nBhmqVEXiiQdFrjzmyg

[20] https://dl.acm.org/doi/fullHtml/10.1145/3391195

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