[原创]某运营商认证系统分析 (TCP 会话劫持)
最近在网上看了比较多的 TCP 会话劫持，嘿嘿，没想到我也碰上了，晚上做了这么一段分析，水平有限，大家还请多多指教。-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
某运营商认证系统分析
前段时间在论坛看到过中国电信使用 TCP 会话劫持技术来推广其“互联星空”广告，学习到了很多东西，深为电信的卑鄙行为感到可耻。没想到的是，这种手段最近也被我碰上了。
最近回到了家中，想上网（我的接入方式是以太网接入，也就是常说的“小区宽带”，不是PPPoE集中拨号的那种），可是我的 ISP 使用了某种认证技术，在打开 IE 之后，不管我要去哪里，都会强制到网关的认证页面上，我的帐号早就过期了，眼睁睁地看着系统托盘中的网络连接图标在不停地闪烁，就是上不去网，这个急啊~~对这个认证系统，我非常感兴趣，打算研究一下，看看能不能找出来什么漏洞，如果能有办法免费上网，岂不是更好？
[attach]12763[/attach]
( 强制弹出的认证页面)
废话不多说，打开我的 OmniPeek，关掉其他所有网络程序，避免多于的数据包影响分析。并且制作高级过滤器，只捕获 MAC 地址为我自己的数据包（广播包非常讨厌）。
[attach]12770[/attach]
有的人喜欢用 Ethereal 或者 Sniffer Pro，但是在做过滤器方面，OmniPeek 的确是非常方便的，简单的几步就实现了我的需求，真是爱不释手啊~~~
我的电脑插上网线就已经获取到了xxx.xxx.132.227的 IP，打开 Firefox，（我的主页默认就是 Google），这时候可以看到OmniPeek在刷刷刷地捕获数据。眨眼之间，我的主页就被重定向到了[url]http://xxx.xxx.132.1/index.htm[/url]这个网址上边，随手输入一个用户名：123456，密码：abcdef，当然不会通过。但是这时候 OmniPeek已经捕获了足够的数据包了，现在开始分析。
[attach]12767[/attach]
第一个数据包是个 ICMP的 echo-request，目标地址居然还是个美国的 IP，我向上天保证我没 ping过这个地址，也有可能我的机器上有了流氓软件了吧。暂且不管它，接着向下分析，开始看后边的两个数据包：
[attach]12768[/attach]
这个是我本机发出的 DNS 请求，目标 IP 地址是我的 DNS 服务器，而且很快就得到了回应，看来，这个网关并没有阻断 DNS 通信。为了方便，双击打开看一下：
[attach]12762[/attach]
( DNS 请求数据包 )
[attach]12761[/attach]
( DNS 响应数据包)
紧接着，我的浏览器向Google的 80 端口发出了连接请求：
[attach]12778[/attach]
紧接着，”Google ”给浏览器发回了相应，为什么这里要加上引号呢？因为这个 Google 是假冒的，并不是真正的 Google：
[attach]12773[/attach]
（假Google给我的回应，一切做得那么像模像样，引用老罗的那句话：“一切都是那么自然“）
紧接着又是一次 ACK，这个就不用看了，标准的 TCP 三次握手，地球人都知道。
OK，TCP会话建立起来了，下边该怎么办，请求 HTTP 数据啊，于是我的浏览器发出了 HTTP GET 命令，向 Google服务器请求数据：
[attach]12764[/attach]
当然，李鬼（假 Google）肯定没有我要的东西，那怎么办呢？假 Google 给我来了个 HTTP redirection，让我去访问别的地方：
[attach]12765[/attach]
访问哪里呢？紧接着的这个 HTTP 数据包给出了答案：
[attach]12766[/attach]
原来是把我重定向到了[url]http://xxx.xxx.132.1/index.htm[/url]这里，这个地址，同时是我的网关，认证服务器（身兼多职），而且，在此次的 TCP 会话中，假 Google 把我的 TCP 会话 FIN 掉了，还用了 PUSH，挺着急啊~~~~
然后，我的善良的浏览器，乖乖的和假 Google 完成了 TCP 终止的 4 次握手：
[attach]12769[/attach]
（做人不能太善良，做浏览器也是）
接着怎么办，我的浏览器按照假 Google的指示，乖乖地被重定向到了它的认证页面上，输入用户名、密码，完成认证。
[attach]12774[/attach]
看到这里，大家应该都明白了，运营商的网关设备劫持了我和 Google之间的TCP会话，并重定向到它所指定的地址上去，完成认证，完成之后会弹出一个极其恶心的小窗口，上网期间都不能关掉，怒… …@#@$#$#%$%^&%^*()*)&
有人会问，为什么这么肯定那个 Google 是假冒的，我们来看一下 TTL：
[attach]12775[/attach]
( 这是假 Google 给我返回的 TTL )
[attach]12776[/attach]
( 这是我的网关给我返回的 TTL )
为什么 TTL 都一样？怪了，难道 Google 服务器在 ISP 的网关上？？？？？？？
[attach]12777[/attach]
( 这是真正的 Google 给我返回的 TTL )
本来我还打算用 traceroute 来探测一下，没想到这个极其恶心的 ISP把 ICMP 全部关掉了，我连网关都 ping 不了，只能作罢。
到了这里，大家可能都看明白了，某些 ISP 为了达到某种手段，连会话劫持这种黑客手段都用上了，不过我的这个 ISP 比电信还要好一点，毕竟人家不是推广广告，而只是来做自己的认证，要保护自己的利益嘛~~~~还能理解。既然说到了认证，我们继续往下看，看看认证部分有没有什么漏洞，看看这个数据包，是我的浏览器向网关提交认证信息的，HTTP POST 方法：
[attach]12759[/attach]
哈哈，看到了什么，既然是 HTTP，那么数据的安全性就没得保证了，嘿嘿，用户名和密码都在里边呢，不要说加密，就是连简单的编码都没有做。看到这里，想必大家都想到了一个阴险的招数——ARP欺骗，这样就可以获取大把大把的帐户了，哈哈，心里这个兴奋啊！
想到这里，在这个数据包中提取了HTTP 特征值“usermsg=username”，制作一个过滤器，注意使用“Pattern“过滤器：
[attach]12771[/attach]
做好了过滤器之后，打开 SwitchSniffer 软件，开始进行 ARP 欺骗：
[attach]12790[/attach]
右边窗口的Host Table 中，最下边的那个是我的机器，单击“Start”开始欺骗，同时使用刚才制作的过滤器开始捕获：
很快就抓到一堆，哈哈，打开一个来看看：
[attach]12760[/attach]
嘿嘿，没想到一个 ISP 的认证系统会是如此的脆弱，居然采用明文的 HTTP 协议来传输用户名和密码，安全意识这么差，怪不得别人啦。拿着抓到的用户名和密码，登录，OK，美丽的 Google终于出来了。
看来，在应用层采用这种 TCP 会话劫持 + HTTP 明文的身份验证方式，安全性极差。所以对于运营商来说，还是 PPPoE 的安全性好一些，如果认证不能通过的话，2层都不通，更何况去获取 IP 地址来实行 ARP 欺骗？某运营商采用的身份验证倒是有技术含量，但是最终却栽在了 HTTP 这个明文协议上。
注：本文仅做技术研究，如因本文引起个人或运营商密码泄露，本人不承担任何法律责任。
（附件是本文的 PDF 版本）
版权所有：Steve Young
E-Mail: [email]steve.young@163.com[/email]
2007年1月18日
[[i] 本帖最后由 SteveYoung 于 2007-1-19 19:46 编辑 [/i]] 这个不算tcp会话劫持吧。一开始就在DNS欺骗，你们小区宽带的DNS Server是只能用工作人员告诉你的那个，还是说可以指定自己想用的DNS Server。这个机制应该是当DNS Server发现客户端尚未通过认证，管你在请求解析什么域名(存不存在都一样)，统统返回一个固定的IP，这个IP上运行着一个很简单的WEB Server，对这个WEB Server的任何请求(有效无效都一样)得到的响应都是302，固定转向认证页面。这个过程是很正常的认证过程。
所谓tcp劫持，是在已经成功建立的tcp连接上，插入、删减、修改数据，必要时还需要修改th_seq、th_ack。早期的tcp hijacking基于TCP ISN可预测的事实，可以进行blind hijacking，技术含量较高。现在的电信搞的tcp hijacking不是blind hijacking，因为这群流氓是路由掌控者，它们完全是串在线路上的，不用猜测th_seq、th_ack，比sniffer到数据再处理还方便快捷，完全是在转发过程中进行hijacking。电信目前的hijacking大多技术含量较低，往往只修改最后一个http协议响应报文，因http协议不保持长连接，很快就会关闭tcp连接，修改这最后一个的好处就是完全不用顾忌th_seq、th_ack。
tcp hijacking与dns hijacking是完全不同的概念。同时dns hijacking与dns spoofing也是不同的概念。一般提hijacking，是指在半路上搞的小动作，而不是在服务端搞的小动作。比如你控制了你所请求的域名的权威名字服务器，此时一般说dns spoofing。比如你没有控制任何DNS Server，但你在半路上某个节点处可以插入伪造好的A记录查询响应报文，使客户端得到错误的IP，这种我们称之为DNS Hijacking。GFW过去干这种事不少，早期干得也不高明，现在要高明一些了。加上中国现在有了根服务器，如果简单使用国内的DNS Server，很可能被恶心到。 顺便说一句，后半截干得不错。不管理论理解如何，最终得到自己想要的结果才是正事。祝贺。同时，少干此类事情为妙。 思路不错，[size=6]不[/size]鼓励大家效仿。 FT 花了俺20minutes下了一个SwitchSniffer
楼主写的不错,怀念曾有过上百个网关的日子.... DNS 的解析是正常的，66.249.89.99 那个地址的确是 Google 的地址，刚开始和我进行 TCP 会话的那个google是假冒的吧？
[[i] 本帖最后由 SteveYoung 于 2007-1-18 12:21 编辑 [/i]] [quote]原帖由 [i]scz[/i] 于 2007-1-18 09:13 发表
这个不算tcp会话劫持吧。一开始就在DNS欺骗，你们小区宽带的DNS Server是只能用工作人员告诉你的那个，还是说可以指定自己想用的DNS Server。 [/quote]
报告版主，我刚才试了一下，没有通过认证之前，我也可以设定全国各地的 DNS 服务器，他们应该没有在 DNS 上做手脚，哈哈，他们还没用到你所说的那种技术 SteveYoung 兄弟分析的很精彩连图片也做的很漂亮!通过TTL来判断数据包的真假有意思很用心啊
SCZ的点评也很精彩!
强烈支持 [quote]原帖由 [i]SteveYoung[/i] 于 2007-1-18 12:18 发表
DNS 的解析是正常的，66.249.89.99 那个地址的确是 Google 的地址，刚开始和我进行 TCP 会话的那个google是假冒的吧？ [/quote]
如果66.249.89.99确实是Google的一个IP，那你面临的这个确实算tcp hijacking。这就是电信现在常用的那种，只要串在线上干这事，没什么难度。 [quote]原帖由 [i]SteveYoung[/i] 于 2007-1-18 13:07 发表
报告版主，我刚才试了一下，没有通过认证之前，我也可以设定全国各地的 DNS 服务器，他们应该没有在 DNS 上做手脚，哈哈，他们还没用到你所说的那种技术 [/quote]
那说明了一个问题，53/UDP未被封。这意味着你可以架设SSL VPN。我们有些同事就是这样免费上网的。 网关应该基于802.1x的验证服务器,类似华为CAMS那种
收藏,谢谢
如果是cable接入的,是怎么做接入验证的? [quote]原帖由 [i]scz[/i] 于 2007-1-18 15:57 发表
那说明了一个问题，53/UDP未被封。这意味着你可以架设SSL VPN。我们有些同事就是这样免费上网的。 [/quote]
这样可以 吗？
什么时候支一招！嘻嘻！减减自己的上网费！
看了这个帖子很受启发，对Hijacking有了更深入的了解 是不是做个client-to-gateway的VPN连接,然后server端用53端口? 好文,不过很早之前有人干这种事免费上网了. 支持。呵呵 [quote]原帖由 [i]scz[/i] 于 2007-1-18 15:57 发表
那说明了一个问题，53/UDP未被封。这意味着你可以架设SSL VPN。我们有些同事就是这样免费上网的。 [/quote]
这个具体怎么实现呢?可否明言?是c/s形式吗?
[[i] 本帖最后由 wxh_tiger 于 2007-1-19 14:01 编辑 [/i]] [quote]原帖由 [i]wxh_tiger[/i] 于 2007-1-19 13:59 发表
这个具体怎么实现呢?可否明言?是c/s形式吗? [/quote]
不是说了吗，架SSL VPN，这么明白的一句话。又没只说架VPN，不就是为了区分出IPSec VPN嘛。让VPN通过这个53/UDP出去就是了。
[url]www.openvpn.net[/url]就是一种实现。难道你们不用Google、baidu的吗？
从未见过非C/S的VPN吗，也想像不出来那样的VPN。 两个带VPN的路由也可以用gateway-to-gateway的方式
这样应该不算C/S吧? [quote]原帖由 [i]crab[/i] 于 2007-1-19 19:32 发表
两个带VPN的路由也可以用gateway-to-gateway的方式
这样应该不算C/S吧? [/quote]
没接触过，不了解，也不知你说这种VPN是否满足我们平时对VPN的需求。在我看来，基于tcp/ip的，即使是p2p，在协议层面也是分得出C/S的。 强人！！！！！！！！！！！！！！！！！ 在我这种新手眼里，水平能够还是不错的。
疑问
按楼主说的，即你能用别人的用户名上网，可真实用户再上时，肯定就不能上了，这样会出问题呀。不知这个问题怎样解决。另通过SSL VPN，如果ISP没有提供53端口，是否还有别的办法呀？请指教。 [quote]原帖由 [i]visualmac[/i] 于 2007-1-21 17:03 发表按楼主说的，即你能用别人的用户名上网，可真实用户再上时，肯定就不能上了，这样会出问题呀。不知这个问题怎样解决。另通过SSL VPN，如果ISP没有提供53端口，是否还有别的办法呀？请指教。 [/quote]
嘿嘿，别人上不了，就会改密码啦。
然后再去搞一些~~不过我打算换个ISP了，网络太差，广播太多了，连VLAN都没划 有个办法可行, 打电话报障, 让技术人员上门, 然后告诉他你要更改密码.
如果他用你的电脑登入验证服务器,即网关IP
你暗中把这个包抓下来, 以后你就为所欲为拉
不过一般都是机房内的IP才能访问验证服务器
可行性不高
呵呵 哈哈,思路不错,就是可能害的别人不能登陆上网了......
学以致用
不错,不错,学以致用就是好!哈哈:lol :lol :lol 我才发现SCZ也是个超厉害角色。。。不得不服...... Gateway--Gateway vpn实际上也是c/s模式,只是互为对方的客户端而矣. 不错，正好当作借鉴，分析一下我们小区的srun2000认证系统 会话劫持这种无耻的事只有中国电信才做得出来~~~
不过，DNS解析过滤好象不久也应该会被“推广使用”了，因为我们公司最近就有同事在为公安做这个东西~~~
什么社会啊~~ 写的相当不错，学习一下了。 支持原创 看了后寒了，真是厉害啊 我要向各位大哥们学习，你们是我的偶像啊！！以后要天天来这！ 请问可以提供整个劫持过程的抓包数据吗？ :victory:
如果电信使用重定向，将我们HttP请求都定向到一个地址上，我们有没有办法破解。 :loveliness:
前几天搬家,发现小区竟然是长城宽带.
但问题是SwitchSniffer只能扫描到两台机子(自已的和网关的),好像是因为交换机上启用了VLAN.
请问,有没别的嗅探工具呀? 还VLAN，长宽哪有那么有钱买那么好的交换机！楼道里全是HUB式交换机 我在深圳,
OMNI显示对方是CISCO的设备. [quote]原帖由 [i]sfih[/i] 于 2007-4-6 17:14 发表 [url=http://www.netexpert.cn/redirect.php?goto=findpost&pid=91086&ptid=13932][img]http://www.netexpert.cn/images/common/back.gif[/img][/url]
我在深圳,
OMNI显示对方是CISCO的设备. [/quote]
用solarwinds探测一下，看看能不能看出他们的SNMP community string，可以的话搞个交换机玩玩也不错
btw：深圳gwbn真有钱，居然上cisco设备！！
页:
[1]
2