Android Settings机制应用安全性分析与评估

路晔绵 应凌云 苏璞睿 冯登国 靖二霞 谷雅聪

(中国科学院软件研究所可信计算与信息保障实验室 北京 100190) (luyemian@tca.iscas.ac.cn)



Android Settings机制应用安全性分析与评估

路晔绵 应凌云 苏璞睿 冯登国 靖二霞 谷雅聪

(中国科学院软件研究所可信计算与信息保障实验室 北京 100190) (luyemian@tca.iscas.ac.cn)

Settings机制是Android系统向应用程序提供的访问和配置部分全局设置的机制，Settings中的数据可被设备上的所有应用读取.实际使用中，一些Android应用及第三方库误将IMEI、BSSID、地理位置等隐私数据或关键配置信息写入Settings中，使得系统面临严重的隐私数据泄露、关键配置信息泄露和污染等安全风险.在分析大量样本的基础上，总结了Settings数据中泄露的隐私数据类型和关键配置信息，并针对部分Android应用和第三方库设计了数据劫持攻击和拒绝服务攻击方案，验证并确认了Settings机制在使用过程中的安全风险；针对该问题设计和实现了基于污点分析的Settings机制应用漏洞静态检测工具——SettingsHunter，该工具利用污点分析技术实现了对Android应用及第三方库Settings数据中的隐私数据泄露和关键配置信息泄露问题的自动检测，该工具将第三方库与宿主应用的分析分离，优化了分析过程，提高了分析效率和分析能力.使用SettingsHunter对3477个应用进行检测的结果显示，23.5%的应用在Settings数据的使用中存在隐私数据泄露或配置信息泄露问题，其中90.7%的应用中Settings相关风险操作完全来自于第三方库.实验结果表明:Settings中隐私数据泄露和关键配置信息泄露问题严重，第三方库中的问题尤为突出.

安卓应用；第三方库；隐私泄露；数据污染；静态污点分析

Android系统是目前最流行的移动智能设备操作系统，据Gartner的统计数据显示，2015年第4季度Android系统的市场占有率为80.7%，远远超过其他移动设备操作系统[1].Android应用的繁荣是Android流行的重要因素之一，每一台Android设备上都同时存在有大量的Android应用.为了更好地协同工作，应用之间的数据共享变得越来越普遍，例如，同一台设备上的多款亚马逊应用之间共享当前用户登录的亚马逊账号，可有效避免用户重复登录，改进用户体验.Android系统中，应用之间存在多种数据共享方式，其中Settings机制是Android系统提供给应用程序共享全局配置信息的重要机制.

Settings机制将Android系统和应用的共享数据存储在系统创建的数据库settings.db中，方便有需要的应用随时进行访问.Settings中存储的数据根据数据来源可以分为2类：1)Android系统写入Settings中的全局配置信息，包括设备名称、飞行模式状态、wifi状态等设备和系统相关信息，设备上所有的Android应用都可以通过系统提供的Settings API读取这些信息，进行相应的操作，例如，应用在发送短信前可以读取当前的飞行模式状态，若飞行模式打开则不进行短信的发送；2)Android应用写入Settings中的数据和配置信息，该类数据多为应用在运行过程中需要时常检测和使用的数据项，例如，手机安全应用“乐安全”将当前是否为访客模式的状态信息写入Settings数据中，在当前用户想要访问联系人列表、通话记录和短信息时读取该值以判断用户是否具有相应的操作权限.

由于Settings中的数据保存在Android系统创建的数据库中，即使写数据的应用程序被用户卸载，之前写入的数据也不会消失，因此很多第三方库采用Settings机制为处于不同宿主应用中的同一个第三方库保存部分需要满足数据一致性的信息，当初始写入该数据的第三方库宿主应用被删除时，其他宿主应用中的第三方库依旧可以正常访问该数据.例如百度云推送SDK将当前设备对应的channel_id信息存入Settings数据中，从而该设备上其他使用百度云推送SDK的应用可以共享该数据.

Settings机制在Android应用和第三方库中的使用已十分普遍，然而其面临的安全问题却很少被关注.由于Settings机制中存储的数据可被设备上所有的Android应用读取，且具备相关权限的应用可以修改其中的内容，因此Settings机制在使用过程中面临的安全问题主要分为2个方面：1)隐私数据泄露风险，当Android应用或第三方库误将隐私数据写入Settings中时，其他应用可轻易获取该数据的内容，例如，百度推出的百度云推送SDK、百度地图SDK等多款第三方库都将IMEI的明文数值写入了Settings数据中，使得其他不具有任何权限的应用可以轻松读取当前设备的标识符；2)关键配置信息污染风险，当Android应用或第三方库误将关键配置信息写入Settings数据中时，恶意应用可以通过修改该值影响目标应用的正常运行，例如，百度云推送SDK将推送数据转发中心所属应用的包名写入了Settings数据中，通过修改该值即可将推送数据的转发中心变为同样嵌入了百度云推送SDK的攻击应用，从而劫持发送给其他应用的推送数据.

本文在对大量样本进行分析的基础上，总结了当前Settings机制在应用过程中存在的安全问题，通过攻击方案实际验证评估了其安全风险；针对该问题提出了相应的检测方法并研发了检测工具SettingsHunter，利用该工具完成了大规模Android应用的检测，对Settings机制应用安全问题进行了评估.本文的贡献主要包括4个方面：

1) 完成了Android应用及第三方库中Settings机制应用的安全性分析，发现了大量的隐私数据泄露、关键配置信息泄露和污染等安全问题，总结了Settings机制应用过程中泄露的数据类型及对该问题的利用模式；

2) 设计了针对Settings机制的攻击方案，成功实施了对Android应用及第三方库的数据劫持攻击和拒绝服务攻击，确认了Settings机制的不当使用带来的安全风险；

3) 提出了基于污点传播分析的Settings应用漏洞检测方法，并实现了原型系统SettingsHunter，该系统利用污点分析技术检测Android应用及第三方库Settings数据中的隐私泄露和关键配置信息泄露问题，并将第三方库与宿主应用的分析分离，优化了分析过程，提高了分析效率和分析能力；

4) 完成了系统的实验评估，对来自于Google Play、豌豆荚、安智市场上的3477个应用进行了检测，实验结果表明:23.5%的应用将隐私数据或关键配置信息写入了Settings数据中，其中90.7%的应用中Settings相关风险操作完全由嵌入的第三方库引入.

1 Settings机制分析

Android系统提供的Settings机制框架图如图1所示:

Fig. 1 Framework of Settings mechanism.图1 Settings机制框架图

Android系统在framework中实现了一个名为SettingsProvider的应用，在其中创建了数据库settings.db，用来存储全局配置信息，同时创建了名为“SettingsProvider”的Content Provider组件封装访问该数据库的接口.之后，android.provider.Settings类通过binder机制跨进程访问SettingsProvider中的数据，而处于最上层的Android应用通过android.provider.Settings提供的API函数操作Settings数据.为了提高访问效率，Settings机制中存在2个数据缓冲区，一个位于SettingsProvider的Content Provider组件中，另一个位于android.provider.Settings类中.Android应用访问的数据首先在android.provider.Settings类的本地缓冲区中进行处理，无法命中时进入SettingsProvider中进行处理.Android系统提供的Settings应用属于Settings机制中Android Apps中的一个，是Android系统提供给用户操作Settings数据的图形操作界面.

在settings.db数据库中，全局配置信息分别存储在名为“global”,“secure”和“system”的3张表中，另外还有其他一些表格存储书签等用户相关信息.在实现了多用户机制的Android系统中，global表只为设备的所有者(owner user)创建，secure和system表则是每一个用户单独拥有一份，不同用户之间的表不能进行交叉操作.但是绝大多数用户在使用Android设备的过程中仍是采用单用户的使用模式，因此对于这些设备上的Android应用来说，Settings中的数据依旧是全部可读取的.

3张表中的数据对所有Android应用来说均是可读的，读操作所需的权限READ_SETTINGS为normal级别权限，不需要在应用程序的AndroidManifest.xml文件中明确列出也不需要用户明确授权，可以直接使用.对global表和secure表中数据进行的写操作受到WRITE_SECURE_SETTINGS权限的保护，对system表中数据进行的写操作受到WRITE_SETTINGS权限的保护.其中WRITE_SETTINGS权限为dangerous级别权限，可被第三方Android应用申请使用，而WRITE_SECURE_SETTINGS为signatureOrSystem级别权限，只能被Android系统应用申请使用，意味着对于第三方Android应用而言，可进行写操作的数据只有system表中的数据.

global,secure和system表中记录均为3个字段，分别为_id，name和value，其中_id为INTEGER类型数据，后2者为TEXT类型数据；而android.provider.Settings类中API函数的操作对象是name-value对，分别对应数据表中的name字段和value字段，其中value可为String,int,long,float这4种数据类型之一，Settings API将传递过来的value数据统一转变为String类型数据后传递给SettingsProvider应用，由SettingsProvider应用的Content Provider组件完成相应的数据库操作.

Settings API分为get和put两类，其中get用于数据读取，put用于数据写入，对应数据库的insert和update操作.由于android.provider.Settings没有提供删除数据的API函数，因此通过Settings API写入的数据，即使在Android应用被卸载后依然存在于设备中，即使设备重启也无法将该数据删除，意味着如果曾经有应用将IMEI写入了Settings数据中，那么该设备之后安装的应用都可以在不申请相关权限的情况下获取当前设备的IMEI值.

2 Settings数据安全问题分析

第三方Android应用及第三方库对Settings机制的不安全使用包括2种类型：1)将隐私数据写入Settings数据项中;2)将关键配置信息写入Settings数据项中.由于Settings中的数据可被同一设备上的所有应用读取，申请了相关权限的应用也可以修改Settings中存储的数据，因此Settings机制的不安全使用可能导致的安全问题相应地可以分为2类：隐私数据泄露和关键配置数据泄露与污染.

2.1 隐私数据泄露

经测试发现，Android应用写入Settings中的数据可能与多种隐私数据相关，例如IMEI、IMSI、MAC地址、BSSID、基站信息等.利用这些数据，攻击者可以实现准确识别用户设备、追踪用户位置改变等多种攻击目的.

1) 识别用户设备

Android系统通常使用IMEI,ANDROID_ID,序列号等数据来唯一标识一台设备，当应用获取了这些信息后即可准确地将当前设备从其他设备中分辨出来.Stevens等人的研究[2]指出，通过使用这些标识信息，广告库可以将不同宿主应用在不同时间段收集的信息对应到同一台设备上，从而达到长时间追踪用户信息的目的.可见保护设备标识符对于用户隐私数据的保护有着重要的意义.

当同一开发者的多款应用安装于同一台设备上，或设备上存在使用同一个第三方库的多款应用时，为了统一这些应用使用的设备标识，以方便远端服务器进行数据统计，部分应用会将IMEI等设备标识通过一定运算后写入Settings数据项中，方便其他相关应用读取.当写入的数据通过MD5等Hash算法转换时，其他应用无法读取对应的IMEI等数据的明文信息，然而实际中存在部分应用并没有对写入Settings中的数据进行加密及Hash保护，导致其他无关应用可以在不申请相关权限的情况下获取IMEI等设备标识的明文信息，造成数据泄露.而另一方面，经过了加密及Hash保护的IMEI等数据依旧具备唯一标识一台设备的属性，通过读取该值，其他应用也可以达到准确识别当前设备的目的.

本文发现在百度推出的多款应用及第三方库中均存在将明文IMEI值写入Settings中的现象，其数据项的键值(name)为“bd_setting_i”.百度系应用还会计算IMEI和ANDROID_ID的MD5值写入名为“com.baidu.deviceid”的Settings数据项中，以作为当前设备的唯一标识符.除此之外，安全应用“乐安全”将IMEI值写入了名为“ReaperAssignedDeviceId”的数据项中；搜狗推送服务将IMEI明文信息写入了名为“sogou_push_device_id”和“SOGOU_UUID”的数据项中.通过读取这些信息，恶意应用可以在不申请任何权限的情况下获取当前设备的唯一标识符，用于之后用户信息的追踪.

2) 追踪用户位置改变

Android应用为了获取用户的位置信息，通常使用LocationManager读取准确的经纬度信息，除此之外，Android应用还可以通过基站信息和BSSID值推断大致的位置信息.其中，BSSID是Android设备当前所连无线局域网网关的MAC地址，虽然局域网内部设备的MAC地址与设备地理位置并不直接相关，然而Zhou等人[3]指出，由于越来越多的公司通过收集无线热点的MAC地址在GPS无法使用的时候推断用户的地理位置，因此在Android设备上BSSID信息的泄露即意味着存在设备地理位置泄露的可能性.

本文发现百度云推送SDK将BSSID写入了Settings中名为“com.baidu.android.pushservice.lac”的数据项中，只要Android设备上存在1个使用了百度云推送SDK的应用，其他任何应用都可以在不申请ACCESS_WIFI_STATE权限的情况下读取当前设备的BSSID值.恶意应用可以通过读取该值后调用Google等公司的BSSID信息查询接口获取用户大致的地理位置信息.

2.2 关键配置数据泄露与污染

作为配置信息，Android应用和第三方库写入Settings中的数据多是为了在运行过程中判断执行流程.当Settings中的数据影响到Android应用或第三方库的关键运行逻辑时，这些数据被攻击程序修改将导致受害应用的运行受到严重影响.本节介绍了3个攻击场景，其中前2个攻击场景通过修改第三方库写入Settings中的配置信息截获目标应用应当接收或发送的数据，实施数据劫持攻击；第3个攻击通过修改Settings中的配置信息破坏应用及第三方库正常功能的运行，达到拒绝服务攻击的目的.

1) 劫持私聊数据

Android推送服务SDK通过在Android应用与推送服务器之间创建并维持1条socket长连接的方式，提供服务器端向客户端主动发送消息的功能，并保证消息的实时性.由于同一设备上可能存在多个使用了同一推送服务SDK的Android应用，为了减少资源消耗，部分SDK选择在多个应用之间共享1条socket长连接，由创建该连接的应用作为推送数据的转发中心，接收从服务器端推送的数据并通过sendBroadcast等函数转发给目标应用.在上述应用场景下，使用同一推送服务SDK的多个应用需要知晓当前的推送数据转发中心是哪个应用，以避免重复创建socket长连接，破坏推送服务SDK的运行逻辑.为了达到数据共享的目的，一些推送服务SDK将担任推送数据转发中心的Android应用包名写入了Settings中，使得设备上所有的应用都可以读取该值，同时申请了WRITE_SETTINGS权限的应用可以修改其中数据.

国内市场占有率最高的百度云推送Android SDK即使用了Settings机制保存推送数据转发中心所属应用包名.使用百度云推送的应用被安装启动后，其中的SDK会读取Settings中名为“com.baidu.push.cur_pkg”数据项的值，如果得到的结果不为null，且其对应的应用中属于百度云推送的service组件处于运行状态中，其所用SDK的版本不低于当前应用所用SDK的版本，则当前应用不修改Settings中的数值，继续使用原有的数据转发中心.若从Settings中获取的数据值为null，判断所有使用百度云推送服务的应用中SharedPreferences中存储的优先级值，将优先级值最高的应用作为推送数据转发中心.优先级值的大小与百度云推送SDK的版本值正相关.

本文设计了一个攻击应用，在应用中嵌入百度云推送SDK，并对其中读取Settings数据的操作进行hook，在百度云推送SDK读取Settings中“com.baidu.push.cur_pkg”数据项的值时，将返回值替换为null，同时将本应用下Sharedpreferences中的值修改为10000，此时百度云推送SDK将自动把“com.baidu.push.cur_pkg”数据项的值修改为攻击应用的包名，而不论攻击应用的真实SDK版本值是多少.使用这种方法，即使攻击应用使用的百度云推送SDK版本不是当前设备中最高的版本，也可以将数据转发中心成功变更为攻击应用自身.由于百度云推送的数据在数据转发中心处以明文形式传播，所以攻击应用可以获取所有推送数据的明文信息.本文将攻击应用安装在已安装了“Pogo看演出”应用的Android手机上，成功获取了“Pogo看演出”应用的用户lulu通过百度云推送收到的私聊信息，如图2所示.从截获到的消息中可以看到发送者的昵称“lilylucy”以及发送的消息内容“have a nice day”.图3为用户lulu实际看到的私聊界面.

Fig. 2 Data intercepted by attack app.图2 攻击程序截获的信息

Fig. 3 Chatting interface of user lulu.图3 用户lulu的私聊界面

2) 获取特定应用列表

腾讯信鸽推送SDK会在设备上实现一个本地Server并开启一个Watchdog端口接收使用了信鸽推送SDK的应用发送过来的一些信息，该端口号保存在Settings中名为“com.tencent.tpnsWatchdog-Port”的数据项中.

本文设计了一个攻击应用，在Service组件中实现了一个本地Server并将其端口号设定为6000，同时将Settings中“com.tencent.tpnsWatchdogPort”数据项的值修改为6 000.此外该Service组件还注册了监听Settings中数据改变的ContentObserver，以便在检测到其他应用修改“com.tencent.tpns-WatchdogPort”数据项的值时将其改回6 000.在攻击应用顺利启动本地Server并修改“com.tencent.tpnsWatchdogPort”数据项的值后，当设备上使用腾讯信鸽推送SDK的应用被打开或被安装时，攻击应用将收到当前设备上使用了腾讯信鸽推送SDK的应用列表，如图4所示，列表中的信息包括应用的包名及应用使用腾讯信鸽SDK时申请的AccessId.列表中的第1项为发送者的包名，后面为当前设备上所有使用腾讯信鸽推送SDK的应用列表.

Fig. 5 Framework of SettingsHunter.图5 SettingsHunter系统架构图

Fig. 4 Application list received by attack app.图4 攻击程序收到的应用列表信息

在腾讯信鸽推送SDK 2.45版本中，WatchdogPort在Settings中的数据项不再直接使用“com.tencent.tpnsWatchdogPort”作为名称，而是将该字符串进行MD5运算后作为名称，同时对传输的数据进行了加密.为了获取该版本SDK传输到WatchdogPort上的数据，攻击程序将开启另一个本地Server，并通过信鸽推送SDK中自带的解密函数进行解密.

3) 拒绝服务攻击

很多应用和第三方库写入Settings中的配置数据都有着固定的类型或格式，如果数据类型被修改或格式被破坏，将导致相应模块运行失败，停止提供正常服务.例如，腾讯信鸽推送SDK将收到的推送消息id进行加密后存入Settings数据中，当收到新消息时会判断Settings数据中是否存储有该消息的id，以判断是否为重放消息.攻击程序将Settings数据中存放消息id的数据项的值改为“test”，从而导致腾讯信鸽SDK解密失败，无法正常处理收到的推送数据，导致数据无法传递给目标应用.此外，通过修改安全应用“乐安全”写入Settings数据中“guest_mode_on”数据项的值，攻击程序可以将访客模式禁用，从而取消对联系人等数据的访问限制.

3 SettingsHunter的设计与实现

为了检测Android应用和第三方库写入Settings数据中的隐私数据和关键配置信息，本文设计并实现了Settings数据静态检测工具——SettingsHunter.SettingsHunter通过静态污点分析技术检测Android应用和第三方库是否将获取的隐私数据作为Settings写操作API函数的参数以及是否将Settings中读取的数据用于关键操作API函数的参数，以此判断Settings数据中是否存在隐私数据泄露和关键配置数据泄露的安全问题.

SettingsHunter的系统架构如图5所示，主要分为3部分功能，分别为预处理(pre-analysis)、污点分析(taint analysis)和第三方库优化(library optimizer).其中，预处理部分以apk样本文件作为输入，从中提取申请的权限信息，判断是否包含WRITE_SETTINGS权限，将包含有上述权限的apk文件作为候选样本进行下面的分析，同时输出权限检测结果用于之后的统计分析；污点分析部分根据配置好的sourcesink函数构建过程间控制流图(ICFG)，并追踪污点数据在过程间控制流图中的传播；第三方库优化部分为污点分析部分提供第三方库信息，消除已知第三方库对分析效率和分析结果带来的影响，并发掘和提取新的第三方库信息.SettingsHunter基于Androguard[4]，Flowdroid[5]和mysql数据库[6]实现相关功能.

在SettingsHunter的设计中，污点分析和第三方库优化是其核心功能，下面将重点进行介绍.

3.1 基于污点分析的数据泄露检测

SettingsHunter中的污点分析将指定的source函数的返回结果作为污点源，追踪污点数据在程序代码中的传播，当发现污点数据到达指定的sink函数时输出检测结果.

SettingsHunter的检测分为隐私数据泄露检测和关键配置数据使用检测2部分，根据检测目的的不同，选用的sourcesink函数也有所区别.

对于隐私数据泄露检测，污点分析模块将传统的获取隐私数据的Android API作为source函数，将Settings.System类下的put类API选为sink函数.SettingsHunter将隐私泄露检测部分的source函数分为DeviceId,Location,WifiInfo,Database,Others这5种类别，每种类别的说明如表1所示:

Table 1 Descriptions of Source Function Categories in

对于关键配置信息检测，SettingsHunter关注的是修改其值后可允许攻击应用访问本不可访问的目标应用的数据或启动本不应启动的目标应用组件的数据项，因此将组件间传送数据的API函数、设置URIURL的API函数、创建socket的API函数等作为sink函数，相应地将其分为ICC，URI，Network和Others这4种类别，每一类别的说明如表2所示.SettingsHunter将Settings.System中的get类API选为该部分检测的source函数.

Table 2 Descriptions of Sink Function Categories in Key Configuration Detection

由于第三方Android应用及第三方库自定义的Settings数据只能写入system表中，因此在上述2部分的检测中都只考虑了Settings.System类提供的操作函数.

3.1.2 污点分析

污点数据在程序代码中的传播分析基于现有的静态污点分析工具Flowdroid进行开发.FlowDroid是一个流敏感、上下文敏感、对象敏感和字段敏感的静态污点分析工具，用于检测Android应用中可能存在的隐私数据泄露问题.Flowdroid提供过程间控制流图(ICFG)的构建及污点数据在ICFG中的传播分析2部分功能.

虽然Flowdroid的检测精度可以达到字段级别，但是过于精确的分析不可避免会带来极大的时间和空间消耗，为了提高Flowdroid的可用性，不得不在准确度和效率之间进行折中.SettingsHunter根据具体的使用场景对Flowdroid进行了2部分的优化，分别为过程间控制流图精简和分析配置优化.

1) 过程间控制流图精简

为了降低过程间控制流图的规模、提高污点分析的效率，在Flowdroid构建过程间控制流图之前，SettingsHunter将对apk文件中的callback函数进行预处理，如果发现在某个callback函数与Settings接口函数之间存在可达路径，则选为候选callback函数，否则在Flowdroid的控制流图构建过程中将不再考虑该callback函数可达的代码.

2) 分析配置优化

SettingsHunter参考了Flowdroid的开发者在实际分析中使用的配置[7-8]，并结合具体的分析场景，对污点分析模块进行了如下配置：

① 不考虑污点数据在隐式流中的传播；

② 使用非数据流敏感的别名搜索算法；

③ 将字段的访问路径最大长度设置为3；

④ 不分析应用布局文件中可能存在的隐私数据源，即不将用户通过界面控件输入的数据看为隐私数据；

⑤ 将array看为一个整体进行污点分析，而不区分其中的具体元素；

⑥ 不分析污点数据在exception处理函数中的传播.

以上配置虽然会在分析过程中引入少量误报和漏报，但可以大大提高污点分析模块的实际可用性，在实际分析中是可以接受的.

3.2 第三方库分析优化

SettingsHunter针对第三方库进行的优化处理主要包括2部分:1)为污点分析提供已知第三方库包名信息，便于精简其构建的过程间控制流图，提高分析效率；2)在样本文件的分析过程中发掘新的第三方库并收集其污点分析结果.

在当前的Android应用开发过程中，开发者大量使用了各种第三方库访问某些服务或简化开发过程，导致同一个第三方库可能存在于多个Android应用中，这一现状会带来3类问题：1)导致Settings-Hunter的污点分析过程中多次重复分析相同的第三方库代码；2)Android应用中大量使用的第三方库会严重影响SettingsHunter的分析速度，Wang等人[9]发现1个Android应用中可能有超过60%的代码来自于第三方库的使用，这就意味着在污点分析过程中可能有60%甚至更多的分析时间耗费在第三方库代码中；3)对Settings数据的使用定责不明，例如一个善意的Android应用本身的功能当中并不包含对Settings数据的操作，但是因为其中使用了百度云推送SDK，导致污点分析的结果显示该应用向Settings中写入了隐私数据和关键配置信息，检测出的安全问题将被归责于该应用的开发者，然而实际的问题出现在该应用使用的第三方库中.为了解决这些问题，SettingsHunter设计了第三方库优化模块，在过程间控制流图的构建过程中将第三方库的代码剔除，有效缩减过程间控制流图的规模，提高污点分析的运行效率.

SettingsHunter针对第三方库的优化分为2部分：

1) 先验排除

作者首先提取了部分已知第三方库的包名，在SettingsHunter构建函数调用图和过程间控制流图的过程中去除第三方库相关的代码.

先验排除中的第三方库信息来源于2部分：①人工下载的国内常用的30个第三方库，从其中的jar文件中提取包名信息；②Li等人从Google Play上145万多个apk文件中提取的1353个第三方库包名信息[10].

为了提取先验排除的第三方库中Settings数据使用的情况，SettingsHunter在分析样本文件的过程中将记录包含有该第三方库包名的apk文件，在全部样本分析结束后，从包含有该第三方库包名的apk文件中随机选取3个apk文件进行再次分析，将该第三方库代码加入过程间控制流图的构建过程，并在寻找source函数时只考虑该第三方库使用到的source函数，从而避免对原apk文件自身功能的重复分析.提取3个apk文件分析结果的交集作为该第三方库的分析结果.

2) 动态反馈

对于未提前获取的第三方库信息，Settings-Hunter在污点分析过程中统计每一对source-sink的调用函数所属包名信息，若发现包含某一对source-sink的包名在5个以上apk文件中出现，则判定该包名属于第三方库包名，存入图5的Library Information中，当SettingsHunter在以后的样本分析中再次遇到该包名时将不再进行函数调用图和控制流图的构建.

第三方库包名的选取条件包括4条：

① 不以宿主应用包名为前缀；

② 不以android,java,javax等系统包名为前缀；

③ 以”.”分割的字段数量大于2；

④ 以”.”分割的字段其字符串长度均大于1.

其中第4条用于排除混淆后的包名，一些本身并不相同的包名在经过混淆之后会变得相同，因此为了减少误报，需要将混淆的包名去除.一般混淆字段的包名多以单个英文字母命名，因此将判断条件中字符串长度设置为1可以有效减少误报.虽然有些混淆字段长度会大于1，但是SettingsHunter对于第三方库包名的检测是基于拥有同样的source-sink对为前提进行的，整个检测过程结合了行为特征和文本特征2个方面的内容，因此即使文本特征的检测结果会有误报，但结合行为特征后也可以有效降低误报率.

此外，由于第三方库的包名字段数量一般为2～4，因此当发现的候选包名字段大于4时，只截取前4个字段作为第三方库包名.

SettingsHunter将样本分析过程中检测到的包名及对应的source与sink函数存入数据库，每找到一次该记录则将数据库中该记录的count字段值加1，当count字段值为5时，判定检测到的包名为第三方库包名，将其写入Library Information中，用于SettingsHunter在后续样本文件的分析过程中去除对该包名下代码的分析.

3.3 SettingsHunter误报漏报分析

SettingsHunter可能产生的误报和漏报主要来自于污点分析过程中使用的Flowdroid工具.由于3.1.2节中使用一些特殊配置在Flowdroid的运行效率和精确度之间进行了折中，因此不可避免会引入一些误报和漏报.其中别名算法的选择和array的处理会引入少量误报，其他的配置会引入少量漏报.此外Flowdroid本身并不能很好地处理组件间通信过程中的数据流动，因此会导致部分漏报的产生.

除了上述情形，由于第三方库不同版本之间对Settings数据的使用可能存在差异，而不同应用可能使用了同一第三方库的不同版本，因此针对第三方库提取的分析结果可能会与实际情况存在些微差异.

尽管存在误报和漏报，但Flowdroid进行数据流分析的精确度高于绝大多数现有的分析工具，因此基于Flowdroid开发的SettingsHunter的分析结果依旧具备很高的参考价值.

4 实验与分析

本节将展示作者使用SettingsHunter对收集到的样本进行检测的结果，并对其进行分析和说明.

4.1 测试样本来源

作者从安智(Anzhi)市场20类应用中随机搜集了1 011个Android应用，从豌豆荚(Wandoujia)市场18类应用中随机搜集了1 220个Android应用，从Google Play的28类应用中搜集了1 326个Android应用，3个应用市场一共搜集了3 557个应用作为实验样本集.所有应用均收集于2016年5月份，能较好地反映当前Android应用对Settings数据的使用情况.

4.2 实验结果分析

1) 权限分析结果

3个应用市场搜集的应用中有80个应用无法使用Androguard进行分析，因此SettingsHunter的实际分析样本集包含3 477个样本.3 477个样本中含WRITE_SETTINGS权限的应用数量及其所占比例如表3所示.可见Android应用对Settings机制的使用十分普遍.

Table 3 Result of Permission Analysis

2) 第三方库信息统计

在SettingsHunter分析的样本中，检测使用到的第三方库包名有433个，其中39个包含Settings数据的使用，20个存在隐私数据泄露或关键配置信息泄露的隐患，其中包含7个在SettingsHunter的分析过程中新发现的第三方库包名.针对第三方库的隐私泄露检测结果如表4所示，关键配置数据使用检测结果如表5所示.

Table 4 Result of Privacy Leakage Detection of

Table 5 Result of Key Configuration Detection of

虽然检测结果显示有问题的第三方库数量并不多，但是使用这些第三方库的应用数量却达到785个，占样本总数的22.6%，占含有WRITE_SETTINGS权限样本总数的51.8%，可见其影响十分广泛.其中根据包名可识别出的知名第三方库有百度云推送SDK、百度地图SDK、百度定位SDK、腾讯信鸽推送SDK等.

3) Android应用信息统计

为了更好地展现第三方库代码对Android应用行为的影响，本部分将Android应用的统计结果分为不包含第三方库和包含第三方库2部分进行展示.

3个应用市场中Android应用的隐私泄露检测结果如表6所示，关键配置数据使用检测结果如表7所示.其中“no-lib”表示去除应用中第三方库代码之后的检测结果，“with-lib”表示添加了第三方库分析结果之后的检测结果.

在3 477个样本中，SettingsHunter共检测出问题样本818个，占样本总数的23.5%，去除第三方库代码后问题样本个数为76个，即仅因嵌入了第三方库而引入了安全问题的样本数量为742个，占问题样本总数的90.7%.由此可见，第三方库对Android应用安全的影响不容小觑.

Table 6 Result of Privacy Peakage Detection of Android Applications

Table 7 Result of Key Configuration Detection of Android Applications

5 讨 论

本文发现的安全问题，本质在于Android应用或第三方库的开发者误将敏感信息写入了可被设备上所有应用访问的公共存储空间Settings中，因此直观的安全解决方案是采用其他安全的数据共享方式代替Settings数据共享机制.

其中SharedPreferences只允许与其所属应用拥有相同签名及相同sharedUserId的应用进行数据读写，当SharedPreferences的打开模式设置为MODE_WORLD_READABLE模式时，同一设备上的任意应用都可以读取其中的内容，但是写操作依旧只有签名相同且sharedUserId相同的应用才可进行.

Content Provider是应用程序对外提供数据访问接口的常见方式，其掩盖了底层数据存储方式的不同，向应用程序提供了读写数据的统一接口.只要应用程序将Content Provider组件公开，其他应用便可以读写其底层存储的数据.为了提供对Content Provider组件的访问控制，应用程序可以设置相应的读写权限，只有具备相关权限的应用才可以通过该Content Provider组件访问底层存储的数据.

Broadcast Receiver组件主要用来接收数据改变的通知，从而改变应用自身存储的数据内容，例如Amazon Seller应用的登录账号退出时会通过sendBroadcast函数向同一设备上的Kindle应用发送当前账号退出信息，此时再打开Kindle应用将需要重新进行登录.与Broadcast Receiver相似，通过Service组件来共享数据时同样是将数据的改变通过bindService函数传递给创建该Service组件的应用.此外，为了提供访问控制，应用程序也可以为Broadcast Receiver组件和Service组件设置访问权限，只有具备相应权限的应用才可以通过send-Broadcast和bindService函数向该应用传递数据.

上述4种数据共享方案中，获取对Shared-Preferences的完整读写权限需要同一开发者开发的应用方能满足签名相同且sharedUserId相同的条件，而其余3种均是使用公开组件进行数据访问和传播，为了防止非授权应用访问相关数据，需要为公开组件设置访问权限，未设置访问权限的公开组件也将面临数据泄露和配置数据污染的问题.公开组件的访问权限一般为应用自定义权限，一个应用需要申请自定义权限时一般也要同时在自己的AndroidManifest.xml文件中定义该权限，因此设备上可能有多个声明了同一自定义权限的应用存在，在Android 5.0之后，只有具有相同开发者签名的应用才可以声明相同的自定义权限，因此在Android 5.0之后，只有同一开发者的应用才可能使用公开组件的方式进行数据共享.

综上所述，只有同一开发者开发的应用才可能安全使用上述4种数据共享方案，对于宿主应用由不同开发者开发且签名密钥不同的第三方库而言则无法很好适用.

对于百度云推送等确实需要在不同宿主应用之间共享数据的第三方库而言，其安全共享数据的目标在于阻止非授权的其他应用读写共享数据以及阻止恶意宿主应用修改配置数据，因此设计安全共享数据方案的难点在于区分读写操作的请求来源于第三方库还是其宿主应用或其他应用.直观的方案是使用函数调用栈的信息来区分操作Settings数据的函数调用来源，然而Seo等人[11]指出，Android应用可以使用原生代码(native code)篡改Dalvik调用栈的内容，使得通过调用栈区分操作来源的方法失效.因此，设计第三方库的安全共享数据方案的前提是设计第三方库与宿主应用运行环境的隔离，这将作为本文的下一步研究工作.

6 相关工作

近年来智能手机得到了飞速发展，人们的生活越来越多地依赖于智能手机，对手机使用的安全性要求也越来越高.作为最受欢迎的智能手机操作系统平台，Android系统及Android应用的安全得到了广泛研究，文献[12]即是从系统安全和应用安全2个角度详细介绍了现有的安全问题及相关的安全研究.

在已发现的安全问题中，隐私数据泄露始终是大家关注的重点之一.传统的隐私泄露问题是指应用通过调用相关API获取IMEI、手机号、通讯录等隐私数据之后通过网络等途径将隐私数据传出设备，相应的检测方案有TaintDroid[13]，Flowdroid[14]，VetDroid[15]等.其中TaintDroid将隐私数据标记为污点源，动态追踪污点数据在应用运行过程中的传播，当发现污点数据通过网络、短信等方式流出设备时即判断可能存在隐私泄露.TaintDroid使用动态检测的方法，可以确保检测出的行为是实际运行过程中可以发生的行为.Flowdroid通过静态污点传播的方式检测应用中的隐私泄露行为，通过构建程序入口点到污点源的可达路径确保检测到的行为实际发生的可能性.VetDroid从权限使用的角度分析应用中隐私数据的获取及之后的使用，重构应用的权限使用行为，检测其中的隐私泄露及其他恶意行为.

除了传统隐私数据泄露的检测，新型隐私泄露场景的挖掘和检测也成为近几年研究的热点之一.例如，TouchLogger[16]利用加速度和陀螺仪记录用户点击屏幕键盘时产生的震动，推断用户输入内容；PIN Skimmer[17]使用麦克风检测触屏事件的发生，使用摄像头估计手机轻微转动的方向，将其与点击的数字位置相关联，推测用户输入的PIN值.类似工作还有文献[18-19].此外，Cheng等人[20]发现利用移动社交应用中的通讯录匹配功能，通过上传海量用户手机号码，可以获取应用账号与手机号码之间的对应关系以及用户账户的详细资料，通过多款社交应用之间数据的一致性分析，可以获取大量用户的真实信息.与上述研究不同，本文发现了在Android应用使用Settings数据时产生的隐私泄露问题，泄露的数据多为IMEI，wifi信息等传统隐私数据，数据流出点为全局可读数据存储区Settings数据库.针对此隐私泄露场景，本文设计了Settings-Hutter来检测Android应用及第三方库使用的Settings数据中的隐私泄露行为，SettingsHunter对Flowdroid进行了改进，在分析Android应用的同时提取第三方库信息.

除了隐私泄露，Android应用组件安全问题也是近年来关注的重点之一.Android应用由四大组件组成，任一组件出现安全问题都会影响整个应用的安全.Zhou等人[21]指出，未加以保护的公开Content Provider组件会导致隐私数据泄露和关键配置数据被修改等安全问题.Chin等人[22]指出，恶意应用可以通过劫持隐式Intent并修改其内容向Intent的目标组件中注入恶意信息，影响目标组件的运行.与上述研究不同，本文发现的数据污染问题出现在Settings数据中，由于部分Android应用及第三方库不慎将关键配置数据写入Settings数据中，导致攻击程序可以通过修改其中数值改变应用程序的运行逻辑.

在当前的Android应用开发过程中，开发者已越来越多地使用到第三方库，同一第三方库可能存在于多个热门应用中，一旦第三方库出现安全问题，产生的影响将远远大于单个Android应用带来的影响，因此第三方库的相关研究也逐渐开展起来.文献[23]和文献[24]均对如何提取Android应用中的第三方库进行了研究，其中Li等人[24]将他们的提取结果公布在了github上供大家使用[10].在Li等人的研究成果基础上，本文采用了先验排除和动态反馈的方式处理污点分析过程中遇到的第三方库，对于分析过程中遇到的多次出现且具有相同行为特征的包名判断为新发现的第三方库，反馈到后续样本的分析过程中.通过将文本特征和行为特征结合，SettingsHunter对第三方库的识别准确性更高.

对于第三方库中出现的安全问题，近年来的研究主要关注于广告库和推送服务的安全分析.Grace等人的工作[23]、Stevens等人的工作[2]以及Book等人的工作[25]对广告库中的权限滥用、隐私信息收集和用户追踪等危险行为进行了分析；Crussell等人的工作[26]和Liu等人的工作[27]对广告库可能面临的虚假访问和不正确显示等攻击进行了研究.Li等人的工作[28]和Chen等人的工作[29]分析了推送服务在逻辑设计上存在的安全问题，并提出了相应的检测方案和安全加固方案.与上述研究不同，本文分析的并不是某类第三方库中存在的安全问题，而是在多种第三方库中都可能出现的Settings数据使用不当问题，其影响范围更为广泛.

为了解决第三方库带来的安全问题，研究人员设计了各种方案将第三方库与宿主应用隔离，并严格控制第三方库的行为，例如AdSplit[30],AdDroid[31]和AFrame[32]采用不同层次的隔离技术解决广告库给宿主应用带来的安全问题以及恶意宿主应用对广告库进行的攻击；FlexDroid[11]采用硬件故障隔离技术，对第三方库的原生代码进行隔离，严格限制第三方库的能力.这些方案可以作为本文所建议的针对第三方库防护方案设计的参考，在对第三方库与宿主应用进行隔离的基础上设计细粒度的共享数据访问控制机制.

7 结束语

本文分析了Android应用及第三方库在使用Settings数据的过程中出现的安全问题，指出了其中可能存在的隐私泄露问题及关键配置数据泄露与污染问题，并成功实施了针对部分Android应用及第三方库的数据劫持攻击和拒绝服务攻击.本文设计了针对上述安全问题的静态检测方案，通过静态污点分析技术检测Settings数据中的隐私数据泄露和关键配置信息泄露问题.本文实现了该方案的原型系统——SettingsHunter，并对来自于安智市场、豌豆荚市场和Google Play的3477个应用进行了检测分析，检测结果显示：23.5%的应用将隐私数据或关键配置信息写入了Settings数据中，其中，90.7%的应用仅因为嵌入了有问题的第三方库而引入了这些安全问题.在样本应用使用到的433个第三方库中，有20个第三方库存在Settings数据使用安全问题.虽然存在安全问题的第三方库数量不多，但是使用到这些第三方库的应用所占比率达到22.6%，其影响不容忽视.实验结果显示，在目前Android应用及第三方库的开发过程中，Settings数据使用的安全情况不容乐观，应引起开发者的广泛关注，在应用和第三方库的设计过程中采用更安全的数据共享方式.

[1]Xinhuanet. Gartner: Global smart phone sales increased by 9.7% in 4Q15[EB/OL]. (2016-02-24)[2016-05-15]. http://news.xinhuanet.com/tech/2016-02/24/c_128744695.htm (in Chinese)(新华网. Gartner：2015年第四季度全球智能手机销量增长9.7%[EB/OL]. (2016-02-24)[2016-05-15]. http://news.xinhuanet.com/tech/2016-02/24/c_128744695.htm)

[2]Stevens R, Gibler C, Crussell J, et al. Investigating user privacy in Android ad libraries[C] //Proc of the 1st IEEE Workshop on Mobile Security Technologies (MoST). Piscataway, NJ: IEEE, 2012

[3]Zhou Xiaoyong, Demetriou S, He Dongjing, et al. Identity, location, disease and more: Inferring your secrets from Android public resources[C] //Proc of the 2013 ACM SIGSAC Conf on Computer & Communications Security. New York: ACM, 2013: 1017-1028

[4]Androguard Team. Androguard[CP/OL]. (2015-10-29)[2016-05-15]. https://github.com/androguard/androguard

[5]Paderborn University and TU Darmstadt. FlowDroid : Taint analysis[EB/OL]. [2016-05-15]. https://blogs.uni-paderborn.de/sse/tools/flowdroid

[6]Oracle Corporation. MySQL[EB/OL]. [2016-05-15]. http://www.mysql.com

[7]Arzt S. How to run FlowDroid[EB/OL]. (2015-11-30)[2016-05-20] https://github.com/secure-software-engineering/soot-infoflow-android/wiki

[8]Avdiienko V, Kuznetsov K, Gorla A, et al. Mining apps for abnormal usage of sensitive data[C] //Proc of the 37th Int Conf on Software Engineering (ICSE). Piscataway, NJ: IEEE, 2015: 426-436

[9]Wang Haoyu, Guo Yao, Ma Ziang, et al. WuKong: A scalable and accurate two-phase approach to Android app clone detection[C] //Proc of the 2015 Int Symp on Software Testing and Analysis. New York: ACM, 2015: 71-82

[10]SerVal Research Group. A repository of Android common libraries and advertisement libraries[EB/OL]. (2015-12-15)[2016-05-15]. https://github.com/serval-snt-uni-lu/Common-Libraries

[11]Seo J, Kim D, Cho D, et al. FLEXDROID: Enforcing in-app privilege separation in Android[C/OL] //Proc of the 23rd Network and Distributed System Security Symp (NDSS). 2016 [2016-05-15]. https://www.internetsociety.org/sites/default/files/blogs-media/flexdroid-enforcing-in-app-privilege-separation-android.pdf

[12]Zhang Yuqing, Wang Kai, Yang Huan, et al. Survey of Android OS security[J]. Journal of Computer Research and Development, 2014, 51(7): 1385-1396 (in Chinese)(张玉清, 王凯, 杨欢, 等, Android安全综述[J]. 计算机研究与发展, 2014, 51(7): 1385-1396)

[13]Enck W, Gilbert P, Han S, et al. TaintDroid: An information-flow tracking system for realtime privacy monitoring on smartphones[J]. ACM Trans on Computer Systems (TOCS), 2014, 32(2): 5:1-5:29

[14]Arzt S, Rasthofer S, Fritz C, et al. Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps[C] //Proc of the ACM SIGPLAN Conf on Programming Language Design and Implementation. New York: ACM, 2014: 259-269

[15]Zhang Yuan, Yang Min, Xu Bingquan, et al. Vetting undesirable behaviors in Android apps with permission use analysis[C] //Proc of the 2013 ACM SIGSAC Conf on Computer & Communications Security. New York: ACM, 2013: 611-622

[16]Cai Liang, Chen Hao. TouchLogger: Inferring keystrokes on touch screen from smartphone motion[C] //Proc of the 6th USENIX Workshop on Hot Topics in Security (HotSec). Berkeley, CA: USENIX Association, 2011: 9-9

[17]Simon L, Anderson R. PIN skimmer: Inferring PINs through the camera and microphone[C] //Proc of the 3rd ACM Workshop on Security and Privacy in Smartphones & Mobile Devices. New York: ACM, 2013: 67-78

[18]Xu Zhi, Bai Kun, Zhu Sencun. Taplogger: Inferring user inputs on smartphone touchscreens using on-board motion sensors[C] //Proc of the 5th ACM Conf on Security and Privacy in Wireless and Mobile Networks. New York: ACM, 2012: 113-124

[19]Aviv A J, Sapp B, Blaze M, et al. Practicality of accelerometer side channels on smartphones[C] //Proc of the 28th Annual Computer Security Applications Conf. New York: ACM, 2012: 41-50

[20]Cheng Yao, Ying Lingyun, Jiao Sibei, et al. Bind your phone number with caution: Automated user profiling through address book matching on smartphone[C] //Proc of the 8th ACM SIGSAC Symp on Information, Computer and Communications Security. New York: ACM, 2013: 335-340

[21]Zhou Yajin, Jiang Xuxian. Detecting passive content leaks and pollution in Android applications[C/OL] //Proc of the 20th Network and Distributed System Security Symp (NDSS). 2013[2016-05-15]. http://www.internetsociety.org/doc/detecting-passive-content-leaks-and-pollution-android-applications

[22]Chin E, Felt A P, Greenwood K, et al. Analyzing inter-application communication in Android[C] //Proc of the 9th Int Conf on Mobile Systems, Applications, and Services. New York: ACM, 2011: 239-252

[23]Grace M C, Zhou Wu, Jiang Xuxian, et al. Unsafe exposure analysis of mobile in-app advertisements[C] //Proc of the 5th ACM Conf on Security and Privacy in Wireless and Mobile Networks. New York: ACM, 2012: 101-112

[24]Li Li, Bissyandé T F, Klein J, et al, An investigation into the use of common libraries in Android apps[C] //Proc of 2016 IEEE 23rd Int Conf on Software Analysis, Evolution, and Reengineering (SANER). Piscataway, NJ: IEEE, 2016: 403-414

[25]Book T, Wallach D S. A case of collusion: A study of the interface between ad libraries and their apps[C] //Proc of the 3rd ACM Workshop on Security and Privacy in Smartphones & Mobile Devices. New York: ACM, 2013: 79-86

[26]Crussell J, Stevens R, Chen Hao. MAdFraud: Investigating ad fraud in Android applications[C] //Proc of the 12th Annual Int Conf on Mobile Systems, Applications, and Services. New York: ACM, 2014: 123-134

[27]Liu Bin, Nath S, Govindan R, et al. DECAF: Detecting and characterizing ad fraud in mobile apps[C] //Proc of the 11th USENIX Symp on Networked Systems Design and Imple-mentation (NSDI 14). Berkeley, CA: USENIX Association, 2014: 57-70

[28]Li Tongxin, Zhou Xiaoyong, Xing Luyi, et al. Mayhem in the push clouds: Understanding and mitigating security hazards in mobile push-messaging services[C] //Proc of the 2014 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2014: 978-989

[29]Chen Yangyi, Li Tongxin, Wang Xiaofeng, et al. Perplexed messengers from the cloud: Automated security analysis of push-messaging integrations[C] //Proc of the 22nd ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2015: 1260-1272

[30]Shekhar S, Dietz M, Wallach D S. AdSplit: Separating smartphone advertising from applications[C] //Proc of the 21st USENIX Security Symp. Berkeley, CA: USENIX Association, 2012: 553-567

[31]Pearce P, Felt A P, Nunez G, et al. Addroid: Privilege separation for applications and advertisers in Android[C] //Proc of the 7th ACM Symp on Information, Computer and Communications Security. New York: ACM, 2012: 71-72

[32]Zhang Xiao, Ahlawat A, Du Wenliang. AFrame: Isolating advertisements from mobile applications in Android[C] //Proc of the 29th Annual Computer Security Applications Conf. New York: ACM, 2013: 9-18

Lu Yemian, born in 1989. PhD candidate. Her main research interests include Android application security and malicious code analysis.

Ying Lingyun, born in 1982. PhD. Senior engineer. His main research interests include malware analysis and mobile security (lingyun@iscas.ac.cn).

Su Purui, born in 1976. PhD. Professor and PhD supervisor. His main research interests include malware analysis and prevention (purui@iscas.ac.cn).

Feng Dengguo, born in 1965. Professor and PhD supervisor. His main research interests include cryptography and information security (feng@tca.iscas.ac.cn).

Jing Erxia, born in 1989. MSc candidate. Her main research interests include Android security and static analysis (jingerxia@tca.iscas.ac.cn).

Gu Yacong, born in 1989. PhD candidate. His main research interests include Android system security and malicious code analysis (guyacong@tca.iscas.ac.cn).

Security Analysis and Evaluation for the Usage of Settings Mechanism in Android

Lu Yemian, Ying Lingyun, Su Purui, Feng Dengguo, Jing Erxia, and Gu Yacong

(TrustedComputingandInformationAssuranceLaboratory,InstituteofSoftware,ChineseAcademyofSciences,Beijing100190)

Offered by Android system, Settings is a mechanism used by applications to read and write some global settings of the device. Data stored in Settings can be read by all the applications on the same device. Some Android applications and third-party libraries carelessly put privacy data and important configuration information into Settings, which leads to serious security risks such as privacy leakage and configuration data leakage. In this paper, we make a comprehensive study of the issues mentioned above. By analyzing a large number of applications, we find the privacy data and configuration information leaked to Settings including IMEI, BSSID and location info, etc. We also successfully undertake some data hijacking attacks and DoS attacks for Android applications and third-party libraries, which confirms that the inappropriate use of Settings can really lead to serious security problems. Based on the above research, we propose SettingsHunter, a static detection tool for Settings issues. SettingsHunter detects privacy data and important configuration information put in Settings using taint analysis technology. In order to improve the efficiency, SettingsHunter separates the analysis of third-party libraries from the one of host applications. This separation also improves the analysis ability for third-party libraries. We use SettingsHunter to analysis 3477 applications and the result shows that 23.5% of the analyzed applications put privacy data or key configuration information into Settings, of which 90.7% is due to the using of third-party libraries. These applications and third-party libraries may suffer from privacy data leakage or configuration data pollution attacks.

Android applications; third-party libraries; privacy leakage; data pollution; static taint analysis

oid应用之间常见的数据共享方式包括SharedP

，Content Provider，Broadcast Receiver和Service.

2016-06-16

2016-08-09

国家“九七三”重点基础研究发展计划基金项目(2012CB315804); 国家自然科学基金项目(61502468); 国家“八六三”高技术研究发展计划基金项目(2015AA01603)

TP309

This work was supported by the National Basic Research Program of China (973 Program) (2012CB315804), the National Natural Science Foundation of China (61502468), and the National High Technology Research and Development Program of China (863 Program) (2015AA01603).