解析暴庫(kù)漏洞原理及規(guī)律

我看暴庫(kù)漏洞原理及規(guī)律
SQL注入流行很久了，我們找漏洞注入目的無非是想得到數(shù)據(jù)庫(kù)內(nèi)的東西，比如用戶名密碼等，更進(jìn)一步的MSSQL數(shù)據(jù)庫(kù)還可以借此獲得權(quán)限�；�于Access的基礎(chǔ)來說，如果我們不用注入就可以得到整個(gè)數(shù)據(jù)庫(kù)，不是更好嗎？于是暴庫(kù)成了一個(gè)比注入更簡(jiǎn)單的入侵手段。
有關(guān)暴庫(kù)的方法，高手們常在入侵文章中提到，但多是一筆帶過，有些就某一個(gè)方法談的，也多是就方法進(jìn)行探討。最近有一篇《再談暴庫(kù)的利用》的文 章，算是對(duì)暴庫(kù)進(jìn)行了一些總結(jié)，因而在網(wǎng)是流傳很廣。但仍沒有談及原理，而且結(jié)論也只是就于經(jīng)驗(yàn)，似是而非，于是決定來談?wù)劚��?kù)的原理與規(guī)律。不到之處， 大家多指教。

“”暴庫(kù)大法
這種方法被認(rèn)為是暴庫(kù)絕招，很是流行了一陣，但是和其它漏洞一樣，隨著知道的人多了，防備也加強(qiáng)了，沒以前那么有效。這種方法簡(jiǎn)單點(diǎn)說就是在打開網(wǎng)頁(yè)時(shí)，把網(wǎng)址址中的“/”換成“”，然后提交，就可以暴出數(shù)據(jù)庫(kù)的路徑。
實(shí)際上，并不是所有網(wǎng)址都有效，需要“asp?id=”這樣的網(wǎng)頁(yè)地址，或者說表示有調(diào)用數(shù)據(jù)庫(kù)的行為的地址。如果你確認(rèn)這個(gè)網(wǎng)頁(yè)有調(diào)用數(shù)據(jù) 庫(kù)的，后面不是這樣的也可以，比如Chklogin.asp等也可以（還有其它條件，后面再談）。先舉個(gè)黑防第四輪實(shí)驗(yàn)室中的例子：
http://219.237.81.46/yddownview.asp?id=3
把第二個(gè)“/”換成“”：
http://219.237.81.46/yddownview.asp?id=3
提交后會(huì)得到如下返回結(jié)果：
Microsoft JET Database Engine 錯(cuò)誤 '80004005'
'D:111admin ds_dbd32rfd213fg.mdb'不是一個(gè)有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務(wù)器。
/yddown/conn.asp，行12

這是黑防實(shí)驗(yàn)室的一個(gè)系統(tǒng)，暴庫(kù)是小編們故意開放的，因?yàn)樗�的關(guān)口不是注入，而是進(jìn)入后臺(tái)后如何獲得WebShell�？梢钥吹轿覀冎苯荧@取了數(shù)據(jù)庫(kù)地址，可以下載了。
現(xiàn)在很多人都知道這個(gè)方法了，我就不多舉例了。但清楚暴庫(kù)原理的人估計(jì)是不多的，有人成功，有人不成功，《再談暴庫(kù)的利用》一文總結(jié)說，須變換第二個(gè)“/”為“”才行。很有實(shí)用性，但這個(gè)結(jié)論只是一種經(jīng)驗(yàn)，其實(shí)并不正確，讓我們先看看它的原理。
“”暴庫(kù)法，它不是網(wǎng)頁(yè)本身的漏洞，而是利用了IIS解碼方式中的一個(gè)特性，如果IIS安全設(shè)置不周全，而網(wǎng)頁(yè)設(shè)計(jì)者未考慮IIS錯(cuò)誤，就會(huì)被 人利用。為何要用“”？它實(shí)際上是“”的十六進(jìn)制代碼，也就是“”的另一種表示法。在電腦中，它們是同一個(gè)東東，但提交“”和“”卻會(huì)產(chǎn)生不同 的結(jié)果。在IE中，我們把下面第一個(gè)地址中的“/”換成“”提交：
http://219.237.81.46/yddown/view.asp?id=3
http://219.237.81.46/yddownview.asp?id=3
二者的訪問結(jié)果是一樣的。IE會(huì)自動(dòng)把“”轉(zhuǎn)變成“/”，從而訪問到同一地址。但是，當(dāng)我們把“/”換成十六進(jìn)制寫法“”時(shí)，IE不會(huì)對(duì)此進(jìn)行轉(zhuǎn)換。地址中的“”被原樣提交了，抓包結(jié)果如下：
GET /yddownview.asp?id=3 HTTP/1.1
當(dāng)IIS收到并做出解析時(shí)，又會(huì)將還原成“”。這樣，IIS中網(wǎng)址的相對(duì)路徑就變成/yddownview.asp，這一點(diǎn)很重要，問題正是從這里開始的。
在ASP網(wǎng)頁(yè)中，凡調(diào)用數(shù)據(jù)庫(kù)時(shí)，都會(huì)用到一個(gè)連接數(shù)據(jù)庫(kù)的網(wǎng)頁(yè)Conn.asp，它會(huì)創(chuàng)建一個(gè)數(shù)據(jù)庫(kù)連接對(duì)象，定義要調(diào)用的數(shù)據(jù)庫(kù)路徑，一個(gè)典型的Conn.asp如下：
<%
dim conn
dim dbpath
set conn=server.createobject("adodb.connection")
DBPath = Server.MapPath("admin/rds_dbd32rfd213fg.mdb")
conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & DBPath
%>
大家注意第４句：“DBPath = Server.MapPath("admin/rds_dbd32rfd213fg.mdb")”，Server.MapPath方法的作用是將網(wǎng)站中的 相對(duì)路徑轉(zhuǎn)變成物理上的絕對(duì)路徑，為何要這樣？因?yàn)檫B接數(shù)據(jù)庫(kù)時(shí)，須指明它的絕對(duì)路徑才能讀取和寫入。那什么是相對(duì)路徑、絕對(duì)路徑？IIS為了不讓訪問者 知道真實(shí)的實(shí)際路徑，并且確保網(wǎng)站不因變換地址而影響使用，它采用了一種相對(duì)路徑來表示目錄與文件之間的關(guān)系。也就是網(wǎng)址目錄只表示從根目錄起的相對(duì)位 置。比如網(wǎng)站：http://219.237.81.46的根目錄為：“D:111”，雨點(diǎn)下載目錄則在根目錄（D:111）內(nèi)的“yddown” 下，我們網(wǎng)站訪問該站時(shí)，就是在訪問D:111yddown目錄，而http://219.237.81.46/yddown/admin/只表明 了Admin與Yddown這個(gè)目錄的相對(duì)關(guān)系，把這個(gè)網(wǎng)站放在E盤，也一樣不改變Admin位于Yddown目錄下的關(guān)系。
當(dāng)Server.MapPath方法將相對(duì)路徑轉(zhuǎn)為真實(shí)路徑時(shí)，它實(shí)際是三部分路徑加在一起得到真實(shí)路徑的：網(wǎng)頁(yè)目前執(zhí)行時(shí)所在的相對(duì)路徑，也就 是從網(wǎng)站物理根目錄起的相對(duì)路徑，比如上面例子中Conn.asp處在從根目錄起的“/yddown/”下；然后調(diào)用的數(shù)據(jù)庫(kù)的相對(duì)路徑是admin /rds_dbd32rfd213fg.mdb，這樣就得到從根目錄起的完整相對(duì)路徑：“/yddown/admin /rds_dbd32rfd213fg.mdb”。這些都只是相對(duì)的路徑，如何變?yōu)檎鎸?shí)路徑呢？
設(shè)置過IIS的人都會(huì)知道，每一個(gè)網(wǎng)站，都必須指定它在硬盤上的物理目錄，比如上例中，網(wǎng)站根目錄所在的物理目錄 為：“D:111”，Server.MapPath方法正是通過把“網(wǎng)站根目錄的物理地址＋完整的相對(duì)路徑”，從而得到真實(shí)的物理路徑，數(shù)據(jù)庫(kù)在硬盤上 的物理路徑是：D:111yddownadmin ds_dbd32rfd213fg.mdb。IIS以“”表示真實(shí)路徑的目錄關(guān)系，而以 “/”表示虛擬路徑，這可能就是IE會(huì)自動(dòng)把我們地址中的“”轉(zhuǎn)為“/”的原因。
明白這些，我們?cè)賮砝斫獗��?kù)就不難了，當(dāng)我們提交：http://219.237.81.46/yddownview.asp?id=3 時(shí)，View.asp調(diào)用Conn.asp后，得到的網(wǎng)頁(yè)相對(duì)路徑是這樣的：“/yddown”，再加上“admin /rds_dbd32rfd213fg.mdb”，就得到“/yddown＋admin/rds_dbd32rfd213fg.mdb”。在IIS 中，“/”和“”代表著不同的意義，遇到了“”時(shí)，認(rèn)為它已到了根目錄所在的物理路徑，不再往上解析（為何不再往上解析？后面還會(huì)分析），于是網(wǎng)站的 完整相對(duì)路徑變成了：“admin/rds_dbd32rfd213fg.mdb”，再加上根目錄的物理路徑，得到的真實(shí)路徑變成：“D:111 admin ds_dbd32rfd213fg.mdb”，而這個(gè)路徑是不存在的，數(shù)據(jù)庫(kù)連接當(dāng)然會(huì)失敗，于是IIS會(huì)報(bào)錯(cuò)，并給出錯(cuò)誤原因：
Microsoft JET Database Engine 錯(cuò)誤 '80004005'
'D:111admin ds_dbd32rfd213fg.mdb'不是一個(gè)有效的路徑。 確定路徑名稱拼寫是
否正確，以及是否連接到文件存放的服務(wù)器。
/yddown/conn.asp，行12
這就是暴庫(kù)方法的來歷。
《再談暴庫(kù)的利用》一文中說，必須是網(wǎng)址中的第二級(jí)目錄才可以成功，第一個(gè)不行。我們從理論上來分析一下，看到底有無規(guī)律。還以上面網(wǎng)址為 例，如果將第一個(gè)“/”換成“”，得到的網(wǎng)站相對(duì)路徑變成“yddows/admin/rds_dbd32rfd213fg.mdb”，解析到“” 時(shí)，認(rèn)為已到物理目錄，不再往前解析。而事實(shí)上，它確實(shí)也是根目錄，所以得到的物理路徑為：“D:111dydowadmin ds_dbd32rfd213fg.mdb”，這個(gè)路徑是正確的，所以不會(huì)出錯(cuò)，當(dāng)然不會(huì)暴出數(shù)據(jù)庫(kù)路徑。
第二個(gè)“/”換成“”的情況，我們上面已作分析，那是不是真的就是二級(jí)頁(yè)面才可以暴出呢？事實(shí)上，只是因?yàn)槎��?jí)頁(yè)面較為常見，并不是真理。如果這個(gè)下載系統(tǒng)是某一個(gè)網(wǎng)站中的三級(jí)目錄，那第三個(gè)“/”成功的可能性更大。也就是說，最右邊第一個(gè)成功可能性大！
我先舉個(gè)例子，再說原因：
http://nice.xmu.edu.cn/channely/blog/showlog.asp?cat_id=31&log_id=246
這個(gè)網(wǎng)址變第二個(gè)“/”為“”時(shí)，網(wǎng)站打開很慢，但沒有出錯(cuò)。當(dāng)我們把第三個(gè)“/”變成“”后，提交：
http://nice.xmu.edu.cn/channely/blogshowlog.asp?cat_id=31&log_id=246
數(shù)據(jù)庫(kù)暴出來了：
Microsoft JET Database Engine 錯(cuò)誤 '80004005'
'H:channelylog_mdb)dlog_mdb).asp'不是一個(gè)有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務(wù)器。
/channely/blog/conn.asp，行18
為何這樣？這是因?yàn)榫W(wǎng)站用了虛擬目錄，也就是說這個(gè)網(wǎng)站的子目錄Channely并不在網(wǎng)站根目錄內(nèi)。設(shè)置過IIS的人會(huì)知道，可以將網(wǎng)站目錄外 的一個(gè)真實(shí)物理目錄設(shè)置為網(wǎng)站的虛擬目錄。也就是說，網(wǎng)站的相對(duì)對(duì)徑并不總是從根目錄算起，很可能在某個(gè)子目錄就指向了物理目錄。

上面的結(jié)果很顯然，Channely已位于H：盤的根目錄上，上面再?zèng)]有目錄。事實(shí)上，很可能網(wǎng)站在D：盤或E：盤，而通過IIS中設(shè)置Channely虛擬子目錄指向網(wǎng)站根目錄以外的“H:channely”。
這里，我們可以更清楚的看到，微軟IIS為何沒有到根目錄，只要遇上“”就認(rèn)為已到物理絕對(duì)路徑，不再往上解析的原因，就是為了處理這種網(wǎng)站虛 擬目錄與根目錄不在一起的情況。它優(yōu)先查詢每個(gè)目錄是否指向了物理路徑，如果指向了，則把它換成絕對(duì)路徑，而它上面的相對(duì)地址不再解析轉(zhuǎn)換。
從以上分析可知，我們只有在數(shù)據(jù)庫(kù)相對(duì)地址和它的目錄絕對(duì)地址之間使用“”（“％５ｃ”）才能達(dá)到目的。上例中，如果在第二處使用，它只會(huì)影響 到IIS尋找虛擬的Channely目錄地址，而Conn.asp中解析出的數(shù)據(jù)庫(kù)地“H:channelyloglog_mdb )dlog_mdb).asp”仍是對(duì)的。
《再談暴庫(kù)的利用》中還說了一種針對(duì)只有一級(jí)目錄的解決方法：“其實(shí)一級(jí)目錄我們也同樣可以成功的，我們可以通過構(gòu)造一個(gè)多級(jí)目錄來達(dá)到暴庫(kù)的目的。如：
http://www.target.com/noexists/..list.asp?id=1
這樣大家就會(huì)有新的驚喜了，呵呵。”真的嗎？從理論上分析，這種方法是不會(huì)成功的。因?yàn)橛龅?ldquo;”時(shí)，頁(yè)面不再解析，所以中間構(gòu)造的目錄不論是真是假，都是不起作用而被舍棄了，相對(duì)路徑還是到了根目錄，路徑不會(huì)出錯(cuò)。為了證明，我特意找了一個(gè)例子：
http://www.om88.com/Article_Show.asp?ArticleID=481
這個(gè)網(wǎng)站我們先用Conn.asp方法暴出數(shù)據(jù)庫(kù)(后面將講解這個(gè)方法），說明服務(wù)器和網(wǎng)站設(shè)置是可以暴庫(kù)的。提交：
http://www.om88.com/inc/conn.asp
可以看到是可以暴庫(kù)的，我們?cè)偬峤唬?
http://www.om88.com/abc/..Article_Show.asp?ArticleID=481
卻暴不出庫(kù)，仍得到正常頁(yè)面（換成存在的路徑結(jié)果也一樣），但圖片無法顯示。這是因?yàn)橄鄬?duì)路徑變了，所以無法正確找到圖片路徑，但絕對(duì)路徑解析時(shí)被“”舍棄了，沒有出錯(cuò)，當(dāng)然暴不出庫(kù)了。

Conn.asp暴庫(kù)大法
這里的Conn.asp只是表示數(shù)據(jù)庫(kù)調(diào)用文件，因?yàn)槎鄶?shù)都是這個(gè)名字（有些網(wǎng)站改名，我們也視同Conn.asp）。其實(shí)，這種暴庫(kù)法是最先出 現(xiàn)的，以前很多牛人都對(duì)此進(jìn)行過探討，我記得黑防也在特別早的時(shí)候?qū)ｉT討論了這個(gè)方法。只是在“”暴庫(kù)大法出現(xiàn)后，倒較少有人提及。其實(shí)個(gè)人認(rèn)為，“ ”暴大法隨著服務(wù)器設(shè)置安全性的加強(qiáng)，用武之地會(huì)越來越少。而Conn.asp暴庫(kù)大法發(fā)揮的余地更大，可以人為構(gòu)造，臭要飯的當(dāng)年著名的動(dòng)網(wǎng)大挪移實(shí) 現(xiàn)暴庫(kù)，其實(shí)也屬于此類。
在上面http://www.om88.com/的一例中，用“”暴不出數(shù)據(jù)庫(kù)路徑，因?yàn)闆]有二級(jí)目錄，但用第二種卻可以暴出，它是動(dòng)力系統(tǒng)的。我們?cè)賮砜戳硗庖粋�(gè)盜帥的例子：http://www.51see.org/
提交：
http://www.51see.org/db/user.asp
得到如下結(jié)果：。
“Microsoft JET Database Engine 錯(cuò)誤 '80004005'
'd:Hostingwwwrootuilady_comhtdocsdbdbdownloadwoaini12345.asp'不是一個(gè)有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務(wù)器。
/db/user.asp，行6 ”
有人可能會(huì)說，這么簡(jiǎn)單就暴庫(kù)，好爽！是不是所有網(wǎng)站都可以這樣��？當(dāng)然不是，已作了防護(hù)的站點(diǎn)肯定不行，沒作防護(hù)的，要暴庫(kù)也是有條件的。如果說第一種暴庫(kù)法是利用了絕對(duì)路徑出錯(cuò)，那么，這種暴庫(kù)法就是利用了相對(duì)路徑出錯(cuò)。
一般來說，只要Conn.asp不在根目錄的系統(tǒng)，而調(diào)用文件在根目錄，就會(huì)出現(xiàn)這種問題。當(dāng)然這種說法也是經(jīng)驗(yàn)性的，準(zhǔn)確的說就是，Conn.asp與調(diào)用它的文件如果相對(duì)位置改變了，就會(huì)報(bào)錯(cuò)，暴出數(shù)據(jù)庫(kù)路徑。這樣說可能有人不明白，不要緊，接著看你就會(huì)明白的。
我們從動(dòng)力文章系統(tǒng)說起。
動(dòng)力文章系統(tǒng)的Conn.asp位于系統(tǒng)下的INC目錄下，而很多調(diào)用它的文件在系統(tǒng)根目錄下，比如User_ChkLogin.asp等，這樣 當(dāng)Conn.asp執(zhí)行時(shí)，它是在系統(tǒng)根目錄“D:wwwrootzyx688wwwroot”下執(zhí)行的。因此，Conn.asp文件中，調(diào)用數(shù) 據(jù)庫(kù)時(shí)它考慮到執(zhí)行時(shí)的目錄路徑，因而數(shù)據(jù)庫(kù)的相對(duì)地址寫成如下：
db="database/fp360609.asp"
這樣，當(dāng)它在系統(tǒng)根目錄下執(zhí)行時(shí)，數(shù)據(jù)庫(kù)的相對(duì)路徑為根目錄下的“database”目錄，但當(dāng)我們直接請(qǐng)求它時(shí)，它工作的當(dāng)前目錄是在根目錄下 的INC目錄內(nèi)，這時(shí)數(shù)據(jù)庫(kù)的相對(duì)路徑就變成了“inc/database/fp360609.asp”，這樣它當(dāng)然出錯(cuò)，得到的絕對(duì)路徑中也多出了 “inc”。為了讓大家看得更清楚，我們舉一個(gè)可以用兩種方法暴庫(kù)的網(wǎng)站，比較一下看有何不同。提交：
http://www.pofen.com/sc/downshow.asp?id=437
得到：
“Microsoft JET Database Engine 錯(cuò)誤 '80004005'
'D:Webdatapofen.comscdbdownload.mdb'不是一個(gè)有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務(wù)器。
/sc/down/db/user.asp，行6 ”
再提交：
http://www.pofen.com/sc/down/db/user.asp
得到：
Microsoft JET Database Engine 錯(cuò)誤 '80004005'
'D:Webdatapofen.comscdowndbdbdownload.mdb'不是一個(gè)有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務(wù)器。
/sc/down/db/user.asp，行6
兩種方法得到的絕對(duì)路徑，一個(gè)比實(shí)際路徑少了，一個(gè)則多了，這兩個(gè)系統(tǒng)都是因?yàn)镃onn.asp不在系統(tǒng)根目錄下而引起的。那是不是 Conn.asp放在根目錄，與調(diào)用的文件在一個(gè)目錄下就無事呢？如果在一起，當(dāng)然沒事，但牛人自有牛法子，可以通過構(gòu)造方法來造成相對(duì)路徑變化，一樣能 達(dá)到暴庫(kù)的目的。比如，動(dòng)網(wǎng)的大挪移手法，將Conn.asp移位，從而暴庫(kù)。
當(dāng)然，實(shí)際操作中，因?yàn)镃onn.asp移走后，網(wǎng)站無法工作，所以沒有成功，但這種思路還是給很多人啟發(fā)。如果有一種方法可以復(fù)制而不是移動(dòng)， 或者說，移動(dòng)的不是Conn.asp,而是調(diào)用Conn.asp的其它文件，比如Chklogin之類，理論上就可以成功。今天剛看到一個(gè)暴動(dòng)易系統(tǒng)路徑 的最新方法，其原理就是構(gòu)造錯(cuò)誤而達(dá)到獲得真實(shí)路徑的目的。

防范暴庫(kù)
說白了，暴庫(kù)是因?yàn)镮IS服務(wù)器會(huì)對(duì)每個(gè)執(zhí)行錯(cuò)誤給出詳細(xì)說明，并停止執(zhí)行，IIS的默認(rèn)設(shè)置又是將錯(cuò)誤信息返回給用戶。因此，要避免暴庫(kù)，就應(yīng)改變IIS的默認(rèn)設(shè)置，選取錯(cuò)誤時(shí)只給一個(gè)出錯(cuò)的通知，不給詳細(xì)信息。
其實(shí)，有些虛擬主機(jī)為了便于站長(zhǎng)調(diào)試，一般不關(guān)掉信息返回，作為網(wǎng)站管理者，又無法對(duì)虛擬主機(jī)設(shè)置時(shí)，只能在網(wǎng)頁(yè)中加強(qiáng)防范。就是在可能出錯(cuò)的頁(yè) 面加上這一句：“On Error Resume Next”。它的意思是出錯(cuò)后，恢復(fù)執(zhí)行下面的語句，也就是不理會(huì)出錯(cuò)，當(dāng)然就不會(huì)給出錯(cuò)誤信息了。動(dòng)易系統(tǒng)3.62版加上這句話后，現(xiàn)在就暴不出路徑 了，而天意商務(wù)網(wǎng)的Conn.asp也不在根目錄，但因?yàn)榧恿诉@句，也暴不出數(shù)據(jù)庫(kù)了。