Filename injection and a four-step privilege escalation: two RCTF web challenges
Two related web challenges from a 2015 CTF both turned on filters that blocked keywords without accounting for how those keywords could be rebuilt after filtering.
Filename-based SQL injection
The first challenge accepted a file upload and stored the filename in a database query without proper sanitisation, a less common injection point than a form field, but functionally the same class of flaw. The application blocked known SQL keywords such as select and union using simple string replacement. Because the filter only removed the keyword once per pass, doubling a keyword's middle letters, so that removing one copy left the other intact, reconstructed a working keyword after the filter ran. Chaining this with boolean and substring-based blind extraction recovered the database and table names, and eventually the flag, one character at a time via response-code differences.
A four-stage privilege escalation
The second challenge required stacking four separate weaknesses to reach an admin-only file manager:
- An authentication token derived predictably from a user ID made it possible to view, and then reset, another account's password without knowing their personal details first.
- An IP allow-list restricting access to the admin panel was bypassed using a client-supplied forwarding header that the server trusted instead of the real connection address.
- The admin panel exposed functionality only through an undocumented action parameter, found by probing likely values.
- A file upload feature enforced extension, content-type and content checks separately, each one bypassable on its own, letting a combination of a disguised extension and an encoded payload slip through all three at once.
Why it matters
Both challenges share a lesson: filters and access controls that each catch the obvious case, but trust client-supplied values, apply a rule only once, or can be satisfied piecemeal, are rarely equivalent to the protection they appear to offer. A defender reviewing upload validation or access restrictions should check whether each control is genuinely separate from the others, and whether any of them trust a value the client can set.
Key takeaways
- A single-pass string filter can be defeated by duplicating the blocked keyword so a remnant survives removal
- Predictable session or authentication tokens derived from a user ID let an attacker impersonate other accounts
- IP allow-lists that trust a forwarding header instead of the real connection address are not real access control
- Upload filters that check extension, content-type and content separately can be bypassed one check at a time
- Chained, individually minor weaknesses often add up to full privilege escalation
This note has been rewritten and checked for this edition; it is not a copy of the original post.