最近，我们的研究人员发现了Android App使用存储资源方式的缺陷。App使用外部存储资源时的粗心大意，犹如打开潘多拉墨盒，有可能导致多种不良后果，例如不经用户同意将恶意App静默安装到用户手机，合法App导致DoS，甚至导致App崩溃，还可能为代码注入大开方便之门，使恶意代码在受攻击App的特权上下文中运行。
当App使用外部存储不多加小心时，才使得Man-in-the-Disk攻击成为可能。外部存储是一种在所有App之间共享的资源，并且不享受Android内置的沙盒保护。如果App本身在使用外部资源时未能使用安全预防措施，App就容易遭受恶意数据操纵的攻击。
什么是外部存储？
为了解释Android设计中的安全性缺陷，我们需要对Android设备上的存储资源有些了解。
在Android操作系统中，有两种存储类型：内部存储，每个App单独使用并由Android沙箱进行隔离；外部存储，一般指SD卡或存储设备中的逻辑分区，由所有App共享使用。实际上，外部存储主要用于在App之间或与PC共享文件。例如，某通讯App为了分享手机相册中的照片，App需要访问外部存储中保存的媒体文件。
但是，还有其他原因导致App开发人员选择使用外部存储而不是被沙盒保护的内部存储。例如，内部存储容量不够，为了与旧设备的向后兼容性，不希望App看起来占用太多空间，甚至只是因为开发人员比较懒。
无论原因是什么，使用外部存储时，都需要采取一些预防措施。
根据Google的Android文档，关于App开发人员如何使用外部存储是有一些准则的。这些准则包括：
- “处理来自外部存储的数据时需执行输入验证”
- “不要在外部存储上存储可执行文件或类（class）文件”
- “在动态加载之前，应对外部存储文件进行签名和加密验证”
但是，我们发现一些Android App，包括来自知名厂商甚至谷歌的App，并没有遵循这些准则。于是就导致了Man-in-the-Disk攻击面，导致任何不小心保存外部存储数据的App都有被攻击的可能。
Man-in-the-Disk 攻击
Check Point研究人员发现的新攻击面，称为“Man-in-the-Disk”，允许攻击者读取并篡改存储在外部存储器上的数据。
通过我们的研究分析，我们目睹了App从App提供商的服务器下载、更新或接收数据的情况，这些数据在发送到App本身之前会通过外部存储 – 如下图所示。这种做法为攻击者提供了在App再次读取之前操纵外部存储中保存的数据的机会。
篡改数据由看似无辜的App（例如伪造的手电筒App）来执行，其中包含攻击者的漏洞利用脚本。攻击者引诱用户下载这个看起来无辜的App，下载的App要求用户授予访问外部存储的权限，而App访问外部存储是非常正常的，并且不太可能引起用户怀疑。从那时起，攻击者能够监视用户设备上的任何其他App与外部存储之间传输的数据，并及时用它自己的数据覆盖之，从而导致受攻击App的执行恶意行为。
通过这种方式，攻击者可以通过“Man-in-the-Disk”拦截用户其他App所请求的流量和信息，并提供精心构造的数据达成攻击目标。
攻击的结果可能会有所不同，具体取决于攻击者的意愿和知识水平。我们的研究证明，无需用户的许可即可在后台安装不需要的App。我们还演示了使受攻击的App崩溃，从而导致拒绝服务。一旦App崩溃并且其防御措施失效，攻击者就可通过代码注入劫持授予崩溃App的权限，并提升其自己的权限，以便访问用户设备的其他部分，例如摄像头，麦克风，联系人列表等。下图为使被攻击App崩溃的示例。
可被 Man-in-the-Disk 攻击的 App
我们针对这一新攻击面进行测试的App包括谷歌翻译、Yandex翻译、谷歌语音输入，谷歌文本转语音，小米浏览器和各种其他App。在参考了Google指南中给出的建议后，我们的团队继续将指南中建议与实际情况进行比较。
对于谷歌翻译，Yandex翻译和谷歌语音输入，我们发现开发人员未能验证从外部存储读取的数据的完整性。因此，我们的团队能够破坏这些App所需的某些文件，从而导致每个App崩溃。
App崩溃示例：通过破坏App所需的某些文件导致谷歌翻译崩溃。
小米浏览器会使用外部存储设备临时存储App的更新资源。结果就是，我们的团队能够通过替换App的更新代码，导致安装其他的、不需要的App，而不是小米浏览器的合法更新。
Man-in-the-Disk 攻击示例： 小米浏览器的更新代码被替换，导致未经用户允许安装了恶意App。
在发现这些App漏洞后，我们联系了谷歌、小米和其他易受攻击的App的供应商，以更新App，并请求供应商回复。针对谷歌各App的修复程序不久之后就发布了，其他易受攻击的App正在更新，并且一旦补丁可用，我们也会将这些App披露出来，而小米此次选择不解决此问题。
当然，应该指出的是，我们只检查了一小部分App。但我们的样本集中普遍存在这些漏洞，足以使我们相信许多其他App使用外部存储资源时也是粗心大意，也可能容易受到类似的攻击。
此外，App访问权限的数量越多，攻击者获得的权限就越多。实际上，对特权App的代码注入将获得其持有的所有特权。但令人担忧的是，我们发现制造商预装的App中包含一些易受Man-in-the-Disk攻击的App，并且这些App被授予了用户没有主动同意授予的权限，因此该制造商的每个设备都有被攻击的可能。
前因后果
由于此种攻击的细节可能看起来很复杂，让我们回顾一下导致此攻击的前因后果：
- Android设备的外部存储是公共区域，可以由同一设备上的任何其他App监测或修改。
- Android没有为外部存储中保存的数据提供内置保护，仅向开发人员提供有关正确使用此资源的指南。
- 任何开发人员都并不总是精通安全需求和潜在风险，也不总是遵循指导原则。
- 一些预装和常用的App忽略了Android指南，并在未受保护的外部存储中保存敏感数据。
- 这可能导致Man-in-the-Disk攻击，导致操纵和/或滥用未受保护的敏感数据。
- 修改数据可能会导致用户设备上出现不太美好的结果。
防范 ‘The Man’
虽然很明显这些设计缺陷使得Android用户可能容易受到网络攻击的威胁，但不太清楚的是谁是真正的过错方，谁有责任对其进行修复。一方面，虽然Android系统的开发人员已经为App开发人员制定了确保App安全的开发准则，但他们也必须意识到，App开发人员不会以安全为前提构建他们的App。另一方面，意识这一点之后，Android的开发人员是否可以多做些什么，来保护他们的操作系统和使用它的设备？
人们可以将我们在移动操作系统领域看到的东西，等同于旧操作系统的早起雏形版本——旧操作系统在早期也常常会爆出缓冲区溢出漏洞。虽然缓冲区溢出漏洞是由各种粗心的开发人员制造的，但并不是直到操作系统和CPU制造商对此采取应对措施（引入DEP和ASLR保护措施）才避免了问题。其核心是认识到开发人员不能始终信任遵循安全准则。
从经验来看，只提供指导准则，似乎不足以让操作系统供应商们免除对App开发人员开发的App的所有责任。相反，保护底层操作系统是防止我们的研究发现的新攻击面的唯一长期解决方案。
有关此研究的完整技术细节，请访问Check Point Research。