英语原文共 5 页
文摘：
有超过10亿台设备运行Android操作系统。它正在全球个人、公共、私人和政府组织中使用。设备和应用程序可用性是全球维护健康应用程序和个人通信的重要组成部分，但在研究中常常被忽视。已发表的关于Android应用程序可用性威胁和漏洞的研究是有限和不完整的。关于静态分析技术用于防止和阻止Android可用性拒绝服务的研究最多只在少数论文中作为题外话进行讨论。为了填补理解上的研究空白，本文从系统层面和应用层面对Android设备拒绝服务技术进行了研究。我们的研究定量地考察了应用程序的可用性风险。这些风险被用于开发用于应用程序拒绝服务场景的Android缓解技术，并告知我们从本研究中产生的第三个贡献。在我们的第三个贡献中，我们引入了一个新的开源Android应用程序App-Nanny，作为一个监督应用程序，帮助确保应用程序在设备上公平运行。最后，我们对未来的移动可用性测试提供了一些见解，包括开发一个ChaosMonkeyApp，帮助确保设备及其运行的应用程序的坚固性和弹性。
关键字：
Android应用安全，可用性，看门狗应用，恶意软件，网络安全，静态分析，应用保姆
第一节 介绍
机密性、完整性和可用性(CIA)是应用程序及其底层系统的核心triad信息安全原则。很多(如果不是大多数的话)安全努力都集中在维护中央情报局的三合会上。
本文主要研究了三合会的可用性组成部分。机密性和完整性是应用程序首次提供服务时需要考虑的主要特性。尽管CIA triad最后提到了可用性，但它并不比其他特性更重要。可用性与机密性和完整性这两大支柱一样，都是信息安全的重要组成部分。
就Android安全性而言，关于可用性的研究很少，除了少数研究文章外，其他所有文章都讨论了可用性。最近，正如三星Galaxy Note 7电池问题、Dyn DoS攻击、WannaCry勒索软件以及最近Chrome多扩展由于网络钓鱼而受到的损害所显示的那样，可用性的丧失会使昂贵的服务变得毫无价值，浪费开发者和消费者的时间和金钱。
第二节 研究动机
总的来说，关于设备或其运行中的应用程序可以被恶意利用或受到善意保护的方式，研究并没有考察许多不同的可用性脆弱表面。检查许多攻击面可以使可用性分析更全面(例如，360度)地了解Android设备可能的攻击面，而且据我们所知，还没有对Android可用性如何受到损害进行过分析。
总的来说，可用性主要是通过期望应用程序符合基本的信任模型来解决的。应用程序被期望具有适当的行为，在许多情况下，应用程序仅仅期望它所依赖的一切也具有适当的行为。此外，还有另外两种方法可以约束同时使用权限的应用程序。首先，应用程序需要声明限制应用程序可以使用的设备API调用的权限。其次，应用程序应该使用设备内部进程间通信(IPC)的权限。然而，在2011年，Felt等人研究了Android应用程序之间的IPC消息。他们的发现之一是，大多数应用程序没有对它们的进程间通信强制执行权限。其他一些研究文章(如[7]、[2]和[1])简要介绍了某些易受攻击的API调用。这些研究考察了一种特殊的可用性可利用面，即进程间通信。
我们的研究动机是填补社区对Android应用程序如何恶意破坏设备可用性、应用程序如何恶意利用其他易受攻击应用程序的可用性以及应用程序如何防御错误设备的理解上的空白。主要发现包括开发缓解技术，通过在Android操作系统中设置防护，并要求对应用程序间和系统内的活动进行许可，从而防范这些问题。我们的第二个贡献是设计一个名为AppNanny的watchdog应用程序，用于监视设备活动，并提醒用户注意潜在的恶意设备活动。研究结果的三元重点是提高当前Android静态分析引擎发现恶意可用性问题的准确性和效率。这些可用性保护静态分析的一个有用的地方是，当开发人员将应用程序上传到谷歌市场时，自动生成一个通知谷歌Play应用程序可能引起的问题。最后一篇论文的贡献是鼓励社区开发一个ChaosMonkeyApp来实时触发可用性问题，以测试设备及其运行中的应用程序的坚固性和弹性。
第三节 应用程序级别的威胁
我们将应用程序级别的威胁表面分类为源自应用程序并仅影响设备上的应用程序的可用性攻击。此类可用性攻击的示例来自管理其他应用程序、内部应用程序通信和应用程序级共享资源。本文研究了最近的Android发行版Nougat(7.0)[4]，以考虑来自应用程序内部导致应用程序级可用性不足的可用性攻击。
3.1 Android权限脆弱
从权限角度检查可用性威胁使用自顶向下的方法，因为应用程序需要在谷歌Play Marketplace和应用程序ApplicationMan-ifest本身中声明其权限。动态分析和静态分析技术都可以使用这些知识来应用应用程序的特定于用例的漏洞分析。如果应用程序没有声明脆弱的应用程序权限，可以从恶意软件分析中取出某些类型的恶意软件，从而节省分析时间。
3.2脆弱的api
在应用程序中定位可用性问题的第二种自顶向下方法是检查应用程序是否存在易受攻击的API调用。通过检查来自Android API调用的可用性威胁非常有用，因为动态分析和静态分析技术在应用程序上应用了更精确的可用性分析指标。API调用可能在不同版本之间发生变化，并且由于设备的许多变体，很难进行研究。
3.3易受攻击的嵌入式库
许多开发人员选择使用库构建应用程序。这些库可以由开发人员、第三方或组织开发。由于鼓励开发人员重用代码，安全漏洞可能会传播。
3.4脆弱网络请求
另一个可以利用应用程序或设备的可用性的威胁面是纯文本网络流量。如果攻击者选择对应用程序进行反编译，或者监视明文网络流量，那么攻击者可以研究应用程序如何接收、清理和解释从网络接收的数据。纯文本网络请求不受应用程序传输级别的保护(例如TLS)，因此很容易受到注入和来自中间人攻击的可能的拒绝服务的攻击。一些分析库和一些应用程序依赖纯文本连接。在这种情况下，分析可能不会发送到服务，或者应用程序可能会根据收到的结果崩溃。
3.5应用程序间接口易受攻击
暴露或导出的应用程序和未许可的应用程序间通信表面可能是可用性问题的目标。两篇发表的论文在他们关于开发Android IPCs的广泛研究中脱颖而出。2012年，Kantola等人[6]提出对Android平台进行修改，通过改变输出脆弱的应用间通信表面的决策流，检测和保护本应是应用内消息的应用间消息。2011年，Felt等人创建了Com-Droid来检查应用程序的内部通信表面。
Felt等人的研究在100个应用程序、50个顶级付费应用程序和50个顶级免费应用程序中发现了不同类型的脆弱应用程序间通信问题。本文发现，许多善意信任的应用程序收到了未经许可的广播消息。此类权限的情况包括更改网络连接、设备电池级别等。在这种情况下，应用程序应该在更改其行为以匹配消息之前验证接收到的广播消息实际上是真的。我们将在第6节中讨论防御。
3.6其他脆弱威胁面
最后一组应用程序级应用程序漏洞可以分为以下几种:(1)独特的编程模式，或(2)其他特定于应用程序的问题(例如，数据库、替代语言、bug等)。在独特的编程模式情况下，程序员可以设计代码来利用设备的可用性，而不需要使用标准的系统API调用。这种技术的一个例子是编写代码来执行大量计算，以在不进行API调用的情况下消耗设备电池。在其他特定于应用程序的情况下，某些应用程序包含可能不会影响其他应用程序的可利用代码。我们将这些想法留到以后的研究中讨论，如第7节所述。
第四节 系统级的威胁
我们将系统级威胁表面分类为暴露于来自应用程序的可用性攻击的表面，这些攻击会影响设备系统级组件的可用性。此类可用性攻击的例子来自于管理设备级别的资源，如更改网络配置、禁用设备密钥保护、杀死后台进程等。系统级威胁类似于应用程序级威胁，可以使用脆弱的系统级权限进行识别。此外，系统级威胁也可以通过易受攻击的api触发。最后，应用程序和底层固件之间的脆弱操作系统交互可能存在漏洞。最后一组系统级应用程序漏洞可以分为以下几种:(1)操作系统特有的脆弱编程模式，或(2)操作系统特定的、固件或设备驱动程序特定的漏洞。在这些情况下，编写不佳的代码或有缺陷的设备组件可能会导致应用程序甚至整个设备的可用性损失。
第五节 防御解决方案
本文中描述的许多与Android相关的可用性问题都可以进行辩护。可用性防御攻击既可以发生在应用程序级，也可以发生在操作系统ievel上。回想一下，由于开发人员在任何时候都在推动应用程序更新，一个良性的应用程序可能会变得恶意，无论是否改变权限。最近的一个例子发生在2017年夏天，当时一个Chrome扩展开发人员的账户被钓鱼盗取。攻击者重写了Chrome的扩展，并把恶意劫持的扩展推给了成千上万无辜的人。我们的研究从数量上显示，见6.3.1节，顶级Android应用程序平均每月更新两次以上。
5.1系统级
有一些针对DoS的操作系统级防御解决方案。最有效的防御解决方案之一是对易受攻击的Android API的应用程序API请求进行速率限制，这样它们就不会被滥用。另一个有效的防御方案是监视设备配置更改的频率。这些防御可以编程到操作系统中，也可以开发成监视程序，如第6.2.3节所述。问题仍然是保护设备和应用程序的责任在哪里。保护是操作系统的工作吗?或者，保护是看门狗申请的工作吗?在现实中，移动设备代码的暂态特性似乎表明，由于不同的原因，责任都在这两个地方。
5.2应用程序级别
针对应用程序级别的DoS，有三种主要的防御解决方案。在第6.2.1节中描述的第一个防御是防止在internet上使用纯文本流量。第6.2.2节中描述的第二种防御是保护所有应用程序间和系统间通信(例如广播和内部IPC消息)。第6.2.3节中描述的第三种防御方法是开发一个监视流程，以帮助用户了解应用程序和系统行为。
5.2.1易受攻击的网络请求
网络请求可以通过不发送纯文本的网络流量和确保其加密满足当前标准来保护其可用性。谷歌为Android开发人员提供了一个名为usesCleartextTraffic的清单标记，他们目前声称这是在最努力的基础上获得的荣誉。谷歌API声明Web View不遵守此标志，也不能保证通过套接字类传递的内容。它还指出，应用程序开发过程中，StrictMode可用于在测试期间识别来自应用程序的任何明文流量。
5.2.2内部沟通
有几种方法可以保护应用程序之间的通信。首先，开发人员需要确定他们的通信表面是应用程序内部的还是应用程序内部的。只有内部应用程序才能导出供其他应用程序使用。其次，在应用程序开发人员决定他们的应用程序需要应用程序间通信之后，它需要保护它在暴露的表面上接收到的通信。
保护应用程序免受其他应用程序恶意代码注入的一种方法是，坚持应用程序之间以及系统和应用程序之间的消息的完整性。这可以通过在两个级别强制使用权限以及清理从进程间通信(URI、组件、活动等)接收的输入来实现。在过去几年里，对设备的广泛研究表明，许多内部通信并不符合这种最佳实践。有两类内部消息需要执行权限。首先，系统广播应该强制执行许可。系统广播可以被欺骗。如果应用程序因接收到的广播而更改其行为，则在使用前应检查未经许可接收到的广播。其次，应用程序通信(例如URI、接收者、服务和活动)在导出时应该强制执行权限。由于应用程序可以随时更新，出于安全原因，应该保留基本的保护。
5.2.3 Appnanny
保护应用程序和设备的另一种方法是创建一个应用程序来监视设备活动，即监视应用程序。对于操作系统来说，为了保持内部状态的完整性，监视进程是很常见的。与期望操作系统被防御性地重新开发以处理恶意软件不同，watchdog应用程序可以是类似于杀毒软件的有用的应用层解决方案。我们已经创建了一个名为AppNanny的开源应用程序原型，以帮助确保应用程序在设备上公平竞争，而设备在应用程序上也公平竞争。AppNanny应用程序的目的是监视操作系统更改是否发生得太频繁，如果发现这些问题发生，可以向用户发出警报。
我们开发的AppNanny原型应用程序是使用Android 7.0 Nougat编写的。我们的第一个版本的应用程序根据我们在第5节中描述的应用程序许可频率的实证分析，分析了设备上的五个常见问题。
我们选择将监视器设置为开源和用户可配置的。用户可以在设备上选择最多5个显示器。这些监视器的设计目的是提醒用户注意特定于可用性的恶意问题。发现可用性问题是一个开放的研究问题，因为我们无法识别任何现有的研究工具，这些工具是专门设计来充当设备监视应用程序的。我们保留了watchdog应用程序的裁剪，以便在不同和不同的工作负载下正确和健壮地工作。我们设计的应用程序允许用户删除和添加他们个人设备上关心的监视器。这种看门狗选择的灵活性可以节省设备电池电量，因为额外的系统工作负载消耗放电电池。
在三星Galaxy Note 7的例子中，如果系统生成适当的通知，可以通过定期分析电池活动与DoS可能引发的可用性特定问题之间的关联来触发显示器。除了直接警告用户设备上的电池活动外，应用程序还可以使用其他技术警告用户，比如向用户发送电子邮件，描述不正确的应用程序行为。更多的看门狗设计功能可以直接设计和集成到应用程序中。例如，如果应用程序连接到web门户RSS新闻提要，它可以检查特定于设备的问题(例如，嵌入到固件中的坏证书)，并在出现可用性危机之前警告用户。
5.3实证分析
我们对2016年10月谷歌Play上排名前100的免费应用程序进行了研究。我们将检查应用程序的更新频率和使用潜在危险的可用性权限检查应用程序，如下面的小节所述。
5.3.1应用程序更新频率
最近有消息称，a Chrome开发人员遭到网络钓鱼攻击，他们的开发证书也受到了损害。攻击者向所有用户
资料编号：[3797]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
