MITRE的Android安全分析精华指南

需积分: 15 73 浏览量更新于2024-07-20 收藏 997KB PDF 举报

"MITRE的Android安全精华分析报告" 这篇报告由Michael Peck、Gananand Kini和Andrew Pyles等人于2016年3月撰写，由美国国家安全局（NSA）赞助，详细探讨了Android应用的安全性，重点关注了Android应用的漏洞分析以及如何使用Android Lint检查器来提升安全性。 1. 引言报告的引言部分介绍了研究背景，强调了在移动设备中，尤其是Android平台上的应用程序安全问题日益突出。随着Android系统的广泛使用，确保应用安全变得至关重要，因为这些应用可能存储或处理敏感用户数据。 2. 使用Android Lint检查器解决应用漏洞 - **App数据传输中的漏洞**：报告指出，由于不安全的证书验证或主机名验证，应用在数据传输过程中可能会面临风险。这通常涉及到SSL/TLS连接的安全性，不正确的配置可能导致中间人攻击。 - **App数据静止时的漏洞**：不安全的文件权限设置可能导致数据在设备上被未授权访问，强调了对存储数据加密和权限管理的重要性。 - **BroadcastReceiver漏洞**：BroadcastReceiver是Android系统中一个组件，不恰当的使用可能导致隐私泄露或恶意行为，报告提醒开发者对此类组件进行严格控制。 - **原生代码的最佳实践**：报告提到了使用C/C++等原生代码时的注意事项，如内存管理和缓冲区溢出等问题，这些都可能导致安全漏洞。 3. 展示Lint检查的有效性 - **MITRE安全代码审查实践**：报告引用了MITRE的安全代码审查方法，强调了利用静态分析工具如Lint来检测潜在安全问题的重要性。 - **F-Droid**：F-Droid是一个自由和开放源码软件应用商店，报告提到它如何通过严格的审核流程来保证上传应用的安全性，这也是一种应用安全实践。 4. 应用Lint检查器而不依赖IDE集成报告讨论了如何在不依赖集成开发环境（IDE）的情况下手动运行和应用Lint检查，这对于持续集成和自动化测试流程特别有用。此报告为Android开发者提供了一套全面的指南，帮助他们在开发过程中识别并修复安全问题，确保应用符合最佳安全实践。此外，它还提醒开发者，安全不仅仅是一个技术问题，而是贯穿整个软件生命周期的过程，包括设计、编码、测试和维护阶段。

2 Addressing Android App Vulnerabilities with the Android Lint

Checker

The Android Open Source Project includes a free, open source Software Development Kit (SDK)

typically used by software developers to create Android apps. The SDK contains a code scanning

tool called lint [3]. Lint scans app code using defined rules and alerts the developer to potential

issues (including, but not limited to, security issues). Lint is integrated into Android Studio and

Eclipse, the primary graphical environments used by Android app developers. Lint is also

integrated into command-line Android app development tools such as gradle and ant. Thus,

placing checks for common app security vulnerabilities in lint enables developers to easily

identify and correct security mistakes up-front in the app development lifecycle, minimizing

security risks and costs. Lint can also be used by security assessors who have access to source

code.

We developed several new lint checks, discussed below, for common app security

vulnerabilities. Our checks were accepted by the Android Open Source Project and are included

in the Android Studio 2.0 beta release and in the current beta release of the Android Plugin for

Gradle used by the Android SDK when compiling apps from the command line. Appendix A

provides historical information, no longer needed, describing how to compile the checks as

custom rules and incorporate them into the lint tool as a plugin. Appendix B provides details of

an app with deliberately introduced vulnerabilities that we used to demonstrate the lint checks.

Figure 1 shows an example of output from the lint tool reporting a vulnerable HostnameVerifier

implementation (as described below in Section 2.1.1). In this example, the lint tool’s HyperText

Markup Language (HTML) output is shown. Lint can also output EXtensible Markup Language

(XML) or plaintext.

Figure 1: Example Lint Output Reporting a Vulnerable HostnameVerifier Implementation

2.1 App Data-in-Transit Vulnerabilities due to Insecure Certificate

Validation or Hostname Validation

Numerous efforts have documented common failures by Android apps to properly check X.509

certificates while establishing Secure Socket Layer (SSL) and Transport Layer Security (TLS)

sessions, making the network connections susceptible to man-in-the-middle (MITM) attacks:

• Fahl, et al. [4] statically analyzed 13,500 popular free apps from the Google Play Store

and found that 1,074 apps contain SSL specific code that either accepts all certificates, or

accepts all hostnames for a certificate, and thus are vulnerable to MITM attacks. They

performed a manual audit of 100 apps and found that 41 of those 100 were vulnerable to

MITM attacks.

• Sounthiraraj, et al. [5] statically analyzed 23,418 apps from the Google Play Store to

similarly search for TrustManager and HostnameVerifier issues, finding 1,453

potentially vulnerable apps. They applied dynamic analysis to those apps and confirmed

726 to be vulnerable to MITM attacks.

• FireEye [6] reviewed “the 1,000 most-downloaded free apps in the Google Play Store as

of July 17, 2014.” They found that of the 614 apps that use SSL/TLS to communicate

with a remote server, 448 use TrustManagers that do not properly check certificates,

and 50 use HostnameVerifiers that do not properly check hostnames.

• Montelibano and Dormann [7] dynamically analyzed 1,000,500 Android apps using the

CERT Tapioca tool, finding TLS-related vulnerabilities in 23,667 of the apps.

Additionally, as described by Grace et al. [8], network communications are in some cases used

by apps to dynamically download new code for the app to execute. Grace et al., found this

behavior in advertising libraries embedded into mobile apps, meaning that the app developer

may not even be aware of the functionality and its potential security impact. Successful MITM

attacks could provide remote code execution ability, as demonstrated by Ryan Welton of

NowSecure against a keyboard app running with system-level privileges on many Samsung

devices [9].

Android’s standard TLS library uses implementations of the X509TrustManager Java class

to perform certificate validation. By default, an OS-provided X509TrustManager class is

used, but apps have the ability to define and use their own X509TrustManager.

For example, app developers commonly, and legitimately, provide their own

X509TrustManager to implement certificate pinning. Certificate pinning is the practice of

defining a restricted list of trusted certificate authorities (CAs) for the app’s network connections

rather than trusting all of the CAs in the default Android trust store. While this can prevent

MITM attacks due to malicious certificates issued by rogue or compromised CAs, the risk of

implementation mistakes increases when developers provide their own X509TrustManager

instead of using the platform default implementation.

Similarly, Android’s standard TLS library uses implementations of the HostnameVerifier

Java class to ensure that the hostname asserted by the other endpoint’s X.509 certificate matches

the expected value. By default, an OS-provided HostnameVerifier is used, but apps have

the ability to define and use their own HostnameVerifier. Just as with

X509TrustManager, the risk of implementation mistakes increases when developers provide

their own HostnameVerifier implementation rather than use the platform default

implementation.

To guard against the use of X509TrustManager and HostnameVerifier

implementations that bypass the desired security checks, we wrote 4 lint checks targeting trust

management functionality. We wrote a lint check that identifies insecure X509TrustManager

implementations whose checkServerTrusted or checkClientTrusted methods do

nothing, thus causing any presented certificate chain to be trusted [10]. Acting on the suggestion

of a Google engineer who reviewed our lint checks, we additionally also wrote a lint check for

use of SSLCertificateSocketFactory.getInsecure(), which returns an

SSLSocketFactory with certificate checks disabled [11]. We wrote a lint check that

identifies insecure HostnameVerifier implementations whose verify method always returns

true, thus trusting any hostname and making the connection susceptible to MITM attacks [12].

剩余31页未读，继续阅读

深入浅出_balance

粉丝: 326
资源: 10

MITRE的Android安全分析精华指南

Android安全攻防实战(带书签目录版).pdf

i.MX Android安全指南：定制与配置详解

Android安全编码指南.docx

Android程序员指南

android开发指南

Android开发指南

android编程指南

Android学习指南

支付宝Android安全支付开发指南

支付宝安全支付服务Android开发指南

最新资源