Đánh giá an toàn thông tin thiết bị Android theo cách tiếp cận phân tích liên ứng dụng

Phân tích tĩnh có ưu điểm là không cần thiết lập môi trường để thực thi ứng dụng, tuy nhiên gặp khó khăn khi phân tích các malware sử dụng kỹ thuật làm rối mã nguồn, mã hóa mã nguồn hoặc

ĐẠI HỌC QUỐC GIA TP HCM

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

Họ và tên NCS: NGUYỄN TẤN CẦM

ĐỀ CƯƠNG NGHIÊN CỨU ĐỀ TÀI

LUẬN ÁN TIẾN SĨ

Tên đề tài: Đánh giá an toàn thông tin thiết bị Android theo

cách tiếp cận phân tích liên ứng dụng

Chuyên ngành: Công nghệ thông tin

Mục lục

1 Giới thiệu tổng quan 7

1.1 Đặt vấn đề 7

1.2 Tổng quan về quá trình phát hiện malware trên Android 10

1.2.1 Các kỹ thuật phân tích malware (Type of dectection) 12

1.2.2 Các loại dữ liệu nguồn dùng để phân tích (điểm quan sát) 17

1.2.3 Phạm vi phân tích (Scope of analysis) 23

1.2.4 Loại nhận diện (Type of identification) 24

1.2.5 Môi trường triển khai (Deployment Platform) 28

2 Lý do thực hiện nghiên cứu 31

2.1 Lý do chọn lĩnh vực nghiên cứu 31

2.1.1 Động lực nghiên cứu 31

2.1.2 Các công trình liên quan 32

2.2 Mục tiêu và mong muốn đạt được 45

2.3 Lý do chọn cơ sở đào tạo 46

2.4 Kinh nghiệm, kiến thức liên quan đến lĩnh vực dự định nghiên cứu 46 2.5 Dự kiến việc làm sau khi tốt nghiệp: 46

2.6 Đề xuất người hướng dẫn 46

3 Mục đích nghiên cứu của luận án 46

3.1 Tính cấp thiết 46

3.2 Ý nghĩa thực tiễn của đề tài 47

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

5 Các phương pháp nghiên cứu 47

5.1 Câu hỏi nghiên cứu 47

5.2 Mô hình đề xuất 48

5.3 Các công cụ sử dụng 49

5.4 Dữ liệu thử nghiệm 50

7 Nơi thực hiện đề tài nghiên cứu của luận án 50

8 Dự kiến sơ bộ về tiến độ thực hiện đề tài nghiên cứu 51

9 Tài liệu tham khảo 52

Danh mụ c hì nh

Hình 1: Số lượng thiết bị được bán theo thời gian 7

Hình 2: Thống kê thị phần hệ điều hành được sử dụng 8

Hình 3: Đặc điểm của các kỹ thuật phát hiện malware 12

Hình 4: Các loại nhận dạng 13

Hình 5: Cấu trúc tập tin apk 13

Hình 6: Quá trình phân tích tĩnh 14

Hình 7: Quá trình phân tích động của TaintDroid 15

Hình 8: Các lớp trong kiến trúc của hệ điều hành Android 15

Hình 9: Quá trình phân tích tổng hợp của AASandBox 17

Hình 10: Loại dữ liệu thu thập 17

Hình 11: Ví dụ về tập tin AndroidManifest.xml 18

Hình 12: Mô hình của Enclamald 20

Hình 13: Mô hình đề xuất trong việc phân tích mạng 21

Hình 14: Các phạm vi phân tích 23

Hình 15: Phạm vi phân tích 23

Hình 16: Loại nhận diện 24

Hình 17: Mô hình hoạt động của Juxtapp 26

Hình 18: Mô hình phân tích malware của DroidAnalytics 27

Hình 19: Môi trường triển khai 28

Hình 20: Ví dụ về nguy cơ rò rỉ thông tin qua nhiều ứng dụng 32

Hình 21: Các cấp theo dõi thông tin 33

Hình 22: Kiến trúc của TaintDroid 34

Hình 23: Mô hình của FlowDroid 35

Hình 24: Ví dụ về các loại Potential Component Leaks, trong đó (B) là PPCL và (C) là PACL 35

Hình 25: Quá trình xử lý của PCLeaks và pcLeaksValidator 36

Hình 26: Kỹ thuật phát hiện các hành vi nhạy cảm của SmartDroid 37

Hình 27: Kiến trúc của SmartDroid 38

Hình 28: Kiến trúc tổng quan của AppsPlayGround 39

Hình 29: Giao tiếp giữa hai Components thông qua Intent và Intent Filter 40 Hình 30: Sơ đồ hoạt động của Epicc 40

Hình 31: Sự kết hợp của FlowDroid và Epicc trong DidFail 40

Hình 32: Giao tiếp giữa các component 41

Hình 33: Mô hình của Amandroid 41

Hình 34: Kiến trúc của XManDroid 42

Hình 35: Mô hình của IccTA 43 Hình 36: Giai đoạn gom hai tập tin apk thành một tập tin apk mới của

Hình 37: Xu thế nghiên cứu ICC 44

Hình 38: Các nghiên cứu dẫn đến hướng IAC 45

Hình 39: Giao tiếp giữa nhiều ứng dụng 48

Hình 40: Sơ đồ hệ thống đề xuất 48

Hình 41: Một ví dụ cho việc tồn tại luồng thông tin từ source nhạy cảm đến sink nguy hiểm 49

Danh mụ c ba ng biể ụ

Bảng 1: Số malware mới trong năm 2013 8

Bảng 2: Nhóm các hành vi tấn công trên điện thoại thông minh 9

Bảng 3: Thống kê tỷ lệ nhóm hành vi tấn công trên điện thoại thông minh trong hai năm 2013 và 2014 9

Bảng 4: Ưu và nhược điểm của các loại dữ liệu nguồn dùng để phân tích 22 Bảng 5: Ưu và nhược điểm của các loại nhận diện 27

Bảng 6: Ưu và nhược điểm của các môi trường triển khai 29

Bảng 7: Thống kê các nghiên cứu hiện tại 29

Bảng 8: Thống kê loại ICC thường dùng 42

Bảng 9: Các công việc chính của IccTA 43

Bảng 10: Danh sách người hướng dẫn 46

Bảng 11 Bảng dự kiến tiến độ thực hiện đề tài nghiên cứu 51

1 Giới thiệu tổng quan

1.1 Đặt vấn đề

Theo thống kê của Gartner [1], số lượng thiết bị điện tử có sử dụng hệ điều hành được bán ra trong các năm 2014 và 2015 đạt gần 2,5 tỷ thiết bị Trong

đó các điện thoại thông minh chiếm gần hai tỷ thiết bị, tức là chiếm 77% tổng

số lượng các thiết bị Mức tăng trưởng của các thiết bị điện thoại thông minh

có xu hướng tăng đều

Hình 1: Số lượng thiết bị được bán theo thời gian

Theo thống kê và dự báo của Gartner, thì hệ điều hành Android là hệ điều hành được sử dụng phổ biến nhất Trong năm 2014, số thiết bị sử dụng hệ điều hành Android được bán ra chiếm 48,6% Và dự kiến tỷ lệ này tăng đều vào các năm 2015 và 2016

Hình 2: Thống kê thị phần hệ điều hành được sử dụng

Theo thống kê của F-Secure [2] thì trong năm 2013 có 99% malware mới nhắm vào mục tiêu là hệ điều hành Android

Bảng 1: Số malware mới trong năm 2013

Hệ điều hành mục tiêu Số biến thể

Bảng 2 mô tả các nhóm hành vi tấn công của phần mềm độc hại trên điện thoại thông minh

Bảng 2: Nhóm các hành vi tấn công trên điện thoại thông minh

Steals device data Thu thập các thông tin của thiết bị, như mã số IMEI hoặc

IMSI Thông tin về hệ điều hành và thông tin cấu hình của điện thoại

Spies on user Cố tình thu thập các thông tin trên thiết bị để theo dõi

người dùng, ví dụ: thu thập nhật ký cuộc gọi, nội dung tin nhắn SMS rồi gởi đến cho một máy chủ trên Internet Sends premium SMSs Gởi tin nhắn đến các tổng đài tính phí để tính phí tin nhắn Downloader Có thể tải các thành phần nguy hiểm khác từ Internet lên

Elevates privileges Tìm cách gán thêm quyền cho ứng dụng nhiều hơn so với

các quyền mà người dùng nhìn thấy khi cài đặt ứng dụng Banking Trojan Theo dõi các giao dịch ngân hàng trên thiết bị, lấy cắp

thông tin nhạy cảm và thực hiện các hành vi nguy hiểm liên quan

SEO poisoning Truy cập đến những địa chỉ URL trên Internet nhằm làm

tăng thứ hạng của trang web có URL này

Adware/ Annoyance Quảng bá thông tin quảng cáo đến người dùng

DDOS Utility Tấn công từ chối dịch vụ

Hacktool Kẻ tấn công dùng thiết bị của nạn nhân trong việc tấn công

mạng, thậm chí lấy thông tin trên thiết bị của nạn nhân

Theo thống kê của Symantec [3] thì nhóm hành vi đánh cắp thông tin trên

thiết bị và theo dõi người dùng chiếm tỷ lệ cao nhất với 36%

Bảng 3: Thống kê tỷ lệ nhóm hành vi tấn công trên điện thoại thông minh trong hai năm 2013 và 2014

Nhóm hành vi

Tỷ lệ trong năm 2014

Tỷ lệ trong năm 2013

1.2 Tổng quan về quá trình phát hiện malware trên Android

Quá trình phát hiện malware bao gồm nhiều giai đoạn con như thu thập dữ liệu, phân tích và nhận diện

Thu thập dữ liệu là quá trình thu thập các thông tin liên quan đến ứng dụng được phân tích Dữ liệu được thu thập bao gồm: thông tin từ gói ứng dụng, thông tin liên quan đến hành vi hoạt động của ứng dụng Dữ liệu này là thành phần quan trọng trong việc phân tích và nhận diện xem ứng dụng này có phải

là malware hay không Để thu thập dữ liệu liên quan ta có thể dùng một số công cụ để giải nén tập tin apk như apktool Kế đến ta viết các chương trình rút trích các thông tin liên quan đến các dữ liệu sau khi giải nén như: AndroidManifest, các tập tin java… Hoặc cũng có thể cho chạy các ứng dụng rồi ghi lại các thông tin liên quan như: các lệnh hệ thống được sử dụng trong quá trình chạy, lưu lượng gói tin mạng…

Quá trình phân tích là quá trình xử lý các dữ liệu thu thập được ở bước thu

Quá trình nhận diện là quá trình xác định xem ứng dụng đang xét có phải là malware không Quá trình này tùy thuộc nhiều vào kết quả của việc xử lý dữ liệu trong quá trình phân tích

Có nhiều đặc điểm khác nhau khi xét quá trình phát hiện malware ở nhiều góc nhìn khác nhau Xét về kỹ thuật phân tích (detection technique), có các

kỹ thuật: phân tích động, phân tích tĩnh và phân tích tổng hợp Xét về các loại

dữ liệu dùng để phân tích (Audit data source), có các loại: system call, application package, network traffic, hardware performance, … Xét về phạm

vi phân tích (Scope of analysis), có các loại: phân tích trên ứng dụng đơn, phân tích trên nhóm ứng dụng và phân tích trên toàn thiết bị Xét về loại nhận diện (Type of identification), có hai loại: signature và anormal Xét về môi trường triển khai (Deployment Platform), có các loại: trên thiết bị, trên máy chủ hoặc trên môi trường điện toán đám mây

Deployment Platform

Host

Server/Cloud

Type of identification

Network traffic

Hardware performance Sensitive Data Flow

Hình 3: Đặc điểm của các kỹ thuật phát hiện malware

1.2.1 Các kỹ thuật phân tích malware (Type of dectection)

Có ba kỹ thuật phân tích malware: phân tích tĩnh, phân tích động và phân tích kết hợp

Detection Technique

Hình 4: Các loại nhận dạng

Phân tích tĩnh là phương pháp phân tích không cần thực thi ứng dụng trong khi đó phân tích động là phương pháp phân tích dựa vào các thông tin thu được khi chạy ứng dụng Phương pháp phân tích tổng hợp là phương kết hợp

cả phương pháp phân tích tĩnh và phương pháp phân tích động

1.2.1.1 Kỹ thuật phân tích tĩnh

Phân tích tĩnh là phương pháp phân tích được sử dụng phổ biến [4-13] Phân tích tĩnh không cần thực thi ứng dụng Các thông tin dùng để phát hiện malware nằm trong gói tập tin cài đặt Ví dụ: thông tin từ tập tin AndroidManifest.xml, các thư viện, hàm API và mã nguồn khác được rút trích từ tập tin của ứng dụng

Hình 5: Cấu trúc tập tin apk

Quá trình phân tích tĩnh có thể bao gồm các bước chính sau:

- Dịch ngược các tập tin cài đặt của ứng dụng sang mã nguồn

- Rút trích các thông tin đặc trưng từ mã nguồn

- Phân tích các bất thường từ các đặc trưng

- Dựa vào các dấu hiệu bất thường trong quá trình phân tích để quyết định ứng dụng này có phải là malware hay không

và IccTA [13] dùng Control Flow Graph trong quá trình phân tích

Phân tích tĩnh có ưu điểm là không cần thiết lập môi trường để thực thi ứng dụng, tuy nhiên gặp khó khăn khi phân tích các malware sử dụng kỹ thuật làm rối mã nguồn, mã hóa mã nguồn hoặc các malware chỉ thực hiện các thao tác nguy hiểm khi chạy chương trình

1.2.1.2 Kỹ thuật phân tích động

Khác với kỹ thuật phân tích tĩnh, phân tích động là phương pháp phân tích cần thực thi chương trình Các ứng dụng được thực thi trong các máy ảo, môi trường giả lập hoặc trên một thiết bị thật Việc thực thi các ứng dụng này cho phép các nhà nghiên cứu giám sát các hành vi của ứng dụng thay vì dựa vào

mã nguồn của ứng dụng Dựa vào thông tin được tạo ra khi chạy chương trình

có thể phát hiện các malware mà kỹ thuật phân tích tĩnh không phát hiện được CrowDroid [17], Paranoid [18], TaintDroid [19], MADAM [20], Andromaly [21] đều sử dụng kỹ thuật phân tích động

New application

Mobile Phone

Taint tracking:

-Variable level -Method level -Message level -File level

Virtual Machine

Dynamic Taint Analysis Install App

Hình 7: Quá trình phân tích động của TaintDroid

Kỹ thuật phân tích động thường gắn tracer (đoạn mã dùng để ghi lại những hành vi của ứng dụng) ở các lớp khác nhau của kiến trúc Android Từ đó tiến hành phân tích những thông tin thu thập được để phát hiện những hành vi bất thường

Hình 8: Các lớp trong kiến trúc của hệ điều hành Android

Để thuận tiện cho việc thu thập thông tin của tracer, kỹ thuật phân tích động thường phải tạo môi trường giả lập (emulator) để thực thi ứng dụng mục tiêu Các emulator thường được chỉnh sửa các module phù hợp để tiến hành ghi lại các hành vi của ứng dụng Số lượng các hành vi của ứng dụng lúc thực thi rất nhiều, do đó cần phải kết hợp với kỹ thuật phân tích tĩnh để giới hạn các hành vi mục tiêu

Nhược điểm chung của kỹ thuật phân tích động là thường phụ thuộc vào các emulator Trong khi đó, một số malware có khả năng kiểm tra môi trường thực thi có phải là emulator hay không, từ đó sẽ thay đổi hành vi khác đi nếu chạy trên emulator

Bên cạnh đó, việc sử dụng công cụ Android Monkey [22] để phát sinh ngẫu nhiên các tương tác người dùng trong quá trình thực thi các ứng dụng cũng gặp nhiều thách thức như: các tương tác phát sinh thường không giống với tương tác của người dùng thực sự Điều này không thể kiểm tra chính xác tất

cả các hành vi trong thực tế

Việc lựa chọn vị trí để gắn tracer cũng ảnh hưởng nhiều đến độ chính xác trong việc phân tích Nếu tracer gắn ở các lớp cao thì có khả năng thu thập được một số hành vi giới hạn Ngược lại, nếu gắn tracer ở các lớp thấp thì thông tin thu thập được nhiều, tuy nhiên việc này có thể gây tốn nhiều tài nguyên và thời gian

TaintDroid [19] sử dụng taint tracking bằng cách gắn tracer vào Dalvik VM DroidBox [23] sử dụng cả taint tracking và core lib tracking TraceDroid [24] thực hiện API tracking bằng cách chỉnh sửa các thành phần của hệ điều hành Android và tiến hành trên emulator DroidScope [25] sử dụng VMI tracking

và chỉnh sửa Dalvik VM để tiến hành tracking trên emulator Sandbox [26] giống như DroidBox, chỉ khác ở điểm là tracer được gắn ở core lib thay vì Dalvik VM

Mobile-1.2.1.3 Kỹ thuật phân tích tổng hợp

Kỹ thuật phân tích tổng hợp là kỹ thuật kết hợp cả phân tích tĩnh và phân tích động Kỹ thuật này tận dụng các ưu điểm của hai kỹ thuật phân tích tĩnh và động AASandBox [27], SmartDroid [28] là các ví dụ điển hình cho kỹ thuật phân tích tổng hợp

New

application

AASandbox

- Disassemble binary

- Search for pattens

- Install binary

- Execute binary

- Track system calls

Static Analysis

Dynamic Analysis

Install App

Hình 9: Quá trình phân tích tổng hợp của AASandBox

Nhược điểm của kỹ thuật phân tích tổng hợp là tốn nhiều tài nguyên trong quá trình phân tích

1.2.2 Các loại dữ liệu nguồn dùng để phân tích (điểm quan sát)

Dữ liệu nguồn dùng để phân tích hay điểm quan sát là các dữ liệu liên quan đến các ứng dụng được dùng để thành lập các giá trị đặc trưng cho từng ứng dụng Tùy vào từng hướng tiếp cận có thể lựa chọn các loại dữ liệu nguồn khác nhau

Audit data source

Hình 10: Loại dữ liệu thu thập

Việc lựa chọn dữ liệu nguồn chính xác sẽ góp phần làm tăng hiệu năng của việc phát hiện malware Một gói ứng dụng chứa tập tin manifest, các lớp dex,

và byte code Các dữ liệu này rất dễ thu thập, tuy nhiên sẽ rất khó khăn để

phân tích nếu dex classes và byte code bị làm rối và mã hóa Các nghiên cứu [5, 9, 29-36] chỉ phân tích malware dựa vào các gói ứng dụng Trong khi đó, các nghiên cứu [12, 13, 19, 37] phân tích các luồng dữ liệu nhạy cảm Các hệ thống này giám sát quá trình xử lý dữ liệu nhạy cảm được thực hiện bởi ứng dụng từ mức ứng dụng đến mức kernel và dữ liệu của các kết nối mạng Nhưng thực tế, không phải bất kỳ ứng dụng độc hại nào cũng xử lý các thông tin nhạy cảm Điều này là một hạn chế của hướng tiếp cận này Thay vì dùng thông tin từ các gói ứng dụng, theo dõi luồng dữ liệu nhạy cảm, chúng ta có thể dùng các thông tin gây ra trong lúc các ứng dụng đang chạy, việc gọi hàm

hệ thống ở mức kernel, lưu lượng mạngđể phát hiện các hành vi của malware Việc này không bị ảnh hưởng nhiều bởi các kỹ thuật làm rối và mã hóa Tuy nhiên, hướng tiếp cận này có thể gây ra một lượng quá nhiều thông tin nếu không chọn lọc các thông tin một cách cẩn thận Các nghiên cứu [17, 18, 38-40] chỉ đề cập đến các lời gọi hàm hệ thống ở mức kernel Các nghiên cứu [41-48] quan tâm đến thông tin gói tin mạng để phát hiện malware Nghiên cứu của Isohara và đồng sự [49] sử dụng cả system call và data flow

Một hướng tiếp cận khác trong việc lựa chọn dữ liệu nguồn cho quá trình phân tích malware là thông tin liên quan đến việc sử dụng phần cứng của thiết

bị Tuy nhiên, các hiệu năng bất thường của thiết bị cũng có thể do chính người dùng sử dụng thiết bị quá nhiều Nghiên cứu của Dixon và Mishra [50]

áp dụng kỹ thuật nhận diện malware dựa vào việc phát hiện hiệu năng bất thường của thiết bị

Hai nghiên cứu của Dini và đồng sự [20] và Shabtai và đồng sự [21] thu thập

dữ liệu từ hầu hết các nguồn dữ liệu ngoại trừ gói ứng dụng Điều này giúp thông tin được thu thập đầy đủ hơn, nhưng tốn nhiều chi phí cho việc thu thập

và phân tích hơn

Theo mô hình bảo mật của Android, thì muốn truy cập một tài nguyên nhạy cảm nào đó thì cần phải được gán quyền tương ứng Mặc định thì các ứng dụng chưa được gán quyền nào cả Ví dụ, một ứng dụng muốn theo dõi các tin nhắn SMS nhận được cần phải gán quyền RECEIVE_SMS

Hình 11: Ví dụ về tập tin AndroidManifest.xml

Cĩ nhiều nghiên cứu phát hiện malware trên Android dựa vào việc phân tích permission [4-9] Các thơng tin liên quan đến permission của một ứng dụng được rút trích một cách dễ dàng bằng các cơng cụ như ApkTool [14]

Huang và đồng sự [4] đề xuất một giải pháp phát hiện malware dựa vào phân tích permission của ứng dụng bằng cách so với cơ sở dữ liệu của hai nhĩm ứng dụng là malware và ứng dụng sạch bằng phương pháp máy học Phương pháp này cĩ tỷ lệ phát hiện đúng là 81%

Cũng dùng phương pháp máy học để phân loại, Sanz và đồng sự [5] đề xuất

hệ thống MAMA trong việc phát hiện malware dựa vào permission MAMA

cĩ đệ chính xác 94.38% khi dùng thuật tốn Random Forest với số cây là

100

Peng cùng đồng sự [6] đề xuất phương pháp đánh giá mức độ nguy hiểm của một ứng dụng bằng cách phân tích permission được yêu cầu bởi ứng dụng Nhĩm tác giả sử dụng kỹ thuật máy học Nạve Bayes

Các nghiên cứu [4-6] đều dùng kỹ thuật máy học để phân loại Cả ba phương pháp đều phân tích permission của ứng dụng với hai nhĩm cơ sở dữ liệu là ứng dụng sạch và malware Chưa xem xét đến trường hợp tập permission vừa thuộc nhĩm ứng dụng sạch vừa thuộc nhĩm malware

Shuang và đồng sự [8] đề xuất một phương pháp phát hiện malware dựa vào việc phân tích các tổ hợp của các permission trong một ứng dụng xem tổ hợp này thuộc vào nhĩm ứng dụng malware hay nhĩm ứng dụng sạch Hướng tiếp cận này cũng chỉ quan tâm đến việc phân tích permission Tức là xem độ tương đồng về danh sách permission của một ứng dụng với cơ sở dữ liệu cĩ sẵn

Enclamald [7] của Xiong và đồng sự phát hiện malware bằng cách phân tích tập các permission của các ứng dụng với cơ sở dữ liệu về tập các permission của các ứng dụng sạch (Clean profile) và tập các permission của các malware (Malware profile) Trong thực tế, cĩ một số ứng dụng dùng các nhĩm permission thuộc cả Clean profile và Malware profile Nhĩm quyền này gọi

là Common profile Trong nghiên cứu này, Xiong và đồng sự đề xuất phương pháp phát hiện malware dựa trên việc sử dụng cả ba loại dữ liệu này (Hybrid profile) Nhĩm tác giả đề xuất một giá trị xác định sự tương phản của nhĩm các permission Nếu giá trị này lớn hơn một ngưỡng nào đĩ thì cho biết ứng dụng là malware ngược lại là ứng dụng sạch

Hình 12: Mô hình của Enclamald

Như vậy, việc phân tích malware dựa vào việc phân tích permission thì đơn giản tuy nhiên chưa chính xác trong thực tế Trong thực tế, không phải cung cấp quyền hạn giống như malware đã là malware, mà cần phải xem hành vi thực sự của ứng dụng đó là gì, tức là cần phải kiểm tra xem các quyền này có thực sự được sử dụng hay không

Một trong những mục tiêu của các nhà viết malware là đánh cắp thông tin nhạy cảm trên thiết bị bằng cách thu thập chúng và gởi đến một máy chủ nào

đó trên Internet Ví dụ: Droiddreamlight Một số khác sẽ truy cập liên tục đến một số địa chỉ web trên Internet nhằm làm tăng thứ hạng tìm kiếm của trang web đó Ví dụ: HongTouTou

Như vậy các thông tin về hành vi truy cập Internet được dùng như những đặc trưng quan trọng trong việc phân tích malware Có nhiều nghiên cứu theo hướng tiếp cận này [42-47, 51]

Theo Feizollah và đồng sự [51], đã phân tích malware trên hệ điều hành Android dựa vào việc phân tích gói tin mạng Họ sử dụng hai thuật toán phân lớp là K-means và Mini batch K-means để phát hiện các bất thường từ các gói tin mạng của các ứng dụng Bên cạnh đó, họ so sánh hiệu năng của mỗi thuật toán Trong bài viết này, nhóm tác giả chỉ tập trung phân lớp các ứng dụng so với tập các malware đã biết, điều này gặp khó khăn trong việc phân tích các họ malware mới (Zero day malware) Hướng tiếp cận này không quan tâm đến ngữ nghĩa của các gói tin Cần mở rộng phân tích nội dung của các yêu cầu kết nối mạng của các ứng dụng để có thể phát hiện các hành vi nguy hiểm thay vì so khớp dữ liệu mạng thu thập được của ứng dụng đang xem xét với dữ liệu mạng thu thập được từ các ứng dụng trong tập mẫu

Hình 13: Mô hình đề xuất trong việc phân tích mạng

Zaman và đồng sự [42] đề xuất một phương pháp phát hiện các malware dựa vào thông tin của các yêu cầu truy cập mạng từ các ứng dụng Hệ thống của

họ tiến hành thu thập các tên miền mà ứng dụng đang truy cập đến, nếu tên miền nằm trong danh sách các tên miền nguy hiểm (lacklist domains) được định nghĩa trước thì hệ thống cho rằng ứng dụng đó là malware Như vậy, hướng tiếp cận này phụ thuộc nhiều vào danh sách blacklist domains Điều này cũng gặp khó khăn trong việc phát hiện các malware sử dụng các tên miền (Command and Control- C&C server) mới chưa có trong danh sách blacklist domains Cần xem xét một phương pháp phân tích hành vi truy cập mạng của ứng dụng kèm với giải pháp này để có thể phát hiện các malware dùng C&C server mới

Li và đồng sự [45] đề xuất một hướng tiếp cận trong việc phân tích malware trên Android bằng cách áp dụng thuật toán phân lớp SVM trên các thông tin truy cập mạng Tác giả cho chạy các ứng dụng sạch trong thời gian dài và tiến hành thu thập thông tin gói tin mạng, tiếp theo cho các ứng malware chạy

để tiến hành thu thập thông tin mạng Việc phân loại dựa vào hai thông tin thu thập này Hướng tiếp cận này chỉ phát hiện malware dưa vào việc so sánh với các malware có sẵn nên gặp khó khăn trong việc phát hiện các malware mới, với các hành vi mới

Shabtai và đồng sự [43] đã đề xuất một hướng tiếp cận phân tích các malware

tự thân cập nhật bằng cách thu thập thông tin mạng Hướng tiếp cận này cũng cho phép phân biệt được sự thay đổi của các hành vi truy cập mạng của ứng

dụng thuộc một trong ba loại: do thói quen của người dùng thay đổi, do một ứng dụng tự cập nhật phiên bản mới và do malware chèn thêm mã độc từ Internet Hướng tiếp cận này chỉ quan tâm đến hành vi truy cập mạng mà không xem xét đến tính nguy hiểm của việc đánh cắp thông tin trên thiết bị rồi sau đó gởi lên mạng thông qua kết nối mạng

Feldman và đồng sự [48] cũng đề xuất một giải pháp cho phép phát hiện malware bằng cách phân nhóm các thông tin mạng với kỹ thuật máy học Phương pháp này cũng không quan tâm đến việc đánh cắp thông tin nhạy cảm hay không mà chỉ quan tâm đến hành vi truy cập mạng, điều này dẫn đến phát hiện nhầm các ứng dụng truy cập Internet bình thường

Như vậy, các nghiên cứu liên quan đến phân tích thông tin mạng hiện tại đề chỉ dừng lại ở bước phân tích thông tin các gói tin mạng, hoặc kết hợp thông tin gói tin mạng với các permission nhạy cảm, hay các hàm API nhạy cảm trên từng ứng dụng riêng biệt Cần phải mở rộng các nghiên cứu này theo hướng phân tích liên ứng dụng Tức là việc phân tích thông tin gói tin mạng

là một quá trình con trong quá trình phân tích liên ứng dụng Quá trình này

có thể xem là một quá trình phân tích chi tiết hóa các sink nhạy cảm làm giảm

tỷ lệ False Positive

Bảng 4: Ưu và nhược điểm của các loại dữ liệu nguồn dùng để phân tích

Application package Đơn giản trong quá

trình phân tích

Gặp khó khăn khi gặp

kỹ thuật mã hóa và làm rối mã nguồn

Không phát hiện được các hành vi thực sự của malware

Sensitive data flow Phân tích đơn giản Không phải tất cả ứng

dụng độc hại truy cập đến các dữ liệu nhạy cảm

Kernel level / System

call

Có thể nhận diện các hành vi thực của malware

Phân tích phức tạp

Dữ liệu thu thập lớn

Network traffic Có thể nhận diện các

hành vi thực của malware

Phân tích phức tạp Tạo dữ liệu thu thập lớn

Hardware performance Có thể nhận diện các

hành vi thực của malware

Các bất thường vể hiệu năng có thể do người dùng sử dụng quá nhiều ứng dụng cùng

1.2.3 Phạm vi phân tích (Scope of analysis)

Một vấn đề cũng liên quan đến các loại dữ liệu nguồn trong quá trình phân tích là phạm vi phân tích Có thể phân tích ở các phạm vi khác nhau: trên từng ứng dụng (A), trên nhóm nhiều ứng dụng (B), hoặc trên cả thiết bị (C)

App1 App2 App3 AppN

Hình 14: Các phạm vi phân tích

Phạm vi phân tích trên từng ứng dụng chỉ thu thập các đặc trưng của một ứng dụng cụ thể, không xét đến mối tương quan của ứng dụng đang phân tích với các ứng dụng khác Trong trường hợp này, việc phân tích nhanh, tuy nhiên không phát hiện các trường hợp tấn công leo thang hay các malware sử dụng

kỹ thuật tấn công cộng tác

Scope of analysis

Hình 15: Phạm vi phân tích

Phân tích trên nhóm nhiều ứng dụng tuy phức tạp trong việc thu thập thông tin, nhưng có thể phát hiện các dạng malware sử dụng kỹ thuật tấn công theo thang hay tấn công cộng tác Đây là hướng nghiên cứu được quan tâm nhiều hiện nay

Hầu hết các nghiên cứu hiện tại chỉ phân tích trên từng ứng dụng Chỉ có các nghiên cứu [12, 13] đề cập đến việc phân tích trên nhiều ứng dụng

Với phạm vi phân tích trên cả thiết bị cho phép phân tích nguy cơ bảo mật trên cả thiết bị thay vì chỉ phân tích trên một số ứng dụng có trên thiết bị này Phân tích firmware của thiết bị di động [52] cũng là một hướng nghiên cứu mới

1.2.4 Loại nhận diện (Type of identification)

Có hai loại nhận diện Android malware: Signature-based detection (SB), Anomaly-based detection (AB)

Type of identification

based

Anomaly-based

41, 50]

Andromaly [21] sử dụng kỹ thuật phân tích động với thuật toán máy học trong

thông tin sử dụng CPU, số lượng gói tin mạng, số tiến trình đang chạy và thông tin sử dụng pin Sử dụng ba thuật toán lựa chọn đặc trưng Chi-Square, Fisher Score và Information Gain Sử dụng các thuật toán phân loại: K-Means, Logistic Regression, Histograms, Decision Trees, Bayesian Networks và Naive Bayes Trong quá trình phân tích, nhóm tác giả dùng số lượng mẫu malware ít và không phải tập các malware trong thực tế Việc sử dụng bộ dữ liệu thử nghiệm của chính nhóm tác giả cho thấy độ chính xác từ 40% đến 100%

Giống như Andromaly, Dini và đồng sự đề xuất MADAM [20] sử dụng kỹ thuật phân tích động trong việc phân tích malware MADAM cũng sử dụng thuật toán máy học để phân loại ứng dụng là malware hay ứng dụng sạch, việc phân tích này cũng thực hiện trên thiết bị di động Tuy nhiên, MADAM được thử nghiệm trên tập malware thật MADAM sử dụng thuật toán K-Nearest Neighbor với K=1 với độ chính xác lên đến 93%

Dù được sử dụng nhiều trong các nghiên cứu trước đây, tuy nhiên việc phân tích chỉ dừng lại ở việc phân tích trên từng ứng dụng đơn mà chưa đề cập nhiều đến việc phân tích liên ứng dụng Thực tế cần được mở rộng phân tích liên ứng dụng để phát hiện chính xác hơn các trường hợp tấn công leo thang, cộng tác giữa các ứng dụng Các trường hợp này có thể không bị phát hiện trong các nghiên cứu trên ứng dụng đơn

Các ứng dụng phòng chống malware thương mại thường sử dụng kỹ thuật phát hiện malware dựa vào giá trị đặc trưng Phương pháp này tiến hành rút trích các mẫu cú pháp hoặc các mẫu ngữ nghĩa, đặc trưng ngữ nghĩa từ ứng dụng rồi đem so sánh giá trị đặc trưng này với từng malware trong quá trình nhận dạng [9, 53-55] Thử thách của phương pháp này là cách lựa chọn các đặc trưng để tăng tính chính xác khi nhận diện Hana và đồng sự [53] đề xuất giải pháp Juxtapp để phát hiện các mã nguồn độc hại được tái sử dụng từ malware trong các ứng dụng Juxtapp tiến hành rút trích thông tin từ tập tin DEX để tạo tập tin Basic Block (BB) và sau đó nhị phân hóa các thông tin trong tập tin này bằng hàm djb2 Việc rút trích thông tin này ảnh hưởng nhiều đến độ chính xác của việc phát hiện malware

Hình 17: Mô hình hoạt động của Juxtapp

Hu và đồng sự [54] đề xuất một phương pháp phát hiện malware dựa vào việc phân tích độ tương đồng của hai chuỗi bằng cách dùng thuật toán Levenshtein distance Việc phân tích này phụ thuộc nhiều vào các chuỗi dùng để phân tích

do đó gặp khó khăn trong việc phân tích malware sử dụng kỹ thuật mã hóa

và biến hình

Faruki và đồng sự phát triển AndroSimilar [29] để phát hiện các biến thể mới của các malware đã biết AndroSimilar dùng kỹ thuật phân tích cấu trúc để tính độ tương đồng của hai ứng dụng

Việc phân tích các malware dựa vào việc phân tích các đặc trưng mang tính

cú pháp [53, 54] gặp khó khăn khi phân tích các malware biến hình Các đặc trưng mang tính ngữ nghĩa là cần thiết để giải quyết các khó khăn này Feng

và đồng sự đề xuất Apposcopy [55] Apposcopy phân tích malware dựa vào hai thuộc tính ngữ nghĩa Control Flow và Data Flow của ứng dụng Android Nếu chỉ dùng permission để phát hiện malware [4-9] thì sẽ phát sinh tỷ lệ phát hiện nhầm cao Tức là các permission được khai báo nhiều chưa chắc đã

là malware, mà cần kiểm tra các permission này có được sử dụng khi thực thi chương trình hay không Việc phân tích thêm hành vi của ứng dụng sau khi phân tích permission là cần thiết

tích các hàm API được gọi và các quyền được yêu cầu khi cài đặt một ứng

dụng Trong nghiên cứu này, nhóm tác giả tiến hành rút trích các thông tin

về quyền hạn được yêu cầu bởi ứng dụng trong tập tin Manifest Rút trích các

thông tin về các lời gọi hàm API liên quan đến các quyền hạn đã được yêu

cầu Nghiên cứu này cũng dùng k-mean và kNN trong việc mô hình hóa và

phân loại malware Phương pháp này có ưu điểm là tốn ít tài nguyên vì không

cần phải thực thi ứng dụng mà chỉ cần phân tích từ tập tin apk

Min và đồng sự đề xuất giải pháp phát hiện malware trên Android có tên

DroidAnalytics [16] bằng cách rút trích các đặc trưng ở ba lớp Application,

Class và Method

Hình 18: Mô hình phân tích malware của DroidAnalytics

DroidAnalytics có thể phát hiện các malware dùng kỹ thuật repackaging,

malware dùng kỹ thuật làm rối mã nguồn và malware sử dụng kỹ thuật tự tải

mã độc (dynamic payloads)

Bảng 5: Ưu và nhược điểm của các loại nhận diện

Signature based Phát hiện các malware đã

biết rất nhanh

Tốn ít tài nguyên

Không hiệu quả với các malware mới

Anomaly based Hiệu quả trong việc phát

hiện các malware mới

Cần nhiều tài nguyên tính toán

Cảnh báo sai nhiều

Tóm lại, phân tích bằng signature thì đơn giản trong quá trình phân tích, tuy

nhiên chỉ phù hợp trong việc phân tích các malware đã biết, và gặp khó khăn

trong việc phân tích các malware mới hay có tính biến hình phức tạp Các

nghiên cứu trước đây của hướng nghiên cứu này cũng chỉ tập trung nhiều trong việc phân tích ứng dụng đơn mà chưa quan tâm sâu vào việc phân tích trên nhiều ứng dụng

1.2.5 Môi trường triển khai (Deployment Platform)

Malware detection có thể được triển khai trên thiết bị di động (host) hoặc triển khai trên máy tính từ xa (Server/CLoud) Nếu triển khai trên máy host, tất cả các hoạt động của thiết bị đều được giám sát, phân tích và xử lý trên chính thiết bị đó Trong khi đó, nếu triển khai trên máy tính từ xa thì việc giám sát các hoạt động của thiết bị được thực hiện trên trên chính thiết bị đó, còn việc phân tích và xử lý được thực hiện trên máy chủ trên mạng

Deployment Platform

Hình 19: Môi trường triển khai

Nếu xét về cách triển khai hệ thống nhận diện malware, hầu hết các nghiên cứu triển khai hệ thống nhận diện Android malware trên chính thiết bị di động Các hệ thống phát hiện malware của các nghiên cứu [5, 19-21, 29, 32,

33, 35, 38-41, 50] được triển khai trên chính thiết bị di động Việc triển khai

hệ thống nhận diện trên các chính các thiết bị di dộng có ưu điểm là thời gian đáp ứng trong việc thu thập thông tin liên quan (audit data source) nhanh Tuy nhiên, điều này cũng gây ra khó khăn trong việc sử dụng quá nhiều không gian lưu trữ vốn bị giới hạn trên các thiết bị di động Bên cạnh đó, khả năng

xử lý hạn chế của các thiết bị di động cũng là một thách thức lớn trong việc đảm bảo khả năng phát hiện malware nhanh chóng Để khắc phục các khó khăn này, các nghiên cứu [17, 18, 30, 49] tiến hành xử lý các dữ liệu đã được thu thập trên các máy tính tập trung hoặc thông qua các máy chủ trên Cloud

Có nghĩa là, dữ liệu giám sát sẽ được lưu thành một tập tin trên thiết bị di động, sau đó chuyển tập tin này đến máy chủ từ xa Máy chủ này xử lý thông tin và kết quả được gởi ngược lại cho thiết bị di động Phương pháp này tốn

ít không gian lưu trữ trên thiết bị di động, đồng thời giảm đáng kể các xử lý phức tạp trên thiết bị di động Tuy nhiên, phương pháp này cũng có một số hạn chế như: nguy cơ lộ thông tin nhạy cảm của người dùng trong quá trình

kiệt Hai nghiên cứu [19, 31] triển khai trên cả thiết bị di động và máy chủ từ

xa

Bảng 6: Ưu và nhược điểm của các môi trường triển khai

dùng nhanh

Không gian lưu trữ và khả năng xử lý bị hạn chế

Server/Cloud Không yêu cầu thiết bị

di động có cấu hình phần cứng cao

Đòi hỏi kết nối Internet liên tục gây hao pin

Mở kênh kết nối ra bên ngoài nên có nguy cơ

để lộ thông tin trên thiết bị

Bảng 7: Thống kê các nghiên cứu hiện tại

Solution Name

Type of identification 1

Detection Technique 2

Deployment Platform 3

Audit Data Source

Scope of analysis 4

All except App package

O

All except App package

O

Moonsamy et

O

1 Các loại nhận diện: A (Anomaly-based); S (Signature-Based)

2 Các kỹ thuật phân tích: S (Static); D (Dynamic); H (Hybrid)

3 Môi trường triển khai: H (Host); S (Server/Cloud)