加密阶段学习了https原理，现在开始尝试破解，工具主要是burp suite， fiddler/charles与之类似。
一些概念性的东西
中间人攻击
在中间人攻击中，攻击主机通常截断客户端和服务器的加密通信。攻击机以自己的证书替代服务器发给客户端的证书。通常，客户端不会验证该证书，直接接受该证书，从而建立起和攻击机的安全连接。这样，客户端发送的数据，都会被攻击机获取和解密。
Certificate Pinning
证书锁定Certificate Pinning是SSL/TLS加密的额外保证手段。它会将服务器的证书公钥预先保存在客户端。在建立安全连接的过程中，客户端会将预置的公钥和接受的证书做比较。如果一致，就建立连接，否则就拒绝连接。
Certificate Pinning在手机软件中应用较多。因为这些应用连接的服务器相对固定，可以预先将服务器的X509证书或者公钥保存在App中。例如，苹果应用商店Apple App Store就预置了这个功能。当使用中间人工具或者Fiddler之类的工具拦截数据，就会造成应用商店无法联网的情况。
https代理抓包原理
简单来讲，就是burp充当客户端与服务端通信，得到服务端的响应之后用自己的证书充当服务端与app通信。如果app不对证书进行验证，或应用使用系统的ca信任库进行验证，而系统又安装了burp的证书，burp就可以完成中间人的角色。
破解手段
根据不同的认证过程需要使用相应的手段进行破解。
使用系统CA库的破解
安卓浏览器，Mac下的Chrome浏览器都是使用系统的信任证书做验证。另外像下面这类代码请求https，应用也是通过系统信任证书做验证。
URL url = new URL(“https://www.baidu.com/“);
HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
urlConnection.connect();
System.out.println(urlConnection.getResponseCode());
对于这种情况，将burp suite等工具的CA证书安装到系统中就可破解。如下是安卓上安装burp证书的过程。
-
导出burp CA证书
点击Proxy -> Options 在Proxy Listeners 面板处的import/export CA certificate
导出burp CA -
将证书上传到手机，直接点击就可以安装了。
PC上的firefox浏览器维护着一套受信凭据，点击 首选项->高级->证书->查看证书，在证书机构中导入就可以了，如下图
Firefox导入证书
另外burp suite出于安全考虑，每次安装都会重新生成一套CA证书，所以如果重新安装了burp，要记得将系统中的CA证书更新。
接受所有证书的app
如果应用代码中使用如下代码，则会接受所有证书(不对证书做验证)，此时直接通过代理就可以抓包。像这代码一般都是放在爬虫里抓数据的。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
static SSLSocketFactory trustAllSocketFactory() throws Exception{
TrustManager[] trustAllCerts =
new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return
null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(X509Certificate[] certs, String authType) {
}
}
};
SSLContext sslCxt = SSLContext.getInstance(
"TLSv1.2");
sslCxt.init(
null, trustAllCerts,
null);
return sslCxt.getSocketFactory();
}
|
Certificate Pinning
前几年的app虽然也都用了https协议，但只需要简单地通过设置代理就能抓到；从去年开始遇到的几个app都不能走代理抓包了，一设置代理就说网络有问题，联不上网。
通过前面的学习总算知道是怎么回事了。原来他们都使用了证书绑定技术，证书绑定简单来说就是app只信任自己内置的证书，如果服务端的证书与app内的信任证书不符，客户端主动拒绝连接，从而造成“网络无法访问”。如下是引用自stackexchange的关于证书验证与绑定的相关评论。
Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer’s “certificates to trust” store.
Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate.
So for example, if you go to google.com, your browser will trust the certificate if it’s signed by Verisign, Digicert, Thawte, or the Hong Kong Post Office (and dozens others). But if you use (on newer versions) Microsoft Windows Update, it will ONLY trust certificates signed by Microsoft. No Verisign, no Digicert, no Hong Kong Post office.
Also, some newer browsers (Chrome, for example) will do a variation of certificate pinning using the HSTS mechanism. They preload a specific set of public key hashes into this the HSTS configuration, which limits the valid certificates to only those which indicate the specified public key.
所以我们可以有以下几个方式破解：
- 李代桃僵
反编译app, 替换cer为burp的证书后重新打包。如果有反二次打包机制，可以通过xposed hook相关方法来替换证书。
另外可以从app内取出cer文件并导入浏览器，就可以用浏览器访问app的url。 - 釜底抽薪
用xposed或修改smali控制创建连接的SSLSocketFactory，使它不加载信任库。
另外app内的证书可能有两种格式
-
.cer/.der
如果是.der证书，按以下步骤- 逆向，取出.cer证书文件
- 用burp的证书替换掉app内的证书，app重新打包
-
.bks
如果是keystore文件就简单了，先取出来，如果是单向认证，用keytool把burp的证书导入使之成为truststore内的一条就可以了；
如果是双向认证，除了加入truststore或替换cer文件，还要把keystore加入burp中，添加之前需要将它转换成pkcs12格式。如下图
burp添加keystore
android 4.X通过设置wifi代理可以为所以应用设置代理，但在5.x版本中设置的wifi代理只能为浏览器使用，如果要为app设置代理需要root后安装全局代理工具(如proxydroid)。