Archive for category 网络安全

百度被黑 快来围观!

现在时间是: EST 2010-1-11 10:15PM  地点:Ontario,Canada

百度域名被劫持,传说是伊朗国家队干的~~。这时,我们分别访问百度百科:

image

百度

image

 

百度知道

image

 

百度空间:

image

 

查了一下WHOIS,“Last update of whois database: Tue, 12 Jan 2010 03:17:47 UTC ”

看来刚被baidu改回来~~~

———————————————————————————————

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: BAIDU.COM
   Registrar: REGISTER.COM, INC.
   Whois Server: whois.register.com
   Referral URL: http://www.register.com
   Name Server: DNS.BAIDU.COM
   Name Server: NS2.BAIDU.COM
   Name Server: NS3.BAIDU.COM
   Name Server: NS4.BAIDU.COM
   Status: clientDeleteProhibited
   Status: clientRenewProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 11-jan-2010
   Creation Date: 11-oct-1999
   Expiration Date: 11-oct-2014

>>> Last update of whois database: Tue, 12 Jan 2010 03:17:47 UTC <<<
---------------------------------------------------------------------------------------------

当然了,用IP还是可以访问百度的

http://119.75.213.61/

http://202.108.22.5/

分享到

Tags:

有意思的淘宝**抢拍器

今天看到了一款极具想象力的软件产品,淘宝**抢拍器 (http://amxxx.net/)主要是针对taobao的秒杀活动的。

这款软件自身使用说明如下:

联合抢拍器的原理类似于迅雷下载,使用的人越多成功率越高,在联合抢拍器中任何用户都可以自己组建团队,组团抢拍,相互协助,凡是抢拍或协助成功者都将获得一定积分和经验值,有了积分才可以让更多人协助,有了经验值可以在比赛活动中获得领先地位,联合抢拍器的收费形式是抢拍成功后收费,收费标准请参考报价栏。

 

从中不能窥出,这个软件的设计思路非常好。如果是单IP提交“拍下”请求,未免成功率不高(可以想象 多个用户各自独立的使用这个软件单机版,那么谁会胜出呢?) 为了解决这个问题,软件设计成了协作版,目的就是让使用该软件的用户协作工作,从多个IP地址 瞬时向服务器提交大量请求,那么有99%的概率 服务器会从中选一个请求作为最终成交。无论这个协作圈子里面谁买到了,都可以转给真正需要这件商品的人,然后其他协作的人会得到经验值。

 

下了个客户端来装上(nod32提示有木马,哎,当神农尝百草了!后来发现好像是它的升级模块造成的误报)

Untitled-1

界面还算精美,功能也很强大,不过需要先充值100RMB到它这个平台里面。估计是为了拍下以后:

  1. 如果这是你协助别人拍的,钱会从那个人的账户中扣除,添加到你的账户中,(不知道这里收货地址怎么协调,是先寄给协助者 还是直接寄给买者?)
  2. 如果正是你自己拍的,那么系统会用你存的这100块钱为你付款。

Untitled-2

软件原理不太难,应该是伪造HTTP请求提交过去。验证码的处理,看到cnbeta上有人讨论,看来淘宝的验证码设计有问题(这个安全问题,应该是因为为了系统的低开销而引入的,否则一个session就需要server生成几百个随机数,那么多session,server handle不过来,也容易被DOS)。不过自己没有研究过CAPTCHA,不妄下结论。

Untitled3

最后,提一些解决“抢拍器”问题的想法,技术方面(可以借用e-voting的一些思想):

  1. 规定一个时间窗,例如[20:00+x,20:02+y] 这里1<x<10和1<y<10是两个随机数,用以确定秒级别的开始时间。也就是说开始和结束时间大致是[20:00,20:02],但在秒级别时随机的。这样杜绝那些用作弊器的用户,因为软件可以做到高精度的时间同步(比如说在20:00 第0秒就发出包) 而人是很难的。因此server最先收到的一批请求里面,作弊器提交的绝对占大多数。
  2. 每个IP在规定时间窗里,只能提交一个请求,若多个则只算第一个
  3. 以每个请求到达时间为每个请求的时间戳, 在结束后,server离线计算在时间窗内的请求的到达的先后顺序,从而判定谁拍到了
  4. 最后记录下每个用户和其提交请求的时间戳与开始时间 (20:00+x)的偏差,用于建立一个用户行为的统计模型(这里就是提个想法,具体一点,可以写一篇硕士论文了)
  5. 那么当这个作弊用户多次参与“秒杀”不同商品时,关于他行为(确切的说是提交时间)的一个统计规律就出来了。如果这里方差很小(小于了阈值),则判定为作弊。 这里利用的是: 作弊器比较机械,会着急在最靠近20:00的时候提交,而人则总是会犯错误的,哪怕是秒杀老手。另外,为了躲避这个模型检测,作弊器也可以引入随机延时,但这势必影响到它的成功率,因此会造成用户流失,也就间接达到了封杀作弊器的目的。
  6. 当然,封杀住绝大部分作弊请求的代价是错杀了一小部分正常请求。
  7. 其实,封杀作弊器是不难的,毕竟机械的提交会造成某些统计规律。taobao应该好好练练技术内功,学习一下google adsense和魔兽世界是如何做的。

非技术方面:

  1. 这个游戏本来就不公平,对网络质量好、电脑配置好的用户有很大优势(假设没有作弊器)
  2. taobao此举不外乎是为了炒作、炫耀自己,顺便提高网站访问量。
  3. 这样的设计在商业上也许是个成功,在技术上确值得商榷。这样做基本上是号召很多用户在这个时间窗内DOS淘宝的服务器(事实也是如此,“秒杀”时 很多用户点击了没有反应,taobao实际上是秒杀了自己的服务器。。。)
分享到

Tags:

Is Bell Sympatico so slow? Bell路由网速慢解决妙方

Here is the google translation of this article: http://translate.google.com/translate?prev=hp&hl=zh-CN&js=y&u=http://www.raullen.net/1073.html&sl=auto&tl=en&history_state0=

 

images 今天高高兴兴的装上了Bell Sympatico的performance plan (速度6M 流量65G 30刀/month Good deal!),本以为可以爽爽的上上网查一下资料,谁知网速到了晚上7点以后简直慢不堪言。 Even 打开google都要10s左右。。。

起初以为,bell像国内的长城宽带一样,所有用户共享一个总的出口带宽,这样晚上用网的人多,网速自然很慢。后来发现不然,因为用megaupload下载东西的时候,网速总能稳定在500k左右。

接下来一想,就有思路了:DNS解析有问题!!!!

因为对于浏览器来说,访问网页的第一个步骤是提交DNS请求给DNS服务器,等拿到传回来的IP地址以后,再拿这个IP地址去访问网站。想必问题就出在第一步。这里,我们进行一个思维实验:所有bell用户的DNS请求都被forward到某一或几个DNS Server那里,DNS Server按照队列模型处理用户的请求 (First come first serve or first in first out). 当用户数量增加,提交的DNS请求数会增加,这个等待队列会增长,因此对于某个时刻到来的某个DNS请求而言,查询时间变长,因此请求此网页的用户会明显的感觉到latency,这也就是所谓的“网速变慢”。。。

找到了问题就很好解决了。首先我在本机做个试验证实一下我的想法: 本机强制制定了DNS服务器地址(网卡-属性-IPv4-使用下面的DNS地址)。这里我用了opendns的中继DNS服务器,

  • 208.67.222.222 (resolver1.opendns.com)
  • 208.67.220.220 (resolver2.opendns.com)

Opendns是个好东西(不明白的可以看看这里),用户向以上两个DNS地址发送请求,它们会根据用户所处的地理位置,把这个请求forward到离用户最近、最快的DNS服务器上面去。有了这个中继层,我们就不用怕DNS服务器地址过期了!!强制制定DNS地址以后,再一开sina,刷刷的往出蹦广告啊!我那叫一个高兴啊!!!

试验成功了,然后就去更新wireless router上的dns设置了。Bell发给我的wireless router是2wire的,我们在这里填入以上两个DNS地址:Internet Connection –> Advanced settings –> Internet DNS –> Manually configure your DNS information,如下图:

 

Untitled-1

然后所有的用户就都可以受益这刷刷往出蹦广告的网速了!!测了一下网速,基本达到ISP声称的速度了!!

Untitled-2

最后查了一下资料,Bell果然把所有用户的DNS请求都集中到了自己的几台服务器上,他们为啥这么做呢?看来和咱们的中国DX push广告的motivation差不多,在返回的dns解析里面神不知鬼不觉的插入些把个广告,赚点零花钱吧~~~~~

哎,天下乌鸦一般黑。。。        20090306

分享到

Tags:

强悍的Linux NULL pointer dereference漏洞CVE-2009-2692 秒杀所有linux

早上起来,看到了一篇博客文章:

黑客再爆Linux内核高危漏洞,一个命令可以攻击所有Linux系统

 

玩心遂起,找了milwrm上的两个exp来试了试 (这两个exp点击量不错,看来非常hot):

http://milw0rm.com/exploits/9435

http://milw0rm.com/exploits/9436

其中一个在我心爱的ubuntu9.04上exploit成功,直接从普通用户提权成root!!!!!利用此漏洞极其简单,并且影响所有的Linux内核,看来这个漏洞还真是强大。

截图如下:

成功:

Ubuntu-2009-08-16-08-52-59

失败:

Ubuntu-2009-08-16-08-48-26

 

另外,securityfocus也提供了两个exp 有兴趣的朋友可以测试一下:

http://www.securityfocus.com/data/vulnerabilities/exploits/wunderbar_emporium-3.tgz
http://www.securityfocus.com/data/vulnerabilities/exploits/36038-4.tgz

这个漏洞是 这个老外 发现的,原理是sock_sendpage 没有检查空指针:

The issue lies in how Linux deals with unavailable operations for some protocols. sock_sendpage and others don’t check for NULL pointers before dereferencing operations in the ops structure. Instead the kernel relies on correct initialization of those proto_ops structures with stubs (such as sock_no_sendpage) instead of NULL pointers.
At first sight, the code in af_ipx.c looks correct and seems to initialize .sendpage properly. However, due to a bug in theSOCKOPS_WRAP macro, sock_sendpage will not be initialized. This code is very fragile and there are many other protocols where proto_ops are not correctly initialized at all (vulnerable even without the bug in SOCKOPS_WRAP), see bluetooth for instance.
So it was decided that instead of patching all those protocols and continue to rely on this very fragile code, sock_sendpage would get patched to check against NULL. This was already the waysock_splice_read and others were handled.

 

redhat官方的解决方案:https://bugzilla.redhat.com/show_bug.cgi?id=516949#c10

分享到