Archive for November, 2008

中国电信HTTP会话劫持 3

November 29, 2008 at 4:55 pm · Filed under Techie

不怕流氓，就怕流氓有文化 — 中国电信对Google Toolbar 搜索劫持更新了：劫持到一个新的地址：http://s.cntsi.net/;
以前的帖子：中国电信ADSL HTTP会话劫持 2； 中国电信ADSL HTTP会话劫持协议分析

Comments (1)

这个扶手椅很舒服

November 15, 2008 at 10:33 pm · Filed under Default Life

IKEA的一个扶手椅，很舒服。

http://www.ikea.com/cn/zh/catalog/products/S59840156

Comments (1)

电信ADSL HTTP会话劫持 – 几个补充

November 10, 2008 at 10:52 pm · Filed under Techie

这个是继续上次谈到的电信对ADSL用户HTTP会话劫持的补充。

    如何避免这种劫持？

技术上来讲，HTTP会话劫持发生时，浏览器无法察觉、TCP会话看上去似乎也是正常；所以试图通过修改DNS服务器、使用IP地址访问等等的方法都不能幸免；比较有效的办法就是设定本机的hosts文件（这个文件在C:\Windows\System32\Driver\etc\目录下，是关于域名和IP对应关系的静态映射文件，优先于DNS解析），将search.cninspirit.com域名对应的IP设置为一个无效的IP，比如127.0.0.1；这样至少不会让电信每次在用户搜索是都窃取和记录用户搜索的内容。

    还有更好的办法解决这个问题吗

只有投诉；投诉电信的无耻行为。如果我们有更好的选择，坚决抛弃这种无良的运营商。

Comments (3)

别让牛根生猥亵你的孩子 转载

November 8, 2008 at 10:50 pm · Filed under Default Life

别让牛根生猥亵你的孩子 转载

抵制蒙牛

别让牛根生猥亵你的孩子
连岳 @ 2008-11-8 17:07:18 阅读(7285) 评论(63) 引用通告 分类: 至少我认为

牛根生的水平也就打打民族牌，其实有张更好的牌，他知道了也不好意思打，只能让软文打，那就是“原罪牌”，民族企业发家史都有污点，谁都往奶粉里加三聚氰胺，所以，何必苛责我？放我一马吧。

首先，虽然三鹿、蒙牛、伊利把奶制品业搞成化工业，仍然有许多奶制品企业经受了这次危机的检验，证明他们是合格的生产商，我们应该支持的，是这些企业。

其次，就算原罪说成立，原罪也是用来赎的，而非脱罪和继续犯罪的理由。蒙牛及牛根生现在要做的是主动赔偿受害者，即使法院不受理。就像屠杀犹太人是现代德国人的原罪，没人可以宣示清白，所以他们的做法是忏悔、赔罪、赔偿。牛根生至今尚末补偿任何一个受害者，反而出来哭求自己的利益，这种逻辑如果德国人接受了，一个纳粹头目就可以在媒体上发布万言书声明自己本意是为了民族利益。

牛根生连纳粹都不如，纳粹都只杀异族，牛根生专门屠杀本民族的孩子。

这样的牛根生，中国的司法体系放纵他，中国的一些企业家施舍他，中国的一些媒体与媒体人为他辩护（如果你们收了牛根生的钱，我诅咒你们世世代代死于肾结石），这样的民族，是一个适合屠杀的民族，是毫无希望的民族。

这就像牛根生猥亵了你的孩子，但是对你说，我是猥亵了，可猥亵的手，是一只民族企业家的巨手。于是你就原谅了他，甚至还说，原罪嘛，那么多人都猥亵！

救牛根生，需要杀死你的孩子。你连你的孩子都保护不了，仍然受牛根生的蛊惑，那你就算个屁！所以，请跟我一起抵制牛根生，抵制蒙牛。

Comments

谈谈电信ADSL的HTTP会话劫持

November 5, 2008 at 12:38 am · Filed under Default Life

  • 现象描述

    • 使用成都电信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中输入任何的词语进行搜索，然后停止“捕捉”。

  • 发现了什么？

    • TCP Packet 大图
    上图是抓取的数据包。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“，我们能看到第二幅图：
    HTTP 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

    > 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

    观察(107-106)的时间差，我们发现第一段来自(G)的回应离(C)发出的请求经过的时间(~68ms)，比从(C) ping (G)服务器的最短时间(124ms)还要短！

      真实的情况是什么？

    通过以上分析，基本可以断定以下事实：
    * 从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).

    中国电信，一坨狗屎！

    Comments (1)