解析暴库漏洞原理及规律

我看暴库漏洞原理及规律
SQL注入流行很久了，我们找漏洞注入目的无非是想得到数据库内的东西，比如用户名密码等，更进一步的MSSQL数据库还可以借此获得权限。基于Access的基础来说，如果我们不用注入就可以得到整个数据库，不是更好吗？于是暴库成了一个比注入更简单的入侵手段。
有关暴库的方法，高手们常在入侵文章中提到，但多是一笔带过，有些就某一个方法谈的，也多是就方法进行探讨。最近有一篇《再谈\\暴库的利用》的文章，算是对暴库进行了一些总结，因而在网是流传很广。但仍没有谈及原理，而且结论也只是就于经验，似是而非，于是决定来谈谈暴库的原理与规律。不到之处，大家多指教。

“\\”暴库大法
这种方法被认为是暴库绝招，很是流行了一阵，但是和其它漏洞一样，随着知道的人多了，防备也加强了，没以前那么有效。这种方法简单点说就是在打开网页时，把网址址中的“/”换成“\\”，然后提交，就可以暴出数据库的路径。
　　实际上，并不是所有网址都有效，需要“asp?id=”这样的网页地址，或者说表示有调用数据库的行为的地址。如果你确认这个网页有调用数据库的，后面不是这样的也可以，比如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

这是黑防实验室的一个系统，暴库是小编们故意开放的，因为它的关口不是注入，而是进入后台后如何获得WebShell。可以看到我们直接获取了数据库地址，可以下载了。
现在很多人都知道这个方法了，我就不多举例了。但清楚暴库原理的人估计是不多的，有人成功，有人不成功，《再谈\\暴库的利用》一文总结说，须变换第二个“/”为“\\”才行。很有实用性，但这个结论只是一种经验，其实并不正确，让我们先看看它的原理。
“\\”暴库法，它不是网页本身的漏洞，而是利用了IIS解码方式中的一个特性，如果IIS安全设置不周全，而网页设计者未考虑IIS错误，就会被人利用。为何要用“\\”？它实际上是“\\”的十六进制代码，也就是“\\”的另一种表示法。在电脑中，它们是同一个东东，但提交“\\”和“\\”却会产生不同的结果。在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中网址的相对路径就变成/yddown\\view.asp，这一点很重要，问题正是从这里开始的。
在ASP网页中，凡调用数据库时，都会用到一个连接数据库的网页Conn.asp，它会创建一个数据库连接对象，定义要调用的数据库路径，一个典型的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方法的作用是将网站中的相对路径转变成物理上的绝对路径，为何要这样？因为连接数据库时，须指明它的绝对路径才能读取和写入。那什么是相对路径、绝对路径？IIS为了不让访问者知道真实的实际路径，并且确保网站不因变换地址而影响使用，它采用了一种相对路径来表示目录与文件之间的关系。也就是网址目录只表示从根目录起的相对位置。比如网站：http://219.237.81.46的根目录为：“D:\\111\\”，雨点下载目录则在根目录（D:\\111）内的“yddown”下，我们网站访问该站时，就是在访问D:\\111\\yddown\\目录，而http://219.237.81.46/yddown/admin/只表明了Admin与Yddown这个目录的相对关系，把这个网站放在E盘，也一样不改变Admin位于Yddown目录下的关系。
当Server.MapPath方法将相对路径转为真实路径时，它实际是三部分路径加在一起得到真实路径的：网页目前执行时所在的相对路径，也就是从网站物理根目录起的相对路径，比如上面例子中Conn.asp处在从根目录起的“/yddown/”下；然后调用的数据库的相对路径是admin/rds_dbd32rfd213fg.mdb，这样就得到从根目录起的完整相对路径：“/yddown/admin/rds_dbd32rfd213fg.mdb”。这些都只是相对的路径，如何变为真实路径呢？
　　设置过IIS的人都会知道，每一个网站，都必须指定它在硬盘上的物理目录，比如上例中，网站根目录所在的物理目录为：“D:\\111”，Server.MapPath方法正是通过把“网站根目录的物理地址＋完整的相对路径”，从而得到真实的物理路径，数据库在硬盘上的物理路径是：D:\\111\\yddown\\admin\\rds_dbd32rfd213fg.mdb。IIS以“\\”表示真实路径的目录关系，而以“/”表示虚拟路径，这可能就是IE会自动把我们地址中的“\\”转为“/”的原因。
　　明白这些，我们再来理解暴库就不难了，当我们提交：http://219.237.81.46/yddown\\view.asp?id=3时，View.asp调用Conn.asp后，得到的网页相对路径是这样的：“/yddown\\”，再加上“admin/rds_dbd32rfd213fg.mdb”，就得到“/yddown\\＋admin/rds_dbd32rfd213fg.mdb”。在IIS中，“/”和“\\”代表着不同的意义，遇到了“\\”时，认为它已到了根目录所在的物理路径，不再往上解析（为何不再往上解析？后面还会分析），于是网站的完整相对路径变成了：“admin/rds_dbd32rfd213fg.mdb”，再加上根目录的物理路径，得到的真实路径变成：“D:\\111\\admin\\rds_dbd32rfd213fg.mdb”，而这个路径是不存在的，数据库连接当然会失败，于是IIS会报错，并给出错误原因：
Microsoft JET Database Engine 错误 '80004005'
'D:\\111\\admin\\rds_dbd32rfd213fg.mdb'不是一个有效的路径。 确定路径名称拼写是
否正确，以及是否连接到文件存放的服务器。
/yddown/conn.asp，行12
这就是暴库方法的来历。
　　《再谈\\暴库的利用》一文中说，必须是网址中的第二级目录才可以成功，第一个不行。我们从理论上来分析一下，看到底有无规律。还以上面网址为例，如果将第一个“/”换成“\\”，得到的网站相对路径变成“\\yddows/admin/rds_dbd32rfd213fg.mdb”，解析到“\\”时，认为已到物理目录，不再往前解析。而事实上，它确实也是根目录，所以得到的物理路径为：“D:\\111\\dydow\\admin\\rds_dbd32rfd213fg.mdb”，这个路径是正确的，所以不会出错，当然不会暴出数据库路径。
第二个“/”换成“\\”的情况，我们上面已作分析，那是不是真的就是二级页面才可以暴出呢？事实上，只是因为二级页面较为常见，并不是真理。如果这个下载系统是某一个网站中的三级目录，那第三个“/”成功的可能性更大。也就是说，最右边第一个成功可能性大！
我先举个例子，再说原因：
http://nice.xmu.edu.cn/channely/blog/showlog.asp?cat_id=31&log_id=246
这个网址变第二个“/”为“\\”时，网站打开很慢，但没有出错。当我们把第三个“/”变成“\\”后，提交：
http://nice.xmu.edu.cn/channely/blog\\showlog.asp?cat_id=31&log_id=246
数据库暴出来了：
Microsoft JET Database Engine 错误 '80004005'
'H:\\channely\\log_mdb\\)dlog_mdb).asp'不是一个有效的路径。 确定路径名称拼写是否正确，以及是否连接到文件存放的服务器。
/channely/blog/conn.asp，行18
为何这样？这是因为网站用了虚拟目录，也就是说这个网站的子目录Channely并不在网站根目录内。设置过IIS的人会知道，可以将网站目录外的一个真实物理目录设置为网站的虚拟目录。也就是说，网站的相对对径并不总是从根目录算起，很可能在某个子目录就指向了物理目录。

上面的结果很显然，Channely已位于H：盘的根目录上，上面再没有目录。事实上，很可能网站在D：盘或E：盘，而通过IIS中设置Channely虚拟子目录指向网站根目录以外的“H:\\channely\\”。
这里，我们可以更清楚的看到，微软IIS为何没有到根目录，只要遇上“\\”就认为已到物理绝对路径，不再往上解析的原因，就是为了处理这种网站虚拟目录与根目录不在一起的情况。它优先查询每个目录是否指向了物理路径，如果指向了，则把它换成绝对路径，而它上面的相对地址不再解析转换。
从以上分析可知，我们只有在数据库相对地址和它的目录绝对地址之间使用“\\”（“％５ｃ”）才能达到目的。上例中，如果在第二处使用，它只会影响到IIS寻找虚拟的Channely目录地址，而Conn.asp中解析出的数据库地“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
这个网站我们先用Conn.asp方法暴出数据库(后面将讲解这个方法），说明服务器和网站设置是可以暴库的。提交：
http://www.om88.com/inc/conn.asp
可以看到是可以暴库的，我们再提交：
http://www.om88.com/abc/..\\Article_Show.asp?ArticleID=481
却暴不出库，仍得到正常页面（换成存在的路径结果也一样），但图片无法显示。这是因为相对路径变了，所以无法正确找到图片路径，但绝对路径解析时被“\\”舍弃了，没有出错，当然暴不出库了。

Conn.asp暴库大法
这里的Conn.asp只是表示数据库调用文件，因为多数都是这个名字（有些网站改名，我们也视同Conn.asp）。其实，这种暴库法是最先出现的，以前很多牛人都对此进行过探讨，我记得黑防也在特别早的时候专门讨论了这个方法。只是在“\\”暴库大法出现后，倒较少有人提及。其实个人认为，“\\”暴大法随着服务器设置安全性的加强，用武之地会越来越少。而Conn.asp暴库大法发挥的余地更大，可以人为构造，臭要饭的当年著名的动网大挪移实现暴库，其实也属于此类。
在上面http://www.om88.com/的一例中，用“\\”暴不出数据库路径，因为没有二级目录，但用第二种却可以暴出，它是动力系统的。我们再来看另外一个盗帅的例子：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 ”
有人可能会说，这么简单就暴库，好爽！是不是所有网站都可以这样啊？当然不是，已作了防护的站点肯定不行，没作防护的，要暴库也是有条件的。如果说第一种暴库法是利用了绝对路径出错，那么，这种暴库法就是利用了相对路径出错。
一般来说，只要Conn.asp不在根目录的系统，而调用文件在根目录，就会出现这种问题。当然这种说法也是经验性的，准确的说就是，Conn.asp与调用它的文件如果相对位置改变了，就会报错，暴出数据库路径。这样说可能有人不明白，不要紧，接着看你就会明白的。
我们从动力文章系统说起。
动力文章系统的Conn.asp位于系统下的INC目录下，而很多调用它的文件在系统根目录下，比如User_ChkLogin.asp等，这样当Conn.asp执行时，它是在系统根目录“D:\\wwwroot\\zyx688\\wwwroot\\”下执行的。因此，Conn.asp文件中，调用数据库时它考虑到执行时的目录路径，因而数据库的相对地址写成如下：
db="database/fp360609.asp"
这样，当它在系统根目录下执行时，数据库的相对路径为根目录下的“database”目录，但当我们直接请求它时，它工作的当前目录是在根目录下的INC目录内，这时数据库的相对路径就变成了“inc/database/fp360609.asp”，这样它当然出错，得到的绝对路径中也多出了“inc”。为了让大家看得更清楚，我们举一个可以用两种方法暴库的网站，比较一下看有何不同。提交：
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
两种方法得到的绝对路径，一个比实际路径少了，一个则多了，这两个系统都是因为Conn.asp不在系统根目录下而引起的。那是不是Conn.asp放在根目录，与调用的文件在一个目录下就无事呢？如果在一起，当然没事，但牛人自有牛法子，可以通过构造方法来造成相对路径变化，一样能达到暴库的目的。比如，动网的大挪移手法，将Conn.asp移位，从而暴库。
当然，实际操作中，因为Conn.asp移走后，网站无法工作，所以没有成功，但这种思路还是给很多人启发。如果有一种方法可以复制而不是移动，或者说，移动的不是Conn.asp,而是调用Conn.asp的其它文件，比如Chklogin之类，理论上就可以成功。今天刚看到一个暴动易系统路径的最新方法，其原理就是构造错误而达到获得真实路径的目的。

防范暴库
说白了，暴库是因为IIS服务器会对每个执行错误给出详细说明，并停止执行，IIS的默认设置又是将错误信息返回给用户。因此，要避免暴库，就应改变IIS的默认设置，选取错误时只给一个出错的通知，不给详细信息。
其实，有些虚拟主机为了便于站长调试，一般不关掉信息返回，作为网站管理者，又无法对虚拟主机设置时，只能在网页中加强防范。就是在可能出错的页面加上这一句：“On Error Resume Next”。它的意思是出错后，恢复执行下面的语句，也就是不理会出错，当然就不会给出错误信息了。动易系统3.62版加上这句话后，现在就暴不出路径了，而天意商务网的Conn.asp也不在根目录，但因为加了这句，也暴不出数据库了。