JWT alg=none vulnerability

[tghosth]

What do you think about a challenge based around the following vulnerability:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

The main disadvantage is that this would allow logging in as any user but then there are already other issues such as SQLi which already allow that.

What do you think?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[bkimminich]

This one is great. @ViktorLindstrm showed this none cypher issue to me at OWASP Summit as well! We went for the "easy" JWT issue of weak key first, but this was actually meant to become a "harder" challenge as well. Any implementation ideas?

[tghosth]

I guess the simplest implementation would be if if the alg field contains "None" then just manually disable checking the signature :)

Alternatively, we see if there is a vulnerable version of jsonwebtoken. It is not clear from the docs however if this library was ever vulnerable to this specific issue though...

[bkimminich]

Retires.js says the lib I use was vulnerable before 4.2.2: https://nodesecurity.io/advisories/17 ... So, downgrading and pinning that version should make this exploitable?

[tghosth]

ok so there are two vulns here. The cleverer one which is mentioned here would break the weak JOSE passphrase challenge because it requires the token to be signed by an asymmetric algorithm. There is a less clever one where you change the alg to none and send a blank signature which can be exploited if you pin express-jwt back to something like its very first version. I am going to do more experimentation and then I will update you.

[tghosth]

For my own reference, need to pin express-jwt to https://github.com/auth0/express-jwt/blob/v0.1.3/package.json

[bkimminich]

Would the clever one and the alg=none both work at the same time? If so, I think @ViktorLindstrm would be okay with you removing the much simpler secret-guessing challenge. We wanted to do some crazier stuff on JWT during OWASP Summit but simply didn't have enough time back then.

[tghosth]

I will have to investigate further and let you know.

[ViktorLindstrm]

Of course i'm ok with that, that would be awesome! I gladly help if there are any questions.

[tghosth]

FYI I have not forgotten about this I just need to get some time to get back to this...

[tghosth]

Hi @bkimminich / @ViktorLindstrm ,

I have finally figured out how to do this. I have included a full explanation of how how to reproduce the two vulnerabilities following some relatively minor code changes in pull request #392.

Let me know if you have any questions. It was hard enough to figure out how to do this, I don't think I am going to be able to figure out how to create the relevant tests for this :(

[bkimminich]

Hi @tghosth! Great stuff! So, what is left to do is remove the current JWT challenge and add two new ones according to #392, but how do we check that they were exploited successfully? My idea:

• JWT Issues Tier 1: Forge an essentially unsigned JWT token that impersonates the (non-existing) user jwtn3d@juice-sh.op. (4-star difficulty)
• JWT Issues Tier 2: Forge an almost properly RSA-signed JWT token that impersonates the (non-existing) user rsa_lord@juice-sh.op (5-star difficulty)

And one remark: The public key would be perfectly placed in the /encryptionkeys folder that is also a brosable directory and is supposed to be found via brute forcing with e.g. DirBuster. That makes it a clear 5 star challenge because you need a rather complex chain of exploits to get the goal.

[bkimminich]

About the tests, it would just be creating a JWT internally for those non-existent user emails and check that when used they solve those challenges. No feasible way to "test" the real hack that leads to the JWT. Many other e2e tests are like that already, so no problem.

[bkimminich]

Hi @tghosth and @ViktorLindstrm! I would very much appreciate your feedback and some testing of those two new challenges on the branch https://github.com/bkimminich/juice-shop/tree/jwt_challenges! Please have a look at routes/verify.js as well, because I am not sure if the alg: 'none' challenge works "properly" without explicitly ignoring the publicKey like done at the moment.

[bkimminich]

Open issues on jwt_challenges branch

• UnauthorizedError: PEM_read_bio_PUBKEY failed is several tests
• TypeError: this.getAuthorizationToken is not a function in server unit tests

[bkimminich]

So, all test issues should now be fixed and previous challenges work again. The two new JWT challenges at the moment cannot determine if they were solved via alg: none or RSA to HMAC downgrade.

• Interpreting the header.alg property of the token needs to be added to verify.js.
• Add e2e tests for both JWT tiers.

[bkimminich]

e2e tests have been added but the one for Tier 2 remains disabled due to problem described in #392 (comment).

[bkimminich]

The challenge currently is not affected by any customization, thus it always expects @juice-sh.op email addresses. Making it configurable will break the existing unit and e2e tests as they use hard-coded JWT's created on jwt.io because on-the-fly creation did not work.

[lock]

This thread has been automatically locked because it has not had recent activity after it was closed. 🔒 Please open a new issue for regressions or related bugs.