关于Nacos身份认证绕过漏洞默认密钥和JWT的研究

前言

由于本人的一个习惯，每次遇到漏洞并复现后都要编写poc，以便下一次的直接利用与复测使用。研究Nacos默认密钥和JWT的爱恨情仇的过程中遇到了莫名其妙的问题，在此做以记录，方便日后有大佬遇到相同的问题路过看到能够得以解决。

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。此信息可以验证和信任，因为它是经过数字签名的。JWT 可以使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名。

尽管 JWT 可以加密以提供各方之间的保密性，但我们将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则向其他方隐藏这些声明。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是签名的一方。

JWT由三部分组成，分别是：header、payload、signature，并且这三部分通过"."来连接，例子：xxxxx.yyyyy.zzzzz

1、header通常由两部分组成：类型以及使用签名算法，例子：

{
  "alg": "HS256",
  "typ": "JWT"
}

然后这部分将被base64url编码，形成JWT的第一部分。

2、payload作为JWT的第二部分，它包含了声明，声明是有关实体和其他数据的结合，有三种类型的声明：已注册、公共、私人。

1. 已注册声明：这是一组预定义的声明，这些声明不是必需的，但建议使用，以提供一组有用的、可互操作的声明。其中一些是：iss（发行人），exp（到期时间），sub（主题），aud（受众）等。
2. 公共声明：可以由使用 JWT 的人随意定义。但为了避免冲突，它们应该在 IANA JSON Web 令牌注册表中定义，或者定义为包含抗冲突命名空间的 URI。
3. 专用声明：这是创建的自定义声明，用于在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。

例子：

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

然后这部分也将被base64url编码，形成JWT的第二部分。

3、signature作为JWT的第三部分，也叫签名部分，要创建签名部分，您必须获取编码的标头、编码的有效负载、机密、标头中指定的算法并对其进行签名，例子：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

签名用于验证消息在此过程中未被更改，并且在使用私钥签名的令牌的情况下，它还可以验证 JWT 的发件人是否是它所说的人。

将这三部分连在一起，就形成了JWT。

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY4Nzc3NTY5NX0.Gyh5fwZavKvHp-Ooitu4iE_8tgYYYqngUb1c4jTEDKs

研究过程

在Nacos身份认证绕过漏洞复现文章中提到jwt.io网站，其中有一个secret base64 encoded的选项，百度一下得知勾选后，即认为密钥是base64编码，加密前会先对密钥进行base64解码。

使用python的base64模块库解码会报错，因为nacos提供的密钥不是4的倍数

随后我尝试了所有base64解码的在线网站都不行，于是就开始了手搓base64解码代码。

解码后

将解码后的字节串和指定header、payload进行JWT加密即可成功绕过身份认证