简单介绍：

在一次某行动暂停之后，某单位重新对自身的业务进行了评估，系统业务使用SSO进行登录，而这个SSO登录后的子系统访问采用JWT进行认证，因此有了这一个漏洞的发生，漏洞利用较为简单，各位师傅请见谅。
 
 
 

Oracle WebCenter
 在这个业务中，登陆口的校验是采用Oracle WebCenter进行认证的，也就是说在系统最初的登录，流量是走到Oracle WebCenter中进行认证的。
  Oracle WebCenter是面向社交业务的用户参与平台。其上下文相关的协作工具可优化人员、信息和管理软件间连接，帮助员工更高效地协作，并可确保用户在其所处的业务流程环境下访问适当的信息。简单的来说它有点像一个简单的OA系统。
 
 
 

JWT
 JTW全程是Json Web Token,是目前最流行的跨域认证解决方案。之前遇到的JWT漏洞情况，可能大多数都是在一开始的登录验证下，通过修改token字段以三个点分割的BASE64字符串。
第一个字符串为JWT头，一般base64解码后长这样
 

{“kid”:”keys/3c3c2ea1c3f213f649dc9389dd71b851",”typ”:”JWT”,”alg”:”RS256"}

第二个字符串为账户

第三个字符串为签名
签名一般不能直接用base64解出来，因为它可能常带有下划线，签名获取的过程稍微比较复杂，不过我们可以知道签名是为了防止数据被篡改，而签名使用的算法就是我们的哥字符串JWT头的Json字段alg。
 
大部分JWT常用的三种关于利用Token的攻击方式：未校验签名，禁用hash，爆破弱秘钥
此部分内容可以参考https://xz.aliyun.com/t/2338
其中，未校验签名的情况，我们可以直接修改的那个账户字符串，既

{"sub":"xxxx11111这里修改，然后重新生成Token，如果没有校验签名则可以进行越权"}

禁用Hash,既第一个JWTheader头的alg值为None,我们可以将HS256篡改为None，然后使用Python pyjwt进行Token的生成。

最后爆破弱秘钥是最常见的，也是比较现实的一种情况
利用脚本来进行爆破 https://github.com/ticarpi/jwt_tool

本次的场景

首先打开网页，需要通过SSO的oracle webcenter认证，在进入系统中，存在许多业务，而对于子业务系统的认证，则采用的是JWT的认证。接下来将从流程来讲解此次漏洞的挖掘。

1、因为这里没有截图了，所以只能用文字描述。首先，在进入系统后，很多业务选项按钮，比如物流系统，金融系统。我们点击金融系统的时候，会发出第一个包，通过Oracle Webcenter来校验当前账户是不是有效，如果有效，则返回一个Json格式的S。

2、在验证了当前的账户有效的时候，会发出第二个包，请求一个OAM接口想获取一个JWT token，这个OAM接口会带上Cookie字段的Sessionid值，证明自己账户现在的状态真的是有效的，当这个OAM接口后接受SessionId的值后，就会返回一个JWT authorizationToken值。

3、当获取了JWT authorizationToken值后，证明JWT认可了你这个账户了，那么此时系统在第三个包发生的时候自动带上JWT authorizationToken字段放到header头去请求资源，此时系统返回UID等敏感信息

4、没错！越权来了。第三个包返回的信息其中的UID和JWT authorizationToken作为凭证来对这个子业务系统进行访问。但是这里的UID和JWT authorizationToken并没有做严格校验，导致可以通过遍历UID来实现越权访问

看到这个是不是就是我们非常熟悉的JWT认证Token值，以点分割三个成三个的base64编码字符串，这个User Token作为这个子系统访问认证的最后一关

5、其实到第4步的时候，漏洞利用就结束了，其实就是一个简单的越权而已，但是我想把后面的几个过程也简单一下。既然成功越权了，那么这一步系统就开始逐渐返回属于这个系统原本的东西了。这里利用UID和Token获取系统的分组权限信息。

6、获取此账户在这个系统中未读取得信息

7、在get请求处获取了UID值，为了获取菜单信息。而我们也可以通过此处的越权，更方便的爆破ID。

8、获取baseinfo，账户的基本信息，内容

9、最后一个包，获取剩余信息，例如按钮，选项之类。

因此整个利用的漏洞非常简单，通过第7步的API来进行爆破，然后再逐步放入第4步的UID修改包中，那么就可以实现对此子业务系统的任意用户登录了。

越权前后的两个截图比较，多了两个功能，并且两张图的账户名都为AAA，原因是因为auth Token记录的第二个base64字符串记录的就是账号信息，而这个账号信息从始至终都未改变，因此账户名不变，而权限管控在UID部分。也是比较不应该了。

修复

恢复authorizationToken，同时校验uid、user、authorizationToken中的用户是否一致
在渗透测试的时候，尽量不要放过每一个包，多看看抓包的history的记录。
对于菜鸡来说，渗透就在于细心与更细心罢了。
最后我认为推荐几篇关于JWT还不错的文章：
https://www.freebuf.com/vuls/211842.html
https://www.jianshu.com/p/576dbf44b2ae
https://xz.aliyun.com/t/6776
https://mp.weixin.qq.com/s/xe8vOVhaysmgvxl-A3nkBA