你尚未登录,仅允许查看本站部分内容。请登录使用邀请码注册
zjcqoo

流量劫持 —— 躲避 HSTS 的 HTTPS 劫持 0个回复 专栏 @ 探索

zjcqoo 发布于 2 年前

前言

HSTS 的出现,对 HTTPS 劫持带来莫大的挑战。

不过,HSTS 也不是万能的,它只能解决 SSLStrip 这类劫持方式。但仔细想想,SSLStrip 这种算劫持吗?

劫持 vs 钓鱼

从本质上讲,SSLStrip 这类工具的技术含量是很低的。它既没破解什么算法,也没找到协议漏洞,只是修改和代理了明文的封包而已。

如果说劫持,要保持源站点不变才算的话,那 SSLStrip 并没做到。根据同源的定义,<协议, 主机名, 端口> 三者必须相同。显然它修改了协议,因此并非在源站点上劫持,而是进入了另个不同的站点。

既然站点都不同,那就属于钓鱼网站了。

但这种钓鱼之所以会如此隐蔽,和大家的常理有关:对大部分用户来说,只要主机名正确那就对了,至于协议和端口,很少有人去关心

而 SSLStrip 正好利用了人们的认知弱点,确实没有修改网站主机名,从而欺骗了大部分用户。

因此更确切的说,这就是一种高级钓鱼。

进一步钓鱼

由于 HSTS 这种反钓鱼的机制出现,即使蒙的了用户,但也骗不过浏览器。

HSTS 正是以主机名为单位的。在新的版本里,甚至还支持所有子域名(includeSubDomains)。

如果还抱有侥幸心理,期望能过滤首次的 HSTS 头,那么 Preloading HSTS 能让浏览器天生就记住某些网站。彻底打消 SSLStrip 的念头。。。

不过,刚刚也说了,SSLStrip 本质就是网站钓鱼。既然都钓鱼了,何必这样鬼鬼祟祟的反倒被发现,为何不正大光明的钓?

反正钓鱼考的就是用户眼力,不如再进一步,干脆把主机名也改了吧!眼力不好的人,可能还是看不出破绽。

例如,将原本 https://www.alipay.com 的链接,跳转到 http://www.alipay.cn 这个钓鱼网站,仍会有不少用户觉察不到。

www.alipay.cn 这个虚假的主机名,显然不会在 HSTS 白名单中,因此又可以无限劫持了!

在流量劫持的环境里,任何明文数据都是可控的。即使访问 www.alipay.cn 这种不存在的域名,中间人也可模拟 DNS 应答,从而可伪造出各种看起来相似的钓鱼站点。

在之前那篇 《SSLStrip 的未来 —— HTTPS 前端劫持》 中,我们是在 URL 的 Query 中进行伪装的:

由于主机名没变,因此仍躲不过 HSTS。

所以,我们需要将 symbol 标记转移到域名里:

将页面中出现的 HTTPS URL 域名稍作修改,即可彻底摆脱 HSTS 的白名单。例如把域名都替换成 .cn 的,虽然完全不是同个站点,但用户仍然不易察觉。

同时,中间人能够识别出这个特征,在转发时还原回先前的域名,进行正常代理。

保留绿色证书

对于大部分用户来说,地址栏里醒目的 HTTPS 绿色证书,是一只强心剂。而 SSLStrip 剥离了协议,显然是不可能出现了。

但如今通过修改主机名,能否要回这个图标?

如果想有,显然得申请一个合法的证书。但要将所有的 .cn 域名都配上数字证书,肯定是不现实的。

不过既然是钓鱼网站,主机名也可以随意改,何必困死在顶级域名上?

我们可以申请一个泛域名证书,例如 *.xx.com。这样,将目标站点都套在该二级域名下,即可以 HTTPS 协议进行钓鱼了。

(这里以自签署的证书演示)

虽然域名相比之前差别较大,但有醒目的绿色证书,反而更容易被蒙蔽了。

HSTS 的意义

由于钓鱼的方式可以千变万化,因此 HSTS 也很难从根本上进行防御。

当然,这并不意味 HSTS 没有实际作用。事实上 HSTS 还是能够避免很大部分的风险。其中最典型的,就是用户在地址栏里敲入网址的情况。

在过去,未提供的协议的网址,都是以默认的 HTTP 方式请求,因此在这个入口就有极大的风险。而 HSTS 的出现,很大程度的解决了这个隐患。

如今,像百度这样的大型导流网站,都在逐步支持 HTTPS 升级,从而在入口源头上堵住这个安全隐患。

防御方案

尽管是钓鱼,但也不是完全没有防御方案。

从攻击者的角度来看,如果要为各种站点制作一个钓鱼网站,成本是极大的。而且更新起来也不容易,数据也难以保持实时。

因此,通常是直接代理线上的站点内容。既然这样,不妨在网页中悄悄加入些监控脚本,统计当前页面究竟在哪些域名里出现过,就能快速找出一些钓鱼网站了。

当然,攻击者也可以过滤掉这段监控脚本,这就是后期对抗的事了。

等待第一条回复
登录后回复,如无账号,请使用邀请码注册