0x01 - Environment & Tooling
Attacker Host: Kali Linux / any modern Linux
Target:
http://10.81.189.115:5000/Primary Tools:
curl- raw HTTP interaction and form submissionsPython 3- to reimplement the RSA key generation and signingPython libraries:
hashlib,sympy- hashing and prime generationcryptography- RSA key construction and signing operations
This challenge is more about understanding flawed crypto design than traditional web exploitation (no SQLi, XSS, etc.).
0x02 - Initial Reconnaissance
2.1 - Enumerating the Application Surface
Start by retrieving the main page:
curl -s http://10.81.189.115:5000/
From the HTML and navigation links, the following endpoints are discovered:
/register- User registration & key generation/login- Username-only login form/messages- Public message board/compose- Likely for sending messages/verify- Digital signature verification page/about- General platform information
This indicates a PKI-like workflow: users send messages and verify signatures, with a central authority (the platform) checking validity.
2.2 - Public Message Board (/messages)
Visiting /messages shows public posts such as announcements and example love notes. Two important observations:
Messages are displayed without showing raw signatures or key data
One of the messages is a welcome announcement from the administrator (this will later be reused as the target message to forge)
The absence of visible cryptographic data suggests that signing/verification is handled purely on the backend or via forms, not via downloadable artifacts.
2.3 - Signature Verification Workflow (/verify)
The /verify endpoint provides a form with the following fields:
username- User identitymessage- Plaintext message contentsignature- Hex-encoded digital signature
Reviewing the page (including its HTML source) reveals:
A status banner that shows whether a signature is valid or invalid.
A hidden or initially empty flag area (e.g.,
divwith aflag-displayclass) that is only populated when a specific verification condition is met, most likely a correct signature for theadminuser with a specific message.
This strongly indicates that the final exploit path is:
Forge a valid signature as admin over a specific message and feed it to /verify.
2.4 - Weak Authentication at /login
The /login endpoint contains a simple form asking only for a username. No password field is present.
Submitting admin logs the attacker in as the administrator immediately:
curl -s -X POST \
-d 'username=admin' \
http://10.81.189.115:5000/login
This confirms:
No password-based authentication is enforced at all.
The
admindashboard can be viewed by any unauthenticated user knowing only the username.
While this is already a serious design flaw, the challenge’s core revolves around signature forgery, not just weak session controls.
🔐 PREMIUM WRITEUP - MEMBERSHIP REQUIRED
🌟 Get Instant Access
Unlock the complete step-by-step solution, techniques used, notes, and exclusive insights by becoming a member.
Why Go Premium?
Early access to full detailed writeups
Passwords for active CTF solutions
Advanced exploitation techniques
Upgrade once - unlock everything instantly.
💬 Need help while solving?
I’ve got your back - reach out anytime:
Email: [email protected]
Keep hacking, keep learning, keep winning. 🎯
