泄露的网站证书和私钥?来做些有趣的实验吧! – 作者:MactavishMeng

网站配套有APP,因为做了SSLPinning,因此用Burpsuite代理抓包会报错:

The client failed to negotiate a TLS connection to xxx.com:443 : Remote host closed connection during handshake

既然这样,利用泄露的证书和私钥来一个“完美”中间人不就行了!

基本概念

在正式实战之前,先介绍一下接下来用到的技术中的一些基本概念:正向代理、反向代理、DNS解析和HTTPS证书。

正向代理和反向代理

代理分为正向和反向两种。

正向代理,也被称之为转发代理,是一种比较常见的代理方式。一般情况下,正向代理(转发代理)用于某个区域的网络(如公司内网)无法直接访问互联网环境,或者被墙等原因,需要借助正向代理服务器来间接的访问。需要使用正向代理的主机需要配置代理服务器的IP。

image.png

比如常用的Burpsuite,就可以看做正向代理服务器,在使用的时候需要把浏览器的代理地址配置到Burpsuite指定的IP和端口上,如默认配置的127.0.0.1:8080

反向代理是一种客户端无感知的代理方式,一般用在负载均衡或业务转发的场景中。比如某网站有两台服务器,服务器A为Web服务器,服务器B为邮件服务器。因此在总的出口上配置反向代理,对于http://example.com/web的请求就转发到服务器A,而http://example.com/mail的请求就转发到服务器B

2020-03-17_192900.png

总的来说,正向代理是隐藏客户端,对于服务器来说发起访问的是代理服务器;而反向代理是隐藏了服务端,比如上面的例子中,用户只对http://example.com有感,而对背后的两台实际处理业务的服务器无感。

反向代理的实现有很多,常见的是ApacheNginx

详细的解释可参见:代理与反向代理,以及其应用场景Nginx正向代理与反向代理

HTTPS证书

HTTPS证书如果展开细说,内容实在有点多,涉及到对称加密、非对称加密、公钥基础设施(PKI)等等概念。此处默认大家已经了解这些概念,不再过多叙述,感兴趣的可参考HTTPS系列干货(一):HTTPS 原理详解

此处需提及的是,在申请HTTPS证书后,一般会得到两个文件:.crt的证书文件,和.key的私钥文件。证书文件是会在请求的时候发到客户端的,私钥文件是用来解密客户端协商密钥的加密数据的。

DNS投毒

上文中提到过,投毒方式有很多种,当然也各有优劣。

  • DNS劫持:在实际攻击中可以使用bettercap进行DNS投毒的操作。这种方法对受害者无感,且无需接触受害者设备。

  • 修改DNS服务器:在有接触路由器或受害者设备的情况下可用此种方式。如果路由器自动分配DNS,则可以直接修改规则将分配的首选DNS设置到攻击者布置的DNS服务器的IP上。

    DNS服务器搭建,有条件可以选用Windows Server进行(原生自带),或者使用软件ISC BIND 9来进行,这类教程网上很多,在此不在赘述。

  • 修改Hosts文件:一般在本地测试或者验证的时候用这种方式,操作简单,影响面小(仅有本机会被影响)。

本次实验即选用修改Hosts文件的方式,简单快捷。

关于修改Hosts,在WindowsLinux平台不过多介绍,因为测试了Android APP,因此踩了个小坑:文件位于/etc/hosts(或/system/etc/hosts,两个路径实际相同),因为回车符\n的问题,编辑的时候可能会导致系统无法识别而解析失败。两种方法解决:

  1. 通过adb pull /etc/hosts命令将文件下载到PC、删除安卓系统中的hosts文件,用Emeditor之类的软件修改后再用adb push hosts /etc/hosts上传回去就好

  2. adb shell连接进入命令行后通过输入命令:

    echo -e \\n >> hosts
    echo 192.168.1.x www.example.com >> hosts

    来写入hosts文件。多个域名时就重复上面的命令多次即可。

攻击准备

首先,需要事先进行一些准备工作。

攻击的前提,需要获取到目标站点的私钥文件,即上节中提到的.key文件。实际的测试过程中,很幸运的在某个配置备份文件中发现了,且有效期还有一年多,足以做很多奇奇怪怪的事了~

其次,构想一下整个攻击的网络模型。由于是一个中间人攻击,因此主要有三方:受害者(victim,简称V),中间人(Man-in-the-Middle,简称M)和服务器(Server,简称S)。主要的思路是,要引导 V 的流量经过 M 转发到 S。其中 M 需要有解开HTTPS密文的能力。

image-20200326190216345

是不是乍一看觉得,这不是Burpsuite或者SSLStrip干的事吗!

但是!这些工具都有一个致命缺陷:会有“站点不安全”的警告!

image-20200324212039174

如果是日常测试,或者安全研究可以通过安装证书解决,但是其他场景下无法安装证书,或者软件做了HTTPS证书绑定,这种方式就失效了。

虽然说证书绑定可以通过各种方法绕过,比如Android App可以用Xposed框架的Just Trust MeSSL Unpinning之类的插件,但是有些情况下这些通用插件不起作用,又懒得hook(比如我)而“恰巧”获取到了网站证书……

攻击的拓扑图大致如下:

image-20200326191141220

M 上搭建反向代理,并投毒DNS,让 V 访问服务器 example.com 的时候将IP地址解析成 M 的地址。这样流量到达 M 的时候通过反向代理。

由于反向代理上配置了证书,因此在流量到达时会尝试进行密钥协商,并处理加密流量。此时,反向代理出口的流量即为明文状态,攻击者即可对此部分流量进行拦截、修改和查看等,再转发到真实服务器上。

实战

DNS投毒

上文中提到过,投毒方式有很多种,当然也各有优劣。

DNS劫持:在实际攻击中可以使用bettercap进行DNS投毒的操作。这种方法对受害者无感,且无需接触受害者设备。

修改DNS服务器:在有接触路由器或受害者设备的情况下可用此种方式。如果路由器自动分配DNS,则可以直接修改规则将分配的首选DNS设置到攻击者布置的DNS服务器的IP上。

DNS服务器搭建,有条件可以选用Windows Server进行(原生自带),或者使用软件ISC BIND 9来进行,这类教程网上很多,在此不在赘述。

修改Hosts文件:一般在本地测试或者验证的时候用这种方式,操作简单,影响面小(仅有本机会被影响)。

本次实验即选用修改Hosts文件的方式,简单快捷。

反向代理

反向代理的架设方法很多,比如利用Nginx或者Apache。由于电脑上装了xampp,本次使用Apache作为反向代理服务器。下面的配置基于xampp v3.2.4的默认配置。

  1. 将证书(后缀.crt)和私钥(后缀.key)文件复制到xampp路径下。记住这两个文件的路径。比如:

    F:\xampp\apache\conf\ssl.crt\test.crt
    F:\xampp\apache\conf\ssl.key\test.key

    这个是按照Apache默认存放证书的位置放进去的。当然放在哪不重要,因为这两个文件的位置是要在配置中指定的。

  2. 进入xampp安装目录,编辑\apache\conf\httpd.conf`文件,添加配置:

    <VirtualHost *:443>
      ServerName example.com
      ServerAlias example.com
      SSLEngine on
      SSLProxyEngine On
      SSLProxyVerify none
      SSLProxyCheckPeerCN off
      SSLProxyCheckPeerName off
      SSLProxyCheckPeerExpire off
      SSLCertificateFile "F:\xampp\apache\conf\ssl.crt\test.crt"
      SSLCertificateKeyFile "F:\xampp\apache\conf\ssl.key\test.key"
      <Proxy *>
          Order deny,allow
          Allow from all
      </Proxy>
      ProxyPreserveHost On
      ProxyRequests Off
      ProxyPass / https://example.com/
      ProxyPassReverse / https://example.com/
    </VirtualHost>

    其中example.com是目标服务器的域名,两个文件路径就是第一步拷贝进来的证书和私钥的地址。

  3. 启动Apache,此时访问https://127.0.0.1,会显示“此站点不安全”的警告,点忽略后会显示example.com(第二步中配置的域名)的内容。

这样就算反向代理配置成功。

控制流量

反向代理出口流量就是明文的了,如果不去管它,会自动被代理转发到服务端。因此这里需要一个机制去拦截、查看和修改流量,达到操纵流量的目的。

本实验在Windows平台下进行,因此使用的是Win平台的软件,Linux平台可找同类软件替换,毕竟真理是不会变的嘛。

Proxifier是一款功能非常强大的socks5客户端,可以让不支持通过代理服务器工作的网络程序能通过HTTPS或SOCKS代理或代理链。通过这个软件,可以将Apache中的流量转发出来。

关于这个软件的安装使用不过多做介绍,只说一下代理规则的配置。这里对Apache的全部流量进行拦截,因此在“应用程序”栏中填写httpd.exe(这个是Apache处理请求的进程),如下:

image-20200326200451393

流量最终是被代理到Burpsuite上,因为这款软件对数据包修改比较友好,比如RepeaterIntruder等模块都可以方便的对请求进行重放、暴破等。

流量操纵

这部分其实不用过多介绍,运行起来之后只需要在Burpsuite中查看获取的流量并进行操作即可。

至此,整个中间人过程完毕,虽然有点繁琐(反代接Proxifier再接Burp),应该可以再优化,但奈何本人才疏学浅,只能想到这种方式来利用,希望有大神可以指点。

在中间人端(M端)流量的关系如下:

image-20200326202158832

结语

这种中间人攻击的方式利用难度很大,但是可以完美的对抗证书认证类的校验,比如APP校验服务端证书。可以利用的场景也比较有限(临近网络)。

写此文的目的有两个,一是分享一下整个攻击的过程,毕竟这种类型的攻击并没有太多提及;二是提醒一下泄露了网站证书的管理员,不要以为仅仅删除了泄露出去的备份文件就安全了,证书泄露的后果还是很严重的。

来源:freebuf.com 2020-03-26 21:08:00 by: MactavishMeng

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论