HTTP会话劫持被劫持的原理分析（转)

• 现象描述

使用成都电信ADSL网络，浏览器使用Firefox 3.0.3, 安装了Google Toolbar工具。在Google Toolbar工具栏中输入任何搜索词，始终发现浏览器状态栏快速的闪动了一个非google的地址，然后又访问google网站返回搜索内容。仔细观察状态栏该地址，发现地址为”search.cninspirit.com”。把Google Toolbar各项设置重置已经升级到Toolbar Beta均发现每次如此。

• 为什么？

开始我感到很迷惑：google和一个cninspirit的网站肯定不会有什么合作，搜索这个关键词也没发现任何有用的信息；浏览器为官方网站下载，也没有安装任何可疑的插件及扩展。从客户端已经找不到任何合理的解释。只有打开wireshark抓包对HTTP会话和网络流量进行仔细的查看。

• 如何实施抓包？

非常简单，安装wireshark抓包及协议分析工具；打开“捕捉”并且开始在Google Toolbar中输入任何的词语进行搜索，然后停止“捕捉”。

• 发现了什么？
•  

上图是抓取的数据包。192.168.1.100 是客户机IP地址(C)，64.233.189.99是 google的一个Web服务器IP地址(G)。主要步骤和解释如下：

103, 104,105: (C)与(G)建立TCP会话阶段；

106, 107, 108, 111, 112, 117: (C)与(G)的HTTP会话内容；看上去似乎很正常；

114,121, 122: 从(G)发出的一些“异常”流量与(C)的回应。

这个会话看上去非常的简单，一段单次的HTTP会话；如果这些包本身还不能说明问题的话，我们可以看看这次会话传输的内容 — 选取其中一个包，在Wireshark中，单击右键，选择”Follow TCP Stream“，我们能看到第二幅图：

问题在哪里？

从第二幅图可以清晰的了解客户端(C)发送的内容和(G)发送的内容，它们分别用不同的背景色被标识了出来。

为什么会有来自(G)的两段回应？

这个问题很好回答。因为第一段回应是数据包106,107的内容，第二段的回应是114,121的内容？

回应有什么不正常？

第一眼就发现,来自(G)的第一段回应不是一个合法的HTTP Response! - 开头就是HTTP BODY的内容而没有任何的HTTP Header。各位，你相信Google的Web服务器会不遵循HTTP RFC吗？很遗憾，Firefox 相信了并且容忍了这一点，也不能怪firefox，RFC对协议实现的要求中一条很有名的原则就是“严于律己，宽于待人”，即尽量对自己发送的数据要符合RFC规范，对自己接受的数据做规范内的最大容忍。第二眼就会发现，来自(G)的一段回应内容也很诡异：非常简单的一个表单，然后再加载一个来自使用IP地址(http://125.64.31.13:81/)的javascript脚本。通过whois查询发现该IP地址NETNAME是CHINANET-SC，属于中国电信四川省。

到这里也许您会想，这说不定是google的策略呢，把搜索业务和当地ISP合作，提供更好的服务，请继续往下看。

为什么会有第二段回应？

来自(G)的第二段回应的内容是：访问的搜索内容已经换了地方，请访问www.google.cn继续搜索；但是为什么会有两段呢? 这还要看第一幅图才能明白。

第二段的回应来自于第一幅图中的114和121两个数据包，同样来自(G)地址，却被协议分析器标识成了”TCP Retransmission”。TCP重传，常见于链路质量不高的网络或网络拥塞，发送方重传定时器超时会重新发送TCP数据包。但是仔细查看内容，wireshark的分析是”(suspected) retransmission”或“怀疑为重传”。那么这个数据包真的是
重传吗–显然不是：因为编号为111，来自服务器(G)的数据包已经确认了TCP Sequence Number (1095)已经收到，而又出现的编号为121，来自服务器(G)的数据包又要求确认TCP Sequence Number (1095)一点也解释不通。

更为诡异的来自于下面的服务器向客户机请求的回应到达客户机时间的数据与分析。
下面的数据显示了几个关键数据包发送与接收的时间差：

104-103= 0.122134 TCP Estab TCP 建立时G服务器到C客户机的回应时间；
107-106= 0.067946 HTTP RESPONSE - client HTTP Request第一段HTTP回应中G服务器到C客户机的回应时间
111-108= 0.075457 Server TCP Close ACK - Client response for server TCP close ACK
117-112= 0.124167 Server response TCP close, FIN, ACK - Client request for TCP close,FIN ACK
114-106= 0.197939 TCP Restransmission, server response - client HTTP request
观察(107-106)的时间差，我们发现第一段来自(G)的回应离(C)发出的请求经过的时间(~68ms)，比从(C) ping (G)服务器的最短时间(124ms)还要短！

> ping 64.233.189.99 -t
…
Reply from 64.233.189.99: bytes=32 time=130ms TTL=241
Reply from 64.233.189.99: bytes=32 time=133ms TTL=241
Reply from 64.233.189.99: bytes=32 time=133ms TTL=241
Reply from 64.233.189.99: bytes=32 time=131ms TTL=241
Reply from 64.233.189.99: bytes=32 time=133ms TTL=241
Reply from 64.233.189.99: bytes=32 time=134ms TTL=241

Ping statistics for 64.233.189.99:
Packets: Sent = 48, Received = 48, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 124ms, Maximum = 134ms, Average = 130ms
Control-C

真实的情况是什么？

通过以上分析，基本可以断定以下事实：
* 从C到G（Google网站）的TCP会话正常建立后(103-105)，C发出的HTTP搜索请求(106)被一个离客户C很近的设备给劫持了，伪造了来自G网站的数据包，并且很快的(~68ms)返回了HTTP回复(107)，而且该回复并不符合HTTP RFC规范！该回复内容是让浏览器下载一个来自IP地址(http://125.64.31.13:81/)的javascript脚本，该脚本内容是提交搜索到search.cninspirit.com，这是为什么能在浏览器状态栏中看到访问该地址的原因。来自伪造G网站的数据包继续完成了与C客户的TCP会话过程(108,111,112,117)；而在这时，真正来自G网站的数据包才到达C客户机，然而该TCP会话已经被来自伪造G网站的数据包正常终止，因此C客户机向G网站发送了连接已经不可用(RST)的信息(122).

中国电信，一坨狗屎！