Danger is My Middle Name – Experimenting with SSL Vulnerabilities in Android Apps 阅读笔记

这篇文章是关于Android app上的信息泄露和SSL脆弱的研究。对100个流行的联网app使用静态分析和动态分析，实验表明32/100的app同意全部certificates和hostnames，有4个app对传输的敏感数据没有加密。进行中间人攻击实验，发现91%的app是易受攻击的，攻击者可以获取敏感信息包括证书、文件、个人资料、信用卡账号等等。

 

1        INTRODUCTION

静态分析：用dex2jar反编译

动态分析：模拟a b c三种中间人攻击的场景（详见3     METHODOLOGY）

 

实验结果：93/100的app带有SSL，78/93使用定制的SSL编码

ü  静态分析结果：一半app同意所有certificates，另一半fail hostname verification

ü  动态分析结果：9/10的app在攻击场景a)建立了HTTPS链接；1/4的app攻击场景b) c)建立了HTTPS链接；

ü  在SSL证书验证过程中受到攻击导致的故障时，只有3个app提供相关反馈指示

ü  攻击者可以访问敏感信息，包括信用卡号码、聊天信息、联系人列表、文件和凭据。

 

本文贡献：介绍了测量android app安全性的办法，表明SSL脆弱依然存在流行的app中；分析静态和动态分析结果为何不同；为开发人员提出了建议。

 

2        BACKGROUND

SSLHandshake：client和server之间信息的交换。Client验证server的身份并发送信息。验证身份包括检查server证书中的信任链，hostname和证书有效性。

 

SSLMiTM Attacks：在针对SSL的中间人攻击里，攻击者会试图破坏SSL握手阶段的证书认证环节。中间人攻击成功的条件：

ž   The client accepts all certificates as theserver’s,

ž   The client does not verify the identity ofanyone claiming to be the server,

ž   The client accepts expired certificates,（失效）

ž   The server’s certificate is forged by theadversary, （伪造）

ž   The client accepts all self-signedcertificates.

 

SSL Implementation in Android：Android SDK的android.net, android.webkit, java.net, javax.net, java.security,javax.security.cert, and org.apache.http 包提供给开发者TrustManager和HostnameVerifier接口。

TrustManager：管理所有Certificate Authorities (CA)的证书，只有根CA被Android信任。

HostnameVerifier：当一个URL的主机名与鉴定证书的主机名不匹配时，执行主机名验证。

 

SSL Pinning：SSL证书绑定，是验证服务器身份的一种方式，是在https协议建立通信时增加的代码逻辑，它通过自己的方式验证服务器身份，然后决定通信是否继续下去。它唯一指定了服务器的身份，所以安全性较高。

 

https协议验证服务器身份的方式通常有三种，一是根据浏览器或者说操作系统（Android）自带的证书链；二是使用自签名证书；三是自签名证书加上SSL Pinning特性。

 

3        METHODOLOGY

测试设备：

Nexus 4 running Android 4.4.4

Lenovo laptop running win8.1 （作为Wi-Fi Acess Point）

为了抓数据包和刺激中间人攻击，使用Wireshark和Fiddler2。

 

分析的app：100个流行app的数据集，这些app被下载1000万次以上，来自不同类别，涉及不同敏感信息，request permission for full network access。

 

静态分析：用dex2jar和JDGUI反编译app，搜索关键词比如HttpsURLConnection, HostnameVerifier, TrustManager，分析app使用的TrustManager 和 HostnameVerifier implementations。

 

动态分析：假设攻击者控制了受害者连接的Wi-Fi Acess Point，发起以下三种不同的攻击情形：

S1: The adversary has his certificateinstalled on the user’s device (to simulate this, we install a Fiddlercertificate as root CA);

S2: The adversary presents an invalid, self-signedcertificate;

S3: The adversary presents a certificate with awrong Common Name (CN) and/or SubjectAltName, signed by a root CA.

 

4        RESULTS

静态分析：93/100的app带有SSL编码，78/93使用SSL编码implement their own Trust-Manager or HostnameVerifier。

分析这93个SSL-enabled apps，48/93的app接受所有的hostnames，41/93的app的验证永远返回true，46/93的app的TrustManager接受所有的certificates。

 

结论：Majorityof SSL-enabled apps are vulnerable to MiTM attacks due to wrong hostnameverification.

Almosthalf of the apps are vulnerable as TrustManager accept invalid or self-signedcertificates.

 

动态分析：

1、通信未加密：表3是不加密地发送敏感信息的app数量。

2、中间人攻击：S1情况下（具有安装在用户设备上的证书的攻击者）91/100应用程序建立登录连接，并提供访问安全页面，泄漏了敏感信息。9/100由于SSL Pinning没有建立连接；S2情况下（攻击者有无效的证书）23/100建立连接；S3情况下（攻击者的证书带有错误的CN或者SubjectAltName）29/100的app建立连接。20/100的app在三种情况下都受到攻击。

只有3/100的app给用户提示错误信息（图a），说明由于SSL认证失败，连接被拒绝。其他的app只是不断加载页面，或者提示没有帮助的警告信息（图b）。

结论：(1)apps with correct implementation of SSL pinning are not vulnerable to

MiTM attacks;

(2)apps with a vulnerable TrustManager establish connections in the presence of anattack;

(3)apps using AllowAllHostnameVerifier or with a vulnerable HostnameVerifier alsoestablish connections.

 

5        ANALYSIS

动态分析的漏报率：由于TrustManagers和SocketFactory的实现，动态分析有一定的漏报率。例如，静态分析表明，NaïveTrustManager和FakeSocketFactory接口在7个应用程序中用于Android应用程序崩溃报告（ACRA）；然而，我们的动态分析不测试ACRA，因此，它不报告这个脆弱点。

 

静态分析的误报率：共有23个应用程序可能包含敏感TrustManagers和SocketFactory实现，动态分析没有检测到但静态分析有报告。在这之中有9个是确认漏洞，但是其他的14个是误报，这14个不是用来创建SSL会话的，可能用于测试但没有被删除的代码。