NGHIÊN cứu cơ CHẾ PHÁT HIỆN rò rỉ THÔNG TIN BẰNG CÁCH kết hợp PHƯƠNG PHÁP PHÂN TÍCH TĨNH và ĐỘNG TRÊN ANDROID

32 CHƯƠNG 3 : MÔ HÌNH KẾT HỢP KỸ THUẬT PHÂN TÍCH TĨNH VÀ ĐỘNG NHẰM PHÁT HIỆN DỮ LIỆU RÒ RỈ THÔNG QUA NHIỀU ỨNG DỤNG ..... thể, đề tài sẽ thực hiện nghiên cứu kết hợp các kỹ thuật phân tí

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

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

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

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

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Phạm Văn Hậu – Trường ĐH Công Nghệ Thông Tin

TP HỒ CHÍ MINH – 2016

LỜI CẢM ƠN

Để hoàn thành luận văn này, tôi xin gửi lời biết ơn chân thành đến TS Phạm Văn Hậu, đã tận tình hướng dẫn cho tôi trong suốt quá trình thực hiện luận văn

Tôi chân thành cảm ơn quý Thầy Cô Trường Đại Học Công Nghệ Thông Tin, ĐHQG.HCM đã tận tình giảng dạy và truyền đạt những kiến thức bổ ích trong suốt quá trình học tập tại trường

Tôi cũng xin được cảm ơn gia đình và bạn bè đã luôn quan tâm, động viên, tạo điều kiện thuận lợi để tôi hoàn thành luận văn

Và cuối cùng, tôi xin kính chúc quý Thầy Cô dồi dào sức khỏe và thành công trong sự nghiệp Chúc Trường Đại học Công nghệ Thông tin, ĐHQG.HCM ngày càng phát triển

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này do chính tôi thực hiện dưới sự hướng dẫn khoa học của TS Phạm Văn Hậu, giảng viên Trường Đại học Công Nghệ Thông Tin, ĐHQG.HCM

Các số liệu và kết quả nghiên cứu trong luận văn là trung thực Các thông tin trích dẫn trong luận văn đã được chỉ rõ nguồn gốc và được phép công bố

Nếu sai, tôi xin hoàn toàn chịu trách nhiệm

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

DANH MỤC CÁC HÌNH VẼ 6

MỞ ĐẦU 8

CHƯƠNG 1: TỔNG QUAN 11

1.1 Tình hình nghiên cứu 11

1.1.1 Tình hình nghiên cứu ngoài nước 11

1.1.2 Tình hình nghiên cứu trong nước 12

1.2 Tính khoa học và tính mới 12

1.3 Mục tiêu, đối tượng và phạm vi nghiên cứu 12

1.4 Nội dung và phương pháp nghiên cứu 13

CHƯƠNG 2 : KIẾN THỨC NỀN TẢNG 16

2.1 Android 16

2.1.1 Kiến trúc Androiod 16

2.1.2 Cơ bản về ứng dụng Android 18

2.1.3 Cơ chế bảo mật trên Android 20

2.1.4 Cơ chế hoạt động phối hợp của các phần mềm độc hại trên Android 21

2.1.5 Tìm hiểu về mã nguồn hệ điều hành Android 22

2.1.6 Smali Byte Code 25

2.2 Các kỹ thuật phân tích dữ liệu rò rỉ 27

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

2.2.3 Kỹ thuật phân tích kết hợp tĩnh và động 28

2.3 DidFail và SmartDroid 29

2.3.1 DidFail 30

2.3.2 SmartDroid 32

CHƯƠNG 3 : MÔ HÌNH KẾT HỢP KỸ THUẬT PHÂN TÍCH TĨNH VÀ ĐỘNG NHẰM PHÁT HIỆN DỮ LIỆU RÒ RỈ THÔNG QUA NHIỀU ỨNG DỤNG 36

3.1 Giới thiệu mô hình 36

3.2 Mô tả chỉ tiết mô hình 39

3.2.1 Static Path selector 39

3.2.1.1 DidFail Module 39

3.2.1.2 Disassamble 40

3.2.1.3 Source-Sink: ACG-FCG 40

3.2.2 Dynamic UI Trigger 41

3.2.2.1 Runtime Execution 41

3.2.2.2 Activity Restriction 41

3.2.2.3 UI Interaction Simulator 42

CHƯƠNG 4 : CÀI ĐẶT, THỰC NGHIỆM VÀ ĐÁNH GIÁ KẾT QUẢ 43

4.1 Cài đặt mô hình 43

4.1.1 Cài đặt hệ thống 43

4.1.2 Cài đặt DidFail 43

4.1.3 Cài đặt Android Simulator 46

4.1.4 Cài đặt ApkTool 49

4.2.1 Xây dựng DidFail Module 50

4.2.2 Xây dựng Disassemble 51

4.2.3 Xây dựng Source-Sink:ACG-FCG 52

4.3 Xây dựng Dynamic UI Trigger 56

4.3.1 Xây dựng Runtime Execution 56

4.3.2 Xây dựng Activity Restrictor 57

4.3.3 Xây dựng UI Interaction Simulator 58

4.4 Kết nối các thành phần 60

4.5 Thực nghiệm và đánh giá kết quả 61

4.5.1 Giới thiệu về tập ứng dụng kiểm thử Toyapps 61

4.5.2 Các trường hợp kiểm thử 63

4.5.3 Đánh giá kết quả 64

CHƯƠNG 5 : KẾT LUẬN 71

TÀI LIỆU THAM KHẢO 73

DANH MỤC CÁC HÌNH VẼ

Hình 2.1: Sơ đồ kiến trúc hệ điều hành android 16

Hình 2.2: Ví dụ minh họa cho Implicit và Explicit Intent 19

Hình 2.3: Ví dụ minh họa cho Confused deputy attack 22

Hình 2.4: Ví dụ minh họa cho Collustion attack 22

Hình 2.5: Cấu trúc mã nguồn hệ điều hành Android 23

Hình 2.6: Ví dụ cho Java – Smali Byte Code 25

Hình 2.7: Cấu trúc của Smali class 26

Hình 2.8: Các kiểu dữ liệu trong Smali Byte Code 26

Hình 2.9: Ví dụ cho Smali method 26

Hình 2.10: Mô hình tổng quát của DidFail 31

Hình 2.11: Mô hình tổng quát của SmartDroid 33

Hình 2.12: Ví dụ cho ACG và FCG 34

Hình 3.1: Mô hình kết hợp DidFail và SmartDroid 36

Hình 3.2: Ví dụ về đồ thị cây source ->sink: ACG-FCG 38

Hình 3.3: Mô hình giai đoạn 1 của DidFail Module 39

Hình 4.1: Hình minh họa cho Android Simulator 48

Hình 4.2: Mô hình Static Path Selector 49

Hình 4.3: Ví dụ minh họa cho tập tin DidFailModule.out 51

Hình 4.4: Các lớp lưu trữ và xử lý thông tin Smali Byte Code 52

Hình 4.6: Mô hình Dynamic UI Trigger 56

Hình 4.7: Lớp SmartDroidConfig 56

Hình 4.8: Ứng dụng android Dynamic UI Control 60

Hình 4.10: Ứng dụng Echoer 62

Hình 4.11: Ứng dụng SendSMS 62

Hình 4.12: Ứng dụng WriteFile 63

Hình 4.13: Sơ đồ hoạt động của Toyapps 63

Hình 4.14: Kết quả phân tích Toyapps của DidFail 64

Hình 4.15: Kết quả phân tích Toyapps của hệ thống mới 66

MỞ ĐẦU

Ngày nay, Android là hệ điều hành di động phổ biến nhất thế giới Android

có mặt trong hầu hết các thiết bị di động như: Điện thoại, máy tính bảng, đồng hồ thông minh, v.v Sự phổ biến của Android đã biến nó thành mục tiêu tấn công của các phần mềm độc hại [14] Theo thống kê của F-Secure, trong số nhưng phần mềm độc hại trên di động mới được phát hiện, Android chiếm 99% [10]

Trước sự phát triển ngày càng tăng của các phần mềm độc hại, vấn đề bảo mật trên nền tảng Android trở nên cấp thiết Hiện nay, đã có rất nhiều kỹ thuật được

áp dụng nhằm phát hiện và ngăn chặn các phần mềm độc hại Trong đó, có các kỹ thuật chính như sau:

• Kỹ thuật phân tích tĩnh [1, 6, 7, 9, 17, 21]: đào sâu vào phân tích ứng dụng để phát hiện những nguy cơ, mà không cần thực thi chúng

• Kỹ thuật phân tích động [8, 11, 19, 20]: tập trung vào phân tích hành vi của ứng dụng khi thực thi để tìm kiếm hành vi bất thường

• Kết hợp cả hai kỹ thuật phân tích tĩnh và động [3, 13, 18]: kỹ thuật phân tích tĩnh thường được áp dụng để định hướng, giới hạn phạm vi phân tích cho kỹ thuật phân tích động

Mỗi kỹ thuật đều có ưu nhược điểm riêng: Kỹ thuật phân tích tĩnh giúp ta hiểu chi tiết về hành vi của ứng dụng, nhưng nó sẽ không phân tích chính xác nếu ứng dụng bị làm rối mã (obfuscation) Trong khi kỹ thuật phân tích động giúp xác định chính xác hành vi bất thường nhưng không thể phân tích hết tất cả hành vi của ứng dụng Để khắc phục nhược điểm của kỹ thuật phân tích tĩnh và động, nhiều hướng nghiên cứu đã thực hiện kết hợp hai kỹ thuật này nhằm tạo ra những kỹ thuật phân tích mới hiệu quả hơn

Trong phạm vi đề tài này, chúng tôi cũng sẽ nghiên cứu về phương pháp kết hợp kỹ thuật phân tích tĩnh và động nhằm tăng khả năng phát hiện dữ liệu rò rỉ Cụ

thể, đề tài sẽ thực hiện nghiên cứu kết hợp các kỹ thuật phân tích của hai công cụ là SmartDroid [3] và DidFail [2]:

• SmartDroid: là công cụ giúp phát hiện dữ liệu rò rỉ bằng cách áp dụng

kết hợp cả hai kỹ thuật phân tích tĩnh và động Hạn chế lớn nhất của SmartDroid chính là nó chỉ giới hạn phân tích trên một ứng dụng; nếu phần mềm độc hại hoạt động theo cơ chế phối hợp nhiều ứng dụng với nhau [xem 2.1.4] thì nó không phát hiện được Đây là một hạn chế rất lớn, vì với sự phát triển ngày càng phức tạp của các phần mềm độc hại,

cơ chế hoạt động phối hợp đang ngày càng trở nên phổ biến

• DidFail: là công cụ mã nguồn mở, sử dụng kỹ thuật phân tích tĩnh để

phát hiện dữ liệu rò rỉ thông qua nhiều ứng dụng Hạn chế chính của DidFail chính là nó không thể xác định được chính xác luồng dữ liệu nào sẽ thực sự rò rỉ khi thực thi Điều này làm giảm đi tính chính xác khi phân tích

Để khắc phục các nhược điểm của hai công cụ này, chúng tôi đề xuất một phương pháp mới nhằm kết hợp SmartDroid với DidFail SmartDroid sẽ giúp

DidFail xác định chính xác luồng dữ liệu rò rỉ khi ứng dụng thực thi Ngược lại, DidFail sẽ giúp SmartDroid mở rộng khả năng phân tích trên nhiều ứng dụng Đây cũng chính là mục tiêu của đề tài

Để thực hiện mục tiêu này, chúng tôi đã gặp không ít các thách thức:

• Trước tiên cần phải nắm và hiểu rõ nền tảng Android như: kiến trúc Android, các cơ chế hoạt động và thực thi của ứng dụng android, v.v

• Kế đến phải tìm hiểu sâu về SmartDroid và DidFail để hiểu và nắm được các kỹ thuật phân tích được sử dụng trong hai công cụ này

• Thách thức lớn nhất chính là phải xây dựng SmartDroid, vì đây không phải là một công cụ mã nguồn mở, nên chúng tôi phải thực hiện cài đặt, xây dựng lại nó từ đầu

• Thách thức trong việc nghiên cứu phương pháp kết hợp các kỹ thuật phân tích của SmartDroid với DidFail để xây dựng một hệ thống mới có khả năng phân tích, phát hiện dữ liệu rò rỉ truyền qua nhiều ứng dụng

• Việc phân tích xác định dữ liệu rò rỉ truyền qua nhiều ứng dụng sẽ phức tạp hơn rất nhiều so với một ứng dụng đơn lẻ

Và cuối cùng, sau thời gian nghiên cứu và vượt qua các thách thức, luận văn

đã hoàn thành, bao gồm 5 chương:

CHƯƠNG 1: TỔNG QUAN

1.1 Tình hình nghiên cứu

1.1.1 Tình hình nghiên cứu ngoài nước

Hiện nay, đã có rất nhiều công trình nghiên cứu nhằm phát hiện và ngăn chặn các phần mềm độc hại trên Android Trong đó, hai công trình nghiên cứu được

xem là nền tảng cho đề tài chính là SmartDroid [3] và DidFail [2]:

• SmartDroid: do nhóm tác giả thuộc đại học Peking và đại học Texas

A&M hợp tác nghiên cứu Đây là công cụ phân tích, phát hiện rò rỉ

thông tin dựa trên phương pháp kết hợp kỹ thuật phân tích tĩnh và động

Cơ chế hoạt động: SmartDroid gồm hai thành phần chính:

o Static Path Selector: áp dụng kỹ thuật phân tích tĩnh, thực hiện biên dịch ngược mã nguồn, phân tích và xác định tập những hành vi nhạy cảm (những hành vi có thể gây rò rỉ dữ liệu)

o Dynamic UI Trigger: áp dụng kỹ thuật phân tích động, thực thi những hành vi nhạy cảm đã xác định bởi Static Path Selector Từ đó, xác định được những hành vi nào thật sự gây rò rỉ dữ liệu

Ưu điểm: SmartDroid đã áp dụng kỹ thuật phân tích tĩnh để định hướng, giới hạn phạm vi cho kỹ thuật phân tích động, giúp tăng hiệu quả phát hiện dữ liệu

rò rỉ

Nhược điểm: SmartDroid hiện tại chỉ hỗ trợ phân tích cho một ứng dụng

• DidFail: là một công cụ mã nguồn mở áp dụng kỹ thuật phân tích tĩnh

để phát hiện dự liệu rò rỉ

Cơ chế hoạt động: DidFail thực hiện biên dịch ngược mã nguồn, chèn vào

mã nguồn những đoạn mã để đánh dấu và theo dõi luồng dữ liệu di chuyển giữa các thành phần ứng dụng và giữa các ứng dụng Từ đó, phân tích, xác định dữ liệu rò rỉ

1.1.2 Tình hình nghiên cứu trong nước

Đề tài luận văn của Mai Đức Viên [12] đã có những nghiên cứu chi tiết trong việc áp dụng TaintDroid [20] để phát hiện rò rỉ thông tin Đề tài cũng đưa ra những đề xuất để triển khai TaintDroid trên nền tảng Android ART [15] và khả năng kết hợp kỹ thuật phân tích tĩnh và động để khắc phục các hạn chế của

TaintDroid

1.2 Tính khoa học và tính mới

Như đã đề cập trong phần tình hình nghiên cứu, hạn chế của công cụ SmartDroid hiện tại là chỉ có thể phân tích cho một ứng dụng nên nó không thể phát hiện những dữ liệu rò rỉ truyền qua nhiều ứng dụng Đây là một hạn chế lớn khi mà các phần mềm độc hại ngày càng thông minh, chúng không chỉ hoạt động độc lập

mà còn phối hợp với nhau hoặc lợi dụng những phần mềm vô hại khác để lấy cắp thông tin người dùng

Để khắc phục nhược điểm này, đề tài đề xuất một phương pháp mới dựa trên việc nghiên cứu phương pháp kết hợp các kỹ thuật phân tích tĩnh và động của SmartDroid với DidFail Việc kết hợp này sẽ giúp ta xây dựng một hệ thống mới có khả năng phân tích trên nhiều ứng dụng, tăng cường khả năng phát hiện rò rỉ thông tin

1.3 Mục tiêu, đối tượng và phạm vi nghiên cứu

Mục tiêu

• Các giải pháp kết hợp kỹ thuật phân tích tĩnh và động hiện tại giải quyết chủ yếu cho từng ứng dụng riêng lẻ Mục tiêu của đề tài là đề xuất một phương pháp kết hợp phân tích tĩnh và động mới, có khả năng phát hiện

dữ liệu rò rỉ thông qua nhiều ứng dụng Cụ thể, đề tài sẽ nghiên cứu kết hợp SmartDroid với DidFail nhằm tạo ra một hệ thống mới, có khả năng phân tích trên nhiều ứng dụng

• Xây dựng công cụ thực nghiệm, đánh giá hiệu suất bằng cách so sánh các kết quả phân tích của hệ thống mới với SmartDroid và DidFail

Đối tượng và phạm vi nghiên cứu

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

o Các phần mềm độc hại hoạt động trên nền tảng Android

o Các công cụ phân tích, phát hiện phần mềm độc hại, cụ thể là DidFail

và SmartDroid

• Phạm vi nghiên cứu sẽ tập trung nghiên cứu phương pháp kết hợp kỹ thuật phân tích tĩnh và động để phát hiện dữ liệu rò rỉ thông qua nhiều ứng dụng

1.4 Nội dung và phương pháp nghiên cứu

• Nghiên cứu chi tiết về công cụ SmartDroid

• Tiến hành xây dựng lại SmartDroid

• Nghiên cứu phương pháp kết hợp các kỹ thuật phân tích của SmartDroid

và DidFail để tạo ra một kỹ thuật phân tích mới, giúp tăng hiệu suất phát hiện rò rỉ thông tin Dựa vào kỹ thuật phân tích mới này, tiến hành xây dựng một hệ thống phân tích mới, có khả năng phân tích và phát hiện dữ liệu rò rỉ thông qua nhiều ứng dụng

vi nhạy cảm thực hiện thông qua nhiều ứng dụng

o Cải tiến Dynamic UI Trigger của SmartDriod để nó có thể thực thi và phân tích những hành vi nhạy cảm được thực hiện phối hợp qua nhiều ứng dụng

• Xây dựng công cụ thực nghiệm, đánh giá hiệu bằng cách so sánh kết quả thực nghiệm của hệ thống mới so với DidFail và SmartDroid

Kết quả

• Xây dựng thành công một hệ thống mới có khả năng phát hiện dữ liệu rò

rỉ lan truyền qua nhiều ứng dụng

• Kết quả thực nghiệm chứng minh hệ thống phân tích hiệu quả hơn so với DidFail và SmartDroid

CHƯƠNG 2 : KIẾN THỨC NỀN TẢNG

2.1 Android

2.1.1 Kiến trúc Androiod

Hình 2.1: Sơ đồ kiến trúc hệ điều hành android

Hệ điều hành Android được chia làm 5 phần với 4 tầng chính:

• Tầng Applications: là tầng trên cùng chứa các ứng dụng android như:

browsers, camera, Clock,…

• Tầng Aplication Framework: cung cấp những dịch vụ cho các ứng

dụng dưới dạng các thư viện java Dưới đây là các dịch vụ chính được cung cấp bởi Android Framework:

o Activity Manager: quản lý vòng đời của các ứng dụng

o Content Providers: cho phép các ứng dụng truy cập và chia sẽ dữ liệu với các ứng dụng khác

o Resource Manager: cung cấp cách thức truy cập đến những dữ liệu chứa trong ứng dụng

o Notifications Manager: cho phép các ứng dụng hiển thị thông báo của mình trên hệ thống

o View System: là một tập hợp các form, controls, được sử dụng để tạo nên ứng dụng

o Telephony Manager: cung cấp thư viện truy xuất đến các dịch vụ điện thoại

o Location Manager: cung cấp thư viện hỗ trợ định vị vị trí của thiết bị

• Tầng Libraries và Anroid Runtime:

Libraries: là tập hợp những thư viện C/C++ Các ứng dụng android sẽ truy

xuất các thư viện này thông qua Android Framework Một số thư viện cơ bản như:

o System C library: tập hợp các thư viện hệ thống

o Media Libraries: hỗ trợ các hàm truy xuất, xử lý hình ảnh, video,

o Surface Manager: quản lý việc hiển thị và kết hợp đồ họa 2D và 3D

o LibWebCore: là webkit engine cho các android browser

o OpenGL/ES: thư viện đồ họa 2D, 3D

o SQLite: quản lý database của ứng dụng

o v.v…

Android Runtime: gồm tập thư viện java core và máy ảo Dalvik

o Thư viện java core: cung cấp hầu hết các chức năng cốt lõi của ngôn ngữ java Nhờ vậy, nó cho phép các nhà phát triển ứng dụng android viết các ứng dụng dựa trên ngôn ngữ java

o Máy ảo Dalvik: mọi ứng dụng android đều chạy trên máy ảo Dalvik, thực chất là máy ảo java được viết lại để có thể chạy nhiều máy ảo cùng lúc một cách hiệu quả trên cùng một thiết bị

• Tầng Linux Kernel: Hệ điều hành android được xây dựng dựa trên

nhân linux 2.6 Nó cung cấp các dịch vụ hệ thống cốt lõi như: security

system, memory management, process managementt, network stack, dirver model, v.v

2.1.2 Cơ bản về ứng dụng Android

Các ứng dụng android có 4 thành phần cơ bản: Activity, Service,

ContentProvider và BroadcastReceiver

• Activity: là nền của ứng dụng android, nó chứa tất cả các giao diện

người dùng như: button, textbox,…

• Service: là những tiến trình chạy bên dưới ứng dụng

• ContentProvider: cho phép các ứng dụng truy cập và chia sẽ dữ liệu

với các ứng dụng khác

• BroadcastReceiver: cho phép các ứng dụng nhận những thông điệp mà

hệ thống gửi đi cho tất cả các ứng dụng

Việc tương tác giữa các ứng dụng android được thực hiên thông qua các Intent Intent là một cơ cấu cho phép truyền thông điệp giữa các thành phần của ứng dụng và giữa các ứng dụng với nhau Mỗi Intent có các thuộc tính sau:

• Action: xác định hành động sẽ được thực hiện

• Data: chứa dữ liệu sẽ được xử lý trong Intent

• Type: kiểu của data

• Component: xác định thành phần nào sẽ nhận và xử lý intent

• Extras: chứa các dữ liệu bổ xung

Có hai loại intent:

• Explicit Intents: là những intent đã được xác định thuộc tính

component, nghĩa là đã chỉ rõ thành phần sẽ nhận và xử lý intent

Explicit Intent thường được dùng để khởi chạy các activity trong cùng một ứng dụng

• Implicit Intents: là những intent không chỉ rõ thuộc tính component,

thay vào đó nó bổ sung thông tin trong các thuộc tính như: action,

data,v.v Khi intent được gửi đi, hệ thống sẽ so sánh những thông tin này với những thông tin được định nghĩa trong intent filter của các component để quyết định component thích hợp nhất có thể xử lý nó Trong đó, Intent filter là một thuộc tính của component, nó định nghĩa những hành động mà component có thể xử lý Trường hợp có nhiều hơn một component thích hợp, hệ thống sẽ cho phép người dùng lựa chọn component nào sẽ thực thi

Để hiểu rõ thêm về intent và cơ chế tương tác giữa các ứng dụng android, ta xem ví dụ trong hình 2.2 dưới đây:

Hình 2.2: Ví dụ minh họa cho Implicit và Explicit Intent

Trong ví dụ hình 2.2, ta thấy:

• Acitivity 1 đã gọi Activity 3 bằng một Explicit Intent, bởi vì activity 3

đã được chỉ rõ trong thuộc tính component của Intent

• Activity 2 đã gọi một Implicit Intent vì nó không chỉ rõ component nào

cụ thể mà chỉ cung cấp thông tin action = ACTION_SEND Khi đó hệ thống sẽ phải tìm trong intent filter của các component, để xác định xem

component nào có khả năng xử lý hành động ACTION_SEND Ở ví dụ này, hệ thống đã tìm được 2 component thích hợp là Faction Email client và Human Email client Vì có nhiều hơn 2 component có khả năng

xử lý ACTION_SEND nên hệ thống trao quyền quyết định lại cho người dùng Người dùng sẽ chọn một trong hai component này để thực thi

Android bảo vệ việc truy cập các thành phần ứng dụng thông qua hệ thống các quyền truy cập Đối với mỗi ứng dụng, ta phải khai báo tất cả các quyền cần thiết của các thành phần mà ứng dụng sẽ truy xuất Có 4 cấp độ quyền truy cập:

• Normal: đây là quyền truy cập mặc định, chỉ được hệ thống xác nhận

một lần khi cài đặt ứng dụng

• Dangeous: là quyền truy cập ở mức cao hơn Ở mức này, hệ thống sẽ

yêu cầu người dùng xác nhận trước khi tiếp tục truy xuất đến thành phần ứng dụng

• Signature: ở mức này, hệ thống sẽ tự động cấp quyền nếu ứng dụng có

quyền trùng với quyền mà thành phần cần truy cập đã đăng ký với hệ thống

• SignatureOrSystem: giống như mức Signature, chỉ khác là nó chỉ áp

dụng cho các ứng dụng mặc định của hệ thống

Và việc khai báo các quyền truy cập cho ứng dụng cũng như cho từng thành phần của nó được thực hiện trong tập tin AndroidManifest.xml

2.1.3 Cơ chế bảo mật trên Android

Các ứng dụng android chạy trong một Sandbox – một khu vực cô lập trong

hệ thống và không được quyền truy cập đến phần còn lại của tài nguyên hệ thống, trừ khi nó được người dùng trao quyền truy cập một cách công khai khi cài đặt Trước khi cài đặt ứng dụng, cửa hàng Google Play sẽ hiển thị tất cả các quyền mà ứng dụng đòi hỏi Sau khi xem xét các quyền này, người dùng có thể chọn đồng ý

hoặc từ chối chúng, ứng dụng chỉ được cài đặt khi người dùng đồng ý tất cả các quyền

Hệ thống Sandbox và cơ chế yêu cầu xác nhận quyền khi cài đặt giúp tăng cường tính bảo mật cho ứng dụng Một số công ty bảo mật, như Lookout Mobile Security, AVG Technologies, McAfee,… đã phát hành những phần mềm diệt virus cho các thiết bị Android Phần mềm này tỏ ra không hiệu quả vì cơ chế Sandbox vẫn áp dụng vào các ứng dụng này, làm hạn chế khả năng quét sâu vào hệ thống để tìm nguy cơ

Google hiện đang sử dụng bộ quét phần mềm độc hại Google Bouncer để theo dõi và quét các ứng dụng trên Cửa hàng Google Play Google Bouncer sẽ đánh dấu các phần mềm bị nghi ngờ và cảnh báo người dùng về những vấn đề có thể xảy

ra trước khi họ tải nó về máy Bắt đầu từ phiên bản Android 4.2 Jelly Bean (phát

hành vào năm 2012), các tính năng bảo mật đã được cải thiện, bao gồm một bộ quét phần mềm độc hại được cài sẵn trong hệ thống, hoạt động cùng với Google Play Đặc biệt, nó cũng có thể quét được cả các ứng dụng được cài đặt trực tiếp không thông qua Google Play

Tuy nhiên, việc xác nhận quá nhiều quyền, cộng với tài liệu hướng dẫn còn hạn chế dẫn đến những bối rối cho người dùng khi cài đặt ứng dụng Họ thường không quan tâm hoặc bỏ qua các quyền này và chọn chấp nhận tất các quyền để cài đặt ứng dụng Do đó làm giảm đi hiệu quả của hệ thống này

2.1.4 Cơ chế hoạt động phối hợp của các phần mềm độc hại trên

Android

Các phần mềm độc hại có thể hoạt động phối hợp với nhau theo hai cơ chế:

• Confused deputy attack: Phần mềm độc hại sẽ lợi dụng các phần mềm bình thường Ví dụ:

Hình 2.3: Ví dụ minh họa cho Confused deputy attack

• Collusion attack: Các phần mềm độc hại phối hợp với nhau Ví dụ:

Hình 2.4: Ví dụ minh họa cho Collustion attack

2.1.5 Tìm hiểu về mã nguồn hệ điều hành Android

Việc cài đặt SmartDroid đòi hỏi phải chỉnh sửa và build lại hệ điều hành Android Để làm được điều đó, trước tiên chúng tôi phải tìm hiểu và nắm rõ cấu trúc

mã nguồn của hệ điều hành Android Cụ thể, chúng tôi đã tiến hành tìm hiểu phiên bản Android 4.0.1 Hình 2.5 sẽ cho thấy cấu trúc tổng thể của toàn bộ mã nguồn hệ điều hành Android

Hình 2.5: Cấu trúc mã nguồn hệ điều hành Android

Trong đó:

• abi: application binary interface, quản lý việc tương tác với CPU Mỗi

loại CPU sẽ có một abi dành riêng cho nó

• bionic: đây là thư viện C được Google phát triển riêng cho Android

• bootable: gồm 3 module:

o bootloader/legacy: mã nguồn SoC (system on a chip) bootloader

o diskinstaller: mã nguồn cài đặt hệ điều hành

o recovery: mã nguồn recovery

• build: chứa các công cụ, tập tin cấu hình để build/compile hệ điều hành

Android

• cts: compatibility Test Suite

• dalvik: tập hợp các công cụ của android dalvik Cấu trúc của dalvik:

o alloc - cấp phát bộ nhớ cho dalvik

o analysis – tập hợp các công cụ liên quan đến bytecode như: dalvik

bytecode structural, xử lý dex file, Davik class file, bytecode optimizations,v.v

o arch: định nghĩa các interface được gọi thông qua JNI

o compiler - compiler cho java application

o hprof: công cụ profiling

o Interp: dalvik interpreter entry point

o jdwp: Java Debug Wire Protocol support

o mterp: mã nguồn của Dalvik interpreter

o native: Internal native functions

o oo: kiểm tra việc truy xuất fields, methods, type,

o os: mã nguồn liên quan đến thread

o reflect: mã nguồn cho reflection và proxy

o test: các test file

• development: mã nguồn những ứng dụng mặc định của hệ thống

• device: mã nguồn liên quan đến target device

• docs: tài liệu chi tiết về java byte code, dalvik bytecode, dalvik library,

dex format,

• external: mã nguồn của những thư viện hỗ trợ như: read image, http api,

xml, astl, bison parser, zip, dhcp, sqlite,

• frameworks: mã nguồn Android Framework Trong phạm vi đề tài này,

chúng ta sẽ tập chung chỉnh sửa lại một số hàm trong Android

Framework để thực hiện việc phân tích động

• hardware: mã nguồn liên quan đến phần cứng của thiết bị

• libcore: mã nguồn những công cụ và thư viện nền tảng như: dalvik

source code, json source code, junit source code,v.v

• ndk: ndk tool

• package: android system application

• prebuilt: chứa các công cụ hỗ trợ building

• sdk: chứa công cụ và thư viện hỗ trợ cho các nhà phát triển ứng dụng

• system: chứa các công cụ và thư viện hệ thống

2.1.6 Smali Byte Code

Các ứng dụng Android được viết dựa trên ngôn ngữ java Khi build một ứng dụng Android, trình biên dịch sẽ chuyển đổi mã nguồn java thành file thực thi dex chứa mã nhị phân dalvik bytecode Máy ảo Dalvik của hệ điều hành Android sẽ chạy những file dex này và chuyển chúng sang mã máy Do file dex là một file nhị phân nên rất khó khăn trong việc đọc hiểu và chỉnh sửa Để giải quyết vấn đề này, một số công cụ đã chuyển đổi dalvik bytecode sang một ngôn ngữ có thể đọc và chỉnh sửa dễ dàng hơn, đó chính là Smali Byte Code

• dex file -> baksmali -> smali byte code

• smali byte code -> smali -> dex file

Hình 2.6 cho ta thấy một ví dụ về sự tương ứng giữa java code và Smali Byte Code:

Hình 2.6: Ví dụ cho Java – Smali Byte Code

Smali Byte Code định nghĩa một số quy tắc như sau:

• Cấu trúc cơ bản cho một Smali class:

Hình 2.7: Cấu trúc của Smali class

• Các kiểu dữ liệu trong Smali Byte Code:

Hình 2.8: Các kiểu dữ liệu trong Smali Byte Code

• Cú pháp cho một Smali class:

L<tên đầy đủ của class, phân cách bởi dấu “/” >

Ví dụ: Lcom/example/myapp/MyClass;

• Cú pháp cho một Smali method:

.method <keywork> <method name> <parameters/return>

Ví dụ:

Hình 2.9: Ví dụ cho Smali method

2.2 Các kỹ thuật phân tích dữ liệu rò rỉ

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

Kỹ thuật phân tích tĩnh là kỹ thuật tập chung vào phân tích ứng dụng để phát hiện nguy cơ mà không cần thực thi chúng Hiện nay, có rất nhiều kỹ thuật phân tích tĩnh khác nhau, một số nghiên cứu nổi bật dựa trên kỹ thuật phân tích tĩnh

có thể kể đến như:

• SCanDroid [9]: là một công cụ sử dụng phương pháp phân tích tĩnh dựa trên việc theo dõi các data flow (luồng dữ liệu di chuyển qua các thành phần của ứng dụng) kết hợp với phân tích các quyền trong file

AndroidManifest của ứng dụng Trong đó, việc theo dõi luồng dữ liệu được thực hiện bằng cách phân tích mã bytecode của ứng dụng

• Stowaway [7]: là một công cụ phân tích tĩnh dựa trên việc phân tích các quyền trong file AndroidManifest và các truy xuất đến các APIs gắn với các quyền đó

• Apposcopy[21]: là một công cụ phân tích tĩnh dựa trên sự kết hợp của control flow và data flow Trong đó, control flow là luồng xử lý chương trình của ứng dụng, còn data flow là luồng dữ liệu đi qua các thành phần của ứng dụng Apposcopy sẽ phân tích control flow và data flow của các phần mềm độc hại đã biết để tạo ra những signature (đặc điểm nhận dạng) Sau đó, nó sẽ dùng những signature này để nhận biết các ứng dụng độc hại mới

Do kỹ thuật phân tích tĩnh chủ yếu dựa trên việc phân tích mã nguồn của ứng dụng nên nó giúp ta hiểu rõ về toàn bộ hành vi của ứng dụng Tuy nhiên sẽ gặp khó khăn nếu ứng dụng bị mã hóa (obfucasing) , dẫn đến kết quả phân tích không chính xác

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

Kỹ thuật phân tích động là kỹ thuật tập chung vào phân tích hành vi của ứng dụng khi thực thi để tìm kiếm hành vi bất thường Hiện nay, cũng đã có rất nhiều nghiên cứu dựa trên kỹ thuật phân tích động, một số nghiên cứu tiêu biểu như:

• Taint tracking: đây là kỹ thuật phân tích động dựa vào việc theo dõi luồng dữ liệu khi ứng dụng thực thi Việc theo dõi được thực hiện thông qua các nhãn gắn với từng luồng dữ liệu Và việc gắn nhãn được thực hiện bằng cách chỉnh lại JVM, Android core lib hoặc Linux Kernel Một công cụ tiêu biểu sử dụng kỹ thuật phân tích này chính là

TaintDroid[20]

• Battery Life Monitoring: đây là kỹ thuật phân tích động dựa vào việc theo dõi và phân tích tình trạng sử dụng bin của ứng dụng Bằng việc theo dõi, phân tích mức năng lượng tiêu thụ của các phần mềm độc hại

đã biết để tạo ra các signture (đặc điểm nhận dạng) Các signture này sẽ được dùng đề nhận biết các phần mềm độc hại mới

• API tracer: đây là kỹ thuật phân tích động dựa vào việc theo dõi việc thực thi các hàm APIs trong Android Framework

• System call (kernel-based behavior analysis) [8]: là kỹ thuật phân tích động dựa vào việc theo dõi các truy xuất đến linux kernel

Kỹ thuật phân tích động cho phép xác định chính xác hành vi bất thường của ứng dụng nhưng nó có nhược điểm là không thể phân tích hết tất cả hành vi của ứng dụng

2.2.3 Kỹ thuật phân tích kết hợp tĩnh và động

Như đã trình bày ở hai phần trên, kỹ thuật phân tích tĩnh và động đều có ưu nhược điểm riêng: Kỹ thuật phân tích tĩnh giúp ta hiểu chi tiết về hành vi của ứng dụng, nhưng nó sẽ không phân tích chính xác nếu ứng dụng bị mã hóa (obfucasing) Trong khi kỹ thuật phân tích động giúp cho việc xác định chính xác hành vi bất

thường nhưng không thể phân tích hết tất cả hành vi của ứng dụng Để khắc phục những nhược điểm này, nhiều hướng nghiên cứu đã thực hiện kết hợp hai kỹ thuật lại nhằm tạo ra những kỹ thuật phân tích mới hiệu quả hơn Trong sự kết hợp này,

kỹ thuật phân tích tĩnh thường dùng để giới hạn phạm vi phân tích cho kỹ thuật phân tích động

Một số nghiên cứu tiêu biểu cho kỹ thuật phân tích kết hợp tĩnh và động:

• Trishul [13]: đây là một công cụ sử dụng kết hợp hai kỹ thuật phân tích tĩnh và động Kỹ thuật phân tích tĩnh được thực hiện khi ứng dụng được

hệ thống tải lên để thực thi, bằng cách dùng taint tracking [xem 2.2.2] để đánh dấu các data flow [xem 2.2.1] Kỹ thuật phân tích động sẽ dựa các thông tin của kỹ thuật phân tích tĩnh để theo dõi các data flow khi ứng dụng thực thi

• SmartDroid [3]: là công cụ phân tích phát hiện dữ liệu rò rỉ bằng kết hợp hai kỹ thuật tĩnh và động Kỹ thuật phân tích tĩnh sẽ phân tích mã nguồn ứng dụng, tạo ra các luồng thực thi giữa các thành phần ứng dụng (được gọi là Expected Activity Switch Paths) Kỹ thuật phân tích động sẽ dựa vào những thông tin này để thực thi ứng dụng, đồng thời theo dõi và phát hiện luồng nào sẽ làm rò rỉ dữ liệu

Kỹ thuật phân tích kết hợp này khắc phục được nhược điểm của kỹ thuật phân tích tĩnh và động, giúp tăng khả năng phát hiện dữ liệu rò rỉ Tuy nhiên, việc nghiên cứu phương pháp kết hợp sao cho hiệu quả là một thách thức lớn Và ngay

cả khi đã nghiên cứu thành công, thì việc cài đặt nó cũng phức tạp hơn rất nhiều so với khi sử dụng từng kỹ thuật riêng rẽ

2.3 DidFail và SmartDroid

Phần này sẽ trình bài chi tiết về hai công cụ cụ thể áp dụng các kỹ thuật phân tích tĩnh và động Đây cũng chính là hai công cụ nền tảng của đề tài Các kỹ thuật phân tích của hai công cụ này sẽ được sử dụng, cải tiến, kết hợp lại với nhau

để tạo thành một công cụ mới, với khả năng phân tích hiệu quả và chính xác hơn

2.3.1 DidFail

DidFail – Droid Intent Data Flow Analysis for Information Leadage, là một công cụ mã nguồn mở do bộ phận nghiên cứu CERT thuộc viện công nghệ phần mềm SEI nghiên cứu phát triển vào năm 2014 DidFail được xây dựng dựa trên kỹ thuật phân tích tĩnh, với khả năng phân tích dữ liệu rò rỉ thông qua nhiều ứng dụng Đây chính là đặc điểm quan trọng khiến chúng tôi quyết định chọn DidFail làm công cụ nền tảng để phát triển đề tài

DidFail là sự kết hợp của FlowDroid [16], Epic [4]:

• FlowDroid: theo dõi những luồng dữ liệu bên trong mỗi thành phần của ứng dụng

• Epic: theo dõi những thuộc tính của các intent, từ đó xác định được hành động của chúng

Sự kết hợp giữa FlowDroid và Epic sẽ giúp DidFail theo dõi được các luồng

dữ liệu bên trong một thành phần của ứng dụng hoặc giữa các thành phần của một hay nhiều ứng dụng

Luồng dữ liệu ở đây được hiểu là đường đi của dữ liệu từ source đến sink:

• Source: là nơi chương trình sẽ đọc thông tin Ví dụ: device ID, contacts, photos, current location,…

• Sink: là nơi chương trình sẽ gửi thông tin đến Ví dụ: internet, sms, file system,

Sự rò rỉ dữ liệu xảy ra nêu dữ liệu thực sự đi từ source đến sink

Hình 2.10: Mô hình tổng quát của DidFail

Mô hình tổng quát cho quá trình phân tích dữ liệu rò rỉ của DidFail được mô

tả trong hình 2.10 Trong đó, DidFail chia quá trình phân tích làm hai giai đoạn:

• Giai đoạn 1: phân tích lần lượt các ứng dụng để xác định luồng dữ liệu trong từng thành phần hoặc giữa các thành phần của một ứng dụng

• Giai đoạn 2: Từ mỗi intent được gửi bởi một thành phần, DidFail sẽ xác định thành phần nào có thể nhận và xử lý intent đó, từ đó xác định được đường đi của intent giữa các thành phần trong một hoặc nhiều ứng dụng Phân tích, tổng hợp các kết quả sẽ xác định được những luồng dữ liệu có khả năng rò rỉ thông qua một hoặc nhiều ứng dụng

Đặc điểm nổi bật nhất của DidFail chính là khả năng phân tích xác định dữ liệu rò rỉ thông qua nhiều ứng dụng Tuy nhiên, nó cũng tồn tại nhiều hạn chế:

• Hiện tại chỉ hỗ trợ phân tích dựa trên các intent và services Chưa hỗ trợ cho hai thành phần khác của ứng dụng android là: content providers, Broadcast receivers

• Không kiểm tra quyền khi kết nối các thành phần dẫn đến kết quả phân tích có thể không chính xác

Trong đó, một nhược điểm quan trọng của DidFail chính là: do dựa trên kỹ thuật phân tích tĩnh, nên nó không thể xác định được một cách chắc chắn các luồng

dữ liệu từ source → sink có thực sự rò rỉ khi ứng dụng thực thi hay không, dẫn đến kết quả phân tích không chính xác Và trong phạm vi đề tài này, nhược điểm này sẽ được khắc phục, tất cả kết quả của DidFail sẽ được kiểm chứng thông qua quá trình phân tích động, để xác định chính xác luồng dữ liệu nào sẽ rò rỉ

Hình 2.11: Mô hình tổng quát của SmartDroid

Mô hình tổng quát cho quá trình phân tích dữ liệu rò rỉ của SmartDroid được mô tả trong hình 2.11 Theo đó, SmartDroid chia làm 2 phần chính:

• Static Path Selector: đây là thành phần thực hiện quá trình phân tích tĩnh Trong đó:

o Disassemble: sử dụng công cụ ApkTool [xem 4.1.4] để dịch ngược tập tin ứng dụng ra mã Smali Byte Code

o FCG (Function call Graph): là một đồ thị dạng cây, biểu diễn mối liên

hệ giữa các hàm trong ứng dụng Trong đó, mỗi nút trong cây đại diện cho một hàm, với nút gốc là các hàm xử lý sự kiện của ứng dụng

và nút lá là các hàm nhạy cảm (những hàm có khả năng gây ra rò rỉ

dữ liệu)

o ACG (Activity call Graph): là một đồ thị dạng cây, biểu diễn mối liên

hệ giữa các activity trong ứng dụng Trong đó, mỗi nút trong cây đại diện cho một activity, với nút gốc là activity chính của ứng dụng, nút

lá là activity chứa sự kiện sẽ gọi đến hàm nhạy cảm

o Expected Activity Switch Paths: Kết hợp FCG và ACG ta sẽ được một đồ thị cây hoàn chỉnh thể hiện đường đi từ activity chính đến

hàm nhạy cảm, với nút gốc là activity chính, nút lá là hàm nhạy cảm Expected Activity Switch Paths là tập hợp tất cả các đường đi từ nút gốc đến nút lá

Hình 2.12: Ví dụ cho ACG và FCG

• Dynamic UI Trigger: là thành phần thực hiện quá trình phân tích động

Để thực hiện Dynamic UI Trigger, các tác giả đã chỉnh sửa lại Android Framework Dynamic UI trigger bao gồm 3 phần chính:

o Runtime Execution: bằng cách gắn các tracker vào các hàm nhạy cảm của Android Framework, giúp theo dõi và xác định hàm nhạy cảm đã đươc gọi từ Expected Activity Switch Paths nào

o Activity Restrictor: dùng để điều khiển các activity của ứng dụng, chuyển hướng chúng theo đúng Expected Activity Switch Paths

o UI Interaction Simulator: dùng để điều khiển và kích hoạt tự động các thành phần giao diện của ứng dụng thực thi theo đúng Expected Activity Switch Paths

SmartDroid đã phân tích khá hiệu quả khi kết hợp kỹ thuật phân tích tĩnh và động Trong đó kỹ thuật phân tích tĩnh đã giúp giới hạn phạm vi phân tích cho kỹ thuật phân tích động, thay gì phải phân tích tất cả các hành vi tương tác lên giao diện ứng dụng thì chỉ cần phân tích những chuỗi hành vi được chỉ ra bởi Static path selector Điều nay giúp tiết kiệm chi phí và tăng tính chính xác cho kỹ thuật phân tích động

Tuy nhiên, SmartDroid cũng tồn tại nhiều hạn chế:

o Quá trình phân tích tĩnh gặp nhiều thách thức khi phải phân tích toàn

bộ mã nguồn để xây dựng ACG-FCG Do độ phức tạp khi phân tích khá lớn, có thể cho ra những kết quả thiếu chính xác

o SmartDroid chỉ có thể phân tích từng ứng dụng độc lập nên nó không thể phát hiện những dữ liệu rò rỉ thông qua nhiều ứng dụng

Những nhược điểm nêu trên sẽ được khắc phục trong phạm vi đề tài này Bằng cách áp dụng những kỹ thuật phân tích của DidFail, ta hoàn toàn có thể giúp SmartDroid mở rộng khả năng phân tích trên nhiều ứng dụng Ngoài ra, chúng ta có thể kế thừa những kết quả phân tích tĩnh từ DidFail để giảm độ phức tạp khi xây dựng ACG-FCG

CHƯƠNG 3 : MÔ HÌNH KẾT HỢP KỸ THUẬT PHÂN TÍCH TĨNH

VÀ ĐỘNG NHẰM PHÁT HIỆN DỮ LIỆU RÒ RỈ THÔNG QUA

NHIỀU ỨNG DỤNG

3.1 Giới thiệu mô hình

Sau khi nghiên cứu các kỹ thuật phân tích được sử dụng trong hai công cụ SmartDroid và DidFail Cụ thể là nghiên cứu các kỹ thuật phân tích tĩnh và động, đặc biệt là phương pháp kết hợp chúng lại với nhau để tăng khả năng phát hiện dữ liệu rò rỉ Đề tài đề xuất một phương pháp kết hợp mới, đó là sử dụng kết quả phân tích của DidFail vào quá trình phân tích tĩnh của SmartDroid để tạo ra một Expected Activity Switch Paths [xem 2.3.2] giữa nhiều ứng dụng Điều này giúp mở rộng khả năng phân tích của SmartDroid, giảm độ phức tạp khi xây dựng ACG-FCG [xem 2.3.2], cũng như tăng tính chính xác của DidFail

Đề tài đề xuất một mô hình phân tích mới như hình 3.1:

Hình 3.1: Mô hình kết hợp DidFail và SmartDroid