Khóa luận tốt nghiệp An toàn thông tin: Phát hiện và phân loại lỗ hổng và mã độc trong hợp đồng thông minh của mạng Blockchain sử dụng các mô hình học sâu Multi-Model và Transfer Learning

LỜI CẢM ƠNViệc hoàn thành đề tài “Phát hiện và phân loại lỗ hồng và mã độc trong hợp đồngthông minh của mang blockchain sử dụng các mô hình hoc sâu Multi-model vàTransfer Learning” quả t

ĐẠI HỌC QUÓC GIA TP HÒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA MẠNG MAY TÍNH VÀ TRUYEN THONG

TRAN DANG HONG LOAN - 20521543

LE NHAT HAO - 20520489

KHOA LUAN TOT NGHIEP

PHAT HIỆN VA PHAN LOẠI LO HONG VA MA ĐỘC

TRONG HOP DONG THONG MINH CUA MANG

BLOCKCHAIN SU DUNG CAC MO HINH HOC SAU

MULTI-MODEL VA TRANSFER LEARNING

Detection and Classification of Vulnerabilities and Malware in

Blockchain Smart Contracts using Multi-model and Transfer

Learning Deep Learning Models

CU NHAN NGANH AN TOAN THONG TIN

GIANG VIEN HUONG DAN

NGUYEN NGỌC TỰ

TP HÒ CHÍ MINH, 2024

LỜI CẢM ƠN

Việc hoàn thành đề tài “Phát hiện và phân loại lỗ hồng và mã độc trong hợp đồngthông minh của mang blockchain sử dụng các mô hình hoc sâu Multi-model vàTransfer Learning” quả thật là một hành trình đầy gian nan và thử thách, đánhdấu bước ngoặt trong quá trình học tập và nghiên cứu của chúng em tại KhoaMạng máy tính và Truyền thông, Trường Đại học Công nghệ thông tin - ĐHQGTPHCM Với tình cảm chân thành và lòng biết ơn sâu sắc, chúng em xin gửi lờicảm ơn đến:

Ban Giám Hiệu Trường Đại học Công nghệ thông tin - ĐHQG TPHCM, Khoa

Mạng máy tính và Truyền thông cùng với đội ngũ giảng viên nhiệt huyết đã tạo

ra một môi trường học tập xuất sắc Sự hỗ trợ và truyền đạt kiến thức của quýthầy cô đã tạo điều kiện cho chúng em tiếp cận những kiến thức mới và tích lũykinh nghiệm quý báu cho quá trình nghiên cứu và hoàn thành khóa luận tốt nghiệpmột cách hoàn chỉnh.

Chúng em muốn bày tỏ lòng biết ơn đặc biệt đến Tiến sĩ Nguyễn Ngọc Tự, người

thầy đáng kính đã luôn hỗ trợ, tận tình hướng dẫn và truyền đạt những kiến thức

chuyên môn sâu rộng Sự tận tâm và những góp ý quý báu của thầy đã giúp chúng

em vượt qua rất nhiều khó khăn trong công việc và hoàn thành nghiên cứu với kếtquả tốt nhất Một lần nữa, chúng em xin chân thành cảm ơn thầy rất nhiêu

Chúng em hi vọng rằng với những nỗ lực không ngừng, khóa luận tốt nghiệp này sẽđóng góp một phần nhỏ bé vào sự phát triển của lĩnh vực Blockchain và an ninhmạng Chúng em cũng mong muốn sẽ nhận được sự góp ý chân thành từ quý thầy cô

và các chuyên gia dé có thé hoàn thiện hơn trong tương lai

Lời sau cùng, em xin kính chúc quý thầy cô trong Khoa Mạng máy tính và Truyềnthông, Ban Giám Hiệu nhà trường sức khỏe déi dào, vững bước trên con đườngnghiên cứu và giảng dạy, gặt hái nhiều thành công trong sự nghiệp

TP.Hồ Chí Minh, ngày 15 tháng 06 năm 2024

MỤC LỤC

Chương 1 PHAN MỞ ĐẦU -.e22ttceettreettrretrrierrtrirrrrrrrrrrrrrrrrree 3

1.1 Bảo mật hop đồng thông minh trong mang Blockchain 3

1.2 Cac khái niệm về lỗ hổng và mã độc trong hợp đồng thông minh 4

1.2.1 Vulnerable smart COTItTACES ccsecccrerirrrirrkrritrirtrrirrrrrrrrriee 4 1.2.2 Malicious Smart CONTACẲS eccccccesriiekirtiiiiiriiiiiiriiee 4 1.3 Phát hiện và phân loại lỗ hổng và mã độc trong hợp đồng thông minh Ss -4-453+44ÝẢÝ 4 1.4 Mục tiêu và phạm Vi đề tài -sececccxveeertrrtestrrrrrirtrrrrrrrrrrrrie 6 In ẽ (0i h6 6

1.4.2 Phạm vi đề tài -. -e-©ccceecc©xeererxetrtretrrreerrrrerrrrrerrrrrerrrreesrie 6 Chương 2 KIEN TRÚC MẠNG BLOCKCHAIN VÀ CÁC VẤN DE BẢO MAT TRONG HỢP ĐỒNG THONG MINH 2:-:+cec2t++eeEEEteSEEEEreEEEErrevrrrirset 8 2.1 Kiến trúc mạng Blockchain -cccvecce+ccvvvvveveteerrrvveesserrrrrrreerree 8 2.1.1 Tổng quan kiến trúc mạng Blockchain -‹ccece- 8 2.1.2 Co chế hoạt động của Blockchain c-seeecccvesscsreeesee 9 2.1.3 Phan tích rủi ro trong hệ thống Blockchain 10

2.1.4 Phan loại và đặc điểm các loại Blockchain - 10

2.2 Các vấn dé bảo mật trong hợp đồng thông minh . - 12

2.2.1 Một số lỗ hổng theo OWASP Smart Contract Top 10 12

2.2.2 Một số loại lỗ hổng bảo mật khác và mã độc trong hợp đồng thông

minh 14

2.2.3 Các phương pháp bảo mật cho hợp đồng thơng minh 18

Chương 3 CAC GIẢI PHÁP ĐỀ XUẤT -22::csetreeetrrerrrrerrrrrerrre 20

3.1 Phương pháp đề xuất cccceecrirrrrrrriiiiiiiiirirriiriiiiirirriee 20

3.2 Phân nhĩm lỗ hổng và trích xuất các đặc trưng trong hợp đồng thơng

mỉnh SỌÏdÏty - xen Hrrrtrrkrrrrrrrrrreee 20

3.2.1 Ly do phân nhĩm lỗ hổng trong hợp đồng thơng minh 20 3.2.2 Mơ tả phương pháp phân nhĩm lỗ hổng - 21 3.2.3 Các nhĩm lỗ hổng và mã độc trong hợp đồng thơng minh 27

3.3 Mơ hình đề xuất .ccc cccrrkerrritrrrriiiirirtriiiirriiriiiirrrrrrrree 35

3.3.1 Self-attention heads (ROBERTa) + RNN + CNN + BiLSTM 35

3.4 Mơi trường thực nghiỆm cs-ss+xxeerxeerrveetrerrtrtrrsrrrrrrrrrrrrrerrke 39 3.5 BO dữ liệu và quá trình xử lý dữ liệu -cccccceccseereeerrsrrres 40

3.5.1 Nguồn gốc và mơ tả bộ dữ liệu -.sccceccccccvveeeerre 40

3.5.2 Qua trình xử lý dữ liệu ceccceecrieekieeriririerririrerrrrke 41

Chương 4 KET QUA THỰC NGHIỆM VÀ ĐÁNH GIÁ -:-s 46

4.1 Kết quả thực nghiệm -cccccsccrkkktrrrtrtrriiirririiirrrrrrrree 46

4.1.1 Kịch bản(U ecccceeeeerriirrrrtrirrrrrrrirrrrrririrrrrirrrrrrrrrrree 46 4.1.2 Kịch bản 1 c.cckHHHHHHHHHHHH re 50 4.1.3 Kịch bản 2 ii re 55

4.1.4 Kịch bản 3 - eeHHHHHHHHH re 59

4.2 Phan tích và so sánh kết quả ccsecccveeeccvveeseerrvessrtrrresree 64 4.3 So sánh đề tài với các cơng trình nghiên cứu liên quan 65

4.4 _ Triển khai hệ thống và demo -cccccvvvvvveveeerierrrrrrrrrrrerrrrrrrrree 66

4.4.1 _ Triển khai hệ thống cccccccreerrrkiiiiiirrrriiriiiiiirrree 66

TÀI LIEU THAM KHẢO -++++c22SSEEEEEEEE.24E11111271211 41111121211 1111111.1 xe 72

PHỤ LỤC Z2 R 82

DANH MỤC HÌNH ẢNH

Hình 2.1 Kết nối các block trong Blockchain .-. -ccss-eccesree 8Hình 2.2 Layer structure of Ethereum blockchain « sscxsexxexxeexxerreserkeee 9 Hình 2.3 Structure of an Ethereum blockchain node -« -e<e-xeseres 9 Hình 2.4 Public blockchaIn csscccssccxxeerxtrrtetkrtrttrtrtkrtrrkrrtirrrrirrrrirrrierrriee 11 Hình 2.5 Private Blockchain -s«-csscrxkrkiitrkrtrkirtrriirttritrkirrirrierrrierrierrriee 11

Hình 2.6 Consortium BlockCha1T -s -s-5sscssrxserxerretrrrtrrerrerrrrrrtrrrrrrrrrrsrrrerrreee 12

Hình 2.7 Lỗ hỗng unchecked send -.+cccstirreceetrrecvetrrrrerrrrerrrrre 15

Hình 2.8 Dangerous Delegate Call in Parity Wallet Contract - 15

Hình 2.9 Lỗ hồng Transaction Ordering Dependence (TOD) - 16Hình 2.10 Lỗ hồng tx origin authentication ccsssssssssessseeessseessassssssssssessssssesasssessasesees 17Hình 2.11 Lỗ hồng out of gas -+ccccccerrreeeecerrrreeerrrrrrirrrerrrrrrrrrrrre 17Hình 3.1 Các đặc trưng tương đồng của 2 lỗ hông Reentrancy va Unchecked

€X{€TrnaÌÏ Ca]ÏÌÏ -.-s- 5< c<+xSE E4 HE HH HH HH HH H111 1etrk 22

Hình 3.2 Các đặc trưng được trích xuất từ một file .sol ic-cccecccerrrrree 30Hình 3.3 Các hàm được trích xuất từ đặc trưng reentrancy_guard_missing 30Hình 3.4 Các đặc trưng viết đưới dạng biéu thức chính quy của nhóm Interaction

and Contract State VulnerabiÏ1(I€S -s-ss-s+srxssrxeekrttrrtrtrtrtrrrrrrirrrrrrrrrrrrrrkrrriree 31Hình 3.5 Các đặc trưng viết đưới dang biểu thức chính quy của nhóm Dependency

Vile ri 1 31

Hình 3.6 Các đặc trưng viết đưới dạng biểu thức chính quy của nhóm

Authentication and Authorization Vulnerabilities -« ccscceesreexeserkeereee 32Hình 3.7 Các đặc trưng viết đưới dang biéu thức chính quy của nhóm Resource GasUsage Vuln€rabDIÏIVIS « «+s<+x+£rx+£rks+rkExrtEkketkkstrkstrkktrrkrrtkkrrkrriirrrrirrrrkrrrkrree 32Hình 3.8 Các đặc trưng viết dưới dang biéu thức chính quy của nhóm Arithmetic

'VulnerabÏ1LI€S « sscccx+ccxt trưng HH trrkrtrrerrrkerrrkee 33 Hình 3.9 Phân loại theo các danh sách -. ee-cscccecertertsetsersertsttserererrrrsrrrrree 33 Hình 3.10 Phân loại đặc trưng theo Black LLISỂ -. -5-e-5cccsereerrresrrerxrxee 34

Hình 3.11 Phân loại đặc trưng theo White LLIS cccccc<sreerieerrekreekreree 34 Hình 3.12 Phân loại đặc trưng theo Grey LLIS -ccccccserxerererrrsrrrrrrree 34

Hình 3.13 Mô hình tổng quan -. +cc52i+eceS2trevEtttrervttrrrvrtrtrrrvrrrrrrrrrrrrrte 35

Hình 3.14 Mô hình Self-attention heads (ROBERTa) + RNN + CNN + BiLSTM.35Hình 3.15 Mã dùng dé triển khai mô hình -:-ccccetrrceeevvtrrrresevrrrrreeeerr 36Hình 3.16 Quá trình tiền xử lý dit liệu 2-+eccetrreceetrrererrrrrrerrrrreerre 41Hình 3.17 Biểu thức chính quy dùng dé tokenize và ham dé lưu token lại 42Hình 3.18 Tách từ theo camelCase và snake_case và chuyên token sang ids 43

Hình 3.19 Xây dựng và cập nhật lai vocab dựa trên tập dữ liệu 43

Hình 4.1 Dataset của kịch bản ( e-ccsccccrsereextstrstrkerkertrttrrrkrttrtkrrrrrsrrkrrrrrrsrree 46 Hình 4.2 confusion matrix của kịch bản Ô -. s-csccs+secseeseesrtsrtersersrssrsersersrssrsee 46Hình 4.3 biểu đồ f1 của kịch bản ( -cexeesceeririiriiriiriiriiriirirrrrri 47Hình 4.4 biểu đồ precision của kịch bản ( -+ceecccerrrreeevvrrrrrcrevrrrrrarerrr 48Hình 4.5 biểu đồ recall của kịch bản ( e-ceieriririrrriirirrirrrie 48Hình 4.6 biểu đồ roc auc của kịch bản ( cvvv2VEEEEEEEEtEtttttrrreeevevvvvveevvrrrrrrrrer 49

Hình 4.7 biểu đồ validation của kịch bản ( +iieceevvvvvrrrttrreeevvvrrtrrrrrreeee 50

Hình 4.8 Confusion matrix của kịch bản 1 -ec-e<c<scecexesxxeerxerereerserreree 51

Hình 4.9 Biểu đồ roc auc của kịch bản Ì -cccccvvvvvvvvvvvEEEEEEEEEttttttttrreeeexevevee 52Hình 4.10 Biểu đồ recall của kịch bản I eeeeersereereeriririrrirrrrr 52Hình 4.11 Biểu đồ f1 của kịch bản l seeerereererririrrirrrrrrre 53Hình 4.12 Biểu đồ precision của kịch bản l -i ccecciceeeceerrreecevrrrrreeeerr 54Hình 4.13 Biéu đồ validation của kịch bản l ccccccciiiieeeeeeeeevevvvvvvvvvverrrrrrer 54Hình 4.14 Confusion matrix của kịch bản 2 « sc-esccscsecssxesreserserserssrssrrsrree 56Hình 4.15 Biểu đồ f1 của kịch bản 2 -«.-ctierieerieriiriiriiririrerrire 56Hình 4.16 Biểu đồ precission của kịch bản 2 -i-ccccetriceecvverrrreeerrtrrrreeerr 57Hình 4.17 Biểu đồ recall của kịch bản 2 -eecserierierieeririiririrrirrrrr 58Hình 4.18 Biéu đồ roc auc của kịch bản 2 ccvvvccccrttttttttttreeevevvvvvvvvvrrrrrrrrr 58Hình 4.19 Biểu đồ validation mertrics của kịch bản 2 -i-cccccccecrrricieces 59Hình 4.20 Biểu đồ f1 của kịch bản 3 ccccccccvv222EEEEEEEE21222 trkvvvevvkrrrrrrrrer 60

Hình 4.21 Biểu đồ roc_auc của kịch bản 3 ccccvccccctttttttttteeevvvvvvvvvvvrrrrrrrrr 61Hình 4.22 Biểu đồ validation metrics của kịch bản 3 -cssrccccssee 61Hình 4.23 Confusion matrix của kịch bản 3 « c c«+ccrexeexeerrerererrsrrrrrkee 62Hình 4.24 Biểu đồ precision của kịch bản 3 -. cc22+iecccccrrrreccerrrrrrcrrrrr 63Hình 4.25 Biểu đồ recall của kịch bản 3 2 +cccstrreceetrrererrrrrrerrrrererre 63Hình 4.27 Kiến trúc hệ thống -22i+cccSttirrerEEEtrvrEErrrrrrtrrrrrtrrrrrrrrrrrrrrre 67

Hình 4.28 giao diện hệ thống 22.+ccc2tireevEEttrvvvtrtdrvrrrtrrvtrrrrrrtrirrrerre 68

Hình 4.29 người dùng tải file lên hệ thống -22++ecsst+reeceerrrererrrrererrre 68Hình 4.30 kết quả sau khi phân tích 2ett2t.ettreEttrrererierrerereer 69

DANH MỤC BANG

Bang 2.1 Mô tả 10 lỗ hồng hàng đầu trong hợp đồng thông minh OWASP 14Bảng 3.1 Kết quả phân nhóm lỗ hồng -22.+cc22i+recSEtrrervvtrrrrerrrrrrrrre 22Bảng 3.2 Trích xuất các đặc trưng và lấy các đặc trưng tương đồng 27Bảng 3.3 Nhóm Interaction and Contract State Vulnerabilifies ‹ - 27 Bảng 3.4 Nhóm Dependency Vulnerabilities -cccesereereerretrrereeree 28

Bảng 3.5 Nhóm Authentication and Authorization VulnerabilitIes 29

Bảng 3.6 Nhóm Resource Gas usage vulnerabilities -« -«s-ceexeeerxeerxeee 29Bang 3.7 S6 Luong 0 41Bảng 4.1 Dataset của kịch bản 1 un sessssecssecssecssesssessessseessecssesseesseesseesteeseesaseessesaeesseeseeseenasees 50

Bang 4.2 Dataset của kịch bản 2 wessesssssessssessessseesseesssessseessssesseesseessseessseesasersseerseesanesssessans 55

Bang 4.3 Dataset của kịch bản 3 -cccccxcerirtrirrrrkrrtrirtirririirrrrrrrrrrrrree 60 Bang 4.4 Bang so sánh giữa 4 kịch Dan esesssesseessesssessssesseesstessseessseesateesnseesseesstessaeesaes 64 Bảng 4.5 Bảng SO sánh -cccccsccc cv th tr tr HH gà HH ng nriưkg 65

DANH MỤC TU VIET TAT

Từ viết tắt Giải thích

BERT Bidirectional Encoder Representations from

Transformers

BiLSTM Bidirectional Long Short-Term Memory

CNN Convolutional Neural Network

DAO Decentralized Autonomous Organization

DApps Decentralized application

DL Deep learning

DoS Denial of service

loT Internet of things

ML Machine learning

OWASP The Open web application security project

PoS Proof of stake

PoW Proof of work

RNN Recurrent neural network

RoBERTa Robustly Optimized BERT Approach

TOD Transaction ordering dependence

TÓM TẮT KHÓA LUẬN

Công nghệ Blockchain và các ứng dụng phi tập trung( DApps) đã phát triển với tốc

độ nhanh chóng trong những năm gần đây, thu hút sự chú ý đáng ké trong cả lĩnh vựcnghiên cứu học thuật và các ứng dụng công nghiệp [1] Hợp đồng thông minh (Smartcontracts) được đề xuất bởi nhà mật mã học Szabo [2] vào năm 1977 Đây là loại hợpđồng đóng vai trò quan trọng trong mạng lưới Blockchain bằng cách cho phép cácgiao dịch và thỏa thuận được tự động hóa một cách minh bach và đáng tin cậy Chínhđiều này đã giúp công nghệ Blockchain không chỉ áp dụng trong lĩnh vực tiền điện

tử mà còn mở rộng ra nhiều lĩnh vực khác nhau như chăm sóc sức khỏe, Internet of

Things (IoT), chuỗi cung ứng, nhận dạng kỹ thuật số và quản lý quy trình kinh doanh

[1]

Tuy nhiên, hợp đồng thông minh cũng mang theo nhiều rủi ro về bảo mật, như các lỗhồng tiềm ân có thé bị khai thác bởi tin tặc, gây thiệt hại hàng tỷ đô la trong thập ky

qua Nhiều cuộc tan công nhằm vào hợp đồng thông minh đã gây thiệt hại nặng nề về

tài chính và uy tín của các tô chức hoặc cá nhân liên quan [3] Do đó, việc nâng caocảnh giác và triển khai biện pháp bảo mật hiệu quả là rất cần thiết dé bảo vệ hệ thốngBlockchain khỏi những mối de dọa tiềm ẩn

Đề giải quyết vấn đề này, khóa luận của chúng em đề xuất nghiên cứu và phát triểncác phương pháp phát hiện và phân loại lỗ hồng va mã độc trong hợp đồng thôngminh dựa trên các mô hình học sâu tiên tiến, cụ thé là Multi-model và kỹ thuật

Transfer Learning Phương pháp Multi-model [4] [5] kết hợp nhiều mô hình học sâu

khác nhau, việc lựa chọn sắp xếp tốt nhất cho các thành phần của mô hình cũng nhưlựa chọn các thành phan tốt nhất như biểu diễn đầu vào khác nhau, nhúng từ và môhình học sâu rất quan trọng dé phân tích và phat hiện lỗ hồng từ nhiều góc độ, từ đóđưa ra dự đoán cuối cùng một cách chính xác và hiệu quả

Transfer Learning là phương pháp học máy mà trong đó kiến thức từ nhiệm vụ nàyđược áp dụng dé cải thiện mô hình khi giải quyết nhiệm vụ khác có liên quan Điềunày cho phép tái sử dụng mô hình trong nhiều ngữ cảnh khác nhau, tiết kiệm thời

gian và tài nguyên, đồng thời cải thiện hiệu suất và độ chính xác trong phát hiện và phân loại lỗ hổng va mã độc trong hợp đồng thông minh.

Sau quá trình nghiên cứu và triển khai, mô hình đề xuất của chúng em đã đạt được

độ chính xác cao trong việc phát hiện và phân loại các nhóm lỗ hồng và mã độc trong

hợp đồng thông minh, vượt trội so với các phương pháp ở thời điểm hiện tại Kết quả

của khóa luận này đóng góp vào việc nâng cao bảo mật và đáng tin cậy hơn trong

mạng Blockchain, góp phan cho sự phát triển mạnh mẽ của công nghệ chuỗi khối vàcác úng dụng phi tập trung trong tương lai Hướng nghiên cứu tương lai của chúng

em sẽ tập trung vào việc tối ưu hóa và mở rộng mô hình hiện tại, tăng cường khả năng

xử lý và phân tích dữ liệu lớn, cải thiện độ chính xác và tốc độ phân loại, cũng nhưtích hợp vào các nền tảng phát triển hợp đồng thông minh phô biến Chúng em cũng

sẽ nghiên cứu các phương pháp mới dé tự động hóa quá trình gan nhãn và phân loại,nhăm nâng cao hiệu quả và tính ứng dụng thực tê của mô hình.

Chương 1 PHAN MỞ ĐẦU

1.1 Bảo mật hợp đồng thông minh trong mạng Blockchain

Hợp đồng thông minh (Smart Contract) là một đoạn mã tự động chạy trên Blockchain

dé thực hiện thỏa thuận giữa các bên tham gia giao dịch Các hợp đồng thông minh

được ứng dụng trong nhiều lĩnh vực như trao đổi tài sản kỹ thuật số, chuỗi cung ứng,huy động vốn cộng đồng và sở hữu trí tuệ Tuy nhiên chỉ cần xảy ra một 16 hongtrong mã của hợp đồng cũng có thé bị khai thác bởi kẻ tan công, dẫn đến các van dénghiêm trọng như mất tiền hay rò rỉ thông tin cá nhân [1] Dé tránh những rủi ro này,đặc biệt là tổn thất tài chính đáng ké, bắt buộc phải tiến hành kiểm tra kỹ lưỡng mã

và các khía cạnh khác trong hợp đồng thông minh

Một ví dụ điển hình là vụ tấn công vào DAO (Decentralized Autonomous

Organization), một hợp đồng thông minh nỗi tiếng của Ethereum, một trong những

nền tang Blockchain được sử dụng rộng rãi nhất , vào thang 6 năm 2016 Do lỗi trong

mã nguồn của DAO đã khiến hợp đồng này bị tan công, gây thiệt hại lên đến 60 triệuUSD Kẻ tấn công đã khai thác lỗ hồng tái nhập (Reentrancy vulnerability) bằng cáchgọi đệ quy hàm phân chia DAO nhiều lần trước khi hàm này kịp cập nhật số dư mới,

từ đó chuyên Ether vào tài khoản của kẻ tấn công mà không làm giảm số dư trong

hợp đồng ban dau [1] Điều này đã làm cho DAO mat hàng triệu USD mà không thékhôi phục được Năm 2017, một lỗ hồng trong hợp đồng ví Parity đã khiến ngườidùng mat 31 triệu USD Năm 2018, tin tặc lợi dụng lỗ hồng tràn số nguyên trong hợpđồng thông minh ERC-20 của Ethereum để tạo ra một lượng lớn token BEC do công

ty United States Chain phát hành, khiến giá trị thị trường của nó giảm gần như bằng

0 Theo thống kê từ trang web của SlowMist, các cuộc tan công vào hợp đồng thôngminh Ethereum đã gây ra tổng thiệt hại hơn 3,1 ty USD tính đến năm 2023

Với những sự cố về bảo mật Blockchain xảy ra thường xuyên và tài sản số liên quan

đến hợp đồng thông minh ngày càng tăng, vấn đề về các lỗ hồng trong hợp đồngthông minh đã thu hút sự chú ý của nhiều cá nhân và tổ chức liên quan hơn Do đặcđiểm của hợp đồng thông minh là không thê can thiệp và tự động thực thi, nên tài sản

bị đánh cắp sẽ khó thu hồi lại được khi xảy ra vẫn đề bảo mật trong hợp đồng thông

minh Do đó việc phát hiện các lỗ hồng bảo mật và mã độc tiềm ẩn trước khi triển

khai là rất cần thiết để đảm bảo tính bảo mật của hợp đồng thông minh và an toàn cholợi ích tài sản của các bên tham gia.

1.2 Các khái niệm về lỗ hong và mã độc trong hợp đồng thông minh

1.2.1 Vulnerable smart contracts

Hợp đồng thông minh có chứa lỗ hồng (Vulnerable smart contracts) là những hợp

đồng có điểm yếu hoặc sai sót trong mã hoặc thiết kế mà kẻ tấn công có thể tận

dụng đề khai thác Những lỗ hồng này có thé xảy ra do lỗi lập trình, các biện pháp

bảo mật không đầy đủ hoặc tương tác không mong muốn với các hợp đồng khác

hoặc đầu vào bên ngoài Các lỗ hổng phô biến trong hợp đồng thông minh bao gồmReentrancy, Integer Overflow/Underflow va Improper Access Control

1.2.2 Malicious smart contracts

Hop đồng thông minh có chứa mã độc (Malicious smart contracts) là những hợp

đồng được thiết kế có chủ đích dé thực hiện các hành động độc hại, lừa dối người

dùng hoặc khai thác lỗ hồng trong các hợp đồng hoặc hệ thống khác Những hợp

đồng này thường được những kẻ tấn công tạo ra đề đánh cắp tiền, thu thập các

thông tin nhạy cảm hay đơn giản là làm gián đoạn các hoạt động của blockchain.

Hợp đồng thông minh có chứa mã độc có thể chứa hidden backdoors, misleading

functions hoặc logic có lợi cho kẻ tan công nhưng lại gây thiệc hại cho những ngườikhác Payloads phổ biến được sử dụng trong malicious smart contracts bao gồm

Hidden Backdoors, False Return Values, Logic Bombs, Phishing Contracts, Sybil

Attack Vectors, Gas Limit Exploitation.

1.3 Phat hiện và phân loại lỗ hong va mã độc trong hop đồng thông minh

Solidity

Phát hiện và phân loại lỗ hong và mã độc trong hợp đồng thông minh Solidity đóngvai trò quan trọng trong việc nâng cao tính bao mật cho các ứng dụng trên nên tang

Blockchain Các phương pháp phát hiện lỗ hồng và mã độc trong hợp đồng thông

minh hiện tại chủ yếu dựa trên các phương pháp phát hiện lỗ hồng truyền thống của

các chương trình thông thường, thường chỉ sử dụng phân tích tĩnh và các kỹ thuậtthực thi động để phát hiện Những phương pháp này thường dựa vào kinh nghiệmcủa chuyên gia và gặp phải các vấn đề như tự động hóa thấp, hiệu quả thấp và thiếu

linh hoạt.

Trong những năm gần đây, với sự phát triển nhanh chóng của học sâu (deep learning),việc sử dụng công nghệ học sâu để phát hiện lỗ hồng và mã độc của hợp đồng thôngminh đã trở thành một chủ đề nghiên cứu nóng Công nghệ phát hiện lỗ hồng và mã

độc dựa trên học sâu có thé khắc phục được các hạn chế về tự động hóa thấp, hiệu

quả thấp và phụ thuộc vào kiến thức chuyên môn của các phương pháp truyền thống.Tuy nhiên, hầu hết các phương pháp học sâu hiện tại chỉ tập trung vào một khía cạnh

dữ liệu của hợp đồng thông minh và không thể khai thác hết thông tin lỗ hồng Vìvậy, trong nghiên cứu này, chúng em đề xuất kết hợp cả mô hình học sâu Multi-model

và kỹ thuật Transfer Learning đề thiết kế bộ phân loại đa nhãn, cho phép mô hình cóthể kết hợp nhiều lớp cũng như tinh chỉnh và huấn luyện trên các tập dữ liệu lớn với

nhiều nhãn lỗ hông khác nhau, dé dàng mở rộng dé phát hiện các nhóm lỗ hồng mới

với dữ liệu hạn chế Khi có lỗ hồng mới, chỉ cần thêm nhánh nhóm mới vào trìnhtrích xuất tính năng và huấn luyện với dữ liệu giới hạn Phương pháp này phát hiện

lỗ hồng mới với chi phí tối thiểu cho việc sửa đổi và huấn luyện lại mô hình, giúpphát hiện và phân loại các nhóm lỗ hồng và mã độc một cách hiệu quả và nhanh hơn

so với các phương pháp phát hiện lỗ hổng và mã độc trong hợp đồng thông minhtruyền thống

Multi-1.4.1.2 Mục tiêu cụ thể

e Nâng cao hiệu quả phát hiện lỗ hồng bảo mật thông qua việc tối ưu hóa các

mô hình học sâu.

e Phân nhóm các lỗ hồng dựa trên các đặc trưng tương đồng dé tối ưu hóa quá

trình phát hiện và phân loại, giúp tăng hiệu quả mô hình và có khả năng mở

rong.

e Xây dựng bộ dữ liệu đa dang và toàn diện về các lỗ hồng trong hop đồng thông

minh dé huấn luyện và đánh giá mô hình

e_ So sánh hiệu quả của phương pháp đề xuất với các phương pháp hiện có trong

lĩnh vực phát hiện và phân loại lỗ hồng trong hợp đồng thông minh

e Đóng góp vào việc bảo mật trong mạng Blockchain thông qua việc phát hiện

và ngăn chặn sớm các lỗ hồng bảo mật tiềm an

1.4.2 Pham vi đề tài

1.4.2.1 Đối tượng nghiên cứu

e_ Hợp đồng thông minh Solidity trên nền tảng Ethereum

e Đề tài sẽ tập trung vào việc phát hiện và phân nhóm 14 loại lỗ hồng và mã độc

phổ biến trong hợp đồng thông minh Solidity, bao gồm:

o Reentrancy

o Unchecked external call

o Unchecked send

o Dangerous delegatecall

o DoS (Denial of Service) (malicious smart contract)

o Out of gas (malicious smart contract)

o Integer Overflow/UnderFlow

1.4.2.2 Phương pháp nghiên cứu

Phân nhóm 14 loại lỗ héng và mã độc vào 5 nhóm dựa trên các đặc trưng tươngđồng

Trích xuất các đặc trưng bằng cách tự viết code, có tham khảo một số công cụphân tích tĩnh và phân tích động.

Ap dụng kỹ thuật Multi-model và Transfer Learning dé phân tích và tổng hợpthông tin từ các đầu vào khác nhau, tăng độ chính xác trong việc phát hiện lỗhồng, đồng thời có thé tái sử dụng và tinh chỉnh dé phát hiện các nhóm lỗ hồngkhác nhau chỉ với điều chỉnh nhỏ về mô hình và tập dữ liệu

Thực hiện thử nghiệm trên bộ dữ liệu thực tế và đánh giá kết quả.

Chương2 KIÊN TRÚC MẠNG BLOCKCHAIN VA CÁC VAN DE

BAO MAT TRONG HOP DONG THONG MINH

2.1 Kiến trúc mang Blockchain

2.1.1 Tổng quan kiến trúc mạng Blockchain

Blockchain là một chuỗi các khối, chứa đầy đủ danh sách các bản ghi giao dịch tương

tự như số cái công khai thông thường Hình 2.1 minh họa cách các block được kếtnoi trong blockchain Mỗi block trỏ đến block ngay trước đó thông qua một thamchiếu, chính là giá tri hash cua block trước đó, được gọi là parent block Các giá trihash của uncle blocks cũng sẽ được lưu trữ trong blockchain Ethereum Block đầu

tiên cua một blockchain được gọi là genesis block và không có parent block.

Hình 2.1 Kết nối các block trong Blockchain

Ethereum là một nền tảng blockchain sử dụng Turing Complete phô biến nhất hiệnnay, cho phép lập trình viên viết các hợp đồng thông minh với các quy tắc riêng vềquyền sở hữu, định dạng giao dịch và trạng thái hoạt động Trong blockchain, bất kỳ

ai cũng có thé chạy một node Ethereum trên máy tính của mình dé tham gia vào mạnglưới blockchain Ethereum Hình 2.2 mô tả kiến trúc phân lớp của blockchainEthereum.

ằ- ô CÔ ÔÐ

-+Proof of Work !+ Peer to Peer |

'

| "Proof of stake

¡ ‘Delegated Proof of Stake 1

' '

'

5 Practical Byzantine Fault Tolerance !

«Proof of Elapsed Time h

Hình 2.2 Layer structure of Ethereum blockchain

Hình 2.3 giải thích cấu trúc của một node blockchain trên nền tảng Ethereum Mỗi

node trong chuỗi được liên kết với node khác bằng cách sử dụng giá trị hash của nodetrước đó Các giao dịch được băm dưới dạng cây Merkle, một phần quan trọng của

blockchain Cây Merkle được sử dụng để xác minh hiệu quả và an toàn tính nhất quán

va toàn vẹn của các tập dữ liệu giao dịch lớn.

=—¬ Previous Block} [nmestamHash P

Quá trình hoạt động chính của mạng Blockchain diễn ra như sau:

e Khoi tạo giao dịch mới: Một node trong mạng tạo ra va gửi dữ liệu giao dịch

lên hệ thống

e Kiểm tra tính hợp lệ: Các node khác trong mạng nhận được dữ liệu sẽ kiểm

tra tính hợp lệ(xác minh tính chính xác) của giao dịch đó.

e Co chế đồng thuận: Mạng lưới sử dụng cơ chế đồng thuận như

Proof-of-Work (PoW) hoặc Proof-of-Stake (PoS) dé xác nhận tính hợp lệ của khối dữ

liệu mới.

s« Bồ sung vào chuỗi: Sau khi đạt được sự đồng thuận, khối dữ liệu mới sẽ được

thêm vào chuỗi các khối giao dịch đã được xác thực trước đó, tạo thành chuỗikhối

2.1.3 Phân tích rủi ro trong hệ thống Blockchain

Mặc dù Blockchain mang lại nhiều lợi ích về tính phi tập trung, minh bạch và không

thể giả mạo, cũng như tạo ra cuộc cách mạng đối với nhiều ngành công nghiệp Tuynhiên, Blockchain cũng không hoàn toàn tránh khỏi các mối đe dọa an ninh Dướiđây là phân tích rủi ro theo các lớp của hệ thống blockchain:

e RủỦIroởỞ tầng đồng thuận (Consensus Layer):

o Nguy cơ tân công 51% (51% Attack): Kẻ tan công chiếm quyền kiểm

soát hơn 50% sức mạnh tính toán trên mạng.

o Chỉ tiêu kép (Double Spending): Kẻ tan công chi tiêu cùng một loại tiền

điện tử nhiều lần cho nhiều giao dịch

e RủỦIroởỞ tầng dt liệu (Data Layer):

o Rò rỉ thông tin giao dich: Chi tiết giao dich nhạy cảm có thé bi lộ, ảnh

hưởng đến quyền riêng tư của người dùng

o Nguy co can thiệp dữ liệu: Dữ liệu có thé bị thay đôi trái phép nếu

không được bảo vệ đúng cách.

e Rủi ro ở tầng ứng dụng (Application Layer):

o Lé hồng trong hợp đồng thông minh: Lỗi trong mã hợp đồng thông

minh có thé bị khai thác (sẽ được đề cập chi tiết trong phần tiếp theo)

o Lỗ hồng trong giao diện người dùng: có thé dẫn đến việc lộ thông tin

nhạy cảm hoặc rủi ro về bảo mật thông tin

2.1.4 Phân loại và đặc điểm các loại Blockchain

Blockchain có thể được chia thành ba loại chính:

10

e Public blockchain: Mọi người đều có thê kiểm tra và xác minh các giao dịch,

đồng thời tham gia vào quá trình đồng thuận Bitcoin và Ethereum là những ví

dụ điển hình cho loại này Public blockchain cho phép sự tham gia rộng rãi vàminh bach cao Hình 2.4 dưới đây sẽ minh họa cho Public Blockchain.

a =

= —

= =

Hinh 2.4 Public blockchain

e Private blockchain: Các nút tham gia sẽ bị han chế, không tat cả các node có

thê tham gia vào Private Blockchain Hệ thống này có quản lý quyền truy cập

dữ liệu nghiêm ngặt Hình 2.5 dưới đây minh họa cho Private Blockchain.

Cc) # _

2 # Em GJ

) se —)

Hình 2.5 Private Blockchain

e Consortium blockchains: Các node có quyền được chọn trước, thường là

giữa các đối tác kinh doanh Dữ liệu có thể công khai hoặc riêng tư, và hệthống được xem là phi tập trung một phần Hyperledger và R3CEV là những

ví dụ cho loại blockchain này Hình 2.6 dưới đây minh họa cho Consortium

Blockchain.

11

Hình 2.6 Consortium Blockchain

Mỗi loại Blockchain đều co ưu và nhược điểm riêng Việc lựa chọn loại nào phụ

thuộc vào nhu cau cụ thê của từng dự án hoặc tô chức Đôi khi, tính tiện lợi của Public

Blockchain là cân thiệt, trong khi các trường hợp khác có thể đòi hỏi sự kiểm soát

chặt chẽ hơn như trong Consortium Blockchain hoặc Private Blockchain.

2.2 Các vấn dé bảo mật trong hợp đồng thông minh

2.2.1 Một số lỗ hồng theo OWASP Smart Contract Top 10

OWASP Smart Contract Top 10 là một tài liệu tiêu chuân nhằm mục đích cung cấpcho các nhà phát triên Web3 và các đội ngũ bảo mật các thông tin chỉ tiết về 10 lỗhồng phổ biến nhất được tìm thay trong hợp đồng thông minh

Top 10 lỗ hồng trong OWASP Smart Contract Top 10 hiện tại (2023) bao gồm:

« $C09:2023 - Gas Limit Vulnerabilities

e - SC10:2023 - Unchecked External Calls

12

- Integer Overflow and

Xảy ra khi một phép tính số học dẫn đến gia trị nam ngoàiphạm vi của kiêu dữ liệu biến bị lợi dung dé thao túng số dư

hoặc các giá trị quan trọng khác.

Underflow

SC03:2023 Nếu hành vi của hợp đồng thông minh phụ thuộc vào

- Timestamp timestamp của khối mà nó được đưa vào, nó có thé dễ bị thao

Dependence túng, khi thợ đào có một mức độ kiêm soát đối với timestamp

của khối

SC04:2023 Khi hop đồng thông minh không triển khai đúng cách kiêm

- Access Control soát truy cập, nó có thé cho phép người dùng không được ủyVulnerabilities | quyền thực hiện các hành động lẽ ra phải bị hạn chế, chăng

hạn như thay đổi trạng thái của hợp đồng hoặc rút tiền

SC05:2023 Kẻ tan công có thé quan sát một giao dịch dang chờ xử lý và

- Front-running sau đó thực hiện giao dịch của riêng với phí gas cao hơn,

Attacks khuyến khích thợ đào đưa nó vào blockchain trước

SC06:2023 Các cuộc tân công DoS nhăm mục đích làm cho hợp đồng

- Denial of không phản hồi hoặc không khả dụng bằng cách tiêu thụ hếtService (DoS) gas có sẵn, hoặc khiến các giao dịch liên tục thất bại

AttacksSC07:2023 Nếu hợp đông thông minh được lập trình kém, nó có thé chứa

- Logic Errors các lỗi logic dẫn đến hành vi không mong muốn Việc tính

13

toán không chính xác đên các câu lệnh điêu kiện sai, hoặc thậm chí là các chức năng quan tri bi lộ.

SC08:2023 Việc tạo ra tính ngẫu nhiên thực sự trong hợp đông thông minh

- Insecure trở nên khó khăn vì mạng Blockchain có bản chất mang tínhRandomness quyết định Nếu kẻ tan công có thé dự đoán hoặc ảnh hưởng

đến một số được cho là ngẫu nhiên, họ có thể thao túng hợpđông đê có lợi cho mình.

SC09:2023 - Gas | Số lượng phép toán mà mỗi khối Ethereum có thé bao gồm sẽ

Limit bị han chế vi có giới hạn gas Nếu một ham trong hợp đồngVulnerabilities | yêu cầu nhiều gas hơn giới han này, dẫn đến không thể thực

thi được, có khả năng đóng băng hợp đồng hoặc tiền của hợpđồng

SC10:2023 Khi một hợp đồng gọi một hàm bên ngoài, nó có thê không

- Unchecked kiểm tra đúng cách kết quả của lời gọi hàm Nếu lời gọi hàmExternal Calls | bên ngoài thất bại nhưng hợp đồng gốc không kiểm tra điều

này, nó có thê giả định lời gọi hàm đã thành công và tiếp tục

thực thi, dan đến hậu quả không lường trước được

Bảng 2.1 Mô tả 10 lỗ hồng hàng đầu trong hợp đồng thông minh OWASP

2.2.2 Một số loại lỗ hồng bảo mật khác va mã độc trong hợp đồng thông

minh

e Unchecked send: Lỗ hồng xảy ra khi hàm chuyên Ether không được ủy quyền

như send() có thé được gọi bởi người dùng bên ngoài nếu chúng được đặt ởchế độ public, ngay cả khi họ không có quyền hạn phù hợp Người dùng khôngđược ủy quyền có thể gọi các hàm này và chuyên Ether từ hợp đồng chứa lỗhồng, dẫn đến mắt mát tài chính hoặc lỗi logic trong hợp đồng Hình ảnh dướiđây là một ví dụ minh họa cho lỗ hồng này

14

1 function bug_unchkSend() payable public{

2 msg.sender.transfer(1 ether); }

Hình 2.7 Lỗ héng unchecked send

Dangerous delegatecall: DelegateCall tương tự như một lệnh gọi thông thường,

nhưng có một điểm khác biệt đó là mã tại địa chỉ đích được thực thi trong ngữ cảnh

của lời gọi hợp đồng Điều này có nghĩa là một hợp đồng có thé tự động tải mã từmột địa chỉ khác trong thời gian chạy, trong khi bộ nhớ vẫn tham chiếu đến hợp đồng

gọi đề triển khai tính năng "thư viện" trong Solidity nhằm tái sử dụng mã Tuy nhiên,

khi đối số của delegatecall được đặt là msg.data, kẻ tan công có thé tao ra msg.datavới chữ ký của một hàm, cho phép họ khiến hợp đồng nạn nhân gọi bất kỳ hàm nào

mà kẻ tan công cung cấp Hình ảnh dưới đây minh họa cho lỗ hồng này Ở dòng 6,hợp đồng Wallet chứa một delegatecall với msg.data là tham số Điều này cho phép

kẻ tan công gọi bat kỳ hàm công khai nào của _walletLibrary với dữ liệu của Wallet

Kẻ tấn công có thể gọi hàm initWallet (6 dòng 10) của hợp đồng thông minh_walletLibrary và trở thành chủ sở hữu của hợp đồng ví Cuối cùng, họ có thể gửiether từ ví đên địa chỉ của chính mình đê hoàn thành cuộc tân công.

contract Wallet{

function() payable { //fallback function

if (msg.value > 0) Deposit(msg.sender, msg.value);

else if (msg.data.length > 0) _walletLibrary.delegatecall(msg.data);

wo] [| [all =||si|>

10 | function initWallet(address[] _owners, uint _required, uint

Hình 2.8 Dangerous Delegate Call in Parity Wallet Contract

e Block number dependency: Lỗ hồng phụ thuộc vào block number giống như

lỗ hồng phụ thuộc vào timestamp dependency Khi một hợp đồng thông minh

15

sử dụng block.number như một phần của điều kiện dé thực hiện một tính toán

quan trọng (như gửi Ether) hoặc là nguồn tạo ra các số ngẫu nhiên Thợ đào

có thé thao túng cả block.timestamp và block.number, bởi vậy chúng không

thé sử dụng như một nguồn entropy Ngay cả khi sử dụng block.blockhash()

và block.number làm tham số cho việc tạo số ngẫu nhiên vẫn tạo ra lỗ hồng do

cơ chế thực thi của EVM hoặc do tính minh bạch của Blockchain

Short address/Parameter Issues: Lỗ hong này xảy ra do điểm yếu của

Ethereum Virtual Machine (EVM) EVM cho phép các đối số được padding

không chính xác, tạo điều kiện cho kẻ tấn công gửi các address được thiết kếđặc biệt dẫn đến việc khai thác Short Address Attack có chiến lược tan công

tương tự như lỗi SQL injection Khi phát hiện underflow, EVM thêm số 0 vào

cuối địa chỉ dé đảm bảo nó bao gồm kiểu dữ liệu 256-bit Tuy nhiên, kẻ tấn

công có thể lợi dụng lỗ hồng này băng cách bỏ qua số 0 cuối cùng của địa chỉEther Lỗ hồng này là một lỗi xác thực đầu vào và chủ yếu xảy ra từ phía ngườigửi do mã tao giao dịch yếu

Transaction Ordering Dependence (TOD): Xảy ra khi kết quả của một giaodịch phụ thuộc vào thứ tự các giao dịch được thực hiện Thợ đào có thể thao

túng thứ tự này, dẫn đến các kết quả không mong muốn hoặc có lợi cho kẻ tấn

công Hình ảnh dưới đây là một ví dụ cho lỗ hồng này.

1address payable winner_tod;

2 function setWinner_tod() public {

3 winner_tod = msg.sender;}

4 function getReward_tod() payable public{

5 winner_tod transfer (msg value) ;}

Hình 2.9 Lỗ hồng Transaction Ordering Dependence (TOD)

Tx.origin authentication: Trong một chuỗi lời gọi ham, khi các hop đồng gọi

các hàm của nhau, việc sử dụng tx.origin để xác thực thay vì msg.sender cô

thê dẫn đến các cuộc tấn công giống như lừa đảo Hình ảnh dưới đây là một ví

dụ minh họa cho lỗ hồng này, sử dụng tx.origin dé rút tiền

16

1 function bug_txorigin(address _recipient) public {

2 require(tx.origin == owner);

3 _recipient.transfer(this balance) ;}

Hình 2.10 Lỗ hồng tx origin authentication

e Out of Gas (Malicious smart contracts): Một số hop đồng thông minh độc

hại được thiết kế có ý dé gây ra lỗi “Out of Gas” nhằm khai thác và thực hiện

các hành vi độc hại, những hợp đồng này có thê lợi dụng việc tiêu thụ Gas quámức đề làm gián đoạn giao dịch hoặc thực hiện các hành vi không mong muốn

mà không cần phải sử dụng nhiều Gas Nguyên nhân chính bao gồm các vònglặp không được kiểm soát trong mã hợp đồng, thao tác trên cấu trúc dữ liệulớn (mảng có kích thước lớn) hay ước tính sai lượng gas cần thiết cho các hoạtđộng phức tạp Một số hợp đồng độc hại còn có thé được thiết kế dé tiêu tốn

it gas nhưng vẫn có thé thực hiện các hành vi chuyên tiền hoặc khai thác khác,lợi dụng cơ chế gas gây hại cho người dùng hoặc hệ thống

[ creditorAddresses = new address[](size);

L J

Hinh 2.11 L6 héng out of gas

e Denial of Service (Malicious smart contracts): Lỗ hồng này xảy ra khi kẻ

tan cong thiét ké hop đồng làm gián đoạn hoặc ngăn chặn các hoạt động bìnhthường của mạng lưới Các hành động độc hại phổ biến bao gồm lạm dụngvòng lặp dé tiêu thụ hết gas, khóa tài nguyên khiến các hợp đồng khác khôngthé truy cập, spam giao dịch dé làm tắc nghẽn mạng lưới, gọi các hàm khôngchính xác dé gây lỗi, Hậu qua của những hành động độc hai nay là làm giánđoạn mạng, tăng chi phí giao dịch, giảm hiệu suất hệ thống, gây thiệc hai tàichính và làm mắt uy tín trên nền tảng blockchain

17

2.2.3 Các phương pháp bảo mật cho hợp đồng thông minh

2.2.3.1 Phân tích tĩnh

Phân tích tĩnh là phương pháp kiểm tra mã nguồn của hợp đồng thông minh mà khôngcần thực thi chúng Phương pháp này thường dựa trên quy tắc hoặc dựa trên dữ liệu,tập trung vào các đặc điểm tĩnh được trích xuất từ hợp đồng thông minh Ưu điểmcủa phân tích tĩnh là có thé phân tích toàn bộ mã nguồn, nhanh chóng và hiệu quả về

mặt tính toán Tuy nhiên, phương pháp nay có những hạn chế như độ chính xác không

cao, phụ thuộc nhiều vào các quy tắc do chuyên gia xây dựng, tỷ lệ dương tính giảcao và khó khăn trong việc phát hiện các lỗ hồng mới Các công cụ và phương phápphân tích tĩnh bao gồm Slither, một công cụ phân tích tĩnh cho hợp đồng thông minh

viết bằng Solidity, sử dung các bộ phát hiện 16 hong được mã hóa thủ công Ngoài ra

có một số công cụ phân tích tĩnh khác như: SolidiFi, Mythril, SmartCheck, Manticore,Securify

2.2.3.2 Cac kỹ thuật thực thi động

Phân tích động là phương pháp kiểm tra hợp đồng thông minh trong quá trình thựcthi, theo dõi các hành vi và trạng thái của hợp đồng trong thời gian chạy Ưu điểmcủa phương pháp này là có thể phát hiện các lỗ hồng phức tạp và tỉnh vi hơn, đồngthời ít dương tính giả hơn so với phân tích tĩnh Tuy nhiên, phân tích động có hạn chế

là thiếu sự đảm bảo toàn diện về độ bao phủ đầy đủ của mã hợp đồng và tốn kém hon

về mặt tính toán so với phân tích tĩnh Các công cụ phân tích động thường mô phỏngviệc thực thi hợp đồng thông minh trong môi trường kiểm soát dé quan sát hành vi

của chúng Một số công cụ phân tích tĩnh phổ biến như GasFuzzer, ILF Fuzzer, sfuzz

Cả hai phương pháp này đều có ưu điểm và nhược điểm riêng Phân tích tĩnh có thékiểm tra toàn bộ mã nguồn mà không cần thực thi, trong khi phân tích động có thểphát hiện các lỗi chỉ xuất hiện trong quá trình chạy thực tế Nhiều công cụ và phươngpháp hiện đại kết hợp cả hai cách tiếp cận dé có kết quả toàn diện hơn

18

2.2.3.3 Các phương pháp học máy và phương pháp học sâu

Các phương pháp học máy (Machine Learning) và học sâu (Deep Learning) khácnhau đã được dé xuất dé tự động hóa quá trình phát hiện lỗ hồng trong hợp đồng

thông minh Ưu điểm của các phương pháp này là có khả năng tự động hóa cao vàtiềm năng phát hiện các mẫu và lỗ hồng mới mà các phương pháp truyền thống cóthé bỏ sót Tuy nhiên, các phương pháp học máy truyền thống vẫn dựa nhiều vàocác dự đoán có định do chuyên gia xây dựng, thiếu khả năng tông quát hóa Ngoài

ra, các công cụ phát hiện lỗ hồng hợp đồng thông minh dựa trên AI hiện tại chưa

giải thích chi tiết mối quan hệ giữa việc lựa chọn phương thức và hiệu suất phát

hiện Sự thiếu hụt rõ ràng này dẫn đến những trở ngại đáng kể trong việc cải thiệnhiệu suât của các phương pháp hiện có

19

Chương 3 CAC GIẢI PHAP ĐÈ XUẤT

3.1 Phương pháp đề xuất

Phương pháp của chúng em kết hợp cả Multi-model và Transfer Learning dé tối ưuhóa việc phát hiện và phân loại lỗ hổng và mã độc trong hợp đồng thông minh Môhình Multi-model sẽ kết hợp nhiều mô hình học sâu khác nhau, tối ưu hóa các thànhphần như biểu diễn đầu vào, nhúng từ và mô hình học sâu đề phân tích va phát hiện

lỗ hồng và mã độc từ nhiều góc độ Transfer Learning sẽ giúp tái sử dụng và tinhchỉnh mô hình cho các nhóm lỗ hồng và mã độc khác nhau với các điều chỉnh nhỏ về

mô hình và tập dữ liệu, từ đó nâng cao hiệu quả và tính linh hoạt của phương pháp.Nhờ vào sự kết hợp này, phương pháp của chúng em có thể phát hiện và phân loại lỗhồng và mã độc một cách chính xác và hiệu quả hơn so với các phương pháp truyềnthống, đồng thời mở rộng khả năng áp dung trong nhiều ngữ cảnh khác nhau

3.2 Phân nhóm lỗ hong và trích xuất các đặc trưng trong hợp đồng thông minh

Solidity3.2.1 Lý do phân nhóm lỗ hồng trong hợp đồng thông minh

Việc phân nhóm lỗ hồng trong hợp đồng thông minh bởi vì chúng em mong muốnxây dựng một công cụ phát hiện và phân loại được hau hết các lỗ hong trong hợp

đồng thông minh một cách hiệu quả dựa trên phương pháp học sâu đa mô hình Mục

tiêu là phát hiện và phân loại phan lớn lỗ hồng một cách nhanh chóng, tiết kiệm đượcthời gian, tài nguyên nhưng vẫn đạt được hiệu suất cao

Số lượng lỗ hồng cần xử lý thực tế là rất lớn, nếu không phân nhóm, việc trích xuấtđặc trưng cho từng loại lỗ hồng sẽ rất nhiều, xử lý đầu vào từng loại lỗ héng cho môhình sẽ rất lớn, đòi hỏi rất nhiều tài nguyên Mô hình cần được huấn luyện kỹ lưỡng

dé xử lý hết dir liệu dé cho kết quả chính xác Quá trình này tốn kém về thời gian, tài

nguyên và chỉ phí để xây dựng và triển khai, nhưng chưa chắc đã đem lại hiệu quả

cao.

20

Chính vì vậy, chúng em thực hiện việc chia các lỗ hồng thành 5 nhóm chính Cách tiếp cận này giúp quản lý và huấn luyện mô hình dé dàng hơn, nhanh hơn và tiết kiệm

tài nguyên, chi phí Đồng thời, mô hình vẫn đảm bảo khả năng phát hiện lỗ hong hiệuquả và phân loại lỗ hổng vào 5 nhóm

3.2.2 Mô tả phương pháp phân nhóm lỗ hỗng

Phương pháp phân nhóm các lỗ hồng trong hợp đồng thông minh của nhóm chúng

em dựa trên việc xác định các đặc trưng tương đồng của từng loại lỗ hồng Chúng em

tập trung vào 14 loại lỗ hồng bao gồm: Reentrancy; Ủnchecked external call;

Unchecked send; Dangerous delegatecall; Timestamp dependence; Block number dependence; Bad randomness; Short address/Parameter Issues; Access control;

Transaction ordering dependence (TOD); Tx.origin usage; DoS (malicious smart contract); Out of gas (Malicious smart contract), Integer Overflow/Underflow.

Dựa trên sự phân tích kỹ lưỡng, chúng em sé phân 14 loại lỗ héng này vào 5 nhóm lỗhồng chính bao gồm: Interaction and Contract State Vulnerabilities (Lỗ hong vềtương tác và trạng thái gop đồng), Dependency Vulnerabilities (Lỗ hồng phụ thuộc),Authentication and Authorization Vulnerabilities (Lỗ hồng xác thực và ủy quyền),Resource Gas usage Malicious code ( Mã độc sử dụng tài nguyên Gas), Arithmeticvulnerabilties (Lỗ hồng số học) Bang 3.1 dưới đây minh họa kết quả phân nhóm các

lỗ hồng

21

Nhóm lỗ hổng Lỗ hổng hoặc mã độc

Interaction and Contract State

vulnerabilities

Reentrancy Unchecked external call Unchecked send

Dangerous delegatecall Dependency vulnerabilities Block number dependency

Timestamp dependency

Bad randomness Short address

Đề có được kết quả phân nhóm lỗ hồng như bảng trên thì cần hiểu rõ hơn về quá trình

trích xuất đặc trưng cho từng loại lỗ hông và sau đó lấy các đặc trưng tương đồng

Hình ảnh dưới đây là ví dụ minh họa cho cách phân nhóm lỗ hồng của chúng em

~~ Unsafe external calls

External call functions for raw

| addresses Lack of boolean return value check

» | NERNNỨSWNDABRCDAokes `

> Violating Checks-Effects: » | Lack of Error Handling Mechanisms

Interactions pattern Insufficient input validation

Ï]———

State updates after external calls s

“ Usage of '.send()' method

ˆ

Hình 3.1 Các đặc trưng tương đồng của 2 lỗ hồng Reentrancy và Unchecked

external call

Hình ảnh trên minh họa các đặc trưng của 2 loại lỗ hồng Reentrancy va Unchecked

external call, trong đó có các đặc trưng tương đồng như “Lack of return value

33c

check”, “State update without verification”, “usage of delegatecall”, vì vay chúng

22

em phân 2 loại lỗ hồng trên vào nhóm Interaction and Contract State Vulnerabilities

(Lỗ hồng về tương tác và trạng thái gợp đồng)

Tương tự như vậy, chúng em sẽ trình bày chỉ tiết bước trích xuất đặc trưng từng loại

lỗ hồng và mã độc dé phân nhóm trong bảng dưới đây Riêng nhóm Arithmetic thìchỉ có 1 lỗ hồng Integer Overflow/Underflow nên chúng em không trích xuất các đặctrưng của lỗ hồng này

Lo hông hoặc mã | Trích xuât các đặc trưng của lỗ hong

độc

Reentrancy External Calls to Untrusted Contracts: (call; 'delegatecall;

‘send’; 'transfer')

Ignored Return Value(Return a Boolean Value)

Use of 'msg.value' and 'msg.sender' Recursive Calls

State Changes After External Calls

Lack of Error Handling Mechanisms, such as ‘require’;

‘revert’; ‘assert’

Fallback Functions without Gas check: 2300 gas limitation

Unchecked External call functions for raw addresses: address.send();

external call address.call(); address.delegatecallQ;

Ignored Return Value(Return a Boolean Value)

State Changes After External Calls

Lack of Error Handling Mechanisms, such as 'require'’;

'revert'; ‘assert’

Fallback Functions without Gas check: 2300 gas limitation Unchecked send _ | Usage of '.sendQ' method

23

Lack of boolean return value check

State update without verification

Fallback function risks: exceed 2300 gas stipend, '.send()' can fail

Dangerous Usage of 'delegatecall'

delegatecall State Variables Manipulation

Context preservation

Library safe practices

Timestamp Relian on Block Timestamp

Block number

dependency

Dependence on Block Number Value: 'block.number'

Manipulation by Miners: 'block.timestamp’, 'block.number'

Usage in Comparison Operations: 'block.number'

Random Number Generation: 'block.blockhash();

‘plock.number' Global variables (block.timestamp, blockhash, and block.number)

Bad randomness Global variables (block.timestamp, blockhash, and

block.number)

24

Lack of private seed storage

Historical block data

Predictability of randomness sources

Timestamp as a Deterministic Random value Short

address/Parameter

issues

Insufficient input and parameter validation

Vulnerable functions handling sensitive data (e.g., ERC20 token transfers, Ether transfers)

Improper input padding practices

Address Variables is not checked Modifier Usage(onlyOwner, ' onlyAuthorized')

Function Visibility(‘public’, ‘external’, ‘internal’, ‘private')

Access control Owner Variable(‘address public owner")

Modifier Usage(onlyOwner, ' onlyAuthorized’)

Function Visibility(‘public’, ‘external’, ‘internal’, 'private’)

Authentication Checks(‘require(msg.sender == owner)’, 'tx.origin’)

Improper input padding practices

Address Variables is not checked Transaction

Ordering

Dependency on Function Order

High Gas Price Transactions

25

State Variables Manipulation

(TOD)

Concurrent Function Invocations

Improper input padding practices

Address Variables is not checked Tx.origin Authorization Checks using 'tx.origin':

authentication require(tx.origin==owner)

Transaction State Variable

Owner Variable(‘address public owner")

DoS (Denial of

Service)

High Complexity Loops (‘for' 'while')

balance check before send state variables manipulation

fallback function interaction High Gas Price Transactions

Concurrent Function Invocations

Recursive Function Calls

High Complexity Loops (‘for' 'while`)

High Gas Price Transactions

Concurrent Function Invocations

26

State-changing Operations (‘storage’, ‘mapping’, 'array’)

Balance check before send State variables manipulation

Bang 3.2 Trích xuất các đặc trưng và lay các đặc trưng tương đồng

3.2.3 Các nhóm lỗ hồng va mã độc trong hợp đồng thông minh

3.2.3.1 Nhóm lỗ hỗng liên quan đến tương tác và trạng thai hop đồng

(Interaction and Contract State Vulnerabilities)Nhóm lỗ hong Lỗ hong Các đặc trưng tương đồng

Interaction and Contract Reentrancy 1 External call functions

State Vulnerabilities 2 State Changes After External

Calls

5 1W 3 Fallback Functions external call

6 State update without verification

7 Use of 'msg.value' and

‘msg.sender'

8 Error Handling

9 Function Visibility

10 Recursive Calls

Bang 3.3 Nhom Interaction and Contract State Vulnerabilities

3.2.3.2 Nhóm lỗ hỗng phụ thuộc (Dependency Vulnerabilities)

27

Vulnerabilities

Timstamp dependency

4 Predictability of randomness sources

5 Historical block data

6 Lack of private seed storage

7 Reliance on Block Timestamp

8 Dependence on Block Number

Value: 'block.number'

9 Timestamp as a Deterministic Random value

Bảng 3.4 Nhóm Dependency Vulnerabilities3.2.3.3 Nhóm lỗ hồng liên quan đến xác thực và ủy quyền

(Authentication and Authorization Vulnerabilities)Nhóm lỗ hong Lỗ hồng Các đặc trưng tương đồng

Authentication and Short 1 Insufficient input and

Authorization address/Parameter | parameter validation

Vulnerabilities issues 2 Authentication Checks

3 Address Variables is not

Access control checked

4 Owner Variable (Access

control, Tx.origin usage)

28

TOD 5 Modifler Usage

6 Function Visibility

7 Use of tx.origin for

authorization

9 Transaction State Variable

10 Improper input padding practices

Bang 3.5 Nhóm Authentication and Authorization Vulnerabilities

3.2.3.4 Nhóm mã độc liên quan đến sử dung tài nguyên Gas (Resource

Gas usage Malicious code)

2 Gas Limit Checks: 'gasleftQ'

3 High Gas Price Transactions

4 Recursive Function Calls

5 State variables manipulation

6 State-changing Operations (storage', ‘mapping’, 'array)

7 Balance check before send

8 Recursive Function Calls

9 Concurrent Function Invocations

10 High Gas Price Transactions

Bang 3.6 Nhom Resource Gas usage vulnerabilities

29

Sau khi phân nhóm các lỗ hồng và mã độc nhờ vào việc trích xuất các đặc trưngtương đồng, tụi em tiễn hành trích xuất và lưu các đặc trưng trên Mongo DB, nhưhình minh họa dưới đây

x functions_with_issues : Object

>» externaL_caLL_function : Array (empty)

state_change_after_external_call: Array (empty)

» error_handling : Array (3) fattback_function_interaction : Array (empty)

unchecked_external_call: Array (empty)

>» use_of_msg_value_or_sender : Array (1) delegatecall_with_msg_data: Array (empty)

» dynamic_delegatecall : Array (empty) 1ibrary_safe_practices : Array (empty)

>» gas_Limitations_in_fallback_functions : Array (empty)

» balance_check_before_send : Array (empty) multiple_external_calls : Array (empty)

» external_call_in_loop : Array (empty)

low_level_call : Array (empty)

library_usage_in_delegatecall : Array (empty)

state_variables_manipulation : Array (empty)

state_update_without_verification : Array (1)

>» recursive_caLLs : Array (empty) context_preservation : Array (empty)

check_return_value : Array (empty)

usage_of_block_timestamp : Array (empty) _

xv

*

Hình 3.2 Các đặc trưng được trích xuất từ một file sol

> external_call_in_loop : Array (empty)

function_content : "function PopBonusCode() public { "

require(® <= bonusCodes length) ; bonusCodes 1ength ;

}

v2; Object

function_name : "UpdateBonusCodeAt „"

function_content : "function UpdateBonusCodeAt(uint idx, uint c) public { "

require(idx < bonusCodes Length) ;

bonusCodes[idx] = c;

}

v3: Object

function_name : "Destroy,"

function_content : "function Destroy() public { k

Hình 3.3 Các hàm được trích xuất từ đặc trưng reentrancy_guard_missing

30