渗透测试|柳暗花明(记一次有趣的高危漏洞以及思考修复方案)

本篇文章共 2600字，完全阅读全篇约 3 分钟 州弟学安全，只学有用的知识

前言

    前段时间做渗透，客户对项目要求很严，一般情况下连XSS/注释泄露信息也不行的这种，所以挖洞这种就比较难挖了

    为什么？因为在这之前，会进入等保流程->基线核查->N次主机漏扫和WEB漏扫，尽管大部分等保的渗透比较水，但是也让我们少了一些没有水洞的机会

本次学习思路仅供参考，请合法学习、全过程已脱敏处理

如您认为本次文章有帮助，请一键三连(转发、点赞、收藏等)

挖掘思路

    好的，先说思路，一个新系统，而且是千锤百炼的项目组公司开发的，那么漏洞不是很多，这是必然的，像一般的任意文件上传，SQL注入，万能密码都很难挖到了，首先登录页面是SSO，这也就代表着账号数据是统一管理的，那么什么是SSO？如下图

    上图为例就是SSO，称为统一身份认证系统，也就是你访问任何的应用资产，登录的情况下都必须在这个地方登录，像这种情况下我们如果没有代码的情况下，做黑盒就很难了，像这种系统大部分都是Java或.NET开发的了，一般做文件扫描大概率是扫出来一些隐藏页面的，备份什么的比较难，像挖SQL注入就更难了，因为现在大部分SQL语句都预编译了，更何况这种专业的开发公司

    都说到这里了，还有什么可以利用的？有的兄弟有的，给你介绍一下

    就不一一列举了，因为都得根据功能来决定如何利用，毕竟公式是套的，不是死记硬背的，说到这里可以看一下之前黑盒挖到的一个edu的SSO系统逻辑漏洞，当时直接刷了几万信息，游走在内部所有系统和教务系统之间

漏洞挖掘|EDUSRC高危漏洞之巧妙拿下学校门户系统管理员权限

    啥？你问我没有账号还不能注册，没有找回密码的情况下咋办？我给你个场景：首先开发是不让爆破的，前端有AES+国密加密，每个请求包都有sign的，每个验证码都没法绕过的，请求是有频率限制的，这个时候咋办？    答：黑盒的情况下，只能扫目录文件+找接口看看有没有泄露信息，最幸运的是有框架漏洞

    啥？你又问我，假设钓鱼呢？不是，我们是挖洞的，不是打红队的，没有钓鱼这一步，假如在我说的场景里面倒是可以试试

    嗯！我倒是看到有RCE了，使用的spring cloud的，如图

    但是这个是在SSO登录以后才可以利用，SSO是没漏洞的，所以还是需要有账号，所以在正规渗透测试的情况下，尽量开账号，不然没有办法深入挖

有趣的漏洞

    闲话少说了，前面都是一些思路上的东西，本次出货了四五个漏洞，其它都是常见的，不值得一提，聊聊我这次新的发现

    首先来到文件上传处，已知是Java，那么整个马子往上传

    啥？你问我不会拦截吗？许可的情况下当然不会啦

    那么接着往下走，传上去以后我意识到不妙，根本不返回路径啊，有木有

    但是值得注意的是，它是返回ID的，那么这里换位思考开发的角度，有两种情况

1. 文件上传后->文件重命名->重命名为ID->保存到目录或桶内
2. 文件上传后->生成ID保存到数据库->关联上传的文件->使用的时候查询id找到对应文件

    先说这两个的利弊：第一个优点是不会存在SQL注入，但是弊端是可能存在目录或桶信息的泄露，再或者是枚举ID读取文件的漏洞

    第二个优点：不会存在目录文件的泄露，也不会存在任意文件读取，但是可能存在SQL注入和枚举ID读取的漏洞

    我个人偏向第二点，开发存放到数据库里面了，然后还有一点，上传后没给路径，只给了个ID，虽然任意文件上传搞不了了(有可能)，任意文件读取呢？

    没给路径咋办？这里有个小技巧，就是我们找到一些可以上传图片的地方，比如上传头像，发信的功能，上传去以后右键这个图片，复制链接地址，就可以找到这个文件存放路径了

    如上图所示，找到路径我们是否可以解析木马？答案是不行的，因为开发对文件做了一个操作，当非接口调用时，比如直接访问，进行下载操作

    唉，那这该如何是好啊，没办法，上了个厕所感觉脑子通了(不是脑子被冲走了)，我发现这个上传功能每次在上传文件的时候都会生成一个ID，那么我多次发包观察一下规律呢？

    后面我发现这个上传文件的fileid每次上传只有倒数第四位和第三位变化，呈递增上升，前面和日期绑定，也就是我只要intruder一下，根据这个规则枚举，岂不是可以读取其它人上传的全部文件了？

    直接发包，等等我还要去趟厕所，喝水喝多了，回来看结果

    好的，直接获取到全部上传的文件，其中包含相互之间的邮件，图片，压缩包，敏感信息等，这个漏洞看着简单，其实一点也不难，算是逻辑漏洞吧

    好的，这时候有师傅说了，那么会不会有SQL注入漏洞？

    没有的，你放心吧，根据前台测试，代码只允许传int类型，且大概率被预编译了

漏洞的修复探讨

    这里我们来列举两种漏洞修复方式，一个简单的和一个逻辑严谨的

    先说逻辑严谨的修复方法(个人观点)

fileid既然是存放到数据库中的(假如)，那么是否可以做权限控制，控制太严格，比如只允许自己访问，那么就会影响功能，因为接口都是用的同一个，这里就该研究一下功能上有哪些东西了

    这样的话可以做到严谨的控制，不用担心上传文件是否可以直接未授权访问下载，因为访问需要携带token的，不要担心越权，系统进行了二次加密和双重校验，用JSESSION来鉴权和生成的SM2鉴权

    但是这样的话又会导致开发成本增加，以及开发变复杂，后期可能出BUG，那么直接上简单的修复方法

简单的修复方法

    直接将上传的fileid进行不规则的命名，比如：x12fg-aafg7-mmn-090或者是时间戳或者MD5，以我之前那篇靶机为例的文件上传

渗透测试|学姐为获取靶场WP，竟不惜以黑丝诱惑我

    这样可以限制被枚举的风险，是不是很简单

    还有其它的一些漏洞这里就不写了，因为没什么值得讨论的，不是框架RCE就是逆向，我之前也写过相关的文章

总结

    随着现在网络安全的发展，OWASP TOP10的趋势也越来越向着逻辑漏洞、API漏洞靠齐，传统的文件上传和SQL注入通过黑盒已经不常见(除非是老系统或者是小的开发公司可能会见到)，像一般比较大的甲方所使用的开发公司都比较强的，想黑盒挖出来通过漏扫或SQLMAP就出洞的是比较难的了，加上现在AI的加持，以后逻辑漏洞会越来越多，传统的DVWA、皮卡丘和一些开源靶场只适合新手入门来训练学习使用，对于上项目还是有很大差距的

    所以关注州弟学安全定期更新渗透测试、应急响应、安全加固、代码审计、CTF靶机，实打实根据项目开发进行复现，包括本次漏洞后面也会复现在线训练

以上均为自身看法，如有其它建议和学习意见环境交流

往期文章分享