原文: https://www.mdpi.com/1099-4300/21/12/1136/htm#B13-entropy-21-01136

近些年来，移动设备的使用经历了快速的增长。然而，在一些情况下，开发应用程序时安全往往被忽视掉。虽然 SSL/TLS 协议存在着漏洞，但仍用于保护通信很多年了。最常见的一个漏洞就是 SSL pinning 绕过。这篇论文首先会说明一些防范 SSL pinning 绕过的保护控制。随后，介绍一些现有的 SSL pinning 绕过方法，并定义两种新的方法。我们进行一些实验来检测安全控制在广泛使用的应用中的使用，并进行 SSL pinning 绕过。最后，我们创建一个适用性框架，涉及到已实现的安全控制和实用的一些方法。这个框架为渗透测试人员和应用开发人员提供一个指南。

关键字：SSL pinning；安全；移动应用；安卓；审计；漏洞

如今，移动设备的使用不断增加，进行着和过去不到十年前习惯在 Web 服务上进行的相同的的操作[1,2]。但是，有必要在这两个环境中提供相同的安全解决方案，因为两种操作都同样重要。SSL/TLS（安全套接字协议/安全传输层协议）技术已经被广泛地用作保护互联网许多方面的基础，例如保护 HTTP 协议[3]。

在2018年，智能手机售出15.4亿部[4]。从而，智能手机数量的快速增长导致了与智能手机相关的安全威胁增加[5]。我们每天都能读到用户使用移动应用程序被骗的案例。例如，用户可能会下载到一些不受所有者控制的修改版本应用程序。在某些情况下，还检测到了应用程序的其他用户访问敏感信息。这是因为在 Web 环境中已经应用到的很多控制仍未在移动环境中考虑。此外，一些移动应用程序甚至没有实现 SSL/TLS 验证[7]。即使使用了 SSL/TLS，应用程序也可能存在漏洞被攻击，尤其是中间人（MiTM）攻击[8]。其他的攻击，例如重放攻击、窃听和会话劫持，也都很常见[3]。安全控制例如 SSL pinning 是值得做的[9]，但始终只是可选的，SSL pinning，也称作证书固定或者 SSL//TLS 验证，可以让客户端更有信心确保服务器的证书没有收到损害[10]。然而，绕过 SSL/TLS 验证是可能的。因此，SSL pinning 可以被跳过。

考虑到移动应用的特殊性，OWASP（Open Web Application Security Project）移动应用安全验证标准(MASVS) 尝试用适用于不同威胁场景的验证等级来对这些要求进行标准化[11]。移动应用安全最重要的挑战之一是保护在不安全通信信道上的数据流[12]。不安全的通信包括握手存在缺陷、不正确的 SSL 版本、脆弱协议或者个人身份信息（PII）明文通信[13]。在这篇论文中，我们解释了如何加强应用程序的安全控制，屏蔽某些方面以避免攻击。

论文首先分析了 SSL/TLS 实现的漏洞和 SSL pinning 技术的必要性。然后，我们提出了一组安全控制可以防止应用程序遭受 SSL pinning 绕过。之后，我们选择一组流行的 Android 应用程序来检查 [7] 中后一种绕过方法是否仍然有效。我们还提出了两种新的绕过方法，并且将它们应用在了应用程序组中。最后，我们定义了一个实用性框架，根据应用程序开发人员实现的安全控制来进行绕过。

论文余下的结构如下。第2节论述了本文的背景，介绍了诸如 OWASP 移动测试指南、SSL/TLS 协议、SSL pinning 技术和 SLL pinning 绕过问题的概念。第3节介绍了一组安全控制来保护应用程序不受绕过方法影响。第4节中，我们通过实验来评估我们的方法。在第5节中会对得到的结果进行分析。最后对论文进行了总结，在第6节中提出了本文的结论和以后的工作。

本节介绍了一些基本概念，以确定本文的背景。首先，介绍了面向移动应用程序的 OWASP 移动测试指南，证明了将其用作 Web 应用程序的安全模型是合理的。其次，简要地介绍了 SSL/TLS 的操作。SSL/TLS 已被使用多年，用来增加一个额外的安全层。最后会介绍一些 SSL/TLS 漏洞，从而证明本文研究的必要性。

OWASP 是一个负责制定 Web 应用程序安全标准的全球组织[14]。这样，我们可以在 OWASP 的文档中找到一些信息和方法论的来源。最著名的方法论是所谓的 Top 10，显示了最常见的漏洞。OWASP 组织针对 web、mobile 和 IoT 软件制定了安全风险 Top 10[15]。根据我们的实践，我们选择 OWASP Top 10 Mobile 作为我们的开始点。表1显示了2016年12月 OWASP Mobile Top 10，这是最新的更新[13]。

表1 OWASOP Top 10

M1 不当的平台使用
M2 不安全的数据存储
M3 不安全的通信
M4 不安全的身份认证
M5 不充分的加密
M6 不安全的授权
M7 客户端代码质量
M8 代码篡改
M9 逆向工程
M10 无关功能

如图所示，不当的平台使用被视为和安全风险联系最为密切，这类问题涵盖了移动操作系统的部分安全控制。然而，不安全通信在 OWASP Top 10 中排名第三，是一个值得考虑的重要的课题，SSL pinning 包含在此类问题中。

虽然还有其他一些方法论或者控制列表可以对移动应用程序进行评审，但我们关注在移动应用安全验证标准(MASVS) 上，它定义在 OWASP 测试指南中。最近 OWASP 移动测试指南发布在了它的第一版中[11]。这份指南中定义了安全控制，可以根据不同的类别来进行评审，指南中说明了每个控制以及展示了如何去测试它。最终，指南有时会提供控制描述的问题的解决方案，但是解决方案必须根据审计的系统或者解决方案来调整。

在 OWASP 的控制中，有几个控制层必须被考虑，这些层的使用取决于应用程序。这里有三个层，称为验证等级：L1，标准安全；L2，深度防御；和 R，对抗逆向工程和防篡改的弹性。

所有的控制都被按类别进行了分组，在每种类别中，必须应用上不同的安全控制。让我们把注意力放到 V5 类上，即网络通信需求。为了保证网络通信的安全，我们应该遵循表2中所示的建议。

表2 网络通信安全验证要求

5.1 数据在网络中使用 TLS 加密，应用程序始终全部使用安全信道
5.2 TLS 的设置符合当前最佳的做法，如果移动操作系统不支持建议的标准则尽可能做到接近
5.3 安全信道建立后，应用程序验证远程终端的 X.509 证书，只接受由可信 CA 签名的证书
5.4 应用程序使用自己的证书库，或者固定终端证书或者公钥，如果提供了一个不同的证书或密钥将不会建立连接，哪怕是由可信 CA 签名的
5.5 应用程序不会依赖一个不安全的通信信道（email 或 SMS）进行重要的操作，如注册和账号恢复

为了实现 L1 等级的要求，必须确保有控制 5.1-5.3，控制 5.4 和 5.5 对应 L2 等级。但是完成控制 5.4 的要求意味着前三个控制都被完成，因此实现控制 5.4 意味着达到了 L1 等级，在练习中，我们能用 SSL pinning 来认识这个控制。

安全套接字（SSL）[16]协议和安全传输层（TLS）[17]协议被广泛地使用在数据通信中用来提供机密性、身份认证和完整性。SSL/TLS 提供了三种主要的安全服务：通过加密数据来实现机密性；通过消息认证码（MAC）来实现消息完整性；通过数字签名来实现身份认证。

SSL/TLS 允许双方进行身份验证、使用未经身份验证的客户端进行服务器身份验证以及完全匿名。客户端和服务器的身份验证可以通过数字签名进行。目前，数字签名大多基于证书（即X.509标准）或共享密钥。在使用证书的情况下，必须始终对证书进行验证，以确保其是由可信证书颁发机构（CA）进行的正确签名。另一方面，这些协议还通过使用 Diffie-Hellman 从 SSLv3.0，TLSv1.0 和更高的版本进行密钥交换来提供匿名身份验证[18]。

SSL/TLS 协议基于客户端和服务器都使用的握手序列，如下所示：（1）协商数据传输过程中使用的密码组，并交换随机数（主密钥）；（2）在客户端和服务器之间建立和共享会话ID；（3）向客户端验证服务器；（4）向服务器验证客户端。

有几个提供程序被广泛使用，比如JSSE（Java安全套接字扩展）[20]、OpenSSL[21]、LibreSSL[22] 或 GnuTLS[23]。甚至还有内置 SSL/TLS 解决方案的特定硬件，比如 iOS 设备[24]。

如上所述，OWASP确定的 Top-3 风险之一就是由于 SSL/TLS 信道配置不当而导致的不安全通信。然而，SSL/TLS 并不是一个没有漏洞的协议[25]。SSL/TLS 攻击可能来自中间人攻击、不良握手或者 SSL 实现。此外，大多数 Android 应用程序使用的 Android 提供的默认的 SSL 实现[25,26]。类似地，大多数应用程序很受到中间人攻击被拦截通信。因此，SSL/TLS 的实现可以被中间人攻击破坏[15]。当客户端位于公共网络中时，攻击者可能会处于通信中间冒充服务器。中间人攻击是由于协议中缺少验证或验证不正确而发生的。

在 SSL/TLS 中，会验证服务器证书来检查它们是否由正确的 CA 签名的。如果使用欺骗性的证书进行中间人攻击，则 SSL / TLS 可能会被误导（见图1）。 如果这个过程是由一个有效的欺骗性证书来完成的，那么客户端系统会检查该证书也会认为它是有效的，然后攻击者就可以捕获到在客户端和服务器之间交换的所有明文数据，尽管证书的来源未知但仍会被信任。一旦证书被接受并且完成握手，SSL / TLS 通信就会安全建立。同时，第三方绕过了信道，进行拦截和解密通信中的所有数据包。

图1：使用欺骗性的证书来绕过 SSL/TLS

Pinning 技术或 HTTP 公钥固定（HPKP）[7]已出现在过去几年中，它作为一种安全控制来加强基于HTTPS的固定来抵御中间人攻击。SSL pinning 技术被广泛用来作为一种强化移动应用程序 SSL/TLS 通信安全性的补充[9]。

图2显示了 SSL pinning 的实现过程，该过程分为两个阶段。在第一阶段，移动设备必须启动与服务器的通信。无论服务器是否处于活动状态，都会做出响应（图2中的 server hello）。然后，当服务器回答其证书和公钥信息的内容时（图2中的 server certficate），客户端请求服务器的证书。

图2：证书验证过程和固定

第二阶段称为 pinning。移动设备，从服务器接收证书后会一个遵循验证过程。 当客户端从服务器收到消息时，会使用存储在客户端中的服务器公钥来检查消息的真实性。接收到的公钥必须与存储的公钥匹配上。如果一致，客户端将启动协商或者发送使用该公钥签名的包，若不一致时，客户端将切断通信，不会向服务器发送任何内容。

SSL pinning 技术已经被证明是对付中间人攻击的很好的对抗措施[27,28,29]。文献中的大部分工作集中在对 SSL/TLS 实现的改进上。通常使用 SSL pinning 技术来抵抗安全通信脆弱与默认的实现以及中间人攻击。然而SSL固定技术并非无懈可击的，因为它可以被绕过。

当 SSL Pinning 没有被很好地实现时候也很容易受到攻击。尽管绕过技术在专业领域中是众所周知的，但是关于绕过 SSL pinning 的研究并不多。 Andzakovic 使用逆向工程在 Android 上绕过了 SSL pinning，但绕过技术只能应用在那一个应用程序上[30]。Sierra 和 Ramirez [31]也使用了不同的技术来绕过证书固定，但是只能通过动态库操作来实现。D'Orazio et Choo 为 iOS 上的 SSL 绕过定义了五种方法，并且他们的研究是我们的起点[7]。最后，Anthi 和 Theodorakopoulos 使用了一些技术来绕过 iOS 和 Android 中的 SSL 验证，但只能绕过 iOS 应用程序中的 SSL 验证[5]。此外，还可以使用几种方法绕过 SSL 固定：

动态分析代码。提取正在内存中执行的代码，并对其行为进行底层分析，如评估寄存器、内存中加载的数据和函数等等。动态分析工具的一个例子就是 Xposed 框架下的 SSL Unpinning，此工具利用了已知的 SSL pinng 实现代码。通常 pinning 开发人员会使用众所周知的或者通用的模板，在这种情况下，攻击者可能会猜测到这一点并在 pinning 阶段使用 SSL Unpinning 来绕过 SSL Pinning。此外，诸如 Frida 或 cypcript 之类的工具可以在运行时修改一些 pinning 的函数。

静态分析代码。它包括在非运行时提取和分析应用程序代码。正如我们要在第3节中所解释的，如果 pinning 没有实现防篡改或修改 pinning 会产生异常，则可以通过替换 SSL Pinning 函数来绕过 pinning 过程。

一定的抵抗措施，例如安全控制，可以帮助应用程序避免 SSL pinning 过程被绕过。借助四种安全措施或控制措施，应用程序可以防御 SSL 绕过，在这里我们将介绍一些好的/最佳的实践或指导原则作为几个步骤的集合，来实现安全 SSL Pinning 的一个充分的安全解决方案。这样，绕过 SSL pinning 就是可以避免的。虽然 OWASP 建议使用一个组合控制来保证信道的通信，但我们的指南演示会证明并确保只需三个步骤就可以加强移动固定，以防止 SSL pinning 绕过，并且不再需要检查更多的控制。

建议的过程（在 BPMN 中，+ 符号表示任务的并行执行）如图3所示，其中给出了保护应用程序免受 SSL pinning 绕过所采取的必要措施。在应用程序的实现阶段，必须要实现的有 root 检测、调试检测和防篡改措施。最后，代码也必须是混淆过的。所有这些安全措施都应该用来保证SSL pinning 不会被绕过，下面将详细介绍它们。

图3 保证 SSL Pinning 的过程

Root 检测是一种安全控制，包括检查可将锁定变为超级用户模式的可执行代码块，因此，root 检测有助于防止在超级用户模式下执行代码，这种控制提高了逆向工程和防篡改过程的有效性。
有多种方法可以检测 root[32]，但是最常见的一种方法是检查 rooted 设备存在的的一些文件（即二进制文件和apk文件），例如 /system/app/Superuser.apk 或 / system / bin / su。 Code 3.1 中提供了一部分用于在执行 pinning 时检查 root 的代码。

调试检测是用于防止应用程序代码受到控制。 如果检测到设备处于调试模式，将会停止执行 pinning。这种措施阻止了攻击者看到单步跟踪代码发生的行为。同下面要说的代码混淆一样，它可以隐藏 pinning 的内部函数。我们在 Code 3. 2 中提供的函数是应用于Android 应用程序的，这段代码是对 OWASP 调试检测指南的修改，尽管还有其他方法可以检测到调试模式。
实际上，可以在调试模式下编译应用（即修改 Android Manifest 文件中相应的标签），这种情况下，整个设备并不处于调试模式，但是应用程序处于调试模式。 Code 3.2 中使用不同的函数检测调试模式：查找 Debugger 标志，检测调试器，检测是程序否由于调试而停止执行，以及检查正在运行的进程。

防篡改方案是一个重要的选择，因为任何攻击者都可以反编译应用程序并且进行重编译。就像在前面 SSL pinning 绕过部分说到的，攻击者修改应用程序的某些部分[32]，可以跳过 SSL pinning，从而使应用程序无效。
Code 3.3 中给出了一个可以包含在 Android 应用程序中的代码示例，特别是在 MainActivity 中的 onCreate 函数。在这种情况下，会在应用程序启动时检查应用程序的签名。在 iOS 中的机制与之类似，正如 Apple Security Transforms Programming Guide[33] 中所描述的。

代码混淆。如果不阻止任何攻击者去知道应用程序的代码，上述所有措施都是没有意义的。通过代码混淆，对 SSL Pinning 函数的分析或者我们之前介绍的任何一个函数的分析都会比较困难，因此代码混淆是必要的。代码混淆器可以将现有代码转换为更加难以辨认的代码，如图4所示。这样对于攻击者而言，探测到哪些是代码的关键函数会更困难。
可以看出，用字母和数字替换掉变量和函数的名称，会使猜测函数的功能变得更加困难。Code 3.4 显示了一个混淆的例子，其中变量和函数的名称都被隐藏了。

Android 和 iOS 上的许多工具都允许对代码进行混淆，比如 Android 上的 Proguard[34] 或者 iOS 上的 iXGuard[35]。
如上所述，与 OWASP 指南相比，这些安全控制是保护应用程序免受 SSL pinning 绕过的简单方法。尽管有这些安全控制，但仍可以使用几种方法来绕过 SSL/TLS 验证。

图4 混淆过程

一旦我们定义了一些加强 SSL pinning 的对策，就必须研究可以绕过这些对策的方法。 首先，我们定义一个威胁情景。其次，我们研究了现有的绕过 SSL pinning 的方法。接下来，我们提出了新的 SSL 绕过方法。最后，我们评估了我们的建议，并为使用 SSL pinning 机制的应用程序正确开发和审计提供了一些指导。

需要注意的是，应用程序客户端和服务器都不会受到攻击，通信才是目标。攻击者可以在自己的设备上安装应用程序，反编译应用程序，篡改应用程序，重编译应用程序，并使用自己的证书对其进行签名。服务器不会验证新证书，但应用程序会。攻击者可以拦截通信，查看通信是如何实现的，以及篡改应用程序。因此，信息的完整性受到损害。图5显示了威胁场景。

图5 威胁场景

例如，如果客户使用应用程序进行付款，则可以绕过 SSL pinning，通过中间人攻击查看通信是如何实现的（如果未进行加密），并修改付款金额。显然，该应用程序的其他功能也是可以修改的。

如2.3节中说到的，中间人攻击可以破坏 SSL/TLS pinning。Burp Suite 或 Charles Proxy 等工具可以用于这些攻击。D'Orazio 和 Choo [7]定义了五种方法来绕过 iOS 设备中内置的 SSL/TLS 验证。他们尝试在40个流行的 iOS 应用程序中绕过 SSL/TLS 验证，但令人惊讶的是，只有10个应用程序使用了 SSL/TLS 验证。使用的五种方法如下所述：

D'Orazio 和 Choo 的实验结果显示在表3中。表中的选中标记表示使用该方法绕过了 SSL / TLS 的实现，破折号则意为未绕过。但是，我们必须强调和结果有关的两个方面：（1）作者避免了第3节中介绍的安全控制的检查；（2）测试仅在iOS应用程序中进行。

表3. D'Orazio 和 Choo [7]绕过 SSL / TLS 应用程序的概要。

我们提出了两种新方法来绕过 Android 设备中的 SSL / TLS 验证以作为一种新的贡献。第一种方法处理 rooted 设备，第二种方法处理 non-rooted 设备。由于将新方法会与4.2节中定义的方法进行比较，我们将新方法分别命名为方法6和方法7。方法6和方法7使在调试模式下进行 SSL pinning 绕过成为可能。

要执行此方法，需要使用一个 rooted 手机和一个远程主机。该过程如下所述：

手机运行一个服务来当作动态代码解释器，作为守护进程服务，可以与设备的物理内存进行动态交互，这样就可以操纵和改变正在执行的应用程序的行为了，也就是说这个服务的目的是操纵或者改变 SSL pinning 过程的预期行为。在我们的例子中，用下面的命令来使用 Frida 服务：

我们应该确认守护进程服务是正在运行着的，并且有足够的权限来读取和操作设备的内存。为此，可以通过以下命令使用 Frida 框架：

图6显示了 Frida 服务如何在模拟器中运行。

一旦守护进程服务在设备上运行起来，就可以访问设备的物理内存了。这样，我们可以在内存中做出适当的更改来绕过 SSL Pinning 方法。有必要指出的是，应用程序代码的必须是在内存中动态地进行修改，为此必须在服务上运行脚本。在下面，我们对在内存中动态修改代码的脚本步骤进行说明。因此，目标应用程序必须和脚本一起在手机上执行才能进行动态修改代码。这里有几种脚本（https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/）。在我们的例子中，脚本会加载我们的证书，创建一个包含我们的证书的密钥库，并生成一个信任我们的密钥库中证书的 TrustManager。当应用程序初始化 SSLContext 的时候，SSLContext.init（）方法中的 TrustManager 参数会替换成我们之前创建的 TrustManager。

需要检查没有别的任何限制来阻止 SSL 握手的连接，如果是这样连接就会建立起来。最后，必须确认目标应用程序能够正常运行并且 SSL pinning 被禁用了。 图7显示了 Frida 如何截获 Twitter 应用程序执行的示例。

图6 在模拟器中运行 Frida 服务的例子

图7 Frida 拦截 twitter 应用程序的执行

如果应用程序实现了 Root 检测，就无法使用方法6了，但可以使用方法7。

执行此方法不必使用一个 rooted 手机，因为 root 检查的存在，上面在 rooted 设备进行的步骤 1-3 都是没有意义的。

因此，有必要跳过 Root 检测来禁用 SSL Pinning，想要实现这个目标，必须将方法6中使用的守护进程服务嵌入到应用程序的内部。该过程如下所述：

需要反编译目标应用程序的代码，比如可以使用 apktool。

需要在目标应用程序中嵌入守护程序，在我们的例子中，守护进程是 Frida gadget。守护程序的功能类似于方法6中的步骤1。
a. 为了把 Frida gadget 放进去，需要在 Android manifest 文件中添加网络访问权限，然后 Frida 就可以打开一个套接字了。
b. 包含 Frida 库的文件需要放在应用程序的库文件夹中。
c. 需要修改目标应用程序 mainactivity 中的 onCreate 方法，来在目标应用程序启动时强制守进程运行。

修改后的应用程序必须重新安装、启动，并且要检查功能是否正常。

从这里开始，执行方法6的步骤2-4。

总而言之，图8显示了方法6和方法7功能的流程图。

图8 方法6和方法7绕过 SSL Pinning 的功能

为了评估我们的建议，设计了一个实验。我们的实验是对表3中 D'Orazio 和 Choo 研究[7]的改进，他们的研究既不包括安全控制分析，也没有使用 Android 版本的应用程序。实验包括两个阶段：（1）检查应用程序是否包含 SSL pinning 以及是否包含其他的任何安全控制（见第3节）；（2）对前两节介绍的七种方法进行检测。 我们的实验的第一阶段是另一个新颖的贡献，第二阶段则引入了两种新的绕过方法。

为了进行第一阶段的实验，以及检查方法1-5，使用了 apktool [36]，d2j-apk-sign [37]，logcat [38] 和 SSL Unpinning [39]，这些工具可以更改证书和调试应用程序。

为了执行新提出的方法，我们使用了Frida工具包[40]。Frida 是为开发人员，安全研究人员和从事应用程序逆向工程的人们设计的框架。它可以 hook 进程来动态地修改代码，允许注入用 JavaScript 编写的脚本，以在应用程序中执行某些操作。我们使用 Frida 作为与应用程序进行交互的服务。为了探索应用执行情况，我们使用了 Objection，Objection [41]是一个可在运行时探索移动设备工具包，用于探索应用程序的执行情况。

我们使用的一组应用程序是 D’Orazio 和 Choo 的研究中使用的应用程序的 Android 版本。这些应用程序是十个在不同领域中被广泛使用。但是，其中有两个应用程序（即 ANZ GoMoney 和 CopyApp）被两个相似的或者更新的应用程序 Outlook 和 Instagram 取代。我们决定更改这两个应用程序的原因是它们在 Android 版本中并不可用，或者是在我们所在地区的使用受到了限制。

在下一个小节中，我们会介绍并分析从上述实验中获得的结果。首先，我们检查了应用程序实现了哪些安全控制。接下来，我们尝试使用上面介绍的七个方法来绕过 SSL pinning。最后，我们建立一个适用性框架，将已实现的安全控制和适用的方法联系起来。

在表4中，我们展示了应用程序是否包含 SSL pinning 机制的检查结果。此外，我们还检查了应用程序是否包含第3节中描述的安全控制。

表4 SSL pinning 和控制的检查结果

通过分析结果可以看出最突出的事实是：（1）所有应用程序都实现 SSL pinning 机制；（2）十个应用中有六个实现了 root 检测和篡改检测机制； （3）一半的应用程序实现了调试检测或混淆的安全控制。从安全性的角度来看，我们可以认为 Bank of America, NAB Bank 和 WhatsApp 是最安全的应用程序，因为它们实现了第3节中定义的所有的安全控制。尽管未实现代码混淆的安全控制，Facebook 和 Instagram 的安全性还是排在了第二。PayPal 和 MEGA 仅实现了 SSL pinning。其余的应用程序均实现两个或三个安全控制。

表5提供了 SSL pinning 绕过方法的检查结果，我们使用 符号表示正确进行了绕过，否则使用破折号。对于五个旧的绕过方法，我们仅检查表3中出现的能绕过的方法，假设其他方法仍不适用。另一方面，对于新的应用程序（即 Outlook 和 Instagram），所有方法均已检查。

表5 绕过 SSL pinning 方法的结果

通过将旧的绕过方法的结果与表5中的结果进行比较，有一些非常有趣的事实值得注意。方法1-3与 iOS 版本应用程序的结果仍然相同。在 iOS 版本中，使用方法4和5绕过了所有应用程序。然而，Android版本中 NAB Bank、Bank of America 和 WhatsApp 都没有被方法5绕过。这些应用程序以及 Facebook 和 Instagram 都没有被方法4绕过。

看下提出的新方法的结果，我们可以看到大多数易受旧的绕过方法攻击的应用程序是如何也同样被新方法绕过的。还有一些应用程序使用新方法无法绕过 SSL pinning，比如 Bank of America, NAB Bank app, Facebook, Instagram 和 WhatsApp。

总之，我们检查了五种旧的方法还有我们引入的两种新方法来绕过 SSL。

基于表5所示的结果，并在对实验进行分析之后，我们得出结论，即适用性框架是我们研究的关键贡献。该框架旨在帮助开发和审计人员正确地进行开发和检查安全通信，这是对 OWASP 指南的有用补充。我们的框架有助于简化开发和审计 Android 移动应用程序的过程。

适用性框架见表6。每个单元格根据实现的安全控制指出哪些 SSL pinning 方法是适用的。 同样，表中第一列中的安全控制实现时，如果方法无法进行 SSL Pinning 绕过就用 符号表示。下面，我们将从安全控制的角度详细解释表中的每个条目：

表6 实用性框架方法 vs 安全控制

Root 检测实现后，就不再能使用方法3和方法6，当使用的方法中有某些步骤需要设备 root 时就会这样。

防篡改安全控制会使方法2、方法5和方法7不能使用。因为这些方法需要静态地修改应用程序的代码来绕过 SSL pinning 检查。 此步骤需要重编译应用程序并对其进行签名。但是，由于我们无法访问应用程序的原始证书，防篡改控制会检测到应用程序被篡改。

反调试安全控制将会使方法3、方法4、方法6和方法7不能使用。如前所述，若检测到设备处于调试模式，将会停止执行 pinning 操作，从而不能够逐步执行应用程序的代码。

代码混淆避免了方法5，因为混淆会阻碍对 SSL Pinning 检查函数的搜索。

另一方面，我们可以从方法的角度来阅读该表：

这表明需要实施所有建议的安全控制来停止所有SSL Pinning 绕过的方法。值得注意的是，方法1和实用性框架是无关的。方法1被证明已过时，因为方法1易于实现，并且大多数应用程序开发人员可能会通过更改检查证书的方式来避免使用方法1，因此方法1实际上是无效的。在2019年，随着 SSL pinning 检测的发展，SSL pinning 绕过中不能考虑更改证书中的 CM，在任何情况下它均不再适用。 此外，我们应该指出，即使一个安全控制没有被绕过，我们也不能保证该控制是完全安全的，如果攻击者有足够的时间，则很有可能会绕过这个安全控制。审计人员或开发人员应该评估 SSL 绕过的潜在风险。

适用性框架提供了具有两个目标的指南：（1）学习 SSL pinning 的绕过方法来检查安全控制应该在什么时候实现；（2）学习实现安全控制来对抗 SSL pinning 绕过方法。因此，可以根据要行动的视角在两个方向上解读表格。例如，如果一个渗透测试者想要检查一些安全控制，则该框架提供了要使用的 SSL pinning 的绕过方法。另一方面，如果开发人员希望应用程序免受不同的 SSL pinning 绕过方法的影响，则应实现一组安全控制。

总之言之，该框架包括两个维度：安全控制和绕过 SSL pinning 的方法。第一个维度从应用程序开发人员的角度描述了建议用于增强 SSL pinning 机制安全性方法。第二维涉及根据应用程序场景和实现的控制来绕过 SSL pinning 的方法，这个维度对审计人员来说是有用的。研究一组应用程序关于安全控制和方法的结果得到了上面所示的适用性框架。实验结果支持表6中给出的结果。例如，应用程序 Bank of America 和 WhatsApp 的案例表明，所有安全控制措施的正确实现可以防止我们使用的任何方法中给绕过。否则，应用不正确的安全控制会打开了一扇门，可以使用一组方法来绕过 SSL pinning。

如今，移动技术的使用在呈指数增长。由于大多数应用程序都需要与外部服务进行通信，移动应用程序市场正在产生新的安全威胁。实际上，不安全的通信在 OWASP Top 10 中排名第3，因此这也是一个非常重要的课题。当前，应用程序的使用至少与访问互联网一样普遍，保护这些应用程序以确保信息的机密性和完整性至关重要。在这一方面，我们向应用程序开发人员和渗透测试人员提供了在 Android 应用程序通信中加强安全性的指南。

在这篇论文中，我们展示了即使是使用了 SSL pinning 技术，SSL/TLS 的实现也是容易遭受攻击的。这样，必须采取一些措施来保护应用程序免受 SSL pinning 绕过。在应用程序的实现阶段，必须实现 root 检测、调试检测和防篡改措施，最后代码也必须要被混淆。

我们还研究了绕过这些对策的方法。首先，我们研究了现有的绕过 SSL pinning 的技术。作为安全审计人员和顾问的一条业务线，绕过技术在专业领域内是众所周知的，但在学术界很少看到它们。因此，我们试图填补这一研究的空白。这篇论文主要的贡献和价值在于介绍了五种已知的方法，并增加了两种新的绕过 SSL pinning 的方法，提出了一些开发人员可以用来避免这种情况的解决方案，并开发了一个适用性的框架。这个框架对开发人员和安全审计人员来说像指南一样有用。

一共介绍了5种方法：更改证书中的 CM、在应用程序中嵌入 CA、使用 SSL Unpinning、调试应用程序和修改应用程序的可执行文件。然后，我们提出了两种新的方法来来绕过 Android 设备中的SSL/TLS验证。第一种方法用在 rooted 设备上，第二种方法用在 non-rooted 设备上。最后，我们设计了一组应用程序的实验来评估我们的建议。实验分为两个阶段：（1）检查 app 是否有 SSL pinning 和是否包含任何安全控制；（2）检查本文提出的七种方法。我们使用的应用程序包括十个广泛应用于不同领域的应用程序。

结果显示了 Android 版本的应用程序是否实现了与 iOS 版本一样的安全控制。此外，新的绕过方法可以作为旧绕过方法的补充。

最后，我们提出了一个适用性框架作为我们研究的一个重要贡献。该框架旨在帮助开发人员和审计人员正确开发和检查安全通信，作为 OWASP 指南一个有用的补充。我们的框架有助于简化 Android 移动应用程序的开发和审计过程。适用性框架提供了一个具有两个主要目标的指南：（1）学习 SSL pinning 的绕过方法来检查安全控制应该在什么时候实现；（2）学习实现安全控制来对抗 SSL pinning 绕过方法。从开发人员和安全审计人员的角度来看，这个框架都很很有帮助。此外，适用性框架表明需要实现所有建议的安全控制来停止所有的 SSL pinning 绕过的方法。适用性框架的评估将是我们以后研究的一部分。

现在已经完成了演示如何绕过 SSL pinning来攻击通信的完整性，我们也提供了一些机制来防止这些攻击。

F.J.R.-L. 在论文的所有阶段都做出了贡献；A.J.V.-V. 构思和设计了实验，分析看结果并撰写论文； J.R., J.L., 和 A.C. 分析了数据和结果并撰写了论文。

这项工作由塞维利亚大学"红色情报中心"资助，部分资金由西班牙科学和技术部通过ECLIPSE（RTI2018-094283-B-C33）提供，安达卢西亚委员会通过 METAMORFOSIS 项目和欧洲区域发展基金（ERDF/FEDER）提供。

所有作者都同意了手稿的最后内容，作者未报告潜在的利益冲突。

在这项工作中进行的实验是严格为学术目的进行的。

©2019年作者所有。许可证持有人 MDPI, Basel, Switzerland。本文是在知识共享署名（CC BY）许可的条款和条件下发布的开放获取文章(http://creativecommons.org/licenses/by/4.0/)

[注意]APP应用上架合规检测服务，协助应用顺利上架！