吾爱破解 - 52pojie.cn

 找回密码
 注册[Register]

QQ登录

只需一步,快速开始

查看: 12207|回复: 49
收起左侧

[Android 转帖] Android平台HTTPS抓包解决方案及问题分析

  [复制链接]
asdf1319964f 发表于 2019-12-20 08:33
本帖最后由 asdf1319964f 于 2019-12-22 18:53 编辑

Android平台HTTPS抓包解决方案及问题分析
HTTP协议发展至今已经有二十多年的历史,整个发展的趋势主要是两个方向:效率和安全。效率方面,从HTTP1.0的一次请求一个连接,到HTTP1.1的连接复用,到SPDY/HTTP2的多路复用,到QUIC/HTTP3的基于UDP传输,在效率方面越来越高效。安全方面,从HTTP的明文,到HTTP2强制使用TLSv1.2,到QUIC/HTTP3强制使用TLSv1.3,越来越注重数据传输的安全性。总而言之,HTTP协议的发展对用户是友好的,但是对开发者而言却不那么友善。
抓包是每个程序员的必修技能之一,尤其是在接口调试和程序逆向方面具有广阔的用途。但是,随着越来越多的通信协议使用加密的HTTPS,而且系统层面也开始强制规定使用HTTPS,抓包似乎是显得越来越难了。
本篇博客,主要详解Android平台下,HTTPS抓包的常见问题以及解决办法。工欲善其事必先利其器,博客中以HttpCanary作为抓包工具进行讲解。更多HttpCanary的资料,请见:github.com/MegatronKin…

  1. 抓包原理
    几乎所有网络数据的抓包都是采用中间人的方式(MITM),包括大家常用的Fiddler、Charles等知名抓包工具,HttpCanary同样是使用中间人的方式进行抓包。
    [img=1280,680]https://user-gold-cdn.xitu.io/2019/4/26/16a5a3423ad3d8f3?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img]
    从上面这个原理图,可以看出抓包的核心问题主要是两个:
    •        MITM Server如何伪装成真正的Server;
    •        MITM Client如何伪装成真正的Client。
    第一个问题,MITM Server要成为真正的Server,必须能够给指定域名签发公钥证书,且公钥证书能够通过系统的安全校验。比如Client发送了一条https://www.baidu.com/的网络请求,MITM Server要伪装成百度的Server,必须持有www.baidu.com域名的公钥证书并发给Client,同时还要有与公钥相匹配的私钥。
    MITM Server的处理方式是从第一个SSL/TLS握手包Client Hello中提取出域名www.baidu.com,利用应用内置的CA证书创建www.baidu.com域名的公钥证书和私钥。创建的公钥证书在SSL/TLS握手的过程中发给Client,Client收到公钥证书后会由系统会对此证书进行校验,判断是否是百度公司持有的证书,但很明显这个证书是抓包工具伪造的。为了能够让系统校验公钥证书时认为证书是真实有效的,我们需要将抓包应用内置的CA证书手动安装到系统中,作为真正的证书发行商(CA),即洗白。这就是为什么,HTTPS抓包一定要先安装CA证书。
    第二个问题,MITM Client伪装成Client。由于服务器并不会校验Client(绝大部分情况),所以这个问题一般不会存在。比如Server一般不会关心Client到底是Chrome浏览器还是IE浏览器,是Android App还是iOS App。当然,Server也是可以校验Client的,这个后面分析。
  2. 安装CA证书
    抓包应用内置的CA证书要洗白,必须安装到系统中。而Android系统将CA证书又分为两种:用户CA证书和系统CA证书。顾明思议,用户CA证书是由用户自行安装的,系统CA证书是由系统内置的,很明显后者更加真实有效。
    系统CA证书存放在/etc/security/cacerts/目录下,名称是CA证书subjectDN的Md5值前四位移位取或,后缀名是.0,比如00673b5b.0。考虑到安全原因,系统CA证书需要有Root权限才能进行添加和删除。
    对于非Root的Android设备,用户只能安装用户CA证书。
    无论是系统CA证书还是用户CA证书,都可以在设置->系统安全->加密与凭据->信任的凭据中查看:
    [img=1280,680]https://user-gold-cdn.xitu.io/2019/4/27/16a5cb0ef8e0bbf7?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img]
  3. Android 7.0的用户CA证书限制
    Android从7.0开始系统不再信任用户CA证书(应用targetSdkVersion >= 24时生效,如果targetSdkVersion < 24即使系统是7.0+依然会信任)。也就是说即使安装了用户CA证书,在Android 7.0+的机器上,targetSdkVersion >= 24的应用的HTTPS包就抓不到了。
    比如上面的例子,抓包工具用内置的CA证书,创建了www.baidu.com域名的公钥证书发给Client,系统校验此证书时发现是用户CA证书签发的,sorry。。。
    那么,我们如果绕过这种限制呢?已知有以下四种方式(低于7.0的系统请忽略):
    3.1 AndroidManifest中配置networkSecurityConfig
    如果我们想抓自己的App,只需要在AndroidManifest中配置networkSecurityConfig即可:
    <?xml version="1.0" encoding="utf-8"?>
    <manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
    ... >
    ...
    </application>
    </manifest>
    复制代码
    <?xml version="1.0" encoding="utf-8"?>
    <network-security-config>
    <base-config cleartextTrafficPermitted="true">
    <trust-anchors>
    <certificates src="system" />
    <certificates src="user" />
    </trust-anchors>
    </base-config>
    </network-security-config>
    复制代码
    这样即表示,App信任用户CA证书,让系统对用户CA证书的校验给予通过。更多相关信息,详见Network security configuration。
    3.2 调低targetSdkVersion < 24
    如果想抓一个App的包,可以找个历史版本,只需要其targetSdkVersion < 24即可。然而,随着GooglePlay开始限制targetSdkVersion,现在要求其必须>=26,2019年8月1日后必须>=28,国内应用市场也开始逐步响应这种限制。绝大多数App的targetSdkVersion都将大于24了,也就意味着抓HTTPS的包越来越难操作了。
    3.3 平行空间抓包
    如果我们希望抓targetSdkVersion >= 24的应用的包,那又该怎么办呢?我们可以使用平行空间或者VirtualApp来曲线救国。平行空间和VirtualApp这种多开应用可以作为宿主系统来运行其它应用,如果平行空间和VirtualApp的targetSdkVersion < 24,那么问题也就解决了。
    在此,我推荐使用平行空间,相比部分开源的VirtualApp,平行空间运行得更加稳定。但必须注意平行空间的版本4.0.8625以下才是targetSdkVersion < 24,别安装错了。当然,HttpCanary的设置中是可以直接安装平行空间的。
    3.4 安装到系统CA证书目录
    对于Root的机器,这是最完美最佳的解决方案。如果把CA证书安装到系统CA证书目录中,那这个假CA证书就是真正洗白了,不是真的也是真的了。由于系统CA证书格式都是特殊的.0格式,我们必须将抓包工具内置的CA证书以这种格式导出,HttpCanary直接提供了这种导出选项。
    操作路径:设置 -> SSL证书设置 -> 导出HttpCanary根证书 -> System Trusted(.0)
    [img=360,640]https://user-gold-cdn.xitu.io/2019/4/27/16a5a7507cf034fe?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img]
    PS. 很不幸的HttpCanary v2.8.0前导出的证书名称可能不正确,建议升级到v2.8.0以上版本操作。
    导出.0格式的证书后,可以使用MT管理器将.0文件复制到/etc/security/cacerts/目录下,或者通过adb remount然后push也可(这里稍微提一下,别在sdcard里找这个目录)。
  4. Firefox证书安装
    火狐浏览器Firefox自行搞了一套CA证书管理,无论是系统CA证书还是用户CA证书,Firefox通通都不认可。这种情况,我们需要将CA证书通过特殊方式导入到Firefox中,否则Firefox浏览网页就无法工作了。
    HttpCanary v2.8.0版本提供了Firefox证书导入选项。在设置 -> SSL证书设置 -> 添加HttpCanary根证书至Firefox 中:
    [img=360,640]https://user-gold-cdn.xitu.io/2019/4/27/16a5a7eee17e2f0c?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img]
    点击右上角复制按钮将url复制到粘贴板,然后保持此页面不动,打开Firefox粘贴输入复制的url。
    [img=360,640]https://user-gold-cdn.xitu.io/2019/4/27/16a5a81b9694b5b4?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img]
    出现下载证书弹框后,一定要手动勾上:信任用来标志网站和信任用来标志电子邮件用户。然后确定即可。
  5. 公钥证书固定
    证书固定(Certificate Pinning)是指Client端内置Server端真正的公钥证书。在HTTPS请求时,Server端发给客户端的公钥证书必须与Client端内置的公钥证书一致,请求才会成功。
    在这种情况下,由于MITM Server创建的公钥证书和Client端内置的公钥证书不一致,MITM Server就无法伪装成真正的Server了。这时,抓包就表现为App网络错误。已知的知名应用,比如饿了么,就采用了证书固定。
    另外,有些服务器采用的自签证书(证书不是由真正CA发行商签发的),这种情况App请求时必须使用证书固定。
    证书固定的一般做法是,将公钥证书(.crt或者.cer等格式)内置到App中,然后创建TrustManager时将公钥证书加进去。很多应用还会将内置的公钥证书伪装起来或者加密,防止逆向提取,比如饿了么就伪装成了png,当然对公钥证书伪装或者加密没什么太大必要,纯粹自欺欺人罢了。
    证书固定对抓包是个非常麻烦的阻碍,不过我们总是有办法绕过的,就是麻烦了点。
    5.1 JustTrustMe破解证书固定
    Xposed和Magisk都有相应的模块,用来破解证书固定,实现正常抓包。
    例如:github.com/Fuzion24/Ju…
    破解的原理大致是,Hook创建SSLContext等涉及TrustManager相关的方法,将固定的证书移除。
    5.2 基于VirtualApp的Hook机制破解证书固定
    Xposed和Magisk需要刷机等特殊处理,但是如果不想刷机折腾,我们还可以在VirtualApp中加入Hook代码,然后利用VirtualApp打开目标应用进行抓包。当然,有开发者已经实现了相关的功能。详见:
    •        github.com/rk700/Virtu…
    •        github.com/rk700/CertU…
    不过,这里CertUnpinning插件的代码有点问题,要改改。
    5.3 导入真正的公钥证书和私钥
    如果Client固定了公钥证书,那么MITM Server必须持有真正的公钥证书和匹配的私钥。如果开发者具有真正服务端的公钥证书和私钥,(比如百度的公钥证书和私钥百度的后端开发肯定有),如果真有的话,可以将其导入HttpCanary中,也可以完成正常抓包。
    在设置 -> SSL证书设置 -> 管理SSL导入证书 中,切换到服务端,然后导入公钥证书+私钥,支持.p12和.bks格式文件。
    [img=360,640]https://user-gold-cdn.xitu.io/2019/4/27/16a5a9c89641facd?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img]
  6. 双向认证
    SSL/TLS协议提供了双向认证的功能,即除了Client需要校验Server的真实性,Server也需要校验Client的真实性。这种情况,一般比较少,但是还是有部分应用是开启了双向认证的。比如匿名社交应用Soul部分接口就使用了双向认证。使用了双向认证的HTTPS请求,同样无法直接抓包。
    [img=528,133]https://www.52pojie.cn/%5Bimg=360,640%5Dhttps://user-gold-cdn.xitu.io/2019/4/27/16a5aad5a3925995?imageView2/0/w/1280/h/960/format/webp/ignore-error/1[/img][/img]
    关于双向认证的原理。
    首先,双向认证需要Server支持,Client必须内置一套公钥证书 + 私钥。在SSL/TLS握手过程中,Server端会向Client端请求证书,Client端必须将内置的公钥证书发给Server,Server验证公钥证书的真实性。
    注意,这里的内置的公钥证书有区别于前面第5点的公钥证书固定,双向认证内置的公钥证书+私钥是额外的一套,不同于证书固定内置的公钥证书。
    如果一个Client既使用证书固定,又使用双向认证,那么Client端应该内置一套公钥证书 + 一套公钥证书和私钥。第一套与Server端的公钥证书相同,用于Client端系统校验与Server发来的证书是否相同,即证书固定;第二套SSL/TLS握手时公钥证书发给Server端,Server端进行签名校验,即双向认证。
    用于双向认证的公钥证书和私钥代表了Client端身份,所以其是隐秘的,一般都是用.p12或者.bks文件+密钥进行存放。由于是内置在Client中,存储的密钥一般也是写死在Client代码中,有些App为了防反编译会将密钥写到so库中,比如S匿名社交App,但是只要存在于Client端中都是有办法提取出来的。
    6.1 双向认证抓包
    这里以S匿名社交App为例,讲解下如何抓取使用了双向认证的App的HTTPS包。
    如果服务器使用了Nginx且开启了双向认证,抓包时会出现400 Bad Request的错误,如下:
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c741df1f0b1e?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c763ccb4369c?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    有些服务器可能不会返回404,直接请求失败。
    接下来看,如何使用HttpCanary配置双向认证抓包。
    首先,解压APK,提取出.p12或者.bks文件,二进制的文件一般存放都在raw或者assets目录。
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c712cd57857e?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    将client.p12文件导入手机,然后在HttpCanary的设置 -> SSL证书设置 -> 管理SSL导入证书中,切换到客户端(因为需要配给MITM Client),然后导入.p12文件。
    由于双向认证的公钥证书和私钥是受密钥保护的,所以需要输入密码:
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c78fb7db1403?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    一般通过逆向可以从APK中提取出密钥,具体操作这里略过。输入密钥后,需要输入映射域名,这里使用通配符*映射所有相关域名:
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c7cfc76d59e8?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    导入完成后如下:
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c7e8f950b17a?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    可以点进证书详情查看细节,这个client.p12文件包含公钥证书和私钥,是用于双向认证的。
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c804628fde09?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    配置完成后,重新进行抓包,看看效果。
    https://user-gold-cdn.xitu.io/2019/4/27/16a5c82b82dcb850?imageView2/0/w/1280/h/960/format/webp/ignore-error/1
    可以看到,之前400 Bad Request的两个要求双向认证的请求成功了!
  7. SSL重协商
    有些服务器可能会开启SSL重协商,即SSL/TLS握手成功后发送请求时服务器会要求重新握手。这种情况一般比较少,但是也不排除,已知的应用比如 10000社区 就使用了SSL重协商。
    由于Android系统对SSL重协商是有限支持,所以部分系统版本抓包会失败,表现为网络异常。在Android 8.1以下,SslSocket是完全支持SSL重协商的,但是SSLEngine却是不支持SSL重协商的,而HttpCanary解析SSL/TLS使用的是SSLEngine。在Android 8.1及以上,SSLEngine和SslSocket统一了实现,故是支持SSL重协商的。
    所以,如果确认服务器使用了SSL重协商,请使用8.1及以上版本系统进行抓包。
  8. 非HTTP协议抓包
    如果确认了以上几点,HttpCanary仍然抓包失败,那么极有可能使用的并非是HTTP协议。比如像微信聊天,视频直播等,使用的就不是HTTP协议,这种情况需要使用其它的抓包工具,比如Packet Capture这种直接解析TCP/UDP协议的,但是往往非HTTP协议的数据包即使抓到了也无法解析出来,因为大概率都是二进制而非文本格式的。
  9. 结语
    抓包是个技术活儿,需要对网络协议有大致的了解,对抓包感兴趣的同学可以多查阅TCP、UDP、SSL/TLS、HTTP等相关资料。
    HttpCanary是专业的HTTP协议抓包工具,专注HTTP协议三十年(吹过头了),不过目前还不支持QUIC/HTTP3这种新协议,等QUIC/HTTP3正式应用起来再说吧。

免费评分

参与人数 15吾爱币 +15 热心值 +14 收起 理由
翟先生 + 1 + 1 欢迎分析讨论交流,吾爱破解论坛有你更精彩!
淡_碎一地 + 1 + 1 谢谢@Thanks!
pangzi + 1 谢谢@Thanks!
阿什顿放 + 1 + 1 谢谢@Thanks!
lweizhou + 1 + 1 我很赞同!
fei8255 + 1 + 1 用心讨论,共获提升!
鹤舞九月天 + 1 + 1 用心讨论,共获提升!
coolu + 1 + 1 用心讨论,共获提升!
随风丶而逝 + 1 + 1 我很赞同!
iflower + 1 + 1 谢谢@Thanks!
xueshanfeihu + 1 + 1 谢谢@Thanks!
dreamlivemeng + 1 + 1 谢谢@Thanks!
孙超 + 1 + 1 用心讨论,共获提升!
乡熊 + 1 + 1 热心回复!
He_Sumver + 1 + 1 谢谢@Thanks!

查看全部评分

本帖被以下淘专辑推荐:

发帖前要善用论坛搜索功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。

bachelor66 发表于 2019-12-20 15:54
一个图都看不到,是不是只有我是这样?                                   
狂暴补师亚丝娜 发表于 2019-12-20 13:20
随风丶而逝 发表于 2019-12-20 11:28
顺便说下JustTrustMe并没有想象中的好用,XPOSE开启JustTrustMe后,部分应用直接404了

最新版本已修复了
沅澧潇湘 发表于 2019-12-20 09:08
风尘男子 发表于 2019-12-20 09:16
看看 学习第一
愤怒的平头哥 发表于 2019-12-20 09:35
感谢大佬分享
遗忘时光 发表于 2019-12-20 09:37
存起来慢慢看
乡熊 发表于 2019-12-20 09:42
每天学习强国
ko2o3 发表于 2019-12-20 09:44
感谢楼主分享
china-ray 发表于 2019-12-20 09:48
为啥看不到图片呢?
a1327831029 发表于 2019-12-20 10:08

学习一下
孙超 发表于 2019-12-20 10:08
mark,下班再看
您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则

返回列表

RSS订阅|小黑屋|处罚记录|联系我们|吾爱破解 - LCG - LSG ( 京ICP备16042023号 | 京公网安备 11010502030087号 )

GMT+8, 2024-11-24 20:44

Powered by Discuz!

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表