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


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



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

800
600
400

333

321

318

259

233

216
200

11

9

6
0
2014

2015

2016

PC

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)

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.


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%


Elevates Privileges

7%

2%

Banking Trojan

7%

3%

SEO Poisoning

0%

0%

Adware/ Annoyance

13%

9%

DDOS Utility

0%

0%

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

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.


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


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à

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ệ



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

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

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


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

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