| 我看暴庫漏洞原理及規(guī)律
SQL注入流行很久了，我們找漏洞注入目的無非是想得到數(shù)據(jù)庫內的東西，比如用戶名密碼等，更進一步的MSSQL數(shù)據(jù)庫還可以借此獲得權限。基于Access的基礎來說，如果我們不用注入就可以得到整個數(shù)據(jù)庫，不是更好嗎？于是暴庫成了一個比注入更簡單的入侵手段。 有關暴庫的方法，高手們常在入侵文章中提到，但多是一筆帶過，有些就某一個方法談的，也多是就方法進行探討。最近有一篇《再談\暴庫的利用》的文章，算是對暴庫進行了一些總結，因而在網(wǎng)是流傳很廣。但仍沒有談及原理，而且結論也只是就于經(jīng)驗，似是而非，于是決定來談談暴庫的原理與規(guī)律。不到之處，大家多指教。 “\”暴庫大法 這種方法被認為是暴庫絕招，很是流行了一陣，但是和其它漏洞一樣，隨著知道的人多了，防備也加強了，沒以前那么有效。這種方法簡單點說就是在打開網(wǎng)頁時，把網(wǎng)址址中的“/”換成“\”，然后提交，就可以暴出數(shù)據(jù)庫的路徑。 實際上，并不是所有網(wǎng)址都有效，需要“asp?id=”這樣的網(wǎng)頁地址，或者說表示有調用數(shù)據(jù)庫的行為的地址。如果你確認這個網(wǎng)頁有調用數(shù)據(jù)庫的，后面不是這樣的也可以，比如Chklogin.asp等也可以（還有其它條件，后面再談）。先舉個黑防第四輪實驗室中的例子： http://219.237.81.46/yddown\view.asp?id=3 把第二個“/”換成“\”： http://219.237.81.46/yddown\view.asp?id=3 提交后會得到如下返回結果： Microsoft JET Database Engine 錯誤 '80004005' 'D:\111\admin\rds_dbd32rfd213fg.mdb'不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。 /yddown/conn.asp，行12 這是黑防實驗室的一個系統(tǒng)，暴庫是小編們故意開放的，因為它的關口不是注入，而是進入后臺后如何獲得WebShell。可以看到我們直接獲取了數(shù)據(jù)庫地址，可以下載了。 現(xiàn)在很多人都知道這個方法了，我就不多舉例了。但清楚暴庫原理的人估計是不多的，有人成功，有人不成功，《再談\暴庫的利用》一文總結說，須變換第二個“/”為“\”才行。很有實用性，但這個結論只是一種經(jīng)驗，其實并不正確，讓我們先看看它的原理。 “\”暴庫法，它不是網(wǎng)頁本身的漏洞，而是利用了IIS解碼方式中的一個特性，如果IIS安全設置不周全，而網(wǎng)頁設計者未考慮IIS錯誤，就會被人利用。為何要用“\”？它實際上是“\”的十六進制代碼，也就是“\”的另一種表示法。在電腦中，它們是同一個東東，但提交“\”和“\”卻會產(chǎn)生不同的結果。在IE中，我們把下面第一個地址中的“/”換成“\”提交： http://219.237.81.46/yddown/view.asp?id=3 http://219.237.81.46/yddown\view.asp?id=3 二者的訪問結果是一樣的。IE會自動把“\”轉變成“/”，從而訪問到同一地址。但是，當我們把“/”換成十六進制寫法“\”時，IE不會對此進行轉換。地址中的“\”被原樣提交了，抓包結果如下： GET /yddown\view.asp?id=3 HTTP/1.1 當IIS收到并做出解析時，又會將\還原成“\”。這樣，IIS中網(wǎng)址的相對路徑就變成/yddown\view.asp，這一點很重要，問題正是從這里開始的。 在ASP網(wǎng)頁中，凡調用數(shù)據(jù)庫時，都會用到一個連接數(shù)據(jù)庫的網(wǎng)頁Conn.asp，它會創(chuàng)建一個數(shù)據(jù)庫連接對象，定義要調用的數(shù)據(jù)庫路徑，一個典型的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)站中的相對路徑轉變成物理上的絕對路徑，為何要這樣？因為連接數(shù)據(jù)庫時，須指明它的絕對路徑才能讀取和寫入。那什么是相對路徑、絕對路徑？IIS為了不讓訪問者知道真實的實際路徑，并且確保網(wǎng)站不因變換地址而影響使用，它采用了一種相對路徑來表示目錄與文件之間的關系。也就是網(wǎng)址目錄只表示從根目錄起的相對位置。比如網(wǎng)站：http://219.237.81.46的根目錄為：“D:\111\”，雨點下載目錄則在根目錄（D:\111）內的“yddown”下，我們網(wǎng)站訪問該站時，就是在訪問D:\111\yddown\目錄，而http://219.237.81.46/yddown/admin/只表明了Admin與Yddown這個目錄的相對關系，把這個網(wǎng)站放在E盤，也一樣不改變Admin位于Yddown目錄下的關系。 當Server.MapPath方法將相對路徑轉為真實路徑時，它實際是三部分路徑加在一起得到真實路徑的：網(wǎng)頁目前執(zhí)行時所在的相對路徑，也就是從網(wǎng)站物理根目錄起的相對路徑，比如上面例子中Conn.asp處在從根目錄起的“/yddown/”下；然后調用的數(shù)據(jù)庫的相對路徑是admin/rds_dbd32rfd213fg.mdb，這樣就得到從根目錄起的完整相對路徑：“/yddown/admin/rds_dbd32rfd213fg.mdb”。這些都只是相對的路徑，如何變?yōu)檎鎸嵚窂侥兀? 設置過IIS的人都會知道，每一個網(wǎng)站，都必須指定它在硬盤上的物理目錄，比如上例中，網(wǎng)站根目錄所在的物理目錄為：“D:\111”，Server.MapPath方法正是通過把“網(wǎng)站根目錄的物理地址＋完整的相對路徑”，從而得到真實的物理路徑，數(shù)據(jù)庫在硬盤上的物理路徑是：D:\111\yddown\admin\rds_dbd32rfd213fg.mdb。IIS以“\”表示真實路徑的目錄關系，而以“/”表示虛擬路徑，這可能就是IE會自動把我們地址中的“\”轉為“/”的原因。 明白這些，我們再來理解暴庫就不難了，當我們提交：http://219.237.81.46/yddown\view.asp?id=3時，View.asp調用Conn.asp后，得到的網(wǎng)頁相對路徑是這樣的：“/yddown\”，再加上“admin/rds_dbd32rfd213fg.mdb”，就得到“/yddown\＋admin/rds_dbd32rfd213fg.mdb”。在IIS中，“/”和“\”代表著不同的意義，遇到了“\”時，認為它已到了根目錄所在的物理路徑，不再往上解析（為何不再往上解析？后面還會分析），于是網(wǎng)站的完整相對路徑變成了：“admin/rds_dbd32rfd213fg.mdb”，再加上根目錄的物理路徑，得到的真實路徑變成：“D:\111\admin\rds_dbd32rfd213fg.mdb”，而這個路徑是不存在的，數(shù)據(jù)庫連接當然會失敗，于是IIS會報錯，并給出錯誤原因： Microsoft JET Database Engine 錯誤 '80004005' 'D:\111\admin\rds_dbd32rfd213fg.mdb'不是一個有效的路徑。 確定路徑名稱拼寫是 否正確，以及是否連接到文件存放的服務器。 /yddown/conn.asp，行12 這就是暴庫方法的來歷。 《再談\暴庫的利用》一文中說，必須是網(wǎng)址中的第二級目錄才可以成功，第一個不行。我們從理論上來分析一下，看到底有無規(guī)律。還以上面網(wǎng)址為例，如果將第一個“/”換成“\”，得到的網(wǎng)站相對路徑變成“\yddows/admin/rds_dbd32rfd213fg.mdb”，解析到“\”時，認為已到物理目錄，不再往前解析。而事實上，它確實也是根目錄，所以得到的物理路徑為：“D:\111\dydow\admin\rds_dbd32rfd213fg.mdb”，這個路徑是正確的，所以不會出錯，當然不會暴出數(shù)據(jù)庫路徑。 第二個“/”換成“\”的情況，我們上面已作分析，那是不是真的就是二級頁面才可以暴出呢？事實上，只是因為二級頁面較為常見，并不是真理。如果這個下載系統(tǒng)是某一個網(wǎng)站中的三級目錄，那第三個“/”成功的可能性更大。也就是說，最右邊第一個成功可能性大！ 我先舉個例子，再說原因： http://nice.xmu.edu.cn/channely/blog/showlog.asp?cat_id=31&log_id=246 這個網(wǎng)址變第二個“/”為“\”時，網(wǎng)站打開很慢，但沒有出錯。當我們把第三個“/”變成“\”后，提交： http://nice.xmu.edu.cn/channely/blog\showlog.asp?cat_id=31&log_id=246 數(shù)據(jù)庫暴出來了： Microsoft JET Database Engine 錯誤 '80004005' 'H:\channely\log_mdb\)dlog_mdb).asp'不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。 /channely/blog/conn.asp，行18 為何這樣？這是因為網(wǎng)站用了虛擬目錄，也就是說這個網(wǎng)站的子目錄Channely并不在網(wǎng)站根目錄內。設置過IIS的人會知道，可以將網(wǎng)站目錄外的一個真實物理目錄設置為網(wǎng)站的虛擬目錄。也就是說，網(wǎng)站的相對對徑并不總是從根目錄算起，很可能在某個子目錄就指向了物理目錄。 上面的結果很顯然，Channely已位于H：盤的根目錄上，上面再沒有目錄。事實上，很可能網(wǎng)站在D：盤或E：盤，而通過IIS中設置Channely虛擬子目錄指向網(wǎng)站根目錄以外的“H:\channely\”。 這里，我們可以更清楚的看到，微軟IIS為何沒有到根目錄，只要遇上“\”就認為已到物理絕對路徑，不再往上解析的原因，就是為了處理這種網(wǎng)站虛擬目錄與根目錄不在一起的情況。它優(yōu)先查詢每個目錄是否指向了物理路徑，如果指向了，則把它換成絕對路徑，而它上面的相對地址不再解析轉換。 從以上分析可知，我們只有在數(shù)據(jù)庫相對地址和它的目錄絕對地址之間使用“\”（“％５ｃ”）才能達到目的。上例中，如果在第二處使用，它只會影響到IIS尋找虛擬的Channely目錄地址，而Conn.asp中解析出的數(shù)據(jù)庫地“H:\channely\blog\log_mdb\)dlog_mdb).asp”仍是對的。 《再談\暴庫的利用》中還說了一種針對只有一級目錄的解決方法：“其實一級目錄我們也同樣可以成功的，我們可以通過構造一個多級目錄來達到暴庫的目的。如： http://www.target.com/noexists/..\list.asp?id=1 這樣大家就會有新的驚喜了，呵呵。”真的嗎？從理論上分析，這種方法是不會成功的。因為遇到“\”時，頁面不再解析，所以中間構造的目錄不論是真是假，都是不起作用而被舍棄了，相對路徑還是到了根目錄，路徑不會出錯。為了證明，我特意找了一個例子： http://www.om88.com/Article_Show.asp?ArticleID=481 這個網(wǎng)站我們先用Conn.asp方法暴出數(shù)據(jù)庫(后面將講解這個方法），說明服務器和網(wǎng)站設置是可以暴庫的。提交： http://www.om88.com/inc/conn.asp 可以看到是可以暴庫的，我們再提交： http://www.om88.com/abc/..\Article_Show.asp?ArticleID=481 卻暴不出庫，仍得到正常頁面（換成存在的路徑結果也一樣），但圖片無法顯示。這是因為相對路徑變了，所以無法正確找到圖片路徑，但絕對路徑解析時被“\”舍棄了，沒有出錯，當然暴不出庫了。 Conn.asp暴庫大法 這里的Conn.asp只是表示數(shù)據(jù)庫調用文件，因為多數(shù)都是這個名字（有些網(wǎng)站改名，我們也視同Conn.asp）。其實，這種暴庫法是最先出現(xiàn)的，以前很多牛人都對此進行過探討，我記得黑防也在特別早的時候專門討論了這個方法。只是在“\”暴庫大法出現(xiàn)后，倒較少有人提及。其實個人認為，“\”暴大法隨著服務器設置安全性的加強，用武之地會越來越少。而Conn.asp暴庫大法發(fā)揮的余地更大，可以人為構造，臭要飯的當年著名的動網(wǎng)大挪移實現(xiàn)暴庫，其實也屬于此類。 在上面http://www.om88.com/的一例中，用“\”暴不出數(shù)據(jù)庫路徑，因為沒有二級目錄，但用第二種卻可以暴出，它是動力系統(tǒng)的。我們再來看另外一個盜帥的例子：http://www.51see.org/ 提交： http://www.51see.org/db/user.asp 得到如下結果：。 “Microsoft JET Database Engine 錯誤 '80004005' 'd:\Hosting\wwwroot\uilady_com\htdocs\db\db\downloadwoaini12345.asp'不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。 /db/user.asp，行6 ” 有人可能會說，這么簡單就暴庫，好爽！是不是所有網(wǎng)站都可以這樣啊？當然不是，已作了防護的站點肯定不行，沒作防護的，要暴庫也是有條件的。如果說第一種暴庫法是利用了絕對路徑出錯，那么，這種暴庫法就是利用了相對路徑出錯。 一般來說，只要Conn.asp不在根目錄的系統(tǒng)，而調用文件在根目錄，就會出現(xiàn)這種問題。當然這種說法也是經(jīng)驗性的，準確的說就是，Conn.asp與調用它的文件如果相對位置改變了，就會報錯，暴出數(shù)據(jù)庫路徑。這樣說可能有人不明白，不要緊，接著看你就會明白的。 我們從動力文章系統(tǒng)說起。 動力文章系統(tǒng)的Conn.asp位于系統(tǒng)下的INC目錄下，而很多調用它的文件在系統(tǒng)根目錄下，比如User_ChkLogin.asp等，這樣當Conn.asp執(zhí)行時，它是在系統(tǒng)根目錄“D:\wwwroot\zyx688\wwwroot\”下執(zhí)行的。因此，Conn.asp文件中，調用數(shù)據(jù)庫時它考慮到執(zhí)行時的目錄路徑，因而數(shù)據(jù)庫的相對地址寫成如下： db="database/fp360609.asp" 這樣，當它在系統(tǒng)根目錄下執(zhí)行時，數(shù)據(jù)庫的相對路徑為根目錄下的“database”目錄，但當我們直接請求它時，它工作的當前目錄是在根目錄下的INC目錄內，這時數(shù)據(jù)庫的相對路徑就變成了“inc/database/fp360609.asp”，這樣它當然出錯，得到的絕對路徑中也多出了“inc”。為了讓大家看得更清楚，我們舉一個可以用兩種方法暴庫的網(wǎng)站，比較一下看有何不同。提交： http://www.pofen.com/sc/down\show.asp?id=437 得到： “Microsoft JET Database Engine 錯誤 '80004005' 'D:\Webdata\pofen.com\sc\db\download.mdb'不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。 /sc/down/db/user.asp，行6 ” 再提交： http://www.pofen.com/sc/down/db/user.asp 得到： Microsoft JET Database Engine 錯誤 '80004005' 'D:\Webdata\pofen.com\sc\down\db\db\download.mdb'不是一個有效的路徑。 確定路徑名稱拼寫是否正確，以及是否連接到文件存放的服務器。 /sc/down/db/user.asp，行6 兩種方法得到的絕對路徑，一個比實際路徑少了，一個則多了，這兩個系統(tǒng)都是因為Conn.asp不在系統(tǒng)根目錄下而引起的。那是不是Conn.asp放在根目錄，與調用的文件在一個目錄下就無事呢？如果在一起，當然沒事，但牛人自有牛法子，可以通過構造方法來造成相對路徑變化，一樣能達到暴庫的目的。比如，動網(wǎng)的大挪移手法，將Conn.asp移位，從而暴庫。 當然，實際操作中，因為Conn.asp移走后，網(wǎng)站無法工作，所以沒有成功，但這種思路還是給很多人啟發(fā)。如果有一種方法可以復制而不是移動，或者說，移動的不是Conn.asp,而是調用Conn.asp的其它文件，比如Chklogin之類，理論上就可以成功。今天剛看到一個暴動易系統(tǒng)路徑的最新方法，其原理就是構造錯誤而達到獲得真實路徑的目的。 防范暴庫 說白了，暴庫是因為IIS服務器會對每個執(zhí)行錯誤給出詳細說明，并停止執(zhí)行，IIS的默認設置又是將錯誤信息返回給用戶。因此，要避免暴庫，就應改變IIS的默認設置，選取錯誤時只給一個出錯的通知，不給詳細信息。 其實，有些虛擬主機為了便于站長調試，一般不關掉信息返回，作為網(wǎng)站管理者，又無法對虛擬主機設置時，只能在網(wǎng)頁中加強防范。就是在可能出錯的頁面加上這一句：“On Error Resume Next”。它的意思是出錯后，恢復執(zhí)行下面的語句，也就是不理會出錯，當然就不會給出錯誤信息了。動易系統(tǒng)3.62版加上這句話后，現(xiàn)在就暴不出路徑了，而天意商務網(wǎng)的Conn.asp也不在根目錄，但因為加了這句，也暴不出數(shù)據(jù)庫了。 |
免責聲明：本站部分文章和圖片均來自用戶投稿和網(wǎng)絡收集，旨在傳播知識，文章和圖片版權歸原作者及原出處所有，僅供學習與參考，請勿用于商業(yè)用途，如果損害了您的權利，請聯(lián)系我們及時修正或刪除。謝謝！
始終以前瞻性的眼光聚焦站長、創(chuàng)業(yè)、互聯(lián)網(wǎng)等領域，為您提供最新最全的互聯(lián)網(wǎng)資訊，幫助站長轉型升級，為互聯(lián)網(wǎng)創(chuàng)業(yè)者提供更加優(yōu)質的創(chuàng)業(yè)信息和品牌營銷服務，與站長一起進步！讓互聯(lián)網(wǎng)創(chuàng)業(yè)者不再孤獨！
掃一掃，關注站長網(wǎng)微信
大家都在看
