Đá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

ĐẠ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ã số:

62 48 02 01

Cán bộ hướng dẫn:
TS Nguyễn Anh Tuấn
TS Phạm Văn Hậu

Tp. Hồ Chí Minh, tháng 10/2015


Mục lục
1

2

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

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

3

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

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

6

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

Nội dung và phạm vi của vấn đề đi sâu giải quyết .............................. 50

2


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

3


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
ApkCombiner .............................................................................................. 44

4


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

5


Danh mục bang 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

6


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.

Số lượng thiết bị được bán (đơn vị: triệu)
2000

1,969

1,906

1,838
1800
1600
1400
1200
1000

800
600
400

333

321

318

259

233

216
200

11

9

6
0
2014

2015

2016

PC

Tablets

Mobile Phones

Khác

Linear (Mobile Phones)
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.

7


Thống kê số thiết bị được bán với hệ điều hành
tương ứng (Đơn vị tính: nghìn)
1,800,000
1,619,030
1,600,000
1,454,760
1,400,000
1,200,000

1,156,111

1,000,000

800,000
626,358
600,000

400,000

333,017
262,615

380,545
355,035
279,415

393,256
298,896
261,155

200,000
0
2014

2015

Android

iOS/Mac OS

Khác

Linear (Android)

2016
Windows

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ể
Android
275
iPhone
1
Symbian
1
Theo thống kê của Symantec [3], trong năm 2014 có 94% malware mới nhắm
vào hệ điều hành Android.
Do đặc tính cấu hình và mục đích sử dụng của các điện thoại thông minh khác
với các máy tính truyền thống nên hành vi tấn công của các phần mềm độc
hại trên điện thoại thông minh và trên máy tính truyền thống có nhiều khác
biệt.
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.

8

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

Nhóm hành vi
Steals device data

Spies on user

Sends premium SMSs
Downloader
Back door
Tracks location
Modifies settings
Spam
Steals media
Elevates privileges
Banking Trojan

SEO poisoning
Adware/ Annoyance
DDOS Utility
Hacktool

Mô tả
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.
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.
Gởi tin nhắn đến các tổng đài tính phí để tính phí tin nhắn.

Có thể tải các thành phần nguy hiểm khác từ Internet lên
thiết bị nạn nhân.
Cho phép kẻ tấn công giao tiếp và điều khiển thiết bị nạn
nhân từ xa.
Thu thập thông tin GPS để theo dõi vị trí của nạn nhân.
Thay đổi thông tin cấu hình trên thiết bị nạn nhân.
Gởi hàng loạt email hoặc tin nhắn đến thiết bị của nạn
nhân.
Gởi các nội dung số, ví dụ: ảnh, phim đến một máy chủ
trên mạng.
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.
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.
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.
Quảng bá thông tin quảng cáo đến người dùng.
Tấn công từ chối dịch vụ
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

Steals Device Data

36%

17%

Spies On User

36%

28%

Sends Premium SMS

16%

5%

9


Downloader

18%

8%

Back door

18%

12%

Tracks Location

9%

3%

Modifies Settings

20%

8%

Spam

7%

3%

Steals Media

0%

3%

Elevates Privileges

7%

2%

Banking Trojan

7%

3%

SEO Poisoning

0%

0%

Adware/ Annoyance

13%

9%

DDOS Utility

0%

0%

Hacktool

0%

0%

Như vậy, nguy cơ bảo mật trên các thiết bị điện thoại thông minh sử dụng hệ
điều hành Android ảnh hưởng đến nhiều người dùng trên thế giới. Việc
nghiên cứu bảo mật trên điện thoại thông minh nói chung và trên điện thoại
thông minh sử dụng hệ điều hành Android trở nên cấp thiết.
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
thập dữ liệu để làm đầu vào cho quá trình nhận diện phía.

10

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.

11


Static
Detection technique

Dymamic
Hybrid
Application
package
Kernel/
Systemcall

Audit data source

Network traffic

Hardware
performance
Sensitive Data
Flow

Detection
Process
Characterization

Standalone App

Scope of Analysis

Group of Apps
Per device

Type of
identification

Anomaly
Signature

Host
Deployment
Platform

Server/Cloud

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.

12


Detection
Technique

Static

Dymamic

Hybrid

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.
13


-

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.

New
application

Disassembly
application

Feature Extractor

Anomaly
detection

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

Trong bước dịch ngược các tập tin cài đặt sang mã nguồn, các công cụ như
ApkTool [14], Dalvik decompider [15] thường được sử dụng.
Các thông tin đặc trưng thường dùng là permission, system call, control flow
graph (CFG), data flow graph, activity flow graph, component flow graph.
Các nghiên cứu [4-9] dùng thông tin permission trong tập tin
AndroidManifest.xml như là các đặc trưng cho quá trình phân tích.
DroidAnalytics [16] sử dụng thông tin về việc gọi hàm API để là đặc trưng
cho mỗi ứng dụng. Trong khi đó FlowDroid [10], PCLeaks [11], DidFail [12]
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.

14

Mobile Phone
New
application

Install App

Virtual Machine

Taint tracking:
-Variable level
-Method level
-Message level
-File level

Dynamic Taint
Analysis

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.

15


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. MobileSandbox [26] giống như DroidBox, chỉ khác ở điểm là tracer được gắn ở core
lib thay vì Dalvik VM.
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.

16


AASandbox
Install App

New
application

Static Analysis
- Disassemble
binary
- Search for
pattens
Dynamic Analysis
- Install binary
- Execute binary
- Track system
calls
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.

Hardware
performance

Network traffic

System Call

Sensitive Data
Flow

Application
package

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 để

17


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, 3840] 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

18

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 toá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 Naï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.

19


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.

20


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
21


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

Ưu điểm
Nhược điểm
Đơn giản trong quá Gặp khó khăn khi gặp

trình phân tích
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 Có thể nhận diện các Phân tích phức tạp.
call
hành vi thực của Dữ liệu thu thập lớn
malware
Network traffic
Có thể nhận diện các Phân tích phức tạp.
hành vi thực của Tạo dữ liệu thu thập
malware
lớn
Hardware performance Có thể nhận diện các Các bất thường vể hiệu
hành vi thực của năng có thể do người
malware
dùng sử dụng quá
nhiều ứng dụng cùng
lúc.
Audit data source
Application package

22


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
Standalone App

App1

App2

(A)

(B)

(C)

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

Standalone App

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

23

Per device


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

Anomalybased

Signaturebased

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

Signature-based detection phát hiện malware bằng cách so sánh đặc trưng
của ứng dụng hoặc các mẫu thu thập được với cơ sở dữ liệu của các malware
đã biết. Anomaly-based detection giám sát các hành động thông thường trong
thiết bị và tìm xem có bất kỳ hành vi nào bất thường không.
Hướng tiếp cận Anomaly-based detection là hướng tiếp cận sử dụng kỹ thuật
xác định các bất thường của các hành vi của một ứng dụng. Nếu sự khác biệt
giữa các hành vi này lớn hơn nhiều so với các tập hành vi bình thường thì
xem ứng dụng này là một ứng dụng độc hại. Hướng tiếp cận này được sử
dụng nhiều trong các nghiên cứu trước đây [5, 17, 18, 20, 21, 29, 32-36, 39,
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
việc phân loại một ứng dụng là malware hay ứng dụng sạch. Quá trình phân
loại được thực hiện trên chính thiết bị. Dữ liệu nguồn dùng để phân tích gồm
24


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: KMeans, 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 KNearest 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.

25