【流量劫持】沉默中的狂怒 —— Cookie 大喷发

时间:2023-11-24 21:34:32

精简版:http://www.cnblogs.com/index-html/p/mitm-cookie-crack.html

前言

上一篇文章 讲解了如何借助前端技术,打造一个比 SSLStrip 更高大上的工具。

今天我们再次使用这套战术,通过前后端的里应外合,实现一个杀手锏级的攻击方案 —— Cookie 数据大喷发。

传统嗅探

在过去,Cookie 的窃取大多通过嗅探流量来实现。

这种方法具有很强的隐蔽性,让人几乎难以察觉。然而,正因为如此,也面临一个巨大的缺陷:速度太过缓慢。

中间人只能嗅探到用户正在访问的页面,对于那些令人期待的网站,只能慢慢等了。在家庭、办公场所这些稳定的网络环境里,长久的等待或许还能得到想要的结果;但对于公共场所上网的用户,就没那么容易了。

在公共网络里,大家多少保持一些警惕,很少会去访问一些重要的网站。况且,临时的网络用户也不会停留太久。因此纯粹的流量嗅探,难以捕捉到更有意义的数据。

前端出击

既然用户不按我们的套路出牌,那么我们的前端战术就得派上用场了 —— 只要能控制页面,一切皆可由我们做主。哪怕用户就是不中圈套,我们的脚本也可以强制跳转过去,从而轻易拿下想要的 Cookie 数据。

不过强制跳转的方式也太过暴力了。尽管我们使用了劫持页面这种高调的方式,但之后的所作所为,仍需保持隐蔽。

也许你会说可以通过隐藏框架页来代替,就可大幅提升隐蔽性了。这个方式确实不错,离我们的目标又近了一步,但仍然不够完美。为什么非得用访问页面的方式来获取 Cookie,这代价不免也太大了。

事实上,Cookie 的发送和请求类型是没有任何关系的。无论是页面的访问、还是第三方资源的加载,只要目标 URL 匹配了 Cookie 数据库的路径,符合的记录最终都会被带上。或许你平时并没有注意到这一点,但我们可以马上来验证下。

我们先在页面里,发起一个第三方的资源请求:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

抓到请求包,自然就获得了其中的 Cookie:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

但这些数据究竟是不是完整的,能否直接利用?不多猜测,我们把它粘到其他浏览器里试试:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

当我们再次刷新页面时,奇迹发生了:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

通过 Cookie,我们成功还原了之前的登录状态。而这一切,仅仅从一个第三方的图片请求中获得!

所以,中间人可以使用非常轻量的方式,来获取某个站点下的 Cookie,并不需要用户主动访问该站点。

我们可以事先收集大量的网站地址,让前端间谍进行逐一侦探,从而能嗅探到相当一部分账号了:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

方案优化

前后端结合战术,在此又一次得到了展现。但为了能将其发挥到淋漓尽致,我们还需进行充分优化。

路径标记

虽然我们可以通过加载第三方资源的方式,将目标站点的 Cookie 送到流量上。但中间人收到请求后又该如何处理?返回空白内容,还是代理正常页面?

如果真走一遍代理,那实在是太浪费了。既然我们已得到 Cookie,随便返回什么都可以;但若返回空内容,要是用户正好打开这个网站,那就白屏了。

为了不影响 Cookie 的发送,同时能让中间人明白这个请求是咱们自己人的,我们在请求的 URL 里加上一个特殊的标记。

当中间人发现请求带有这个暗号,自然就明白了 —— 记录下其中携带的情报,然后放心的返回空白就可以了。

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

因为 Cookie 的 Path 属性不包括 Query,所以加上这个记号,并不影响 Cookie 的携带。原来有哪些,现在仍一样。

此外,修改了路径还有另一个好处:即使侦探被缓存了的站点,也能产生请求流量。从而不错过任何一个目标!

DNS 加速

解决了代理问题,发送 Cookie 现在只需极小的流量。

这时的瓶颈,已不仅仅是 HTTP 流量了。因为我们事先准备了大量的网站,他们都有各自的域名,因此 DNS 查询也成为不可忽视的一部分。

为了缩短查询时间,我们可以将所有发往 UDP/53 的数据包,全转发到中间人的 DNS 服务下,并且都解析成自己的 IP。这样不仅加快域名查询的过程,而且还能给中间人节省不少带宽。

当然,如今的浏览器,对域名解析做了大量的优化。因此在前端上,速度提升或许并不明显。

但这种方式仍有极大的意义 —— 我们同时劫持了 DNS 和 HTTP,这意味着整套方案,可以不依赖互联网,进行离线攻击!这尤其适用于上网成本较高的户外环境里。

痕迹收集

当然,并不是所有账号都得通过 Cookie 成功还原的。稍微重视安全的网站,其登录会话都绑定了 IP 地址段。如果还原时的外网 IP,和用户之前使用的存在较大区别,这个 Cookie 很有可能就失效了。

但大多数时候,我们劫持的都是附近的用户,甚至是同一内网的,所以仍有不少能够还原的。

但随着安全等级的提高,一些网站不仅仅绑定 IP 地址,有的还关联了 User-Agent 等信息。在将来,甚至还会绑定用户更多的痕迹,例如屏幕分辨率、插件版本、绘图算法等等,更精确的识别用户。

为了能提高还原成功率,我们也尽可能多的收集用户信息。除了 User-Agent,我们还可以考虑通过前端代码,收集更详细的浏览器特征信息。在账号还原时,把这些信息都模拟到沙盒里,伪装到天衣无缝。

攻击演示

Demo: https://github.com/EtherDream/cookie_hijack_demo

当受害者进入我们的劫持环境里,打开任意页面,即可触发布置其中的 XSS 脚本。(当然,这里为了演示简单,把整个页面都替换了。实战中,可以参考前一篇的文章的注入方法)

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

我们的日志,成功记录下各种账号的 Cookie:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

于是,就在这一瞬间 —— 尽管没做任何事,但众多账号已被黑客所控制:

【流量劫持】沉默中的狂怒 —— Cookie 大喷发

当然,这里只演示最基本的功能,将嗅探到的 Cookie 保存在文件里。至于如何还原,有无数种方式,这里就不再介绍了。