SpringBlade框架JWT认证缺陷漏洞
漏洞分析
SpringBlade框架JWT认证缺陷漏洞
1.前言 ==== 在某次代码审计项目中，发现项目代码是基于SpringBlade框架实现的，于是在审计的过程中，顺带着挖到了SpringBlade框架的一个0day漏洞。CVE编号：CVE-2021-44910 2.漏洞分析 ====== SpringBlade前端通过webpack打包发布的，可以从其中找到app.js获取大量接口：  然后直接访问接口：api/blade-log/api/list  直接搜索“请求未授权”，定位到认证文件：springblade/gateway/filter/AuthFilter.java  2.1 错误的认证逻辑 ----------- 我们看下代码逻辑： （1）首先，从ServerWebExchange类中获取到uri，然后判断是否跳过：  跟进isSkip函数，如下：  判断路径是否在不需要认证的名单中，跟进getDefaultSkipUrl函数，看不需要认证的名单有哪些：  只要符合以上路径则不需要权限校验，否则都是需要权限校验的。而程序核心业务逻辑都是在/api/下的，显然需要授权。 （2）回到AuthFilter，接下来通过两种方式获取token，如果两者都为空时，则提示“缺失令牌，鉴权失败”。  我们跟进下AuthProvider.AUTH\_KEY,看需要传入认证字符串的字段名称：   所以需要get或者在headers中有blade-auth，并从其中获取到鉴权字符串。 （3）解析token，判断token是否合法：  先看下getToken，实现如下：  这里解释下，为什么要从第七位取字符串，因为BEARER格式的认证串为：bearer\[空格\]认证字符。 接着看parseJWT方法的实现：  使用jwt密钥，对认证字符串进行解密，然后返回其内容，**如果解密结果不为空，则直接绕过认证。**那么继续往下，找JWT的解密过程及密钥： 看下JwtUtil.BASE64\_SECURITY的值，如下：  是由TokenConstant.SIGN\_KEY进行base64加密得来的。看一下TokenConstant.SIGN\_KEY：  由此，我们可以伪造auth认证字符串了，测试：  带入接口测试：  成功伪造了任意用户进行登录。 **\[其他\]** 1、/api/blade-log/api/list接口中会泄漏账号密码，只要管理员登录过  2、部分情况下接口的前缀会被改，blade部分，可以从前端的app.js里面看得到完整接口。 2.2 权限提升 -------- 其实刚才伪造的用户只能算是普通用户，在测试时候，发现还有些接口用伪造的token访问不了  这个接口是查看系统用户的，结果没权限。找下其代码：  其中使用了PreAuth接口进行了鉴权，看下其鉴权方式：  调用了hasRole函数进行鉴权，找一下hasRole实现方式：（实现代码在：org/springblade/blade-core-secure/3.0.2/blade-core-secure-3.0.2.jar!/org/springblade/core/secure/auth/AuthFun.class）  跟进this.hasAnyRole方法：  跟进一下SecureUtil.\_getUser\_方法，如下：  从web容器内部获取BLADE\_USER的相关属性，如果没获取到的话，则会使用另外一个getUser方法，实现如下：  直接从请求头中获取blade-auth，然后进行jwt解密，将各个属性set给bladeUser类。 回到AuthFun.class，往下看：  其中r的来源是hasAnyRole被调用的时候传入的，我们看下传入的值：  所以，只需要我们在构造jwt的时候，加上role\_name且其值为administrator，则可以实现权限提升。  试试token是否有效：  可见，权限进行了提升。 **\[注意\]** 1、/api/blade-user/user-list 接口会泄漏所有账号密码，不过需要administrator权限，不加role\_name时，也可以，但无内容。  恰巧其登录时，直接用md5即可，所以，你懂的。 2、一般admin默认安装时，对应的id为：1123598811738675201，部分接口需要有对应的user\_id，可以尝试。如：api/blade-user/info接口 3、jwt的密钥SIGN\_KEY硬编码到jar里面了，而且不是写在配置文件里面，开发根本不会关注到这点，所以使用该框架的项目都受到影响。 3.修复方案 ====== 1、对于框架使用者而言，其实修改SIGN\_KEY已经就让漏洞无法利用了 2、对于框架作者而言： 1）jwt的密钥，放在配置文件中，并提示用户修改。jar包里面硬编码改起来太麻烦 2）修改认证流程，本质还是认证流程出了问题。建议把用户账号、密码密文放到jwt里面，然后认证过程中，通过jwt里面的账号、密码进行鉴权。
发表于 2022-03-14 10:25:34
阅读 ( 17576 )
分类：
漏洞分析
1 推荐
收藏
1 条评论
Alivin
13 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
