0x01 前言

本文涉及到的漏洞并不高级 主要分享实战中的一中经验。

0x02 过程

接到客户的系统后 打开发现页面主要是用Flash写的 技术很老了 在这种系统上挖掘到漏洞应该不是什么难事。

看到这种只有一个登录界面的系统笔者通常会联想到以下几种是否

• 是否可绕过/沿用验证码（尝试删除验证码参数/重复使用）
• 是否可遍历账号（点击登录后提示用户名不存在）
• 是否可爆破密码（超过登录限制阀值时账号是否会被禁用）
• 是否可以注入(万能钥匙)
• js中是否包含了敏感目录 是否可越权（登录绕过）

用户名top500一顿跑下来发现前台虽然不提示用户名不存在 但是后台却很诚实的告诉你了的 过程中尝试删除验证码发现不行后测试验证码沿用确实存在 有效期比较短而已

得到了用户名且已知验证码可爆破后并不推荐直接爆破 一不小心账号就被锁了 比如

值得一提的是这是admin账号登录测试的界面 提示中失败3次就会被锁号 但是为什么失败了92次仍未被锁号呢？要站着开发者的角度来看是可以理解的 假设其他账号/功能出问题 需要紧急重置时 缺有人在后面故意输错账号密码 导致admin一直被锁定 那系统不就一直处于停滞状态了？

既然有了用户名 已知验证码可沿用 且账号不会被锁定 那就可以进一步对密码进行爆破了。

通过top10000密码 加上诸如单位名称拼音缩写加123456 这样的组合 顺利进去后台

按照客户需求 到此处后还是可以继续深入测试

对每个功能都进行相关测试后并没有发现什么大问题 注入一类的也不存在 有一个上传点（一个录入信息的地方）

此处上传对文件后缀没有做限制 但是奇怪的是bp抓不到流量 浏览器的开发者选项中的也无法查看到流量 而且上传后的路径也找不到

查阅资料得知是基于FLASH的swfupload开发的 上传过程中文件被转化成了流文件 bp无法抓取到 提供一个demo 有空的师傅可以试试

http://www.miniui.com/demo/fileupload/fileupload.html

目前就很伤了 好好的一个上传就成了鸡肋 这样的漏洞假设提交个SRC至少有九成的把握会被打回 无法找到shell的地址就等于无法证明文件的确上传成功了（审核复现时发现bp没有拦截到流量也会以为这是个没有完善的功能点 并没有真的上传成功）

但是 既然上传了系统肯定就会用到的！

随后发现下面这么一个东西

权限最高的自然就是管理员 然后下面依次是董事长 总经理 部门主管 业务员 等等的。业务逻辑应是这个样子的

调查/业务人员录入客户信息
业务/部门主管人员审核信息

这样理解后去看 管理员并不需要录入信息 那么那个上传点久是不应该出现的 可能是权限配置出错导致的。

随后在后台添加一个业务员账号a 一个部门主管账号b进行测试

通过a录入信息（包括上传shell文件）后登录b进行审核

如此一来 Shell的路径就找到了

0x03 总结

实战中这是第三次遇到这样的问题了 第一次是自己学校的一个学分管理系统 和开发的学长认识 帮忙测系统时发现上传后系统直接返回了路径 修复时他直接删除了返回的路径 后续测时通过上述思路就又找到了路径 第二次是测贵州这边某听起来很高大上的局的App 也是类似的问题 没找到路径直接提交时被开发diss被打回来 总的来说要相信系统既然给上传了 那么一定是会用到上传的这个文件的 试着去理解业务逻辑 在进一步渗透 结果会好很多。