某运营商认证系统分析（TCP会话劫持）

原文地址：

本文仅从技术角度对该认证系统进行分析，如因本文导致个人或运营商密码泄露，作者不为因此造成的法律纠纷承担任何责任。

前段时间在论坛看到过中国电信使用 TCP 会话劫持技术来推广其“互联星空”广告，学习到了很多东西，深为电信的卑鄙行为感到可耻。没想到的是，这种手段最近也被我碰上了。

最近回到了家中，想上网（我的接入方式是以太网接入，也就是常说的“小区宽带”，不是PPPoE集中拨号的那种），可是我的 ISP 使用了某种认证技术，在打开 IE 之后，不管我要去哪里，都会强制到网关的认证页面上，我的帐号早就过期了，眼睁睁地看着系统托盘中的网络连接图标在不停地闪烁，就是上不去网，这个急 啊~~对这个认证系统，我非常感兴趣，打算研究一下，看看能不能找出来什么漏洞，如果能有办法免费上网，岂不是更好？

( 强制弹出的认证页面)

废话不多说，打开我的 OmniPeek，关掉其他所有网络程序，避免多于的数据包影响分析。并且制作高级过滤器，只捕获 MAC 地址为我自己的数据包（广播包非常讨厌）。

有的人喜欢用 Ethereal 或者 Sniffer Pro，但是在做过滤器方面，OmniPeek 的确是非常方便的，简单的几步就实现了我的需求，真是爱不释手啊~~~

我的电脑插上网线就已经获取到了xxx.xxx.132.227的 IP，打开 Firefox，（我的主页默认就是 Google），这时候可以看到OmniPeek在刷刷刷地捕获数据。眨眼之间，我的主页就被重定向到了这个网址上边，随手输入一个用户名：123456，密码：abcdef，当然不会通过。但是这时候 OmniPeek已经捕获了足够的数据包了，现在开始分析：

第一个数据包是个 ICMP的 echo-request，目标地址居然还是个美国的 IP，我向上天保证我没 ping过这个地址，也有可能我的机器上有了流氓软件了吧。暂且不管它，接着向下分析，开始看后边的两个数据包：

这个是我本机发出的 DNS 请求，目标 IP 地址是我的 DNS 服务器，而且很快就得到了回应，看来，这个网关并没有阻断 DNS 通信。为了方便，双击打开看一下：

( DNS 请求数据包 )

( DNS 响应数据包)

紧接着，我的浏览器向Google的 80 端口发出了连接请求：

紧接着，”Google ”给浏览器发回了相应，为什么这里要加上引号呢？因为这个 Google 是假冒的，并不是真正的 Google：

（ 假Google给我的回应，一切做得那么像模像样，引用老罗的那句话：“一切都是那么自然“）

紧接着又是一次 ACK，这个就不用看了，标准的 TCP 三次握手，地球人都知道。

OK，TCP会话建立起来了，下边该怎么办，请求 HTTP 数据啊，于是我的浏览器发出了 HTTP GET 命令，向 Google服务器请求数据：

当然，李鬼（假 Google）肯定没有我要的东西，那怎么办呢？

假 Google 给我来了个 HTTP redirection，让我去访问别的地方：

访问哪里呢？紧接着的这个 HTTP 数据包给出了答案：

原来是把我重定向到了这里，这个地址，同时是我的网关，认证服务器（身兼多职），而且，在此次的 TCP 会话中，假 Google 把我的 TCP 会话 FIN 掉了，还用了 PUSH，挺着急啊~~~~

然后，我的善良的浏览器，乖乖的和假 Google 完成了 TCP 终止的 4 次握手：

（做人不能太善良，做浏览器也是）

接着怎么办，我的浏览器按照假 Google的指示，乖乖地被重定向到了它的认证页面上，输入用户名、密码，完成认证：

看到这里，大家应该都明白了，运营商的网关设备劫持了我和 Google之间的TCP会话，并重定向到它所指定的地址上去，完成认证，完成之后会弹出一个极其恶心的小窗口，上网期间都不能关掉，怒… …@#@$#$#%$%^&%^*()*)&

有人会问，为什么这么肯定那个 Google 是假冒的，我们来看一下 TTL：

( 这是假 Google 给我返回的 TTL )

( 这是我的网关给我返回的 TTL )

为什么 TTL 都一样？怪了，难道 Google 服务器在 ISP 的网关上？？？？？？？

( 这是真正的 Google 给我返回的 TTL )

本来我还打算用 traceroute 来探测一下，没想到这个极其恶心的 ISP把 ICMP 全部关掉了，我连网关都 ping 不了，只能作罢。

到了这里，大家可能都看明白了，某些 ISP 为了达到某种手段，连会话劫持这种黑客手段都用上了，不过我的这个 ISP 比电信还要好一点，毕竟人家不是推广广告，而只是来做自己的认证，要保护自己的利益嘛~~~~还能理解。既然说到了认证，我们继续往下看，看看认证部分有 没有什么漏洞，看看这个数据包，是我的浏览器向网关提交认证信息的，HTTP POST 方法：

哈哈，看到了什么，既然是 HTTP，那么数据的安全性就没得保证了，嘿嘿，用户名和密码都在里边呢，不要说加密，就是连简单的编码都没有做。看到这里，想必大家都想到了一个阴险的招数——ARP欺骗，这样就可以获取大把大把的帐户了，哈哈，心里这个兴奋啊！

想到这里，在这个数据包中提取了HTTP 特征值“usermsg=username”，制作一个过滤器，注意使用“Pattern“过滤器：

做好了过滤器之后，打开 SwitchSniffer 软件，开始进行 ARP 欺骗：

右边窗口的Host Table 中，最下边的那个是我的机器，单击“Start”开始欺骗，同时使用刚才制作的过滤器开始捕获：

很快就抓到一堆，哈哈，打开一个来看看：

嘿嘿，没想到一个 ISP 的认证系统会是如此的脆弱，居然采用明文的 HTTP 协议来传输用户名和密码，安全意识这么差，怪不得别人啦。拿着抓到的用户名和密码，登录，OK，美丽的 Google终于出来了。

看来，在7层采用这种 TCP 会话劫持 + HTTP 明文的身份验证方式，安全性极差。所以对于运营商来说，还是 PPPoE 的安全性好一些，如果认证不能通过的话，2层都不通，更何况去获取 IP 地址来实行 ARP 欺骗？某运营商采用的身份验证倒是有技术含量，但是最终却栽在了 HTTP 这个明文协议上。

点击可以下载本文的PDF版

发表于“”中