Luận văn thạc sĩ Khoa học máy tính: Kiểm tra ứng dụng trên điện thoại di động Android bằng kiểm tra mô hình

Vẻ hình thức, các công trình hiện tại hoặc ở dạng middleware cho Android platformnhư Sorbet, TaintDroid, XmainDroid.., hoặc là một chương trình riêng để kiểm tracác chương trình được cài

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

TRƯỜNG ĐẠI HỌC BÁCH KHOA

NGUYÊN THANH HỎNG

KIEM TRA UNG DUNG TREN ĐIỆN THOẠI DI ĐỘNG

ANDROID BANG KIEM TRA MO HÌNH

Chuyên ngành: KHOA HỌC MAY TINH

Mã số: 60.48.01

LUẬN VÁN THẠC SĨ

TP HỎ CHÍ MINH, tháng 06 năm 2013

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠITRƯỜNG ĐẠI HỌC BÁCH KHOAĐẠI HỌC QUỐC GIA TP HỎ CHÍ MINH

Cán bộ hướng dẫn khoa học: PGS.TS QUAN THÀNH THƠ

Cán bộ cham nhận xét 1: TS NGUYÊN CHÁNH THÀNH

Cán bộ chấm nhận xét 2: TS BÙI HOÀI THẮNG -2-scss¿Luận văn thạc sĩ được bảo vệ tại trường Đại Học Bách Khoa, DHQGTp HCM ngày 24 tháng 07 năm 2013

Thanh phan Hội đồng đánh giá luận văn thạc sĩ gồm:1 TS HUỲNH TƯỜNG NGUYEN .

2 TS NGUYEN ĐỨC THÁI

3 TS NGUYEN CHANH THÀNH

4 TS BÙI HOÀI THẲNG

5 TS NGUYEN THI MINH TUYEN

Xác nhận cua Chu tịch Hội đồng đánh giá Luận Văn và Trưởng Khoa quản lýchuyên ngành sau khi luận văn đã được sửa chữa (nêu có).CHỦ TỊCH HỘI ĐÔNG TRƯỞNG KHOA

ĐẠI HỌC QUỐC GIA TP.HCM CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

TRƯỜNG ĐẠI HỌC BÁCH KHOA Độc lập - Tự do - Hạnh phúc

NHIỆM VỤ LUẬN VAN THẠC SĨ

Họ tên học viên: NGUYEN THANH HÔNG MSHV:09070438

Ngày tháng, năm sinh: 20/11/1982 - 5555 5++++<<<<<s Nơi sinh: TP HCM

Chuyên ngành: KHOA HOC MAY TÍNH 55c: Mã số : 60.48.01 I TÊN DE TÀI: G11 S111 T9 1E TT 1T HE HH

KIEM TRA UNG DUNG TREN ĐIỆN THOẠI ANDROID BANG KIEM TRA MÔ HINH

II NHIỆM VỤ VÀ NỘI DUNG ou cccceccsscssecsseecsseccseecssecssecessecsseessscesteceseeesteseseeesteesseee1) Hiện thực module kiểm tra một vài tính chat của chương trình Android băng phương pháp

kiểm tra mô hình trên công cụ PAT2) So sánh hiệu quả của hai kĩ thuật on-the-fly và không on-the-fly khi thực hiện kiểm tra mô hình

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 21/06/2013 sex sv xxx:V CAN BO HUONG DAN : PGS.TS QUAN THÀNH THƠ - - + + se:

LOI CAM ONTôi xin gửi lời cam ơn chân thành đến PGS TS Quan Thanh Thơ, người thay đã hướngdẫn cho tôi hoàn thành luận văn này và cũng là người giảng dạy cho tôi trong quá trình học

Cao Học

Tôi xin gửi lời cảm ơn đến TS Bùi Hoài Thăng, các bạn Hà Xuan Lĩnh, Lê Dinh Thuan,

Nguyễn Hữu Vũ, Châu Vĩnh Tuân, những người đã hỗ trợ rất tích cực cho tôi trong quá

trình làm luận văn

Tôi xin gửi lời cảm ơn đến các đồng nghiệp ở công ty Tường Minh và gia đình tôi,

những người đã ủng hộ và tạo điêu kiện đề tôi có thê hoàn thành được luận văn này

il

TOM TAT LUẬN VĂN

Các ứng dụng trên Android có nhiều lỗi bảo mật Những rắc rối cho người dùng như thông tin cánhân của họ bị chuyển cho các nhà quảng cáo, cuộc gọi bị nghe lén, điện thoại tự động gửi nhiềutin nhăn dẫn đến thiệt hại về tài chính cho người dùng là những van dé khá phổ biến.

Một trong những nguyên nhân cơ bản của những lỗi bảo mật đó được cho là người phát triển ứngdụng đã không áp dụng cơ chế bảo mật dựa trên phân quyên của hệ điều hành Android một cách

Android applications have been found to contain many kinds of security holes, which may beserious to leave smartphone users at risks of various attacks, such as privacy loss (user’sinformation is passed to adversories), eavesdropping, financial loss (SMS messages are sent outuncontrolledly which financially impacts to users)

Among various root causes of these attacks, that Android security mechanism is not correctlyenforced and results in some kinds of leaks in the application, 1s supposed to be one of the basic

LỜI CAM ĐOAN

Tôi cam đoan răng, ngoại trừ các kêt quả tham khảo từ các công trình khác như đã ghi rõtrong luận văn, các công việc trình bày trong luận văn là do chính tôi thực hiện và chưa cóphân nội dung nào của luận văn này được nộp đê lây một băng câp ở trường này hoặctrường khác

Ngày 2I tháng 06 năm 2015

Nguyễn Thanh Hồng

MỤC LỤC

NHIỆM VỤ LUẬN VĂN THẠC SĨ - 52: 2:22:22 21 2122122122121111112121121121121111 Ea i909.) ,09)0ẢÝÊÝÊÝỶ iiTOM TAT LUẬN VAN ooceccsosessessssssssssssssssesstssessessasatstsnsussasssissssssssessssssstsssssnsaseeessssaseseeeaeeeees iii

[nh §N›v.\0lHadddddddddtẦtẢẦ{ẦẢẨẮẢẮẨẦẮÚ IV

LOI CAM DOAN DùẰùẰùDŨỤẶẰẶẰẦŨAŨẰỤẶẦẶẦẮ V

\ 18 9S aỔẳỎiẳiỎẳŸÕỐẦẲẦẢẦ Vi

IM.9)J58./101985)))1:EdaaŸÃẼẢỶẢẢỶẢỶẢA ixIM.9))28./10198:7.))/9Haầắắđắáaâaầđaaầẳ XChương 1: Phát biểu vấn đề - 2+ St tt E3 E1 1112151111711111111117 1511151111011 TETET1EEEEEEEErrrrei l1.1 Những van đề về bảo mật của điện thoại Android - + sa se St xSEE2E3312E53 E155 E2EsEEssee l

1.2 Các phương pháp giải hiện fại - - G2 2211111222311 11121511111 18511 1111150111111 khe 21.3 Mục tiêu của luận văn - L1 S1 ST TT TT vn sa 2I S9 8⁄0) vì 000, oo e 3

1e 1i: 07 8 Š II a c-claằằ 3Chương 2: Những cơ sở lý thuyết nền tang c1 E1 S3211111E1E71E1112111111 71111111 EEErrrkd 42.1 Tổng quan về Android cccccccecescsscsesesesesesececevsvevsusecececevsvevssecavecevevsveususacevevevevevsnseseceeers 42.1.1 Câu trúc hệ điều hành Android + - + sa sa 2x18 1381555315151 18 1515555555151 11 1111155551 Ex 4

2.1.2 Android Security Framework %aa 52.2 LTL - Propositional Linear time Temporal LLOBIC - c5 53222222213 **+++#e+seeeseesa 8

2.2.1 N00 (110/0 00ì))4-2ẲđẠẠOỤŨ 8

2.2.2 Cú pháp biéu thức LTL c.cecccccccececcsesecscsesesesecececsvsvsveusesececevsvsesesecevevevevsnesevecevevsveee 92.2.3 Ngữ nghĩa biểu thức L/TÌU - se E323 SEEEEEEEEEEEESESEEEEEEEEEEEESEEEEEEEEEEEETtktrerrree 92.3 Tổng quan về On-the-fly LTL Model Checking ¿ 2 + ‡ESEEEE2E£E+EEEeEvEErkreersres 10

2.3.1 Nguyên lí của Model Checking - - - 2 2 2211112222211 1111915111111 5 1111k crg 102.3.2 On-the-fly LTL Model CheckIng - - - - 2 2 2211122232581 11 1133531111151 xerea II

2.4 Kiểm tra mô hình với công cụ PATT sc St SE21 S113 EEEEEEEE2E1111EEEEEEETEEETESEEEEEEEErrrrsre 12Chương 3: Tổng thuật các công trình liên quan - 5: 1s S‡EEESE2E+E£EEEEEEEEEESEEEEEEEeErEkrkrkersre 14

3.1 Các hướng nghiên cứu hiện nay - - 22 122222 22111113 32321111 13553 111115581111 ng ren 14San v09 143.1.2 (0o (2n 4 15

3.1.3 Android Model — Type and Effect SŠysfem 2221213222211 2 krrerea 160) ce 17B15 StOWAWAY oo = = ẦẢ 18

S9 in a6 ¬-‹ :‹7 V1 ẼšẼ š sa 20

3.1.9 Scandal - c c1 221111112111 111511 11121111118 111g K1 ng kg KH vn 233.1.10 ComDTOI c2 1 2111222111112 1119211111201 1 011111101111 KH kg vn 233.1.11 (00-17 4 243.1.12 Cac hung Kha oo e 25

3.2 Thao luận về các hướng nghiên CỨU - 5: + St 3E EEEEEEEEEEEEESEEEEEEEEEEEETEEESEEEEEEEErkrkersre 253.2.1 Tóm tắt các hướng hiỆn tad - - c2 2 2221111122231 111 1188 1111115511111 1122 xec 253.2.2 Giới thiệu cách tiếp cận On-the-fly LTL Model Checking 5x5: 27Chương 4: Phương pháp giải quyết van dé và hệ thống ứng dung ¿cv vzczezxseez 28

SNpb aac::aiai 284.2 Giải quyết vân đề - - c scn cv T3 1111111111 112T11111111111 1111111101 EE 1T o 294.2.1 Framework tong Quat c.ccccccccccscsccecesesececsescsesececscevevsvssecececevevsusesececevevsvivsvesecevecsen 294.2.2 Đặc tả thành phan Android Model Checker c.ccccccccccccsesesesecsvsesesesesececevevsvevseeeees 304.2.3 Câu trúc input file của toàn mo.dulÌe + scs SE S323 SE £EEEEEEEEEESEEEEEEEEEEEErkrkereree 314.2.4 Đặc tả phan chương trình trừu tuong cee cecceccscsscsescsesecesececevsesesesececevsvsvevsneeseveesen 324.2.5 Đặc tả phan assertions c.ccccccccccesesesesscsvscsesesecscevevsvssecscevsvevsusesececevevsvsvsvssecevecse 444.2.6 Cách thức xử lí kiểm tra mô hình ¿5-1 SE E1 S321 5EEEEEEEEE 11211111 EEEEEEEErkrreree 45

Churong 5: Thurc nghiém 00072757577 = 46

5.1 Thực nghiệm 1: kiêm tra lỗi bảo mật của ứng dung Android ¿2 s+s+x+zvzerszsred 465.1.1 Phát hiện lỗi rò rỉ tường minh (explicit leak) ¿2 2 sx+E+E+EE£EvEEEeksxsxserreree 46

5.1.2 Phát hiện implicit leak - - - 2 2 2221121222 2311111335821 111115581111 155811 11111152 xe 53

5.2 Thực nghiệm 2: kiêm tra độ hiệu quả của phương pháp on-the-fÏy 5c cszscs2 61

5.2.1 Nội dung và cach thức thực nghiệm - - 7G E2 2221112223221 Series 61

5.2.2 Kết qua thực nghiệm oo ceccccccccccsesccesecesecscsvsvsesecececsvsvsvsvssecececsvsnsvssecevevsvavsvensecesees 625.2.3 Phân tích kết quả thực nghiệm 2-2221 S33 EEEEEEEE2E111EEEEEEEEEEEETESEEEEErrrrrrree 63

Vil

Chương 6: Kết Wat ooo cccccccccccccccscsecesececsvsvevsusecececevscevsusecucscevevsvevsusasavevevevsvsnsesivevevevsvensesnsasevecees 65m1 ằEỒOỒ 656.2 Hướng phát tridt ce cccccccccccscscsesecescecsvsvsvsesececevevsvevsusecevecevsvsveusecacecevavsvssevacecevevsvesnseses 66

Tài liệu tham khảo - - L1 1220202111101 1015035111111 1 1 10 15111111 k vu nu TT vu TT nà 67

PHU LUC A: BANG DOI CHIEU THUAT NGU ANH - VIỆT 2 sec E21 SE S2E2E2EEcszsssee |PHU LUC B: LY LICH TRICH NGANG 5 aAaa -nqq 2

Vill

Hình 5 Một hệ thống chuyên trạng thai c.c.ccccccccsececccesesscscsesesececevscevsessececevevevsvssecevevevevevstseseeeeens 8

Hình 6 Nguyên lí của Model checking - c1 1112221111112 11112811 112 1111188 1111 811k ng xa 10Hình 7 Nguyên lí của On-the-fly Model Checking 2 2 231122231312 EE+Seerserexes HI

lšI¡0:8.8.612i005:.0::0.0IEPNùaaầađ 13

Hình 9 Cách thức xử lý của ScanÏÖrO1d 2 1 3 221111122221 111 11155811111 5511 11111118 1 vn 14Hình 10 Cách thức xử lý của WoodPecker - - c2 2211112 22211111119 8011 111151 111g ng 15Hình 11 Cách thức xử lý của Type and Effect System o.oo cccccccsceccssseccesseeeeessseeeessseeessaes 16

Hình 12 Kiến trúc XmainDroid oo ceeccccscsceesesesecsesesececscsecevevsvsecevsvsesecsvsssevevsessevsvsesevevsesseveee 20

Hình 13 Quá trình phat hiện Malware của Crowd roid 0.0.0 ccccccccccsecceeeseeeccssseccsseeeseesseeccssseeeesaes 21

Hình 14 Kiến trúc của TaintIDDrOid 5c 5+ x1 SE EE219EEE11151EE11111E1E111111111111111111101 11111101 11 tyeg 22

Hình 15 Quá trình phân tích Android Leaks - c1 22112222101 1112251 1111531111 821 111581111121 xk5 24

Hình 16 Framework kiểm tra chương trình AnidrOid - - scc E23 SE‡EEEEEEEEEEEEEESEEEeErrerrkersre 29

Hình 17 Bên trong Adroid Model Checker - - E112 20112112111 112551 111153111118 111158111118 xkg 30

Hình 18 Cấu trúc input file oo cccccececescscsescsesececscecsvsvevsecececevevsesesecevavsvevsnsesesavevecsvavsesnsesevecees 31

Hình 19 Định dang của chương trình ftrừu tƯợng .- - 2-1112 2 2222111111355 1113582111 ng gky 32

Hình 20 Quá trình kiểm tra mô hình của Android Module -¿ ¿- + ‡EvEEEEEE+Eexerererrerrsees 45Hình 21 Case Study 1: Lay thông tin Contact băng public API - + cSz c2 SE+EcEeEvErsrerrsees 46Hình 22 Tóm tat quá trình kiểm tra lỗi rò rỉ tường minh - cece - s9 E‡E£E2E‡EEEEE2E2EEEErkexee 49Hình 23 Kết quả kiểm tra lỗi rò ri tường mình 2-5: + Sk*xEEEEEE+EEEEEEEE 1E 1117111111111 gxeC 52Hình 24 Case study 2: Lay thông tin contact bằng SharedUserld - 5-5 s+scx‡E2E2E£Ezxzxet 53Hình 25 Quá trình kiểm tra lỗi rò rỉ ấn tàng (Ï) - 2+ + 2x3 SEEEEEE2E1111EEEEEEE E211 SE EEEEETErrsre 55Hình 26 Kết quả kiểm tra lỗi rò rỉ ân tảng ((1) - 2+ c cv 3E EEEEEE211111EEEEEEEEEEEESEEEEEErrrerere 57Hình 27 Quá trình kiểm tra lỗi rò rỉ ấn tàng (2) - 2+5: 2t St c3 SEEEEE1211111E1E7E1111111 11x EEEEETEEtEtre 57Hình 28 Kết quả kiểm tra lỗi rò rỉ ân tang (2) 5+2 zSt v3 EEEEEEE211111E1E7EEE12E11 111 EEETErrrre 60

Hình 29 So sánh mức độ sử dụng bộ nhớ - - - 22 1111222211111 1 132511111 55531 11111582111 ng 63Hình 30 So sánh thời g1an Chay - - c1 22 2222311111222301 11111158111 T191 111g vn kg 64

1X

DANH MỤC BANG

Bang 1 Smartphone Operating System Market Share 2011 và 2015

Bang 2 Kết qua thử nghiệm - - St E2 SE EEeErrrrrersre

Chương 1: Phát biểu van đề

1.1 Những vẫn đề về bảo mật của điện thoại AndroidSmartphone ngày càng trở thành phương tiện gan gũi và quan trọng đối với người dùng

vì tính tiện lợi của nó Smartphone không chỉ có chức năng của điện thoại thông thường,mà người dùng còn có thê thực hiện hau hêt các công việc cá nhân như kiêm tra email,tham gia mạng xã hội, giao dịch với ngân hàng (banking)

- _ Hệ điều hành Android hiện đang là hệ điều hành chiếm thị phan cao nhật [7] trong số

các hệ điêu hành trên thiệt bị di động (Android, 1OS, BlackBerry, Windows Phone ).He điều hành 2011 2015 2015/2011

Market Share Market Share Evolution

Android 39.5% 45.4% 23.8%

BlackBerry OS 14.9% 13.7% 17.1%iOS 15.7% 15.3% 18.8%Symbian 20.9% 0.2% -65.0%Windows mobile 7 5.5% 20.9% 67.9%

Cac loai khac 3.5% 4.6% 28.0%

Tổng cộng 100% 100% 19.6%

Bang 1 Smartphone Operating System Market Share 2011 và 2015

- Tuy nhiên, người sử dung Android cũng đứng trước nhiều nguy cơ bị tan công, như

mât thông tin cá nhân, quá trình sử dụng điện thoại gặp trở ngại, thậm chí là thiệt hại vêtài chính Một sô kiêu tân công phô biên như:

vvv

Nghe lén (Eavesdropping): hacker tìm cách xâm nhập vào cuộc gọi của người

dùng để ghi âm lại cuộc nói chuyện.Availability Attacks: hacker làm tắt nghẽn các dịch vụ của điện thoại khiến chocác tín hiệu truyền nhận đến các dịch vụ đó bị nghẽn lại.

Đánh cắp thông tin cá nhân (Privacy Attacks): hacker đánh cắp các thông tin cánhân như địa chỉ liên lạc, email, vi trí hiện tại và truyền đến các third-party

server cho mục đích quảng cáo hoặc nơi chuyên tạo ra malware

Impersonation attacks : các ứng dung malware thực hiện các hành động dẫn đếnlàm thiệt hại về tài chính cho người dùng như tự động gửi tin nhăn nhiều lần.Tần công từ chối dịch vụ (Denial of Service Attacks): ứng dụng gây hai làm chongười dùng không thể sử dụng các chức năng của điện thoại.

Botnet: điện thoại nhiễm virus bị điều khiển từ bên ngoài thông qua các kênh giaotiếp của điện thoại như Bluetooth, Infrared

Proof-of-concept : mục tiêu của loại tân công này làm cho người dùng hoảng sợ vàtin rằng điện thoại bị tan công.

Unsolicitated information flow: hacker gửi liên tục ngày càng nhiều tin nhăn đếnđiện thoại, có thể dẫn đến từ chối dịch vụ.

1.2 Các phương pháp giải hiện tạiHiện tại đã có rat nhiều công trình nghiên cứu về van dé này với rất nhiều hướng tiếp

cận (xem chi tiệt trong phan 3 Tông thuật các công trình liên quan)

Vẻ hình thức, các công trình hiện tại hoặc ở dạng middleware cho Android platform(như Sorbet, TaintDroid, XmainDroid ), hoặc là một chương trình riêng để kiểm tracác chương trình được cài đặt trên điện thoại Android để thông báo thông tin cho ngườidùng (Scandal, Android leaks, ), hoặc là chương trình hỗ trợ người phát triển ứng dụngkiểm tra ứng dụng của họ có đạt tiêu chuẩn nào đó về bảo mật không (ScanDroid,

WoodPecker, Stowaway, )

Mục tiêu của các công trình là hỗ trợ người dùng phát hiện những bất thường của cácứng dụng trong quá trình sử dụng điện thoại (kiểm tra động), kiểm tra ứng dụng có phảilà malware, kiểm tra khả năng xảy ra rò rỉ thông tin cá nhân của người dùng khi cácứng dụng được chạy thực tế (kiểm tra tinh)

Mỗi phương pháp hiện tại đều có những ưu điểm và hạn chế (xem chỉ tiết trong phan3.2 Thảo luận về các hướng nghiên cứu) Đối với phương pháp kiểm tra tĩnh, mộttrong những điểm hạn chế là tính khả thi không cao của các công trình đó khi chươngtrình ứng dụng có kích thước lớn với nhiều đường thực thi (execution path), vì cácphương pháp này phải tìm ra tất cả các đường thực thi của ứng dụng trước khi bắt đầu

kiêm tra

1.3 Mục tiêu của luận văn

Luận văn này cũng hướng đên cùng mục tiêu với các công trình hiện tại: thực hiệnkiêm tra ứng dụng trên điện thoại, nhăm tìm ra các 161 bảo mật có thê có

Luận văn muốn giới thiệu một phương pháp khác để giải quyết van dé, cũng năm trong

nhóm kiêm tra tĩnh, chưa được đê cập trong các công trình hiện tại và cũng không kémphân hiệu quả, đó là “kiêm tra mô hình”

Phương pháp kiểm tra mô hình ngày nay thường được áp dụng với kĩ thuật kiểm tra the-fly Đó là cách kiểm tra mà không can phải tìm ra tat cả các đường thực thi ngay từdau, thay vào đó các trạng thái (hoặc đường thực thi) của ứng dụng được tạo ra vàkiểm tra một cách dan dan, những trạng thái đã xử lí qua rồi có thể giải phóng khỏi bộnhớ Với kĩ thuật này, chúng tôi hi vọng có thé đáp ứng được cho các ứng dụngAndroid có kích thước lớn, và khắc phục được một trong những hạn chế nói trên của

on-các phương pháp hiện tại

1.4 Đóng góp của luận văn- Chung tôi đã áp dụng và thử nghiệm độ hiệu quả của kiểm tra mô hình với kĩ thuật on-

the-fly cho ứng dụng end-user trên Android, điều mà hiện tại vẫn chưa được áp dụngnhiều.

- Qua luận văn nay chúng tôi đã đóng góp thêm module kiểm tra ứng dụng Android vàocông cu PAT Hiện tại chỉ hoàn thành một phan của module, nhưng trong tương lai nếutiếp tục phát triển các phan còn lại, PAT sẽ có một module day đủ dành cho Android.1.5 Câu trúc luận văn

Phan còn lại của luận văn bao gồm các phan như sau : phan 2 trình bày về cơ sở lí thuyết,phân 3 trình bày về các công trình liên quan và những ý kiến thảo luận của chúng tôi, phần4 trình bay framework của chúng tôi va phan 5 trình bay kết quả thực nghiệm.

Chương 2: Những cơ sở lý thuyết nên tảng

2.1 Tổng quan về Android2.1.1 Cấu trúc hệ điều hành Android

Manager Framework Libraries

LINUX KERNEL.

Display Camera Bluetooth Flash Memory Binder (IPC)Play )Driver Driver Driver Driver Driver

USB Keypad WiFi Audio Power

Driver Driver Driver Drivers Management

Hình 1 Cau Trúc Hệ Điều Hanh Android- Linux kernel: Hệ điều hành Android bao gồm nhiều lớp, trong cùng là Linux kernel

2.6 Phan nhân Linux chịu trách nhiệm tương tác với phan cứng va chứa tat cả cáchardware driver Tat cả các core functionality của Android như quản lí vùng nhớ, quanlí process, networking, security setting, đều xây dựng dựa trên các chức năng tương

ứng trong Linux kernel- Libraries: Bao bọc bên ngoài Linux kernel là lớp thư viện Day là lớp cho phép các

thiệt bi quản lý các lọai dữ liệu đặc trưng riêng Cac thư viện gôm có : surface manager,media framework, SQLite, WebKit, OpenGL

Android Runtime: Bên trên Linux kernel là lớp Android Runtime, chứa DalvikVirtual machine và các core java libraries Dalvik virtual machine là một dang của

JVM dùng dé chạy ứng dung Android (.dex file) và được tối uu dé ít tốn năng lượng xửlí và bộ nhớ nhất Phan core java libraries bao gồm hau hết các chức năng định nghĩa

trong Java SE libraries, tuy nhiên nó không phải là Java SE hay Java ME.Application Framework: chứa các dịch vụ quản lý các chức năng cơ bản của điệnthoai như quan lý tài nguyên, quan lý cuộc gọi, quan lý định vi, quản lý life cycle củaứng dụng, quan lý việc chia xẻ dữ liệu giữa các ứng dụng đề lớp ứng dụng trên cùngsử dụng

Applition layer: Day là lớp ngoài cùng trong cầu trúc của hệ điều hành Android Nó

bao gồm tat cả các ứng dụng cho người dùng Một số ứng dụng được cai đặt sẵn chongười dùng như: SMS client, dialer, web-browser, contact manager

2.1.2 Android Security Framework

2.1.2.1 Application SanboxMỗi ứng có một UID (user ID) duy nhất và được chạy trong một quá trình (process)

tách biệt Cac ứng dụng không được phép truy xuât dit liệu của nhau và bi hạn chê truyxuât đên hệ thông

Thi dụ: như một ứng dụng A không thể đọc đữ liệu của ung dung B hoặc không được

gọi đên một sô điện thoai nào đó nêu không được hệ điêu hành cap quyên

2.1.2.2 Permission

Do tính chất sandbox, các ứng dụng gần như tách biệt lẫn nhau Mỗi ứng dụng khai báo

các lọai quyền cần có khi chạy và người dùng sẽ xác nhận việc cấp các quyền này khicài đặt ứng dụng

Android định nghĩa các quyên truy cập tới các tài nguyên chung trong hệ thống Thí dụ:

android.permission.CALL _EMERGENCY_NUMBERSandroid.permission.READ_OWNER_DATA

android.permission.SET WALLPAPERandroid.permission DEVICE POWER

Ung dung cũng có thé đặc tả các quyền mà ứng dung khác phải có để truy cập tài

nguyên của nó.Android cũng ho trợ ứng dụng câp/ thu hôi/ kiêm tra động các quyên trên các tàinguyên

2.1.2.3 Sơ lược về một ung dụng trên Android

- _ Một ứng dụng trên Android bao gồm các thành phan (component) và một manifest filechứa các thông tin quan trong Android can có dé có thé chạy ứng dụng.

- - Các thành phan giao tiếp với nhau và giao tiếp với hệ thống thông qua thông điệp

(intent-based)

Manifest file

<?xml version="1.0" encoding="utf-8"?><manifest>

<uses-permission /><permission /><permission-tree /><permission-group /><instrumentation /><uses-sdk /><uses-configuration /><uses-feature /><supports-screens /><compatible-screens /><supports-gl-texture /><application>

<activity>

<intent-filter><action /><category /><data /></intent-filter>

IntentCác thành phân (component) trong ứng dung và giữa các ứng dụng tương tác với nhau

theo cơ chế trao đối thông tin (messaging) hoặc gọi là intent.Intent là một thông điệp thể hiện yêu cầu muốn làm một việc gì đó Thí dụ, nếu ứng

dụng muốn hiển thị một trang web, nó sẽ thé hiện ý muốn bằng cach tạo ra một intentgửi đến hệ thống Hệ thống sẽ tìm đọan code tương ứng (trường hợp này là browser) và

Có 4 loại component, mỗi component có một định danh riêng.

> Activity : tương ứng với một màn hình trong ứng dụng> Service: các dịch vụ chạy ngầm bên dưới ứng dụng, cung cấp interface cho các ứng

dụng khác giao tiếp.

> Content Provider : lưu dữ liệu của ứng dụng (trong database), cho phép chia sẻ dữ

liệu giữa nhiều ứng dụng

> Broatcast Receiver: nhận các thông điệp từ các ứng dụng khác

callbackCommunicating with a Service

Read/Write! ! 1

|

Query ——————— ! ! !

— Ị = ‘Send TM| Broadcast 1!Content | ; LÍ Activit

¡( Activity Y intent Receiver

: Provider | }

;

' ' Ị 'i l l i' ' Ị ÙReceiving an Intent Broadcast

Hình 3: Liên hệ giữa các component

2.1.2.4 Thí dụ về một ng dung Android

Bên dưới là hình ảnh về cau trúc ứng dụng Music Player

Activities ! Services ! Receivers ! Providers

Í View Song Ì Í Pause Song | !List Screen on

( Play a Song Ì _—¬ ( Database of Ì

` J! in 1 ⁄ Songs

' | background ! !

'đ ; N 1 I 1

Edit Song me ) 4 Resume me J

Detail song whe

Screen call end

4.L:S> P(AP) là một ham thông dịch Chúng ta viết s|= pif pe L(s): nghĩa là một

trạng thái s được gọi là thỏa mãn điều kiện p nào đó nêu p thuộc tập đích của L(s)

ON

@ ta, BS (8 tb}Hình 5 Một hệ thống chuyển trang thái

dUy : ø phải đúng, ít nhất là cho tới khi ự đúng

2.2.3 Ngữ nghĩa biểu thức LTL

- Tai liệu tham khảo: [17] [18] ¬- Cong thức LTL ø được dịch thành chuôi bat định (infinite paths) của các trạng thai

7T = So SS}

- Goi M là transition system (tên gọi khác Kripke structure) Chung ta viết :

M,a\=@ : nghĩa là ø đúng trên một path z của MM |ECó : nghĩa lag đúng trên mọi path z của VM

- Goi 2‘ là một phan của path z, bắt dau từ trạng thái s,, Z“ = S,S,,¡S„.¿

zEP|=m' |= pay

7 |= X¢

Z' |EL lø

z' =©øz'|=øU

© s,|Ep

& A(x' =ø)

Sm lot |EWaie

=> Vizier’ |=¢

©3/>¡iez'|E=ựAVk|i<k< j-l*®z'|Eø

2.3 Tổng quan về On-the-fly LTL Model Checking

- Phan này trình bảy tổng quan về on-the-fly LTL model checking.

- Tài liệu tham khảo: [15].[16].[17]

2.3.1 Nguyên lí của Model Checking

- Binh thường, dé kiểm tra mô hình có thỏa mãn tính chất nào đó không, các bước thựchiện gồm có :

> Xây dựng automat biểu diễn tat cả trạng thai cho mô hình> Xây dựng automat biểu diễn tat cả trạng thái cho phan phủ định của tính chat cần

kiểm tra> Lay tích hai automat Nếu kết quả khác rỗng, mô hình được xem là không thỏa

mãn tính chất

:4

¬đ

| <>(p U []q) |— [new ue |—m (a)

Property Ne cated Property

Hình 6 Nguyên lí của Model checking

- _ Việc xây dựng toàn bộ các automat cho mô hình và tính chat cần kiểm tra từ đầu có thélàm giảm hiệu suất (performance), đặc biệt có thể dẫn đến tình trạng đầy bộ nhớ

(memory exhausted) nêu mô hình càng phức tap

10

2.3.2 On-the-fly LTL Model Checking

On-the-fly model checking 1a cach lam nham khac phục hạn chế của model checking

thông thường, đó là sử dụng memory ít nhât có thê.> Không xây dung automat day đủ cho mô hình và thuộc tính cần kiểm tra ngay từ

đầu Việc xây dựng hai automat này và việc lây tích sẽ được thực hiện song song,do đó trạng thái mới của 2 automat chỉ được sinh ra dan dan, theo nhu cau của quátrình kiểm tra, và cũng không can phải lưu giữ các đường thực thi (execution path)

như thông thường

Trong quá trình lấy tích, nếu tìm được counterexamples thì quá trình kiểm tra dừnglại với kết quả là mô hình không thỏa mãn thuộc tính Như vậy, chỉ trong trườnghợp xâu nhất hoặc là thỏa mãn thì mới phải sinh ra toàn bộ 2 automat.

On-the-fly checking cũng có hạn chế, đó là thời gian xử lí có thể tăng cao vì nó dùng

nguyên lí depth-first-search, do đó phải sinh lại những trạng thái đã đi qua Một cách

khắc phục là lưu trữ lại chỉ những trang thái cần dùng, nhưng điều này van có thé danđến tinh trạng hết bộ nhớ (memory exhausted).

2.4 Kiểm tra mô hình với công cu PAT

- Phan này giới thiệu công cu PAT: Process Analysis Toolkit, được dùng trong quá trình

hiện thực của luận văn Tài liệu tham khảo [28].- PAT là một framework hỗ trợ tạo, chạy giả lập, suy dién/kiém tra các hệ thống chạy

đồng thời, hệ thống real-time và nhiều hệ thống thuộc các lĩnh vực khác, được xây

dựng bởi nhóm nghiên cứu của PGS Liu Yang thuộc trường Đại Học Quốc Gia

Singapore, từ nam 2007

- PAT hiện thực nhiều kĩ thuật kiểm tra mô hình như fairness assumptions, refinementchecking, probabilistic model checking PAT cũng hiện thực nhiều ki thuật tối ưu như

partial order reduction, symmetry reduction, process counter abstraction, parallel model

checking dé tăng hiệu suất xử lý.- PAT hỗễ trợ nhiều loại property như deadlock-freeness, divergence-freeness,

sang Labeled Transition System (LTS), Timed Transition System (TS) Trong core

của PAT là các giải thuật kiểm tra va giả lập các input là LTS, TTS đó.

12

Distributed Algorithms, Web Services, Bio-systems, Security Protocols, Sensor Networks, etc.

2 Probabilistic Web Service

3 Concurrent Module Real-time Module Module “hea |e=

s Verification || Verification || Verification example Verification Solvers

b Algorithms || Algorithms || Algorithms Generator, Algorithms

<x

Explicit Model Checking Symbolic Model Checking

Hình 8 Kiến trúc của PATHiện tại trong PAT đã có rất nhiều module hỗ trợ các hệ thống khác nhau như

Communicating Sequential Processes (CSP) Module, Real-Time System Module,Probability CSP Module, Probability RTS Module, Labeled Transition System Module,Timed Automata Module, NesC Module, ORC Module, Stateflow(MDL) Module,Security Module and Web Service (WS) Module

Nhóm nghiên cứu PAT đã thực hiện nhiều thử nghiệm va thấy rang PAT có kha năngkiểm tra được những hệ thống lớn, và trong nhiều trường hợp công cụ còn chạy tốt hơn

các công cụ kiêm tra mô hình phô biên khác

13

Chương 3: Tổng thuật các công trình liên quan

3.1 Các hướng nghiên cứu hiện nay

3.1.1 ScanDroid

- Bait báo: SCanDroid: Automated Security Certification of Android Applications [3]

- Tom tắt nội dung:v Tác giả dé cập van đề vi phạm tính toàn vẹn về quyền truy cập (permission

integrity) trong ứng dụng Android Thí dụ: Một ứng dụng Android đọc dữ liệu từ

resource A và ghi vào resource B Resource A yêu cầu quyền READ, WRITE đểcó thé đọc, ghi dữ liệu của nó Resource B yêu cầu quyền READ’, WRITE’ dé đọc,ghi dữ liệu của nó Nếu quyên WRITE’ là cao hơn quyền WRITE, thì ứng dụng viphạm tính toàn vẹn đữ liệu, vì bất kì ai có quyền WRITE cũng có thể ghi vào B.v_ Cách giải quyết; phân tích ứng dụng để rút trích ra các data-flow (e.g dòng chảy

dữ liệu từ resrouce A sang resource B), phân tích manifest file của ứng dụng để rúttrích ra đặc tính về bao mật (security specs), so sánh security specs với data-flows,kiểm tra xem có sự không tương thích nào không.

ứng dụng Android

Cách tiếp cận của tác giả vẫn có hạn chế là khi phân tích các lời gọi hàm thư viện,vì không có source code nên phải làm bằng tay nên độ chính xác có thé bị hạn chế.

14

3.1.2 WoodPecker

- Bai báo: Systematic Detection of Capability Leaks in Stock Android Smartphones [2|

- Tom tắt nội dung:

v Tác gia đưa ra hai loai permission leaks (capability leak) của ứng dụng trên

Android : implicit leak và explicit leak

> Explicit leak: ứng dụng không xin cấp quyên truy xuất đến các dữ liệu cánhân của người dùng hoặc hệ thống, nhưng thông qua các interface/service docác ứng dụng khác cung cấp (các interface/service này không được bảo vệbăng quyên truy cập), nó vẫn có thé truy xuất các dit liệu đó.

> Implicit leak: ứng dụng không xin cấp quyền truy xuất đến các dữ liệu cánhân của người dùng hoặc hệ thống, nhưng bằng cách kế thừa quyền truy xuấttừ ứng dụng khác (đặt thuộc tính sharedUserld trong manifest file), nó vẫn cóthể truy xuất các dữ liệu đó.

v_ Cách giải quyết:> Đối với explicit leak: phân tích manifest file của ứng dụng để xác định các

khả nang (capability) mà ứng dụng yêu cau, xây dựng CFG cho từng dau vào(entry point) của ứng dụng băng cách phân tích bytecode, và xác định cácđường thực thi có liên quan tới capability Trong số các đường thực thi đó,những đường nao không có kiểm tra quyên truy cập hoặc không có sanity

check cho bên gọi (caller), sẽ được coi là rò ri (leak)

> Đối với implicit leak: cách làm cũng tương tự như đối với explicit leak,

nhưng áp dụng cho trường hợp trong manifest file có đặc tả thưộc tính“sharedUserld” và không có yêu câu cấp quyên Khi đó khả năng của ứngdụng được xác định bằng cách tập hợp các khả năng của các ứng dụng khácmà có cùng userld

trên Android

w_ Trong quá trình phân tích code dé xây dựng CFG và tìm đường thực thi dẫn đếncác truy cập đến hệ thống (capability), ở những chỗ gọi hàm, tác giả dùng cách lưulại tóm tat hàm (method summary) để có thé dùng lại Đối với hàm thư viện, vikhông thé phân tích code trực tiếp nên tác giả phải thực hiện tóm tat băng tay tatcả các interface do Android framework cung cấp.

15

3.1.3 Android Model — Type and Effect System

Bai bao: Formal Modeling and Reasoning about the Android Security Framework [1]

Tóm tat nội dung:v_ Các tác giả đưa ra một cách để mô hình ứng dụng Android, trong đó cho phép mô

tả các yêu tố liên quan đến bảo mật của Android Security Framework.

> Ung dụng được mô hình bang cách chỉ tập trung vào những xử li mang tinh

tương tác như lời gọi hàm (giữa các ứng dụng, hoặc giữa ứng dụng với hệthông) hoặc xử lí có liên quan đên resource như new, grant, revoke

Các thông tin về quyên (permissions), đặc quyền (privileges) của ứng dụng

cũng như trạng thái cua platform cũng được mô hình lại băng ngữ cảnh(execution context)

v_ Để kiểm tra ứng dụng Android có đảm bảo một mục tiêu về bảo mật nào đó hay

không, tac giả dua ra “Type and Effect system” dựa trên kĩ thuật history

expression, dùng dé sinh ra mô hình của platform (nhiều ứng dụng) và kiểm chứng

các mục tiêu bảo mật trên đó.> Type and effect system biéu diễn các hiệu ứng (side-effect) có thé xảy ra khi

chạy chương trình Nhận input là chương trình ứng dụng đã được mô hình hóa,

Type and Effect System biểu diễn “type” là hiệu ứng của biểu thức

(expression), “history expression” là hiệu ứng của câu lệnh (statement)

Tác giả chứng mình được răng, đặt thuộc tính cần kiểm tra ở dạng historyexpression, nếu có thể ép kiểu (typing) chương trình ứng dụng sang historyexpression đó hoặc là dạng con của nó, thì có thể kết luận chương trình an

toan với mục tiêu bao mật đã đặt ra

Android Program Modeling ———>| Abstract Program | THIỆP and encesSystem

ŠF »

Security Policy Check to see if Effects(History effects is or (HistoryExpression) subtype of policy Expressions)

` y,

r

Result: Satisfiedor UnSatisfied

Hình 11 Cách thức xử lý của Type and Effect System

16

- - Ưu điểm & hạn chế:v Mô hình ứng dụng Android của tác giả bao quát được tương tác giữa ứng dụng va

ứng dụng, ứng dụng với platform bên dưới

Tác giả xây dựng “Type and Effect system” dé mô hình ứng dụng và kiểm tra cácthuộc tính bảo mật Tuy nhiên, cách này yêu cầu phải dịch toàn bộ chương trìnhsang ngôn ngữ mô hình và đưa vào hệ thông kiểm tra Nếu là chương trình ứngdụng thực tế với dung lượng lớn thì có thé tính kha thi không cao.

v

3.1.4 Sorbet

- Bai báo: Modeling and Enhancing Android’s Permission System [4]

- Tom tắt nội dung:VY Tác giả đưa ra hai van dé về permission trên Android là privilege escalation attack

va unrestricted permission delegation.>

>Privilege escalation attack: ứng dụng truy cập vào resource không được phépthông qua một chudi gọi hàm đên các ứng dụng khác

Unrestricted permission delegation: các component có thể grant/revokepermission cho các component khác tùy ý Thi dụ: một component có thégrant một permission mà nó được cấp tạm thời cho component khác, hoặc mộtcomponent có permission cố định có thể revoke permission đó từ tất cảcomponent được cấp động

v_ Cách giải quyết

> Công trình của tác giả không hướng đến việc kiểm tra xem ứng dụng Androidcó thỏa mãn security goal nào đó hay không, mà tập trung vào việc cải tiếnAndroid permission system, bằng cách xây dung một hệ thống bồ sung choAndroid, hỗ trợ người phát triển định nghĩa các luật (policy) cho ứng dụngcủa minh nhằm giảm thiểu hai van dé đã nói ở trên.

Về mặt hình thức, tác giả xây dựng một mô hình trừu tượng, cho phép môhình hóa những kiến trúc phân quyền có dạng giống Android, và đặc tả các

thuộc tính bảo mật mục tiêu Từ mô hình trừu tượng, tác giả tạo ra mô hình

Android và từ đó có thể phân tích được hệ thống của Android chưa thỏa mãn

được các thuộc tính bảo mật mục tiêu

- Ưu điểm và hạn chế:v Tác giả đề xuất một mô hình bao quát những tương tác trong hệ thống của

Android.Việc chứng minh ứng dụng Android có thỏa mãn mục tiêu bảo mật chỉ dừng lại ở

mức độ phân tích, lí luận Để ứng dụng vào chứng minh tự động, có lẽ cần phảixây dựng thêm nhiều yếu t6 khác như semantic, context

v

17

3.1.5 Stowaway

- Bai báo: Android Permissions Demystified [5]

- Tom tắt nội dung:VY Tác giả đưa ra van đề overprivileged của ứng dung Android Trong nhiều trường

hợp, người phát triển ứng dụng, vì một lý do nào đó, yêu cầu nhiều đặc quyền hơnnhu cau thật sự.

Thí du: ứng dụng 1 yêu cau ứng dụng 2 làm một thao tác nào đó trên tài nguyêncủa hệ thống, thì chỉ có ứng dụng 2 bắt buộc phải yêu cầu đặc quyên Tuy nhiêntrong thực tế, rất nhiều trường hợp, người phát triển ứng dụng lại đi yêu cầu đặcquyền đó cho ứng dụng 1.

VY Việc dư thừa đặc quyên này dẫn đến một nguy co là, các lỗi bảo mật nếu có của

ứng dựng có thê trở nên nghiêm trọng hơn

v Một trong những lý do dẫn đến việc yêu cầu nhiều đặc quyền hon can thiết là,người phát triển ứng dụng thường dựa vào các tài liệu của Google về đặc quyềncủa mỗi API, nhưng các tai liệu này thường liệt kê không day đủ và thiếu chínhxác Người phát triển ứng dụng thường chỉ muốn yêu cau cho đủ quyền dé sao cho

ứng dụng của họ chạy được

v_ Cách giải quyết> Tác giả xây dựng công cụ Stowaway gồm hai phan : bộ phân tích ứng dụng để

tìm ra tất cả API được sử dụng, và một bảng ánh xạ giữa API và đặc quyềncần thiết được xây dựng băng cách unit test các API để xác định đặc quyền

mà mỗi API yêu cầu Băng cách so sánh giữa kết qua phân tích va bang anhxạ, tac giả có thé xác định được ứng dụng có yêu cau nhiều hơn đặc quyền canthiết hay không

attacks” Đó là kiểu tan công ma một ứng dụng không có quyên nhưng nó vẫn truy

cập được hệ thống thông qua một ứng dụng khác Kiéu tân công này có thé đượcchia làm hai loại :

> Confused deputy attack: ứng dụng “có hại” tận dụng nhưng interface makhông có giới hạn đặc quyền của ứng dụng “có ích” Thí dụ: Androidbrowser cung cập API dé download file, mở các link đến các website Mộtứng dụng “có ích” sử dụng Android browser để mở các web-links trong cácquảng cáo Nhưng một ứng dụng “có hại” tận dụng Android browser để

download các content/file có hại

>» Collusion attack: ca hai ứng dụng (có và không có quyền truy cập hệ thống)

déu là ứng dụng có hại Hai ứng dụng kêt hợp với nhau đê đạt được một tậpcác đặc quyên đặc biệt nào đó

* Công trình của tác giả đi theo hướng cải tiến Android security framework Tác giảxây dựng thêm các module dé tích hợp vào Android security framework Cácmodules này kiểm tra giao tiếp giữa các ứng dụng xem có thỏa mãn security

policy mới do tác giả đặt ra hay không.Thí du : tac gia đặc ra các policies như : một ứng dụng không được thực hiện cuộc

gọi hoặc gửi tin nhăn ra ngoài nếu không có xác nhận từ user, ứng dụng truy cậpuser contact database thì không được có giao tiếp với một ứng dụng có network

access, ứng dụng muốn truy cập internet phải có quyén

Y Các policies có thé gây trở ngại cho những ứng dụng “có ich” (thi dụ như trườnghợp của Android browser ở trên) Dé giảm thiêu những trở ngại đó, tác giả chothực hiện phân tích dữ liệu giao tiếp giữa các ứng để xác định chính xác hơn khảnăng có tan công, và trong nhiều trường hợp có thể yêu cau xác nhận của user.

19

se el | ! Runtime Monitor System Policy

ee ^ joo installer

Application FrameworkAndroid Middleware

( Unmodified CS Modified for XManDroid ©) Created for XManDroid

Hinh 12 Kién tric XmainDroid

Tác giả áp dụng kĩ thuật phân cum K-means để phân biệt hành vi của các ứng

dụng, từ đó có thê xác định được ứng dụng nào là ứng dụng “có hại” (malware)

Framework bao gồm một chương trình client (gọi là Crowdroid) cài trên điện thoại

người dùng Chương trình nay theo dõi việc truy cập hệ thong (system call) củacác ứng dụng còn lại trên điện thoại và truyén dữ liệu đó vê một máy chủ

Ở phía máy chủ, đữ liệu về hành vi của các ứng dụng sẽ được phân tích, tạo ra cácvectors về việc truy cập hệ thống (system call) Mỗi vector đại diện cho một kiềugọi hệ thống nào đó, chứa các dữ liệu về hành vi của các ứng dụng khi thực hiệnlời gọi đó Sau đó, tác giả dùng giải thuật phân cụm K-means để phân loại các tậpđữ liệu Bang cach nay, tac gia thay được các ứng dung “có ich” sẽ thực hiện các

lời gọi hệ thông theo kiểu gần giống nhau, và các ứng dụng “có hại” (malware) cókiểu gọi khác, ngay cả khi chúng có cùng tên gọi hoặc user ID

20

Data Analyzer Script

OUTPUTINFOANALYZER

Hình 13 Quá trình phát hiện Malware của crowdroid

Ưu điêm và hạn chê:

vv

Công trình của tac giả áp dung nguyên tắc của crowdsourcing dé thu thập dữ liệuhành vi Người dùng càng sử dụng Crowdroid nhiều thì kết quả càng chính xácTrong trường hợp không có malware, kết quả phân loại vẫn 2 tập riêng biệt, do đócần thêm phân tích băng tay Ngoài ra, dữ liệu phải được truyền qua mạng đếnmáy chủ nên có nguy cơ bị tan công, làm sai lệch dữ liệu.

TaintDroid là một phan bổ sung cho Android platform, giúp theo dõi hành vi củacác ứng dụng third-party và các ứng dụng do người dùng tự tải về Framework lưu

lại quá trình dữ liệu cá nhân được sử dụng trong một ứng dung, cũng như việc dữ

liệu đó được truyền đến đâu trong hệ thống để báo lại cho người dùng Mục tiêuchính của TaintDroid là phát hiện khi dữ liệu bảo mật di ra khỏi hệ thống thôngqua các ứng dụng thiếu tin cậy.

Kĩ thuật được tác giả sử dụng là: gán nhãn cho dữ liệu từ khi nó còn ở tại

datasource (privacy data source), va mỗi khi dữ liệu được truyền qua các biến, file,hoặc qua các thông điệp gửi đến ứng dụng khác, nó tiếp tục được gán thêm các

nhãn mới Khi dữ liệu được truyền ra mạng hoặc rời khỏi hệ thông, TaintDroid lưu

vết lại toàn bộ quá trình dựa vào các nhãn găn trên dữ liệu và thông bảo cho người

dùng ngay tức thời

21

5 Trusted Application Untrusted Application

Binder IPC Library | Binder Hook | Binder Hook ' Binder IPC Library

2 { Binder Kernel Module¬ Đ—è>Tm=TễE.y Tễ=y.=TễTễïÏïÏìèẮFừ—èèừFèèễỄễèễE‡E TT TJỶJT JTJTJTJTJTJ JZT `=S—E—-T~l

Hình 14 Kiến trúc của TaintDroidƯu điểm và hạn chế:

v_ Việc lưu vết lại quá trình sử dụng dữ liệu giúp cho người dùng có thé phát hiệncác hành vi không đúng của ứng dụng Chức năng này cũng hỗ trợ các ứng dụng

khác trong việc phân tích ứng dụng

¥ Framework dựa trên việc phân tích dataflow, và không dựa vào control flow (vìcác ứng dụng third-party thường không cung cấp source code) Trong thực tế, các

ứng dụng malware có thê lây các dữ liệu cá nhân thông qua control flow

22

Tac gia tiếp cận cùng van dé với TaintDroid : tim privacy leak (dữ liệu cá nhân

được truyền từ nguồn nay sang nguồn khác và cuối cùng có bị chuyền ra ngoài hệthống)

Tác giả không sử dung reverse engineering mà phân tích trực tiếp từ bytecode, từđó xây dựng control flow graph Để tìm ra privacy leak, tác giả phân tích để tìmxem có flow nào từ lúc dữ liệu cá nhân được lây ra (source) cho đến khi dữ liệu

được truyền ra ngoài (sink), đánh dau đường đi bang giá trị của program counter

Nếu phát hiện một flow như vậy thì xem là có privacy leak> Source: là những api call dé lay dữ liệu cá nhân Tác giả xử lí cho 3 loại dữ

liệu cá nhân (location information, phone identifier, eavesdropping)

> Sink : là những api call dé truyền dữ liệu ra mang, file, hoặc SMS

- - Ưu điêm và hạn chê:

v

v

Tác giả phân tích tir bytecode nên có thé phân tích tĩnh và không gặp các van dévề việc dịch ngược (decompiler) Scandal có lợi thế hơn TainDroid ở chỗ khôngcần chạy ứng dụng lên mới có thể phân tích được, vì thế có thể giảm tải cho CPU.Scandal vẫn có các hạn chế như false positives khi xử lí cho các lời gọi hàm thư

viện (tác giả muốn bao quát hết mọi trạng thái có thé khi ứng dụng chạy, vì thế với

lời gọi library, tác giả giả định hết mọi khả năng dữ liệu được truyền qua lại giữacác thông sô của hàm thư viện, dẫn đến kết quả thu thập được có thé là một đường

thực thi nào đó không có thực nếu như hàm thư viện thực sự không có sự chuyểnđối data giữa các thông số) , hoặc là không hỗ trợi JNI, reflective calls

3.1.10 Com Droid

- Bai bao: Analyzing Inter-Application Communication in Android [10]

- Tom tat nội dung:

v Công trình của tac giả hướng tới các kiểu tan công có thé xảy ra trong quá trìnhgiao tiếp giữa các ứng dụng như eavesdropping, man-in-the-middle, system-intent-spoofñng Đây là những kiểu tan công mà hacker dựa trên cơ chế implicit intentcast của Android (không chỉ định rõ ứng dung đích), hacker có thé tạo ra ứngdụng bên nhận cũng có đủ những interface như yêu cầu để có thé nhận được

thông điệp từ bên gửi (eavesdropping), hoặc ứng dụng bên gửi gửi thông điệp yêu

cầu ứng dụng thật hoạt động sai lệch (intent spoofing), Tác giả phân tích bytecode của ứng dụng (DEX file), kiểm tra xem có những

trường hợp như implicit intent được gửi tới những component không được bảo vệ

bang quyên, hoặc được bảo vệ nhưng lỏng lẻo (weak permission), và đưa ra cảnh

báo

- - Ưu điêm và hạn chê:

v Tác gia chưa hỗ trợ xử ly day đủ cho cấu trúc if và swtich, dẫn đến có thé có falsenegative ComDroid chỉ đưa ra các cảnh báo về nguy cơ tân công, nó không kiểmtra xem có tân công thật sự hay không, vi thế người dùng phải tự đánh giá các kết

quả cảnh báo

23

3.1.11 AndroidLeaks

Bài bao: AndroidLeaks: Detecting Privacy Leaks In Android Applications [11]Tóm tắt nội dung:

v Công trình của tác giả cũng hướng tới van dé privacy leak : hỗ trợ người dùng hiểu

được chi tiệt quá trình dữ liệu cá nhân của họ được các ứng dụng sử dụng hoặctruyền ra ngoài như thê nào

Framework của tác giả nhận dữ liệu vào là file apk của ứng dụng Android Dữ

liệu đầu vào này được chuyển từ định dạng DEX sang dạng JAR, từ đó tác giảdùng WALA để phân tích java bytecode tạo ra call graph Dựa vào call graph, tácgia tim ra một chuỗi các lời gọi hàm bắt đầu từ các hàm trong ứng dụng dẫn đếnhàm API (có yêu cầu đặc quyên), từ đó xác định được cách dùng vê quyên trong

ứng dụng Nếu phát hiện chuỗi gọi hàm nao đó có kết hợp các quyền có thé gây ròri, thí dụ READ PHONE STATE và INTERNET, tác giả sẽ cho phân tích dòng dữ

liệu của nó dé xác định dữ liệu cá nhân có được truyén từ source (nguồn dit liệu)đến sink (api dé truyền dữ liệu ra network, SMS ) hay không.

Intents es

Taint Analysis Leak Reports

3 —

a —Sinks > ca ‘J

Hinh 15 Qua trinh phan tich Android Leaks

Uu diém va han ché:

vv

Android Leaks framework cũng gặp phải các van đề về hiệu suất (performance),

false positive nhu các framework khác

Khi tac gia chuyên từ ứng dụng dex bytecode sang java bytecode, một phan củaung dung bi chuyén thành invalid bytecode, nên kết qua của quá trình phân tích

ứng dụng không đây đủ

24

3.1.12 Các hướng khác

- Ngoài ra còn nhiều các công trình khác như Kirin [22], Saint [23] [25], QUIRE

[24] la những middleware trên Android platform dé tăng cường khả năng bảo mật cho

Android, hay như SymDroid [26] - một symbolic executor cho chương trình Android

ma thông qua đó có thể phát hiện ra được những điều kiện dẫn đến thông tin contact cóthé bị truy xuất trái phép, static analyzer [27]_- một framework giúp phân tích sourcecode dé tim ra các lỗi về class-cast, dead code, nullness nhăm tăng chất lượng chochương trình Android Mỗi framework đều có những ưu điểm và nhược điểm cầnkhac phục.

3.2 Thảo luận về các hướng nghiên cứu

3.2.1 Tóm tắt các hướng hiện tại

- _ Có thé thay các công trình hiện nay chủ yếu tập trung vao các lỗi bảo mật sau:

v

SNA

Privacy leak: một khi đã cho phép một ứng dụng sử dung thông tin cá nhân của

mình, người dùng không thể biết được thông tin cá nhân của mình được sử dụngnhư thé nào bên trong ứng dụng đó Chính vi vậy có trường hop thông tin cá nhâncủa người dùng bị truyền ra ngoải qua các ứng dung third-party hoặc malware

(TaintDroid, Scandal, AndroidLeaks)

Capability leak: các ứng dụng có quyền truy cập đến hệ thông hoặc các thông tin

cá nhân của người dùng, do vô tình hoặc cô ý, lại cung cap các interface cho cácứng dụng khác gọi, mà không giới hạn quyền Nhờ vậy malware có truy cập đếnhệ thống thông qua các interface không được bảo vệ đó (WoodPecker, Sorbet,XmainDroid, Comdroid)

Overprivileged: ứng dụng yêu cầu nhiều hơn quyén can thiết (Stowaway)Sự không nhất quán về quyên của ứng dụng trên một dataflow (Scandroid)

Phân biệt ứng dụng có hại và ứng dụng có ích, dựa trên hành vi của ứng dụng(Crowdroid)

- _ Có hai hướng tiếp cận chủ yếu:

v

v

Xây dung một công cu dé kiểm tra ứng dụng và thông báo với người dùng

(Scandroid, WoodPecker, Stowaway, Scandal, Crowdroid )

Cải tiễn Android platform băng cách thêm vào các middleware dé tăng cường khanăng bảo mật của Android, hoặc là dé theo dõi, phân tích hành vi của ứng dụng va

thông báo với người dùng (XmainDroid, TaintDroid, Sorbet )

25

- _ Cách giải quyết van đề của các công trình cũng khá da dạng:

v Phận tích động: phân tích khi ứng dụng chạy thực tê

v

> Phân tích data flow : Xmaindroid, Taintdroid> Hoc may (machine learning) : CrowdroidPhân tích tinh : phan tích dựa trên bytecode hoặc source code của ứng dụng

> Phân tích dataflow : Scandroid, Scandal, Androidleaks

> Phân tích control flow : Uoodpecker

> Phân tích call flow, tim system call: Stowaway, Comdroid, Androidleaks

> Trừu tượng hóa chương trình va tìm hiệu ứng lề : type & effect system, Sorbet

- Véuu điêm và nhược diém:

vv

Xem uu va nhược điểm cụ thé của từng phương pháp trong phan 2.1Phương pháp phân tích động: ap dụng khi ứng dụng chạy thực té, nhờ vậy độchính xác của kết quả phân tích thường cao hơn phương pháp phân tích tĩnh Tuynhiên phân tích động đòi hỏi framework phải chạy cùng với ứng dụng để có thểtheo dõi và phân tích hành vi của ứng dụng, vì vậy có thể gây ảnh hưởng đến hiệusuất chung của hệ thong

Phương pháp phân tích tinh: dựa trên bytecode hoặc source code vì vậy không

cần ứng dụng phải chạy thực tế mới kiểm tra được, nhờ đó tránh được ảnh hưởng

đến tốc độ xử lý chung của hệ thống Tuy nhiên, phân tích tĩnh gặp không ít khókhăn vì hiện tại có nhiều cấu trúc gọi hàm mà tất cả các phương pháp tĩnh đềuchưa có cách phân tích đúng (như reflective calls, JNI )

> Ngoài ra, các phương pháp phân tích tĩnh hoàn toàn (không kết hợp với phan

tích động) như xây dung control flow, data flow (Scandroid, Woodpecker, )

có điểm chung là phải tìm ra tất cả các flow hoặc đường thực thi của ứng dụnghoặc các ứng dụng trước rồi mới bat đầu kiểm tra có lỗ hỏng bảo mật hay

không.Thí dụ:

<> ScanDroid tìm ra tat cả dataflow của các ứng dụng sau đó đưa và bộ kiểmtra độ an toàn của flow dựa trên tính tương thích của các quyền áp dụng

trên flow đó

<> WoodPecker dựa vào control flow graph dé tìm ra tất cả các potentialpaths Trong số các path đó, có thể có các path không nguy cơ xảy ra lỗibảo mật, hoặc có path có tiềm năng xảy ra lỗi bảo mật nhưng lại khôngphải là path khả thi, vì thé tác giả tiếp tục phân tích dataflow để tìm rapath khả thi và có tiềm tang nguy cơ lỗi bảo mật

> Cách làm này có thé không khả thi nếu ứng dụng Android có kích thước lớn.Vì khi đó, có thé bùng nỗ về số lượng flow hoặc đường thực thi, dẫn tới hết

bộ nhớ hoặc hạn chê vê hiệu quả xử li

26

=> Hạn chế trên là động lực dé chúng tôi tiếp tục tìm kiếm cách tiếp cận mới, vớihi vọng là có khả năng khắc phục được phan nào khả năng xử lí ứng dụng kíchthước lớn Trong dé tài này chúng tôi xin giới thiệu một cách tiếp cận khác, cũngnam trong nhóm phân tích tinh, áp dụng kiểm tra mô hình cùng với kĩ thuật kiểmtra on-the-fly giúp hạn chế bùng no trạng thái khi chương trình có kích thước lớn.Hi vọng phương pháp nay có thé khắc phục được hạn chế nói trên của các phương

pháp hiện tại

3.2.2 Giới thiệu cách tiếp cận On-the-fly LTL Model Checking

Với phương pháp này, ứng dụng Android và các lỗ hỏng bảo mật sẽ được mô hình lại

thành các máy trang thái (automata) Một chương trình (gọi là model checker) nhận 2

automata đó làm input và thực hiện tích hai automata Nếu kết quả là tập rỗng thì xemnhư ứng dụng không có lỗi bảo mật đó, và ngược lại.

Khi ứng dụng càng lớn thi automata của ứng cảng chứa nhiều trạng thái Nêu xây dựng

toàn bộ automata ứng dụng từ đâu, va lây đây đủ kêt quả tích của automata ứng dungva automata 161 bảo mật, thì khả năng bùng nô trạng thái và không đủ bộ nhớ lưu trữ rat

cao.

Bang cách áp dụng kĩ thuật kiểm tra kiểu on-the-fly, automata ứng dụng sẽ được xâydựng dân dan cùng vơi việc lay tích 2 automata Những trang thái nào đã xử lí qua rồisẽ được xóa để giúp giải phóng vùng nhớ Như vậy, về lí thuyết, phương pháp này hoàntoàn có thé xử lí cho ứng dụng có kích thước lớn Trong thực té, kha năng xử lí ứngdụng lớn sẽ phụ thuộc vào cách hiện thực và tối ưu source code của chương trình kiểm

tra

27

“Thực hiện kiểm tra một ung dung Android có thỏa man mục tiéu về bao mật hay

không băng cách áp dụng phương pháp kiêm tra mô hình, và kiêm tra tính hiệu quả củaphương pháp này khi có ap dung ki thuật on-the-fly”

Trong giới han của luận van này, chúng tôi không thé xử ly được hết các trường hopcủa ứng dung Android, vi vậy chúng tôi chủ yếu thử nghiệm tinh khả thi của dé taibăng việc thực hiện kiểm tra được một loại lỗi bảo mật cụ thể, trên các chương trìnhAndroid đơn giản Cụ thể như sau:

v_ Lỗi bảo mật có thể xử lý: như đã trình bày trong phan 3.2.1, có nhiều lỗi bảo mậtđược các công trình nghiên cứu hiện tại quan tâm xử li Trong dé tai này, chúngtôi chọn xử lí lỗi bảo mật về “capability leak”, với hai trường hop implicit

capability leak và explicit capability leak

> Explicit capability leak: ứng dung A (không có quyên truy cap resource S)

thông qua lời gọi đến các ứng dụng khác (có quyên truy cập resource S) van

có thé truy cập đến resource S mà không cân trực tiếp yéu câu cấp quyên.

> Implicit capability leak: hành vi tương tự như trường hợp của explicit

capability leak, nhưng thay vì khai thác các interface không được bảo vệ của

các ứng dụng hoặc dịch vụ khác, ứng dụng A thừa kế quyên truy cập resource

S từ những ứng dụng khác mà có cùng signing key (cùng tac gia) với nó

* Dù không hỗ trợ các lỗi bảo mật còn lại, nhưng với cách làm tương tự, có thê

tiêp tục mở rộng framework dé xử lí cho các 161 còn lại

v_ Android component có thể xử lý:

> Chương trình Android, có 4 loại component là Activity, Provider, Service,

Receiver Hiện tại chúng tôi hỗ trợ xử lí cho 3 loại: Activity, Provider, Service* Dù chưa hỗ trợ cho Reciever, nhưng hoàn toàn có thể mở rộng xử lí theo các

làm tương tự đê xử lí cho Reciever

28