CTF比赛中JWT漏洞的利用

前言

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

算法混淆漏洞

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

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

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

解题思路

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

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

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

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

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

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

比如：

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 时，就会出现问题。由于这个有缺陷的假设，他们可能总是将固定的公钥传递给该方法，如下所示：

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

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

复现

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

2、在Burpsuite的JWT Editor 中

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

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

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

6、复制新生成的秘钥

7、替换之前的旧JWT

Other

未验证签名

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

未对签名算法强验证

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

秘钥泄露

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

弱密钥

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