Capture the Flag - Mindreader
2017 was a tough one. Nonetheless, big thanks to for hosting an event.
Can you read my mind?
All you get is an input box:
Checking the page source doesn't reveal anything fruitful. In hindsight the
name="f" may have been
a clue, but it's subtle. (spoiler: f for file)
Moving on, let's check the input box. Entering
abc returns a 404:
Likewise other words,
flag.txt return a 404.
At this point one has to make a decision. Brute force, i.e., throw a word-list at the problem or continue pounding your head.
Took a step back, re-re-read the FAQ for inspiration and reiterated what I already knew. Brute-forcing is almost always not the right solution:
A good CTF challenge doesn't require a lot of guessing, in that it should be quite clear what is the problem to solve after a short time looking at it
Some google searches later, some more prodding, it's starting to feel like a local file inclusion challenge. A type of vulnerability that allows an attacker to read files on the server.
/etc/passwd (very common file on *nix system) yielded interesting output:
Could spend days guessing the location of flag file, but deep down you know the answer is: "don't do that".
At this point we know we can read files on the server, and we suspect the flag is in a file. Let's
poke around some more by reading files in
So we have Debian "jessie", which gives an idea what linux files we may expect. The Linux Filesystem Hierarchy is a good reference for understanding the purpose of various directories and files on a linux system.
After even more probing and information gathering I moved on to
/proc, a special-purpose
filesystem that contains info about currently running processes and kernel parameters. Inspiration
from Discover the possibilities of the /proc directory
Woaaaaahh!! This is unusual and whenever you see something unusual it gets exciting. Do we
need root, issues with mounting
/proc? This post is getting long so I'll gloss over some bits.
After a bunch of tinkering it became apparent the string 'proc' was getting filtered. Mash
lkkljhdfproc on your keyboard and it'll return 403.
More internet. Solving problems with proc, specifically Redirect harder:
Most UNIX tools can read from standard input, either by default or with a specified filename of "-".
But sometimes we have to use a program which requires an explicitly named file. proc provides an elegant workaround for this flaw.
A UNIX process refers to its open files using integers called file descriptors. When we say "standard input", we really mean "file descriptor 0". So we can use /proc/self/fd/0 as an explicit name for standard input:
This trick is useful enough that many distributions provide symlinks at /dev/stdin, etc.
Is it possible we can get access to
/proc via the
At this point it was getting frustrating 1.
stdout also returned 403. mindreader
was not liking specific keywords.
stdin was an okay keyword but cannot be used.
We can use
/dev/fd symlink to access
/proc/ without .. typing .. in .. 'proc'
Linux version 3.16.0-4-amd64 ([email protected]) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2 (2017-04-30)
FINALLY!!!! we can access
Clearly mindreader made it difficult to get here, so now that we're here let's explore.
With enough probing you'll eventually come across
environ, this Red Hat Chapter 5. The proc File
System was useful.
Some more probing and testing of various processes will lead to: