夜火博客 个人的碎碎念收集箱

细说暴库的原理与方法

SQL注入流行很久了,我们找漏洞注入目的无非是想得到数据库内的东西,比如用户名密码等。(当然mssql数据库还可以借此获得权限)。如果我们不用注入就可以得到整个数据库,不是更好吗?于是暴库成了一个比注入更简单的的入侵手段。

  有关暴库的方法,高手们常在入侵文章中提高,但多是一笔带过,有些就某一个方法谈的,也多是就方法进行探讨。最近有一篇《再谈%5c暴库的利用》文章,算是对暴库进行了一些总结,因而在网是流传很广。但仍没有谈及原理,而且结论也只是就于经验,似是而非,于是决定来谈谈暴库的原理与规律。

  一,关于"%5c"暴库大法:

  这种方法被认为是暴库绝招,很是流行了一阵(随着知道的人多了,防备也加强了,没以前那么有效了)。这种方法,简单点说就是,打开网页时,把网址址中的"/"换成"%5c",然后提交,就可以暴出数据库的路径。

  实际上,并不是所有网址都有效,需要"asp?id="这样的网页地址(表示有调用数据库的行为),如果你确认这个网页有调用数据库的,后面不是这样的也可以,比如chklogin.asp等也可以。(当然,也还有其它条件,后面再谈。)

  先举个例子,
 

http://219.237.81.46/yddown%5cview.asp?id=3


  把第二个"/"换成"%5c"
 

http://219.237.81.46/yddown%5cview.asp?id=3


  提交后会得到如下结果:   
 

Microsoft JET Database Engine 错误 ’80004005’


’D:111admin ds_dbd32rfd213fg.mdb’不是一个有效的路径。 确定路径名称拼写是否正确,以及是否连接到文件存放的服务器。  
 

/yddown/conn.asp,行12


   (说明:这是黑防实验室的一个网站,暴库是他们故意开放的,因为它的关口不是注入,而是进入后台后如何获得shell)。

  现在很多人都知道这个方法了,我就不多举例了。但清楚暴库原理的人估计是不多的。有人成功,有人不成功,《再谈%5c暴库的利用》一文总结说,须变换第二个"/"为"%5c"才行。很有实用性,但这个结论只是一种经验,其实并不正确。让我们先看看它的原理 "%5c"暴库法,它不是网页本身的漏洞,而是利用了IIS解码方式中的一个特性,如果IIS安全设置不周全,而网页设计者未考虑IIS错误,就会被人利用。

  为何要用"%5c"?它实际上是""的十六进制代码,也就是""的另一种表示法。在电脑中,它们是一个东东。(十六进制转换图)

  但提交""和"%5c"却会产生不同的结果,在ie中,我们把下面第一个地址中的"/"换成""提交:
 

    http://219.237.81.46/yddown/view.asp?id=3

  http://219.237.81.46/yddownview.asp?id=3


  二者的访问结果是一样的。ie会自动把""转变成"/",从而访问到同一地址。

  但是,当我们把"/"换成十六进制写法"%5c"时,ie不会对此进行转换。地址中的"%5c"被原样提交了。这是抓包结果: 
 

GET /yddown%5cview.asp?id=3 HTTP/1.1


  当IIS收到后解析时,又会将%5c还原成""。这样,iis中网址的相对路径就变成/yddownview.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:111yddown目录,而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:111yddownadmin ds_dbd32rfd213fg.mdb。

  在这里,IIS以""表示真实路径的目录关系,而以"/"表示虚拟路径,这可能就是IE会自动把我们地址中的""转为"/"的原因吧。

  明白这些,我们再来理解暴库就不难了,当我们提交http://219.237.81.46/yddown%5cview.asp?id=3时,view.asp调用conn.asp后,得到的网页相对路径是这样的:/yddown (见上),再加上"admin/rds_dbd32rfd213fg.mdb",就得到"/yddown"+admin/rds_dbd32rfd213fg.mdb。在iis中,"/"和""代表着不同的意义,遇到了""时,认为它已到了根目录所在的物理路径,不再往上解析(为何不再往上解析?后面还会分析的),于是网站的完整相对路径变成了
:"admin/rds_dbd32rfd213fg.mdb",再加上根目录的物理路径,得到的真实路径变成:"D:111admin ds_dbd32rfd213fg.mdb",而这个路径是不存在的,数据库连接当然会失败,于是IIS会报错,并给出错误原因:
Microsoft JET Database Engine 错误 ’80004005’ ’D:111admin ds_dbd32rfd213fg.mdb’不是一个有效的路径。 确定路径名称拼写是否正确,以及是否连接到文件存放的服务器。

  /yddown/conn.asp,行12

  这就是暴库语句的来历。

  《再谈%5c暴库的利用》一文中说,必须是网址中的第二个才可以成功,第一个不行。我们从理论上来分析一下,看到底有无规律:
 还以上面网址为例,如果将第一个"/"换成"%5c",得到的网站相对路径变成yddows/admin/rds_dbd32rfd213fg.mdb,解析到""时,认为已到物理目录,不再往前解析。而事实上,它确实也是根目录,所以得到的物理路径为:"D:111dydowadmin ds_dbd32rfd213fg.mdb"
这个路径是正确的,所以不会出错,当然不会暴出数据库路径。

  第二个个"/"换成"%5c"的情况,我们上面已作分析,那是不是真的就第二个可以暴出呢,事实上,它只是因为二级网站较为常见,并不是真理。如果这个下载系统是某一个网站中的三级目录,变第三个也是可以的。有时,变第三个成功的可能性更大。也就是说,最右边第一个成功可能性大。

  不信?我先举个例子,再说原因:
 

http://nice.xmu.edu.cn/channely%5cblog/showlog.asp?cat_id=31&log_id=246


  这个网址,变第二个"/"为"%5c"时,网站打开很慢,但没有出错。

  当我们把第三个"/"变成"%5c"后,提交: 
 

http://nice.xmu.edu.cn/channely/blog%5cshowlog.asp?cat_id=31&log_id=246


  可以看到,数据库暴出来了! 
 

Microsoft JET Database Engine 错误 ’80004005’


 ’H:channelylog_mdb\%29dlog_mdb%29.asp’不是一个有效的路径。 确定路径名称拼写是否正确,以及是否连接到文件存放的服务器。  
 

/channely/blog/conn.asp,行18



为何这样?

  这是因为网站内用了虚拟目录,也就是说这个网站的子目录channely并不在网站根目录内,设置过IIS的人会知道,可以将网站目录外的一个真实物理目录设置为网站的虚拟目录。也就是说,网站的相对对径并不总是从根目录算起,很可能在某个子目录就指向了物理目录。


  上面的结果很显然:channely已位于H:盘的根目录上,上面再没有目录。事实上,很可能网站在d:盘或e:盘,而通过IIS中设置channely虚拟子目录指向网站根目录以外的"H:channely",这里,我们可以更清楚的看到,微软iis为何没有到根目录,只要遇上""就认为已到物理绝对路径,不再往上解析的原因,就是为了处理这种网站虚拟目录与根目录不在一起的情况。它优先查询每个目录是否指向了物理路径,如果指向了,则把它换成绝对路径,而它上面的相对地址不再解析转换。

  从以上分析可知,我们只有在数据库相对地址和它的目录绝对地址之间使用""("%5c"),才能达到目的。上例中,如果在第二处使用,它只会影响到IIS寻找虚拟的channely目录地址,而conn.asp中解析出的数据库地H:channelylog、log_mdb\%29dlog_mdb%29.asp仍是对的,当然不会暴库。

  《再谈%5c暴库的利用》中还说了一种针对只有一级目录的解决方法:

  "其实一级目录我们也同样可以成功的,我们可以通过构造一个多级目录来达到暴库的目的。
  如下:
 

http://www.target.com/noexists/..%5clist.asp?id=1


  这样大家就会有新的惊喜了,呵呵。"

  真的吗?从理论上分析,这种方法是不会成功的。因为遇到"%5c"时,不再解析,所以中间构造的目录,不论是真是假,都是不起作用的,被舍弃了,相对路径还是到了根目录,路径不会出错。

  这个网站我们先用conn.asp方法暴出数据库(后面将讲的),说明服务器和网站设置是可以暴库的。

  得到如下结果 
 

http://www.om88.com/abc/..%5cArticle_Show.asp?ArticleID=481


  却暴不出库,仍得到正常页面(换成存在的路径结果也一样),但图片无法显示。这是因为相对路径变了,所以无法正确找到图片路径,但绝对路径解析时被"%5c"舍弃了,没有出错,当然暴不出库。

  二,conn.asp暴库大法

  这里,conn.asp只是表示数据库调用文件,因为多数都是这个名字(有些网站改名,我们也视同conn.asp)。其实,这种暴库法是最先出现的,以前很多牛人都对此进行过探讨。只是在"%5c"暴库大法出现后,倒较少有人提及。其实个人认为,"%5c"暴大法随着服务器设置安全性的加强,用武之地会越来越少。而conn.asp暴库大法发挥的余地更大,可以人为构造,臭要饭的当年著名的动网大挪移实现暴库,其实也属于此类。

  上面http://www.om88.com/

  一例中,用"%5c"暴不出数据库路径,因为没有二级目录,但用第二种却可以暴出。它是动力系统的。
我们再来看另外一个ASP系统一个盗帅的例子:_blank>http://www.51see.org/

  提交

  http://www.51see.org/db/user.asp

  得到如下结果  
 

"Microsoft JET Database Engine 错误 ’80004005’


 ’d:Hostingwwwrootuilady_comhtdocsdbdbdownloadwoaini12345.asp’不是一个有效的路径。 确定路径名称拼写是否正确,以及是否连接到文件存放的服务器。

  /db/user.asp,行6 "

有人可能会说,这么简单就暴库,好爽!是不是所有网站都可以这样啊?当然不是,已作了防护的肯定不行,没作防护的,要暴库也是有条件的。

  如果说第一种暴库法是利用了绝对路径出错,那么,这种暴库法就是利用了相对路径出错。

  一般来说,只要conn.asp不在根目录的系统,而调用文件在根目录,就会出现这种问题。当然这种说法也是经验性的,准确的说就是,conn.asp与调用它的文件,如果相对位置改变了,就会报错,暴出数据库路径。这样说可能有人不明白,不要紧,接着看你就会明白的。

  我们从动力文章系统说起:

  动力文章系统的conn.asp位于系统的inc目录下,而很多调用它的文件在系统根目录下,比如User_ChkLogin.asp等,这样当conn.asp执行时,它是在系统根目录D:wwwrootzyx688wwwroot下执行的,因此,conn.asp文件中,调用数据库时,它考虑到执行时的目录路径,因而数据库的相对地址写成如下:
 

dim db
db="database/fp360609.asp"


  这样,当它在系统根目录下执行时,数据库的相对路径为根目录下的"database"目录内。但当我们直接请求它时,它工作的当前目录是在根目录下的INC目录内,这时,数据库的相对路径就变成了"inc/database/fp360609.asp",这样它当然出错。得到的绝对路径中多出了"inc。为了让大家看得更清楚,我们举一个可以用两种方法暴库的网站,比较一下看有何不同:
 

  提交:http://www.pofen.com/sc/down%5cshow.asp?id=437
  得到:
  "Microsoft JET Database Engine 错误 ’80004005’


  ’D:Webdatapofen.comscdbdownload.mdb’不是一个有效的路径。 确定路径名称拼写是否正确,以及是否连接到文件存放的服务器。  
 

/sc/down/db/user.asp,行6 "


  再提交:http://www.pofen.com/sc/down/db/user.asp

  得到:  
 

"Microsoft JET Database Engine 错误 ’80004005’



  ’D:Webdatapofen.comscdowndbdbdownload.mdb’不是一个有效的路径。 确定路径名称拼写是否正确,以及是否连接到文件存放的服务器。

  /sc/down/db/user.asp,行6 "

  两种方法得到的绝对路径,一个比实际路径少了,一个则多了,所以路径错误而报错暴出数据库。

  这两个系统都是因为conn.asp不在系统根目录下,而引起的。(其实这样的系统不止两个)。

  那是不是conn.asp放在根目录,与调用的文件在一个目录下就无事呢?如果在一起,当然没事,但牛人自有牛法子,可以通过构造方法来造成相对路径变化,一样能达到暴库的目的。比如,动网的大挪移手法,将conn.asp移位,从而暴库。当然,实际操作中,因为conn.asp移走后,网站无法工作,所以没有成功。但这种思路还是给很多人启发。如果有一种方法可以复制而不是移动,或者说,移动的不是conn.asp,而是调用conn.asp的其它文件比如chklogin之类的,理论上就可以成功。(当然,如果服务器和网页对暴库进行了安全处理,就是另一回事)。这种方法,当也就是一些牛人把网页存到本地改路径而搞出来的。今天刚看到一个暴动易数据库的最新方法,其原理也是构造错误而达到获得真实路径的目的。

  三,暴库的防范


  说白了,暴库是因为IIS服务器会对每个执行错误给出详细说明,并停止执行,而IIS的默认设置又是将错误信息返回给用户。因此,要避免暴库,就应改变IIS的默认设置,选取错误时只给一个出错的页面,不给详细信息。

  "处理 URL 时服务器出错。请与系统管理员联系。"
  其实,作为网站管理者,无法对虚拟主机设置时,只能在网页中加强防范。就是在可能出错的页面加上这一句:
  "On Resume Next",特别是在conn.asp文件中要加上。
  它的意思是出错后,恢复执行下面的,也就是不理会出错,当然就不会给出错误信息了。
  动易系统3.62版的加上后,现在就暴不出路径了。而天意商务网,conn.asp也不在根目录,但因为加了这句,也暴不出数据库。

留言列表
发表评论
来宾的头像