WrongWindow
A regional credit union's online member portal. The login flow asks for a hardware-token code on a second screen. The verify form has more in it than the page would suggest.
The Scenario
Cedar Creek Credit Union has 8,400 members and two branches in
eastern Kentucky. They mailed out hardware tokens in 2020 after a
bad year of SIM-swap fraud. The token verify page was implemented
by the same shop that built the original 2014 portal — they tried
to make it flexible enough that a service rep at the branch could
re-verify a member at the counter using the member's handle. Then
the flexibility shipped to production.
Challenge Intel
Synopsis
The OTP step happily verifies a different member than the one you're logged in as, if you ask it to. Pick a target from the public roster, brute-force their code, and the session walks in on their accounts.
What It Is
Cedar Creek's member portal asks for a hardware-token code after password sign-in. The verify form encodes which member's code is being checked — a leftover from when the bank wanted to support "rep-assisted verification" at the branch counter, and the server-side never tightened back up. The player has to spot the seam in the form, find a target on the bank's About page, and burn through the four-digit code space until the session swaps over. The senior member's dashboard surfaces a vault notice carrying the flag.
Who It's For
Testers who've seen 2FA flows and want to internalize that the "which user is this code for" question is server-side, not client-side.
Skills You'll Practice
- Reading hidden form fields for trusted client input
- Differentiating session-bound identity from client-supplied identity
- Patient brute-forcing of a small keyspace
- Pivoting through a session swap to read another user's data
What You'll Gain
- A reflex that asks 'who is this server-side check for?'
- Working understanding of cross-account OTP attacks
Ready to hack WrongWindow?
Upgrade to Pro to unlock this challenge and the full library.