移动安全

四种方法绕过Android SSL验证和证书锁定

移动应用程序强烈地忽略所有SSL错误并允许您随意拦截和修改它们的流量的日子已经一去不复返了。相反,大多数现代应用程序至少会检查证书是否向有效的可信证书颁发机构(CA)提供链。作为pentesters,我们希望说服应用程序,我们的证书是有效和可信的,所以我们可以中间人(MITM)它,并修改它的流量。在本博客中,我将介绍4种可用于绕过Android上SSL证书检查的技术:

  • 将自定义CA添加到受信任的证书存储区
  • 使用自定义CA证书覆盖打包的CA证书
  • 使用Frida钩住和绕过SSL证书检查
  • 冲销自定义证书代码

这些范围从相当简单到相当先进 - 这个博客将尽力涵盖每个博客,而不会陷入特定情况的细节。

SSL MITM - 为什么?

为什么我们需要特别注意移动应用程序的 SSL MITM条件?为了查看和模糊移动应用程序的Web服务调用,我们需要使用拦截代理(如BurpSuite或ZAP)。使用代理拦截SSL流量时,来自客户端的SSL连接会在代理处终止 - 无论代理发送用于标识自身的任何证书都由移动应用程序评估,就好像该代理是Web服务端点一样。默认情况下,Burp等工具生成的自签名证书不具有有效的信任链,并且如果证书无法验证为可信,则大多数移动应用程序将终止连接,而不是通过可能不安全的渠道进行连接。下面的技术都有一个共同的目标,即说服移动应用程序信任我们的拦截代理提供的证书。

技术1 - 将自定义CA添加到用户证书存储区

避免SSL错误的最简单方法是拥有一个有效的可信证书。如果您可以将新的受信任的CA安装到设备上,则这相对容易 - 如果操作系统信任您的CA,则它会信任您的CA签署的证书。

Android有两个内置证书存储区,用于跟踪操作系统(系统存储区(持有预先安装的CA)和用户存储区(持有用户安装的CA)所信任的CA)来自developer.android.com:

默认情况下,来自所有应用的安全连接(使用TLS和HTTPS等协议)信任预安装的系统CA,而针对Android 6.0(API级别23)或更低级别的应用默认情况下信任用户添加的CA存储。应用程序可以使用base-config(针对应用程序范围的自定义)或domain-config(针对每个域的自定义)自定义自己的连接。

这对我们意味着什么?如果我们试图以MITM为目标的Android 6.0或更低版本的应用程序,我们可以简单地将我们的CA添加到用户添加的CA商店。当应用程序验证我们自定义证书的信任链时,它会在信任库中找到我们的自定义CA,并且我们的证书将被信任。但是,如果应用程序的目标版本是6.0以上的Android版本,它将不会信任用户添加的CA商店。为了解决这个问题,我们可以编辑应用程序的清单并强制其将Android 6.0作为目标。目标API级别在AndroidManifest.xml文件的'manifest'元素的'platformBuildVersionCode'属性中指定。

上面的manifest元素的目标是'platformBuildVersionCode = 25',我们需要将其更改为23。

当应用程序使用此更新的清单重新打包时,它将信任用户添加的CA存储。

或者,如果需要在特定平台上运行版本,我们可以在APK的'/res/xml/network_security_config.xml'配置文件中定义特定的信任锚点。例如,以下文件定义了需要存储在/ res / raw / my_ca(来自https://developer.android.com/training/articles/security-config.html)的新的可信CA:

如果应用程序仅验证所提供的证书是有效的,则该技术应该允许您建立成功的MITM条件。

技术2 - 用自定义CA证书覆盖打包的CA证书

如果您成功将证书安装到用户添加的CA商店,该应用程序的目标是Android 6.0,并且当您尝试浏览其他受SSL保护的资源时,证书显示为有效,但该应用程序仍然死于SSL错误?开发人员有可能采取了额外的步骤来限制应用程序所信任的一组CA。回想一下技术1,我们定义了一个自定义的信任锚,并提供了一个CA证书的路径 - 这是开发者可能用来保护他们的应用程序免受SSL拦截的功能。

如果自定义证书链与应用程序一起分发,则提取APK并用我们的自定义CA覆盖提供的CA应该足以使我们的拦截证书可信。请注意,在某些情况下,可能会发生对信任链的附加验证,因此此方法可能会产生混合结果。

使用诸如APK Studio之类的工具打开APK可以使与已部署的应用程序捆绑在一起的证书显而易见。在上图中,证书位于“资产”目录下。用我们的自定义CA覆盖适当命名的'UniversalRootCA'证书应该允许我们欺骗应用程序接受我们的证书。

技巧3 - Frida Hook

如果安装自己的CA不足以成功代理SSL通信,则应用程序可能正在执行某种SSL固定或额外的SSL验证。通常,为了绕过这种类型的验证,我们需要挂钩应用程序的代码并干扰验证过程本身。这种类型的干扰仅限于根植/越狱手机,但在Frida Gadget的帮助下,现在可以测试Android应用程序,并且可以访问完整的Frida功能,而无需设备生根。

如果您以前执行过移动应用程序渗透测试,那么您可能熟悉Frida框架。完全覆盖Frida的功能不在本博客的范围之内,但是在较高层面上,它是一个允许您在运行时篡改应用程序代码的框架。通常情况下,Frida将作为独立程序在操作系统上运行 - 但这需要根植设备。为了避免这种情况,我们可以将Frida Gadget注入到目标APK中。Frida Gadget包含了Frida的大部分功能,但封装在一个动态库中,该库在运行时被目标应用程序加载,允许您测试和修改目标应用程序的代码。

要加载Frida Gadget,我们需要提取APK,插入动态库,编辑一些smali代码,以便我们的动态库是在应用程序启动时被调用的第一件事,然后重新打包APK并安装它。整个过程已经在John Kozyrakis的文档中详细记录,并且至少需要手动进行一次,以便了解所有内容如何协同工作。但为了节省时间,我们还可以使用另一种工具 - 异议。 异议自动完成整个过程,并且只需要在命令行上提供目标APK。

在此之后,我们的工作目录中应该有一个名为'test_app.objection.apk'的文件 - 异议默认情况下会将'.objection'附加到原始APK的名称。我们可以像安装任何其他APK一样安装此APK - adb install test_app.objection.apk应将其推送到我们的连接设备。在目标设备上安装了异议更改APK后,运行该应用程序应导致在应用程序启动屏幕上暂停。此时,我们可以连接到应该在设备上侦听的Frida服务器。如果您更喜欢使用Frida实用程序:

此时,您应该能够从内置的SSL固定旁路功能中受益:

技术4 - 反转自定义证书验证码

最后,开发人员可能会选择提供自己的SSL库,而不是依赖系统库来处理SSL证书验证。如果是这种情况,我们可能想要提取APK并将smali转换回Java,以便我们可以查找负责处理证书验证的代码。

使用'dex2jar',语法如下:

生成的.jar文件应该可以在您最喜欢的Java反转工具(如JD-GUI)中打开。

一旦确定了负责证书验证的代码,您就可以选择完全打补丁或使用Frida钩住所需的功能。为了避免重新构建整个应用程序,钩住负责证书验证的功能通常更高效。使用技术#3中的步骤将允许您对应用程序进行测试 - 从那里,您应该能够使用Frida命令行工具或Objection接口(无论哪个更适合您)来挂接函数。

结论

上面提到的技术应该允许您拦截Android SSL流量并绕过开发人员采用的一些更常见的防御措施。此外,这个博客还提供了对异议和Frida的简要介绍 - 绕过SSL固定和其他防御措施的能力只是抓住了这些工具提供的功能惊人的表面。我希望这个博客能够介绍各种可用于Android 移动应用程序安全测试的技术,并说明有多种方法绕过给定的安全控制的重要性。

参考:https://blog.netspi.com/four-ways-bypass-android-ssl-verification-certificate-pinning/

本文由安全周翻译。转载请注明出处

(0)

热评文章

发表评论