解析暴库漏洞原理及规律

  • A+
所属分类:网络安全

我看暴库漏洞原理及规律

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

%>

大家注意第4句:“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为何没有到根目录,只要遇上“\”就认为已到物理绝对路径,不再往上解析的原因,就是为了处理这种网站虚拟目录与根目录不在一起的情况。它优先查询每个目录是否指向了物理路径,如果指向了,则把它换成绝对路径,而它上面的相对地址不再解析转换。

从以上分析可知,我们只有在数据库相对地址和它的目录绝对地址之间使用“\”(“%5c”)才能达到目的。上例中,如果在第二处使用,它只会影响到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也不在根目录,但因为加了这句,也暴不出数据库了。