CTF比赛中JWT漏洞的利用
Yu9

文章首发先知社区
链接:https://xz.aliyun.com/t/14214

前言

在最近的ctf比赛中,经常可以碰到一些jwt相关的题目,然后感觉思路挺有意思,拿出来分享一下,后边也总结一下ctf比较常见的集jwt相关题目解题思路

算法混淆漏洞

腾龙杯 web[这又是一个登录页面]

img

使用zkaq/zkaq登录之后,又跳到了一个登录页面。账号密码我用的是admin/admin(随便输入的)

image-20240317195349245

之后会跳转到http://ckqongk8.lab.aqlab.cn/fl4g页面,告诉我们只有`@dministr@t0r`用户可以访问

image-20240317195456323

解题思路

用yakit抓一下这个页面的登录包看看

image-20240317191539008

很容易可以看出来是jwt做的身份校验,解密发现使用的算法是RSA256

image-20240317191617328

使用的事RSA算法,弱密钥有点不太现实,试了一下另外两个jwt简单绕过:未对签名进行验证、未对加密算法进行强验证,不过都没成功

原理挺简单的,可以看看我之前的文章奇安信攻防社区-JWT渗透姿势 (butian.net)

后边经过测试在robots.txt拿到了公钥

image-20240317200941042

然后就想起之前打过的一个靶场,大概思路就是对签名方法过滤不严

比如:

1
2
3
4
5
6
7
8
9
10
function verify(token, secretOrPublicKey){ 
algorithm = token.getAlgHeader();
if(algorithm == "RS256")
{
// Use the provided key as an RSA public key
}else if (algorithm == "HS256")
{
// Use the provided key as an HMAC secret key
}
}

当随后使用此方法的网站开发人员假设它将专门处理使用 RS256 等非对称算法签名的 JWT 时,就会出现问题。由于这个有缺陷的假设,他们可能总是将固定的公钥传递给该方法,如下所示:

1
2
3
publicKey = <public-key-of-server>; 
token = request.getCookie("session");
verify(token, publicKey);

在这种情况下,如果服务器收到使用 HS256 等对称算法签名的令牌,则库的通用verify()方法会将公钥视为 HMAC 密钥。这意味着攻击者可以使用 HS256 和公钥对令牌进行签名,并且服务器将使用相同的公钥来验证签名。

复现

1、把pem格式的秘钥base64编码

image-20240317192017977

2、在Burpsuite的JWT Editor

image-20240317192223050

3、base64加密过的那个替换k

image-20240317192306019

4、抓包,需要改两个地方

image-20240317192353937

5、点击sign,选择刚刚创建的JWT

image-20240317192440061

6、复制新生成的秘钥

image-20240317192508370

7、替换之前的旧JWT

image-20240317192535499

Other

未验证签名

首先看到jwt相关题目,第一个想法就是先直接修改,看看能不能过签

image-20240401141719601

未对签名算法强验证

若直接修改内容无法过签,那就在尝试修改Header部分加密算法

image-20240401142010786

秘钥泄露

翻一番robots等文件,看看有无秘钥泄露,有的话就可以直接构造

image-20240317200941042

弱密钥

弱密钥,我们就可以通过一些工具来进行爆破

image-20240401142213426

由 Hexo 驱动 & 主题 Keep
总字数 50.7k 访客数 访问量