Android 系统的安全性分析(一)--移动设备上的安全威胁

声明

  1. 最近工作上涉及到对Android系统安全性的改造,在改造之前先分析整理下目前Android系统自身的安全性;
  2. 参考了一些文章及书籍,在这里大部分是对别人描述的提炼,我挑出一些对我有用的内容整理;

0 写在前面的

    在刚接触Android时就知道他的底层内核是Linux,其实换一种理解角度的话Android系统其实类似于Linux在移动设备上的一个发行版,只是这个发行版在内核层加入了独有的驱动、在文件系统中加入了Dalvik/ART虚拟机以运行Java代码。所以,这样看来Android的安全性自然就是由虚拟机层和原生代码层这两个层面共同提供的了:

  • Android依靠底层的Linux基础设施来实现基本安全需求;
  • 针对大部分Android应用来说,它们还受到了由Dalvik/ART虚拟机执行的更高一层的安全保护;

1 系统失守的原因

    移动设备在某些方面和个人电脑有些类似,移动设备面对的威胁方面主要是:

  • 移动设备的高度便携性, 比如它们可能会被无意间放错地方,或者不小心被偷;
  • 移动设备更加私人化,更有可能会记录用户的个人隐私信息,用户私人数据就成为黑客攻击目标;

1.1 安装的APP是否可靠–本地提权

    坚固的防御常常从内部瓦解,移动设备的主要攻击向量来自它的内部不靠谱的APP。如果其中哪个应用中出现了错误的行为,或者是有意诱使你安装的恶意应用,它就能试图访问用户数据,甚至是使用于机通信的功能(比如发送诈骗短信)牟利。一般这类攻击会被归类为“本地提权”(local privilege escalation)攻击一一因为攻击发生时APP已经被安装并运行在移动设备中了,它只拥有一些受限制的权限,并想要提升自己的权限。

    为了防止出现本地提权。在默认情况下,应用将只被赋予最小权限集中的权限,除了这个最小权限集之外,所有的权限都是被禁止的。这个最小权限集中是不包括任何可能是敏感的权限的。比如,使用网络权限可能会被恶意地用来把设备中的信息传出去,因此它就不在最小权限集中。当应用需要任何一个不在最小权限集中的权限时,它就必须在Manifest文件里显式地声明,要求系统赋予它这个权限。

    从Android 4.4开始,通过引入SELinux, Android使用一个强制实施的访问控制框架,有效地把所有的进程置于沙箱里,将其束缚在可信区域内。到了Android Lollipop 版,这些框架又被进一步扩展,己经能支持对包(package)进行限制了。

    即使一个APP确实只拥有很少的一些权限,但它还是可以试图攻击它所在系统中具有安全漏洞的组件。利用这些安全漏洞,进而控制操作系统中拥有更多权限的组件特别是以root权限运行的组件。由于Android框架的实现是由极其大量的代码组成的,更底层的Linux内核中的代码更多,不可能保证每一行代码都没有问题。

1.2 用户是否可靠

    因为手机作为移动设备很容易被偷,手机需要某种方式知道当前操作自己的是不是真正的主人:

  1. 屏幕密码解锁
  2. 指纹、人脸解锁
  3. Boot Loader加锁:试想如果小偷懂IT,偷了你的手机后,用技术手段给你刷机了,你之前的密码、指纹、人脸什么的都没用了,这也是Android设备默认都会对Boot Loader加锁原因之一,同时一旦Boot Loader被解锁,整个/data分区中的数据会马上被擦除掉;
  4. 数据加密:如果到了黑客级别的高手,他会直接从底层访问闪存中的二进制数据,这种方式听着有点恐怖了,估计除非手机里有绝密级别的东西才会被这样针对;值得注意的是加密密钥是由用户锁屏密码推算出来的,而绝不能直接存储在手机中;

1.3 远程代码注入

    移动设备仍然还要面临和服务器及桌面电脑一样的远程代码注入的威胁。因为Android浏览器Webkit已被证明存在很多漏洞,虽然AOSP的代码里默认使用它作为浏览器,但是Google的Nexus和Pixel这些手机的默认factory包里的浏览器已经默认是Chrome了。

2 系统的漏洞来源

    Android的复杂性决定了它受攻击的方向太多:

            

2.1 源自Android

    这些漏洞是来自于AOSP本身的。可能位于框架的代码中,也可能位于更底层的系统守护进程中。Android中的大部分守护进程都已经惨遭被重写的命运,使它们无需拥有root权限就能正常工作,所以大部分守护进程只得到了一个系统AID。只有很少的几个守护进程(vold和lmkd)还在以root权限运行。不过从Android L 版开始,这些进程也受到了SELinux的约束,以增强Android的安全性。

2.2 源自厂商

    这些漏洞都是出现在厂商(或运营商)在设备中新增的代码或服务(比如:我就经常在系统里加一些守护进程或内置一些APP,如果我的代码不严谨,很可能存在漏洞)。这些问题没出在Android AOSP自身代码中,而是出在那些额外增加进来的组件中,而且这些组件常常还是以超出自身所需的权限运行,又没有足够的安全防护的。

2.3 源自第三方

    Android中使用了大量的其他开源项目,它们为Android提供了许多原生库(Native Library )以及系统中的守护进程(比如wpa_supplicant 、mdnsd 、racoon等),这些代码中很可能存在安全漏洞。

2.4 源自Linux

    Android非常依赖于它的基础设施——Linux,但系统安全有一句行话——“信赖往往会变成负担” 。Android不光是(几乎一字不改地)使用了Linux的内核,在大部分关键组件上照抄了Linux 。因此,在Linux内核中发现的任何漏洞,几乎都可以用来黑掉Android设备。

3 结论

    所以,Android整体的防御措施主要分布在Linux层、Dalvik层、用户层、存储四个方面,后面我再写4篇分别总结下这四个层次的安全防御措施。

发布了48 篇原创文章 · 获赞 5 · 访问量 7799

猜你喜欢

转载自blog.csdn.net/Xiaoma_Pedro/article/details/103901801