关于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的第二部分，它包含了声明，声明是有关实体和其他数据的结合，有三种类型的声明：已注册、公共、私人。
- 已注册声明：这是一组预定义的声明，这些声明不是必需的，但建议使用，以提供一组有用的、可互操作的声明。其中一些是：iss（发行人），exp（到期时间），sub（主题），aud（受众）等。
- 公共声明：可以由使用 JWT 的人随意定义。但为了避免冲突，它们应该在 IANA JSON Web 令牌注册表中定义，或者定义为包含抗冲突命名空间的 URI。
- 专用声明：这是创建的自定义声明，用于在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。
例子：
{
"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加密即可成功绕过身份认证
