第3章 移动终端漏洞类型 通过对移动终端目前发现的漏洞进行分析可以发现,移动终端的攻击面主要包括操 作系统、App 、固件、硬件、通信协议等方面,本章将详细讨论各部分的漏洞情况。移动终 端漏洞主要参见CVE通用安全漏洞库、国家信息安全漏洞库、国家信息安全共享平台和 Google安全公告。 1　操作系统漏洞 3. 3..操作系统分布 11 产业界各方都将移动智能终端当作自己进军移动互联网领域的入口,但由于自身优 势和经营理念差异,其发展模式也各不相同。按照操作系统的授权方式和应用商店的运 营方式,主要可分为封闭端到端模式、半封闭模式和开放开源模式。 (1)封闭端到端模式是指终端厂商完全控制终端产品的生产,基于封闭的操作系统 平台构建端到端闭合的应用生态系统,在终端中深度内置自营业务,并对第三方应用的开 发、测试、上架和使用全程控制,不允许第三方应用商店存在,如苹果公司、黑莓公司等。 (2)半封闭模式是指操作系统厂商授权给OEM厂商或者终端设备厂商生产终端产 品,但不向其开放源代码。同时,操作系统厂商构建封闭端到端的应用生态系统,在操作 系统中深度内置自营业务,同时对第三方应用的开发、测试、上架和使用全程控制,不允许 未经审核认证的应用在操作系统上使用,如微软公司WindowsPhone操作系统。 (3)开放开源模式是操作系统厂商对源代码开放开源,任何终端厂商均可针对操作 系统进行定制和修改,任何硬件开发商均可为操作系统开发驱动程序,从而组成范围更大 的产业联盟。同时,操作系统厂商对第三方应用的开发、传播一般不做任何限制,允许任 何应用在操作系统上运行。开放开源模式以Google公司的Android系统为代表,普遍被 终端领域后进入者所采用,发展极为迅猛。 统计机构Staticsta发布了2019年第二季度移动终端操作系统市场份额占比,如图3-1 所示。其中操作系统Andd占比最高,为77.与2019 年第一季度占比基本一致; roi14%, 83%, e03%, iOS 系统占比22.位居第二;其他(Othr)移动终端操作系统相加占比仅0.完 全不及iOS 系统和Android系统。 图3- 1 2019 年第二季度移动终端操作系统市场份额占比 如图32所示,在Andd系统中,1为20.占比最高,较2019 年第一 季度占比上升约2%;0占比为16.0占比为14. -roiAndroid8.03%, Andri16%;ri96%;roi0 od6.Andod8.Andd9. 占比为12.较2019 年第一季度占比上升约8%;1占比为9. 18%, Android7.53%;Android 1占比为9.0占比为7.4占比为4.0占 5.41%;Android7.29%;Android4.25%;Android5. 比为2.其他版本(r)45% 。 74%; OtheAndroid系统占比为3. 图3- 2 Android系统各版本占比(2019 年第二季度) 如图33所示, iOS12 为56.较2019 年第一季度占比 -在iOS 系统中,86%,占比最高, 上升约7%;iOS11 占比为19.iOS10 占比为10.iOS9 占比为5. 44%;43%;iOS8 占比为2.iOS7 占比为0.iOS 系统占比为4.37%; 40%;64%;其他版本(Other)86% 。 不同移动智能终端的发展模式也使得终端面临的安全威胁程度不一。在封闭端到端 模式和半封闭模式下,终端厂商在封闭的生态系统中占据绝对主导地位,承担一定的第三 方应用管理责任,因此针对其的恶意代码和违反其经营理念的数字内容较少。但是,终端 24 第3章移动终端漏洞类型 图3- 3 iOS系统各版本占比(2019年第二季度) 厂商自身的各种行为难以得到有效监管和制约,如苹果公司能够对其出售的所有移动终 端上的应用程序进行远程安装和卸载。而在开放开源模式下,操作系统厂商基本不对应 用程序进行任何控制,导致针对开源操作系统的恶意代码和不良信息呈现泛滥趋势。 3333333..............操操操操操操操作作作作作作作系系系系系系系统统统统统统统架架架架架架架构构构构构构构11111112222222 目前,移动终端常用的操作系统包括Android、iOS 、WindowsMobile、Symbian、 BlackBeryOS,以及其他操作系统(如Linux、PalmOS 、WebOS 、MeGo…),其中iOS和 Android系统是目前主流的移动终端操作系统,占据了绝对的主导地位。由于iOS系统 的闭源特性,其系统特征无法进行详细研究,因此下面以Android系统为例进行说明。 Android是一种基于Linux的自由及开放源代码的操作系统。主要使用于移动设 备,如智能手机和平板计算机,由Google公司和开放手机联盟领导及开发。目前, Android尚未有统一的中文名称,较多人使用“安卓”。Android系统最初由AndyRubin 开发,主要支持手机。2005年8月,由Google公司收购注资。2007年11月,Google公司 与84家硬件制造商、软件开发商及电信营运商组建开放手机联盟共同研发改良Android 系统。随后Google公司以Apache开源许可证的授权方式,发布了Android的源代码。 第一部Android智能手机发布于2008年10月。随后Android逐渐扩展到平板计算机及 其他领域上,如电视、数码照相机、游戏机、智能手表等。 Android系统在正式发行前,最开始拥有两个内部测试版本,并且以著名的机器人名 称对其进行命名,它们分别是阿童木(And和发条机器人(And0)。后来 roidBeta) roid1. 由于涉及版权问题,Google公司将其命名规则变更为用甜点作为它们系统版本的代号的 命名法。甜点命名法开始于And5发布。作为每个版本代表的甜点尺寸越变越大, roid1. uae,ri5)、Dnt,然后按照26个英文字母表顺序如下:纸杯蛋糕(CpCkAndod1.甜甜圈(ouAndri6)、EngihMun,ri0/2.冻酸奶(ryo,ri2)、 od1.松饼(lsfiAndod2.1)、FoAndod2.姜饼 (Gingerbread,Android2.3)、蜂巢(Hive,Android3.0)、冰激凌三明治(IceCream Sadwih,ri0)、JlyBaAndod4.ri2)、tKa ncAndod4.果冻豆(een,ri1和Andod4.奇巧(Kit, Android4.Lolipop,Android5.rshmalow,Android6. 4)、棒棒糖(0)、棉花糖(Ma0)、牛轧 25 ( 糖( 0Q )。 0)、奥利奥(O0)、派(0)和未知 Nougat,Android7.reo,Android8.Pie,Android9. Android10. Android的系统整体架构和其操作系统一样,采用了分层的架构,如图3-4所示。从 架构图看,Android系统分为4层,从高层到低层分别是应用程序层(Applications)、应用 程序框架层(ApplicationFramework)、Android运行库层(AndroidRuntime)和Linux内 核层(LinuxKernel)。 图3- 4 Android系统整体架构图 1. 应用程序层 Android会同一系列核心应用程序包一起发布,该应用程序包包括客户端、短消息(SMS) 程序、日历、地图、浏览器、联系人管理程序等。所有的应用程序都使用Java语言编写。 2. 应用程序框架层 开发人员也可以完全访问核心应用程序所使用的API框架。该应用程序的架构设 计简化了组件的重用,任何一个应用程序都可以发布它的功能块并且任何其他的应用程 序都可以使用其所发布的功能块(须遵循框架的安全性)。同样,该应用程序重用机制也 使用户可以方便地替换程序组件。 隐藏在每个应用程序后面的是一系列的服务和系统,其中包括以下内容。 (1)丰富而又可扩展的视图系统(ViewSystem),可以用来构建应用程序,它包括列 表(Lists)、网格(Grids)、文本框(Textboxes)、按钮(Butons),以及可嵌入的Web浏 览器。 26 第3章移动终端漏洞类型 (2)内容提供器(ContentProvider)使应用程序可以访问另一个应用程序的数据(如 联系人数据库),或者共享它们自己的数据。 (3)资源管理器(ResourceManager)提供非代码资源的访问,如本地字符串、图形和 布局文件(LayoutFiles)。 (4)通知管理器(NotificationManager)使应用程序可以在状态栏中显示自定义的提 示信息。 (5)活动管理器(ActivityManager)用来管理应用程序生命周期,并提供常用的导航 回退功能。 3. Android 运行库层 Android系统包含一些C/C++库,这些库能被Android系统中不同的组件使用。它 们通过Android应用程序框架层为开发者提供服务。一些核心库如下。 (1)系统C库。一个从BSD继承来的标准C系统函数库libc,它是专门为基于 EmbeddedLinux系统的设备定制的。 (2)媒体库。基于OpenCore(PacketVideo),该库支持多种常用的音频、视频格式回 放和录制,同时支持静态图像文件。编码格式包括MPEG4 、H. 264 、MP3 、AAC 、AMR 、 JPG 、PNG等。 (3)SurfaceManager。对显示子系统的管理,并且为多个应用程序提供了2D和3D 图层的无缝融合。 (4)LibWebCore。一个最新的Web浏览器引擎,支持Android浏览器和一个可嵌入 的Web视图。 4. Linux 内核层 Android系统运行于LinuxKernel之上,但并不是GNU/Linux系统。因为在一般 GNU/Linux系统里支持的功能,Android系统大都没有支持,包括Cairo、X11 、ALSA 、 FFmpeg、GTK 、Pango及glibc等都被移除。Android系统又以Bionic取代glibc,以Skia 取代Cairo,再以OpenCore取代FFmpeg,等等。Android系统为了使应用可商用,必须 移除被GNU 和GPL授权证所约束的部分,例如Android系统将驱动程序移到 Userspace,使LinuxDriver与LinuxKernel彻底分开。Bionic/Libc/Kernel/并非标准的 Kernelheaderfiles。Android系统的Kernelheader是利用工具由LinuxKernelheader 所产生的,这样做是为了保留常数、数据结构与宏。 Android系统的LinuxKernel控制包括安全(Security)、存储器管理(MemoryManagement)、程序管理(ProcesManagement)、网络堆栈(NetworkStack)、驱动程序模 型(DriverModel)等。下载Android源码前,先要安装其构建工具Repo来初始化源码。 Repo是Android系统用来辅助Git工作的一个工具。 3..操作系统安全现状 13 1. Android 系统的特点 1)开放性 Android平台首先就是其开放性,开发的平台允许任何移动终端厂商加入Android 27 2 8 联盟中。显著的开放性可以使其拥有更多的开发者,随着用户和应用的日益丰富,一个崭 新的平台也将很快走向成熟。 开放性对于Android系统的发展而言,有利于积累人气,这里的人气包括消费者和厂 商,而对于消费者,最大的受益正是丰富的软件资源。开放的平台也会带来更大的竞争, 如此一来,消费者将可以用更低的价位购得心仪的手机。 2)丰富的硬件 这与Android平台的开放性相关,由于Android系统的开放性,众多的厂商会推出千 奇百怪、各具特色的多种产品。功能差异和特色却不会影响数据同步,甚至软件的兼容, 如同从诺基亚Symbian风格手机一下改用苹果iPhone,同时还可将Symbian中优秀的软 件带到iPhone上使用,联系人等资料可以方便转移。 3)方便开发 Android平台提供给第三方开发商一个十分宽泛、自由的环境,不会受到各种条条框 框的阻扰,可想而知,会有多少新颖别致的软件诞生。但也有其两面性,如何控制血腥、暴 力等方面的程序和游戏正是留给Android系统的难题之一。 4)Google应用 从搜索巨人到全面的互联网渗透,Google服务(如地图、邮件、搜索等)已经成为连接 用户和互联网的重要纽带。Android从2005年被Google公司收购,在互联网时代已经 走过10多个春秋,无缝整合了这些优秀的Google服务。 2. Android 系统安全机制 Android系统安全性方面的重要设计:在默认情况下,应用程序没有权限执行对其他 应用程序、操作系统或用户有危害的操作,这些操作包括读写其他应用程序的文件等。 Android系统主要提供如下安全机制。 1)进程保护 程序只在自己的进程空间,与其他进程完全隔离,从而保证进程间安全。在同一个进 程内部,可以任意切换到Activity;在不同的进程间,如进程A 的Activity去启动进程B 中的Activity,结果通常是请求被拒绝(PermissionDenial)。 2)权限模型 Android系统要求用户在使用API时进行申明,称为请求(Permission)。申明在 AndroidManifest.xml文件里进行设置。这样对一些敏感API的使用在安装时就可以给 用户风险提示,由用户确定是否安装。下面是一些最常用的权限许可。 (1)READ_CONTACTS:读用户通讯录数据。 (2)RECEIVE_SMS:监测是否收到短信。 (3)ACCESS_COARSE_LOCATION:通过基站或者WiFi获取位置信息。 (4)ACCESS_FINE_LOCATION:通过GPS获取到更精确的位置信息。 例如,要监控是否有短信到达,需要在AndroidManifest.xml文件中进行如下设置: 第3章移动终端漏洞类型 同时,Permision通过ProtectionLevel分为4个保护等级:normal、dangerous、 signature、signatureorsystem 。不同的保护级别代表程序要使用此权限时的认证方式。 normal的权限只要申请就可以使用;dangerous的权限在安装时需要用户确认才可以使 用;signature的权限可以让应用程序不弹出确认提示;signatureorsystem的权限需要开 发者的应用和系统使用同一个数字证书(其实就是需要系统或者平台签名)。dangerous 是最常用的权限,在平时安装应用时都会提示应用使用了哪些权限。 例如,在Androd系统的API中提供SyselcstunTieMis函数修改系统 itmCok.eCretmli 时间,可惜调用这个函数时发现,无论是模拟器还是真机,在logcat中总会出现“Unableto openalarmdriver:Permisiondenied”。这个API其实就是signatureorsystem权限等级,即 调用这个函数需要系统签名,但真实手机中的系统签名密钥只有厂商知道。 3)文件访问 Android应用程序的安装目录分为以下3部分。 (1)/data/data下会有每个应用程序的私有目录。 (2)/data/app会保存所有安装文件的APK(Android系统的安装包)。 (3)/data/dalvik-cache会有每个应用程序的核心文件DEX(DEX文件是Android系 统的可执行文件,包含应用程序的全部操作指令及运行时的数据)的缓存文件,主要是为 了提高效率。 (4)/System/app通常是系统自带的应用程序目录。 每个Android应用程序(apk文件)会在安装时分配一个独有的Linux用户ID,这就 为它建立了一个沙盒,使其不能(.) 与其他应用程序进行接触(也不会让其他应用程序接触 它)。这个用户ID会在安装时分配给它,并在该设备上一直保持同一个数值。所有存储 在应用程序中的数据都会赋予一个属性———该应用程序的用户ID,这使得其他安装包 (Package)无法访问这些数据。当通过方法getSharedPreference、openFileOutput等创建 一个新文件时,可以通过使用MODE_WORLD_READABLE 、MODE_WORLD_ WRITEABLE标志位设置是否允许其他Package访问读写这个文件。当设置这些标志 位时,该文件仍然属于该应用程序,但是它的全局读写权限已经被设置,使得它对于其他 任何应用程序都是可见的。下面的例子给出了Android文件存储的4种方式。 (1)Context.MODE_PRIVATE:默认操作模式,代表该文件是私有数据,只能被应 用本身访问,在该模式下,写入的内容会覆盖原文件的内容。 (2)Context.MODE_APPEND:该模式会检查文件是否存在,存在就往文件追加内 容,否则就创建新文件。 (3)Context.MODE_WORLD_READABLE:用来控制其他应用是否有权限读该文 件,存在即表示当前文件可以被其他应用读取。 (4)Context.MODE_WORLD_WRITEABLE:用来控制其他应用是否有权限写该 文件,存在即表示当前文件可以被其他应用写入。 当然也有方法可以使两个程序相互访问对方的资源,即使用sharedUserId属性。通 过使用Andrinfs.l文件的maiet标签中的saeeId属性, odMaietxmnfshrdUsr使不同的 Package共用同一个用户ID 。通过这种方式,这两个Package就可以进行资源的相互访 问。但共用同一个用户ID需要两个应用程序可被同一个签名签署才能实现。 29 4)应用程序签名 Android系统的代码签名采用自签名机制,是一种适度安全策略的体现,在某种程序 上保证了软件的溯源目标及完整性保护。但程序签名只是为了声明该程序是由哪个公司 或个人发布的,无须权威机构签名和审核,完全由用户自行判断是否信任该程序。API按 照功能划分为多个不同的能力集,应用程序要明确声明使用的能力。应用程序在安装时 提示用户所使用到的能力,用户确认后安装。 APK安装时的验证过程如下。 (1)计算CERT.f文件的哈希值。 s (2)用公钥( 验证CERT.s得到结果与上面的CERT.f文件的哈希值 证书) ra文件, s 进行比较。如果相同,则表明CERT.f文件是未被篡改的 。 s (3)由于CERT.f文件包含了APK中MANIMF文件的哈希值, FEST. sFEST.而MANIMF 文件包含了APK中其他文件的哈希值,因此从CERT.f文件可以得到其他文件的正确哈希值。 s (4)最后验证MANIFEST.MF中列出的APK中的其他文件和其对应的哈希值是否 一致,从而判断APK的完整性。 5)系统区和用户区分离 Android系统的核心应用都部署在系统区(system/app),该区域是只读的。用户程 序通常部署在data/app 。 6)密码学服 务 Android系统支持下列算法 。 (1)对称算法,包括AES 、DES 、3DES 、RC5 、RC2 、PBE 。 (2)非对称算法,包括RSA 、DSA 、ECC 。 (3)杂凑算法,包括SHA1 、MD5 、MD2 。 (4)传输加密。 0\3.d系统的传输加密支持L2TP/IPSEC 、L2TP 、支持SSLV2.1。 AndroiPPTPVPN, 0\3. 2　App漏洞 3. Android系统由于其开源的属性,市场上针对开源代码定制的只读存储器(Read- OnlyMemory,ROM)参差不齐,在系统层面的安全防范和易损性都不一样,Android系 统应用市场对App的审核相对iOS系统也比较宽泛,为很多漏洞提供了可乘之机。市场 上一些主流的App虽然做了一些安全防范,但由于大部分App不涉及资金安全,所以对 安全的重视程度不够;同时由于安全是门系统学科,大部分App层的开发人员缺乏安全 技术的积累,措施相对有限。 21 App 安全概述 3.. 移动市场成熟发展的同时,不法分子利用应用安全漏洞,致使安全事件频发,黑灰产 业链也向移动终端用户蔓延,App成为国家网络安全领域的重点对象。 1. App 发展现状 1)应用数量持续增加,用户增量饱和 据中华人民共和国工信部数据显示,2019年年底我国App数量达367万。其中,游 30 第3章移动终端漏洞类型 戏类应用以占比30.生活服务类、07% 和9. 73% 排行第一; 电子商务类分别以占比12.38% 排名第二和第三。规模前三的应用类型总和占比为整个App 市场规模的52.如 图3-5所示。 18%, 图3- 5 App 类型分布 截至2019 年年底,我国移动互联网用户总数达13.我国手机上网用户数量达 9亿, 12. 6亿,自2019 下半年起维持稳定,市场用户增量基本饱和,如图36所示。 图3- 6 2019 年我国手机上网用户数量 2)App 漏洞大量催生,平均每个App 存在19 个漏洞 大量的用户基数及与日俱增的市场规模,为不法分子实施恶意攻击等行为提供了前 提条件,权威数据表明,在2019 年公开信息安全漏洞统计中,58% 来自应用程序漏洞,而 操作系统漏洞与数据库漏洞仅占11% 和1%,应用程序漏洞大量催生。 31 Testin云测安全实验室对2019 年扫描的573652 款App 分析后共计发现漏洞 10794512 个,平均每个App 存在19 个漏洞, 3% 的App 不存在漏洞。其中,20% 仅有0. 属于高危漏洞,39% 属于中危漏洞,41% 属于低危漏洞,如图3-7所示。 图3- 7 漏洞威胁等级分布 在应用风险类型分布中,由数据安全和代码安全因素引发的漏洞占比最多,所占比例 分别为30% 和28% 。如图3-8所示。 图3- 8 应用风险类型分布 3)数据保护监管愈发严格,用户信息安全意识觉醒 2019 年是信息泄露严重爆发的一年,如用户隐私信息在暗网公开售卖、上市公司窃 取用户隐私牟利超千万、数十亿公民虹膜扫描和指纹信息外泄、新生婴儿信息非法倒卖等 事件数见不鲜,信息泄露让数以亿计的用户毫无隐私可言且惶恐不安,也让不少企业深陷 舆论泥潭,用户信息安全保护意识开始觉醒。 堪称史上最严格《通用数据保护条例》(GeneralDataProtectionRegulation,GDPR) 的正式生效,定义了个人数据安全监管和保护新的要求高度,企业必须将用户个人的IP 地址或Cookie数据等信息置于和其他机密数据(姓名、地址以及社会安全号码等)相同的 保护等级。根据GDPR 的要求,企业在获取用户资料时被要求使用简明语言,必须说明 为什么要处理数据,谁将接收到这些数据,以及这些数据将被存储多长时间;一旦企业发 生数据泄露事件,将被处以4% 的全球营业额或2000 万欧元的罚款,同时在发现违规事 件的72 小时内,向监管当局和受到违规事件影响的个人通报数据违规行为。 而对于App,可导致信息泄露的攻击面则在日益扩大。例如,使用不安全的通信协 议,使用不安全的加密算法,应用提交数据时未对目标域名进行校验,无断网和网络异常 提示等App 漏洞是引发信息泄露的风险来源之一。 32 第3章移动终端漏洞类型 2. App 存在的共性安全问题 App 存在的共性安全问题主要包括以下6方面。 1)关键信息泄露 虽然Java代码一般要做混淆,但是Android系统的几大组件的创建方式是依赖注入 的方式,因此不能被混淆,而且目前常用的一些反编译工具(如ApkTool等)能够毫不费 劲地还原Java里的明文信息,Native里的库信息也可以通过objdump或IDA 获取。因 此一旦Java或Native代码里存在明文敏感信息,基本上毫无安全可言。 2)App 重打包 App 重打包即反编译后重新加入恶意的代码逻辑,重新打包一个APK 文件。重打 包的目的一般都是和病毒结合,对正版APK 进行解包,插入恶意病毒后重新打包并发布, 因此伪装性很强。截住App 重打包就一定程度上防止了病毒的传播。 3)进程被劫持 这个几乎是目前针对性最强的一种攻击方式,一般通过进程注入或者调试进程的方 式Hook进程,改变程序运行的逻辑和顺序,获取程序运行的内存信息,即用户所有的行 为都被监控起来,这也是盗取账号密码最常用的一种方式。 当然Hook行为不一定完全是恶意的,如有些安全软件会利用Hook的功能做主动 防御(如最新的APKProtect线上加固产品)。一般来说,Hook需要获取root权限或者与 被Hook进程相同的权限,因此如果手机没有被root,而且是正版APK,被注入还是很困 难的 4 。 )数据在传输过程中遭劫持 传输过程最常见的劫持就是中间人攻击。很多安全要求较高的App 的所有的业务 请求都要通过HTTPS,但是HTTPS 的中间人攻击逐渐增多,并且在实际使用中,证书交 换和验证在一些非主流手机或者ROM 上存在一些问题,让HTTPS 的使用受到阻碍。 5)键盘输入安全隐患 支付密码一般是通过键盘输入的,键盘输入安全直接影响了密码安全。键盘输入安 全隐患来自以下3方面。 (1)使用第三方输入法,则所有的点击事件在技术上都可以被第三方输入法截取,如 果不小心使用了不合法的输入法,或者输入法把采集的信息上传并且泄露,后果是不堪设 想的。 (2)截屏,该方法需要手机具有root权限,才能跑起截屏软件getevent,通过读取系 统驱动层dev/input/event1中的信息,获取手机触屏的位置坐标,再结合键盘的布局,就 能算出事件与具体数字的映射关系,这也是目前比较常用的攻击方式。编者之前做过一 套安全键盘的方案,就是“自定义键盘+数字”布局随机化。但是随机化的键盘很不符合 人性的操作习惯。所以之后去除了随机化。还需要说明,有一种更为安全的方式就是现 在TrustZone的标准已经有GlobalPlatform_Trusted_User_Interface,即在TrustZone里 实现安全界面的一套标准,如果安全键盘在TrustZone里弹出,则黑客无论通过什么手段 都无法拿到密码,是目前最为安全的方式,但是TrustZone依赖设备底层实现,如果设备 不支持TrustZone,或者TrustZone不支持GlobalPlatform_Trusted_User_Interface标 准,这种方式也是无能为力的。 33 6)WebView漏洞 由于现在HybridApp 的盛行,WebView在App 的使用也是越来越多,Android系统 WebView存在一些漏洞,造成JavaScript提权。最为著名的就是传说中JavaScript注入 漏洞和WebKit的XSS 漏洞。 3. 个人信息保护面临的挑战 随着大数据时代的到来,个人信息保护问题逐渐暴露。信息泄露、信息过度收集使 用、权限滥用等问题严重威胁了广大用户的切身利益。应用API 等级低、一揽子授权、不 授权不给用等现象的存在,将用户推入隐私与便利的两难选择。移动智能终端产业用户 个人信息保护工作面临严峻的挑战。 1)用户信息过度收集 主要存在以下两种方式。 (1)App 在用户不知情的情况下,过度收集和使用个人信息。大量用户反映,个人信 息在不知情的情况下被收集使用,搜索过的信息、说过的话、敏感的健康数据,以用户可感 知的方式呈现。但信息是如何被收集,通过何种渠道共享传播? 普通用户难识别、难举 证。较多应用并未通过隐私政策或其他途径告知用户收集使用信息的目的、方式和范围, 也未向用户提供明确的允许和拒绝的选择,这种累积性的权益侵害在日常生活中普遍存 在,引发了用户的严重担忧。信息过度收集使用的乱象亟待解决。 (2)应用第三方软件开发工具包(SoftwareDevelopmentKit,SDK)大量收集使用个 人信息。应用通常会使用第三方SDK 快速实现业务功能,而第三方SDK 与应用在收集 用户信息方面具有同样的能力。鉴于第三方SDK 的不开源性,应用无法完全掌控第三方 SDK 的行为。部分应用不清楚SDK 申请权限的目的,难以准确明示第三方SDK 所收集 使用的用户信息,通常只能通过协议约束第三方SDK 收集使用用户信息的行为。某些第 三方SDK 同时被多个App 集成使用,收集的海量数据一旦泄露,将造成广泛的恶劣 影响。 2)App 权限申请过度 权限是指为保护用户的隐私,移动终端操作系统对于应用访问敏感用户数据或使用 特定系统功能的限制。为满足用户可知、可控的要求,我国终端大都具备权限管理机制, 权限申请在显著位置提示,并经用户同意后方可使用。但目前权限申请过度仍是普遍 现象。 (1)权限申请过度现象严重。根据对国内应用市场Top1000 应用取样分析显示, Android应用普遍会申请电话、定位、摄像头和录音等核心敏感权限,其中读取电话状态 权限的比例为97.15%,申请摄像头权限的比例为 37%,申请位置权限的比例为84. 66.8%,申请录音权限的比例为59.申请联系人权限的比例为42. 1%, 4% 。应用过度申请 权限的问题普遍存在。申请超出应用实际业务功能和场景的权限,为应用过度收集用户 个人信息打开了通道,极易造成用户信息泄露。 (2)权限过度申请、滥用规范难判定。如何判定应用权限过度申请和滥用,存在易感 知难判定的问题。目前尚缺乏成熟的技术规范和判定手段,难以正确引导应用开发者遵 循合法正当必要原则申请权限,是智能终端产业在个人信息保护工作中面临的巨大的挑 战。如图3-9所示。 34 第3章移动终端漏洞类型 图3- 9 应用权限获取情况 3)低API等级应用规避Android系统安全机制 App与Android系统的交互依赖框架API,开发时要配置App的目标API等级以明 确App支持的Android目标系统版本。低API等级App风险高、升级难度大。Android 系统在应用运行时检查目标API等级设置,若系统版本低于或等于App的目标API等 级,系统无须进行任何兼容性处理;若系统版本高于此项配置,则系统会执行兼容性策略。 低API等级应用运行在高版本的Android系统上,可绕过Android系统的信息保护机制。 同时,Android系统针对目标API等级23及以上的App执行运行时权限机制,即业务功 能运行时系统才会授予App权限;目标API等级23以下的App采用一揽子授权,存在 不授权无法安装使用的问题。目前,我国App达到目标API等级26及以上的比例大致 为10%,推动App开发者及时适配高版本Android系统,加强移动智能终端预置与分发 环节对App高API等级的上架要求,是近期用户个人信息保护的重点工作。 4)常见的Android系统App漏洞 (1)AndroidManifest配置相关的风险或漏洞。 ①程序可被任意调试。 风险详情:Andririnfs.l中的adod: od系统AppAPK配置文件AndodMaietxmnridebuggable=true,调试开关被打开。 危害情况:App可以被调试。 修复建议:把Andrinfs.l配置文件中调试开关属性关掉, nri odMaietxm即设置adod: debugable="false"。 ②程序数据任意备份。 风险详情:Andririnfs.l中的adod: od系统AppAPK配置文件AndodMaietxmnrialowBackup=true,数据备份开关被打开。 危害情况:App应用数据可被备份导出。 修复建议:把AndrodMaietxml配置文件备份开关属性关掉,即设置adod: infs.nri alowBackup="false"。 35 组件暴露:建议使用android:protectionLevel="signature"验证调用来源。 ③Activity组件暴露。 风险详情:Activity组件的属性exported被设置为true,或未设置exported值,但 IntentFilter不为空时,Activity被认为是导出的,可通过设置相应的Intent唤起 Activity。 危害情况:黑客可能构造恶意数据针对导出Activity组件实施越权攻击。 修复建议:如果组件不需要与其他App 共享数据或交互,将AndodMaietxml rinfs. 配置文件中设置该组件为exported="False";如果组件需要与其他App 共享数据或交 互,对组件进行权限控制和参数校验。 ④Service组件暴露。 风险详情:Service组件的属性exported被设置为true,或未设置exported值,但 IntentFilter不为空时,Service被认为是导出的,可通过设置相应的Intent唤起Service。 危害情况:黑客可能构造恶意数据针对导出Service组件实施越权攻击。 修复建议:与Activity组件暴露修复建议相同。 ⑤ContentProvider组件暴露。 风险详情:ContentProvider组件的属性exported被设置为true或AndroidAPI≤ 16 时,ContentProvider被认为是导出的。 危害情况:黑客可能访问到App 本身不想共享的数据或文件。 修复建议:与Activity组件暴露修复建议相同。 ⑥BroadcastReceiver组件暴露。 风险详情:BroadcastReceiver组件的属性exported被设置为true或未设置exported 值,但IntentFilter不为空时,BroadcastReceiver被认为是可导出的。 危害情况:导出的BroadcastReceiver可以导致数据泄露或者是越权。 修复建议:与Activity组件暴露修复建议相同。 ⑦IntentSchemeURLs攻击。 风险详情:在AndrodMaiatxml设置Sheme 协议后,可以通过浏览器打开对应 infs.c 的Activity。 危害情况:攻击者通过访问浏览器构造Intent语法唤起App 相应组件,轻则引起拒 绝服务,重则可能演变对App 进行越权调用甚至升级为提权漏洞。 修复建议:App 对外部调用过程和传输数据进行安全检查或检验,配置categoryfitr, nriitn.aeoy. le添加adod.netctgrBROWSABLE 方式规避风险。 (2)WebView组件及与服务器通信相关的风险或漏洞 ①WebView存在本地Java接口。 风险详情:Android系统的WebView组件有一个非常特殊的接口addJavaScriptInterface, 能实现本地Java与JavaScript之间交互。 危害情况:targetSdkVersion使用低于17 的版本时,攻击者利用addJavaScriptInterface 这个接口添加的函数,可以远程执行任意代码。 修复建议:建议开发者不要使用addJavaScriptInterface,使用注入JavaScript和第三 方协议的替代方案。 36 第3章移动终端漏洞类型 ②WebView组件远程代码执行(调用getClasLoader)。 风险详情:targetSdkVersion使用低于17的版本,并且在Context子类中使用 addJavaScriptInterface绑定this对象。 危害情况:通过调用getClasLoader可以绕过Google底层对getClas 方法的限制。 修复建议:targetSdkVersion使用高于17的版本。 ③WebView忽略SSL证书错误。 风险详情:WebVienRciesro直接执行hnlrpoed() w调用oeevdSlEr方法时, ade.rc 忽略该证书错误。 危害情况:忽略SSL证书错误可能引起中间人攻击。 修复建议:不要重写onReceivedSslEror方法,或者对于SSL证书错误问题按照业 务场景判断,避免造成数据明文传输情况。 ④WebView启用访问文件数据。 风险详情:WebView中使用setAlowFileAcetrue),App可通过WebViw访问 私有目录下的文件数据。 s(e 危害情况:在AndriestAlowFieAs(re) od系统中,mWebViw.elcetu为默认设置。 etAlowFileAcetrulavaScrip 当ss(e)时,在Fie域下,可执行任意的Jt代码,如果绕过同 源策略能够对私有目录文件进行访问,导致用户隐私泄露。 修复建议:使用WebView.eStigs()stAlowFieAs(as禁止访问私有文 gten.elcefle) 件数据。 ⑤SSL通信服务端检测信任任意证书。 风险详情:自定义SSLX509TrustManager,重写checkServerTrusted方法,方法内 不做任何服务端的证书校验。 危害情况:黑客可以使用中间人攻击获取加密内容。 修复建议:严格判断服务端和客户端证书校验,对于异常事件禁止return空或nul 。 ⑥HTTPS关闭主机名验证。 风险详情:构造HtpClient时,设置HostnameVerifier参数使用ALLOW_ALL_ HOSTNAME_VERIFIER或空的HostnameVerifier。 危害情况:关闭主机名校验可以导致黑客使用中间人攻击获取加密内容。 修复建议:App在使用SSL时没有对证书的主机名进行校验,信任任意主机名下的 合法的证书,导致加密通信可被还原成明文通信,加密传输遭到破坏。 ⑦SSL通信客户端检测信任任意证书。 风险详情:自定义SSLX509TrustManager,重写checkClientTrusted方法,方法内 不做任何客户端的证书校验。 危害情况:黑客可以使用中间人攻击获取加密内容。 修复建议:严格判断服务端和客户端证书校验,对于异常事件禁止return空或nul 。 ⑧开放Socket端口。 风险详情:App绑定端口进行监听,建立连接后可接收外部发送的数据。 危害情况:攻击者可构造恶意数据对端口进行测试,对于绑定了IP0.0. 可发起远程攻击。 0.0的App 37 修复建议:如无必要,只绑定本地IP127.0.并且对接收的数据进行过滤、验证。 (3)数据安全风险或漏洞 0.1, ①SD 卡数据被第三方程序访问。 漏洞描述:发现调用getExternalStorageDirectory,存储内容到SD 卡可以被任意程 序访问,存在安全隐患。 安全建议:建议存储敏感信息到程序私有目录,并对敏感数据加密。 ②全局可读漏洞。 风险详情:opnltuSrname,nd方法创建内部文件时, eFieOupt(tignitmoe) 将文件设 置了全局的可读权限MODE_WORLD_READABLE 。 危害情况:攻击者恶意读取文件内容,获取敏感信息。 修复建议:开发者确认该文件是否存储敏感数据,如存在相关数据,去掉文件全局可 读属性。 ③全局文件可写。 风险详情:opnltuSrname,nd方法创建内部文件时, eFieOupt(tignitmoe) 将文件设 置了全局的可写权限MODE_WORLD_WRITEABLE 。 危害情况:攻击者恶意写文件内容,破坏App 的完整性。 修复建议:开发者确认该文件是否存储敏感数据,如存在相关数据,去掉文件全局可 写属性。 ④全局文件可读写。 风险详情:opnltuSrname,nd方法创建内部文件时, eFieOupt(tignitmoe) 将文件设 置了全局的可读写权限。 危害情况:攻击者恶意写文件内容,破坏App 的完整性;或者攻击者恶意读取文件内 容,获取敏感信息。 修复建议:开发者确认该文件是否存储敏感数据,如存在相关数据,去掉文件全局可 读写属性。 (4)私有文件泄露风险或漏洞 ①配置文件可读 。 风险详情:使用getSharedPreferences打开文件时,第二个参数设置为MODE_ WORLD_READABLE 。 危害情况:文件可以被其他应用读取,导致信息泄露。 修复建议:如果必须设置为全局可读模式供其他程序使用,需保证存储的数据是非 隐私数据或加密后存储。 ②配置文件可写。 风险详情:使用getSharedPreferences打开文件时,第二个参数设置为MODE_ WORLD_WRITEABLE 。 危害情况:文件可以被其他应用写入,导致文件内容被篡改、影响应用程序的正常运 行或更严重的问题。 修复建议:使用getSharedPreferences时,第二个参数设置为MODE_PRIVATE 。 38 第3章移动终端漏洞类型 ③配置文件可读写。 风险详情:使用getSharedPreferences打开文件时,第二个参数设置为MODE_ WORLD_READABLE|MODE_WORLD_WRITEABLE 。 危害情况:文件可以被其他应用读取和写入,导致信息泄露、文件内容被篡改、影响 应用程序的正常运行或更严重的问题。 修复建议:使用getSharedPreferences时,第二个参数设置为MODE_PRIVATE 。 禁止使用MODE_WORLD_READABLE|MODE_WORLD_WRITEABLE模式。 ④AES弱加密。 风险详情:在AES加密时,使用AES/ECB/NoPadding|AES/ECB/PKCS5Padding 模式。危 害情况:ECB是将文件分块后对文件块做同一加密,破解加密只需要针对一个文 件块进行解密,降低了破解难度和文件安全性。 修复建议:禁止使用AES加密的ECB模式,显式指定加密算法为CBC或CFB模 式,可带上PKCS5Padding填充。AES密钥长度最少是128位,推荐使用256位。 ⑤随机数不安全使用 。 风险详情:调用SecureRandom类中的setSed方法 。 危害情况:生成的随机数具有确定性,存在被破解的可能性 。 修复建议:用/dev/urandom或/dev/random初始化伪随机数生成器 。 ⑥AES/DES硬编码密钥 。 风险详情:使用AES或DES加解密时,密钥在程序中采用硬编码 。 危害情况:通过反编译获取密钥可以轻易解密App通信数据 。 修复建议:密钥加密存储或变形后进行加解密运算,不要硬编码到代码中 。 (5)文件目录遍历类漏洞 ①Provider文件目录遍历。 风险详情:当Provider被导出且覆写了openFile方法时,没有对ContentQueryURI 进行有效判断或过滤。 危害情况:攻击者可以利用openFile接口进行文件目录遍历以达到访问任意可读文 件的目的。 修复建议:一般情况下无须覆写openFile方法,如果必要,对提交的参数进行“ . /”目 录跳转符或其他安全校验。 ②unzip解压缩漏洞。 风险详情:解压ZIP文件,使用getName方法获取压缩文件名后未对名称进行校验。 危害情况:攻击者可构造恶意ZIP文件,被解压的文件将会进行目录跳转,被解压到 其他目录,覆盖相应文件,导致任意代码执行。 修复建议:解压文件时,判断文件名是否有“ . /”特殊跳转符。 (6)文件格式解析类漏洞 ①FFmpeg文件读取。 风险详情:使用了低版本的FFmpeg库进行视频解码。 危害情况:在FFmpeg的某些版本中可能存在本地文件读取漏洞,可以通过构造恶 39 意文件获取本地文件内容。 修复建议:升级FFmpeg库到最新版。 ②Janus漏洞。 asdx文件(A文件), 漏洞详情:向原始的AppAPK的前部添加一个攻击的clse.eAndrid系统在校验时计算了A文件的哈希值,并以casdx"字符串作为key保存。 o"lse.e 然后Andrilse.eB文件), "lse.e"字符串 od系统计算原始的casdx文件(并再次以casdx 作为key保存,这次保存会覆盖掉A文件的哈希值,导致Android系统认为APK没有被 修改,完成安装。APK程序运行时,系统优先以先找到的A文件执行,忽略了B文件,导 致漏洞的产生。 roiignatureSchemev 危害情况:该漏洞可以让攻击者绕过Andd系统的S1签名机 制,直接对App进行篡改。由于Android系统的其他安全机制也是建立在签名和校验的 基础上,因此该漏洞相当于绕过了Android系统的整个安全机制。 修复建议:禁止安装有多个同名ZipEntry类的APK文件。 (7)内存堆栈类漏洞 ①未使用编译器堆栈保护技术。 风险详情:为了检测栈中的溢出,引入了StackCanaries漏洞缓解技术。在所有函数 调用发生时,向栈帧内压入一个额外的被称为canary的随机数,当栈中发生溢出时, canary将被首先覆盖,之后才是EBP寄存器和返回地址。在函数返回前,系统将执行一 个额外的安全验证操作,将栈帧中原先存放的canary和.data中副本的值进行比较,如果 两者不吻合,说明发生了栈溢出。 危害情况:不使用StackCanaries栈保护技术,发生栈溢出时系统并不会对程序进行 保护。修 复建议:使用NDK编译so库时,在Andmk文件中添加“_ roid.LOCALCFLAGS:= -Wal-O2-U_FORTIFY_SOURCE-fstack-protector-al”。 ②未使用地址空间随机化技术。 风险详情:PIE全称PositionIndependentExecutables,是一种地址空间随机化技 术。当so库被加载时,在内存里的地址是随机分配的。 危害情况:不使用PIE,将会使shelcode的执行难度降低,攻击成功率增加。 修复建议:NDK编译so库时,加入“LOCAL_CFLAGS:=-fpie-pie”开启对PIE的 支持。③ libupnp栈溢出漏洞。 风险详情:使用了低于1.18版本的lbpp库文件。 6.iun 危害情况:构造恶意数据包可造成缓冲区溢出,造成代码执行 。 修复建议:升级libupnp库到1.18版本或以上 。 (8)动态类漏洞 6. ①DEX文件动态加载。 风险详情:使用DexClasLoader加载外部的APK 、JAR或DEX文件,当外部文件的 来源无法控制或被篡改时,无法保证加载的文件是否安全 。 危害情况:加载恶意的DEX文件将会导致任意命令的执行 。 40 第3章移动终端漏洞类型 修复建议:加载外部文件前,必须使用校验签名或MD5等方式确认外部文件的安 全性。 ②动态注册广播。 风险详情:使用reisterReceiver动态注册的广播在组件的生命周期里是默认导 出的。 g 危害情况:导出的广播可以导致拒绝服务、数据泄露或越权调用。 修复建议:使用带权限检验的registerReceiverAPI进行动态广播的注册。 (9)校验或限定不严导致的风险或漏洞。 ①Fragment注入。 风险详情:通过导出的PreferenceActivity的子类,没有正确处理Intent的Extra值。 危害情况:攻击者可绕过限制访问未授权的界面。 修复建议:当使用高于targetSdk19的版本时,强制实现了isValidFragment方法;当使 用低于targetSdk19的版本时,在PreferenceActivity的子类中都要加入isValidFragment。两 种情况下在isValidFragment方法中进行Fragment名的合法性校验。 ②隐式意图调用。 风险详情:封装Intent时采用隐式设置,只设定action属性,未限定具体的接收对 象,导致Intent可被其他应用获取并读取其中数据。 危害情况:Intent隐式调用发送的意图可被第三方劫持,导致内部隐私数据泄露。 修复建议:可将隐式调用改为显式调用。 (10)命令行调用类相关的风险或漏洞。 动态链接库中包含执行命令函数。 风险详情:在Native程序中,有时需要执行系统命令,在接收外部传入的参数执行命 令时没有过滤或检验。 危害情况:攻击者传入任意命令,导致恶意命令的执行。 修复建议:对传入的参数进行严格的过滤。 3333333.......2222222.......2222222行行行行行行行业业业业业业业应应应应应应应用用用用用用用安安安安安安安全全全全全全全 2020年《网络安全法》实施已逾两年,GDPR正式生效,信息安全早已上升至国家层 面,早在2018年中国人民银行发布的《关于开展支付安全风险专项排查工作的通知》,将 金融等重点行业应用安全要求推至新的高度。 1. 金融行业信息泄露隐患严重 2019年第三季度,金融类App数量约为15万款,较2019年年初增幅超过15%,同时 金融行业由于其业务的特殊性及敏感性,也是我国信息安全重点关注的行业。 2019年,Testin云测安全实验室累计扫描金融类App46273款,共发现漏洞1102160 个,平均每个金融类App存在30个漏洞。金融类App高危漏洞Top10如下。 (1)ContentProviderURI用户敏感信息泄露。 (2)不安全的ZIP文件解压。 (3)服务端证书弱校验。 (4)客户端XML外部实体注入。 41 (5)IntentSchemeURL 攻击 。 (6)WebView远程代码执行 。 (7)不安全的内部存储文件权限 。 (8)Fragment注入 。 (9)Janus签名漏洞 。 (10)不安全的SharedPreference文件权限。 如图3-10 所示,高危漏洞中出现频率最高的漏洞为ContentProviderURI 用户敏感 信息泄露。该漏洞属于组件安全范畴,是指App 在使用ContentProvider提供对外数据 访问接口时,未设置合理权限,攻击者利用此漏洞盗取账户信息及账户资金,直接危及用 户和企业的安全。Testin云测安全实验室建议可通过为导出的ContentProvider组件设 置合理的调用权限进行漏洞修复。 图3-10 金融类App 高危漏洞Top10 高危漏洞中出现频率第二的漏洞为不安全的ZIP 文件解压。该漏洞属于代码安全范 畴,是指App 在解压文件时使用ZipEntry.etName 方法。该方法返回值里面会将路径 原样返回。如果ZIP 文件中包含路径字符串 g,同时没有进行防护,继续解压缩操作,就会 将解压文件创建到其他目录中,覆盖掉敏感文件。造成敏感文件篡改,恶意代码执行等 威胁。 2. 电商行业恶意攻击行为亟待防御 电商类App 因涉及线上交易等业务且与用户账户资金密切相关,往往易成为黑灰产 业的攻击对象,恶意刷券、虚假注册套取平台奖励等事件数见不鲜,一旦App 潜在的漏洞 隐患被非法利用,造成的损失难以估量。 2019 年,经由Testin云测安全实验室漏洞扫描引擎扫描的96456 款电商App 中,共 发现漏洞3071250 个,其中高危漏洞1074587 个,高危漏洞所占比例最高,高达35%, 平均每个电商应用存在38 个漏洞。 高危漏洞中出现频率最高的漏洞为IntentSchemeURL 攻击。该漏洞属于代码安全 42