发新话题
打印

Hidden型参数变量未过滤导致的上传漏洞利用一则

Hidden型参数变量未过滤导致的上传漏洞利用一则

  无意中看见一个图形设计网站,网站全部由静态asp构成,做得十分漂亮。感叹它设计精美的同时,不由心里嘀咕,全静态asp页面的确能防止注入漏洞的产生,但WEB漏洞不止注入这一种,我很想看看这个网站在其他漏洞的防范方面做得如何。
  在Google上搜索了一阵,翻到了这个网站的一个上传页面,发现它没有做验证,任何人都可以上传图片文件,于是决定从这里入手。
  试着上传.asp文件,直接跳出对话框(图1)

[img=400,115]http://www.hack58.net/Article/UploadPic/2008-12/200812261825212.jpg[/img]

  (图1)

  查看源文件,可以看出是用JavaScript在本地做了限制。(图2)

[img=400,273]http://www.hack58.net/Article/UploadPic/2008-12/200812261829442.jpg[/img]

  (图2)

  把源文件中的JavaScript代码全部删除,修改post的地址为绝对网址,之后另存为htm文件。再次上传.asp文件,几秒钟后出现结果如图3

  (图3)

  可以想到虽然程序没有禁止外部提交数据,但是文件在上传到服务器保存时又做了一遍验证,如果要保存的文件名后缀不合法,则拒绝执行。以下是源代码中的相关部分(图4)

  (图4)

  继续,上传一个正常的图片文件并抓包。(如图5、6)

  (图5)

  (图6)

  把抓包得到的数据与上传页面的源文件相对照
  抓包数据,如图7

  (图7)

  源文件中对应部分如图8

  (图8)

  可以发现有很多隐藏的参数在里面,而这些参数的值默认都是空的。如果我们改变这些参数的值,结果会怎样呢?
  把源文件中的“hidden”改为“text”,如图9

  (图9)

  保存后打开,如图10

  (图10)

  现在这些参数的值可以自己构造了
  试验着改参数值上传了几次之后,摸到了一点规律。
  把参数“mulu”对应的值改为asp.asp,试试上传gif后缀的asp小马

  (图11)

  上传成功

  (图12)

  由抓包的数据中找到上传路径,提交看看,

  (图13)

  出现了可爱的画面。
  可以想到这个上传程序的运行方式是,在处理参数“mulu”的值的时候,如果值不为空则创建,于是就在服务器上创建了一个“asp.asp”目录。
  以下是源代码中的相关部分

  (图14)

  可以看到对提交的变量只是简单的把“/”转换成了“\” ,其他没有做任何过滤。这里即漏洞所在。
  Win2003存在着一个文件解析路径的漏洞,当文件夹名为类似asp.asp的时候(即文件夹名看起来像一个ASP文件的文件名),此时此文件夹下的文本类型的文件都可以在IIS中被当做ASP程序来执行,因此我们上传的xiaoma.gif被作为asp程序执行了。
  之后就是写个大点的webshell进去,如图15

  (图15)

  结果出错,无法写入

  (图16)

  换了几个小马都是如此,看来不是小马的问题,可能FSO组件被禁用或者改名了。
  直接上传大马不能执行

  (图17)

  (图18)

  大概是服务器解析目录“asp.asp”的时候把这个目录当作了asp文件,因此出错。
  为了看清楚些,把asp探针文件后缀改为gif传了上去。

  这么看就明白了。
  怎么突破呢?可以看到,虽然禁用了FSO组件,但是WScript.Shell组件和Shell.Application组件还在,我们可以用它们来读写文件,只要把用WScript.Shell组件或Shell.Application组件读写文件的webshell写到“asp.asp”以外的web目录里执行就可以了。
  这里可以利用的写文件方法很多,如XML写文件,JMail写文件,ASPUpload上传都可以。这里我用ASPUpload上传。
  构造两个文件“本地提交用.htm”和“upload.gif”,代码如图21

  (图21)

  upload.gif上传到服务器,本地提交用.htm 用于本地打开提交上传文件。

  (图22)

  (图23)

  成功上传海洋顶端木马到上一层目录,并可以正常使用。

  (图24)

  服务器的权限设置不严,webshell可以浏览所有文件及目录,同时SERV-U为默认设置且没有设置管理密码,还是system启动服务运行的。(=_=!)

  (图25)

  很容易地利用SERV-U提升权限,并添加管理员用户sai52

  (图26)

  (图27)

  本次检测到这里就结束了。这个网站安全方面外紧内松,程序员和管理员都有责任,不过我个人认为,主要还是管理员的责任。(=_=!)
好好学习,天天向上!

TOP

发新话题