2017 was a tough one. Nonetheless, big thanks to for hosting an event.
Challenge: 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)
<html> <head> </head> <body> <p>Hello, what do you want to read?</p> <form method="GET"> <input type="text" name="f"> <input type="submit" value="Read"> </form> </body> </html>
Moving on… let’s check i/o of that input box
abc returns a 404:
The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.
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-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, it’s starting to feel like a local file inclusion challenge.
/etc/passwd (common file on *nix system) yielded an interesting output:
Could spend days guessing location of the flag file, but deep down you know the answer is …
We know a valid file path will echo the contents of a file. Since there are a lot of files it makes sense to get an idea of where we are and what’s running.
Debian GNU/Linux 8 \n \l
So we have Debian “jessie”, which gives an idea what linux files we may expect. Check out FHS for more info.
After 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
Forbidden You don’t have the permission to access the requested resource. It is either read-protected or not readable by the server.
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.
/etc returns 404 and
/proc returns 403
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 inspiration. 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.
$ ls -l /dev/stdin lrwxrwxrwx 1 root root 15 Jun 25 10:04 /dev/stdin -> /proc/self/fd/0
Is it possible we can get access to
/proc via the
At this point it was getting frustrating [see update below].
stdout also returned 403. mindreader was not liking specific keywords.
stdin was an okay keyword but cannot be used.
$ ls -l /dev/fd lrwxrwxrwx 1 root root 13 Jun 25 10:04 /dev/fd -> /proc/self/fd
We can use
/dev/fd symlink to access
/proc/ without .. typing .. in .. ‘proc’
Linux version 3.16.0-4-amd64 (email@example.com) (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 (get it?) 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:
UPDATE I never got to the bottom of why the keywords were filtered. Here is a great explanation Hacking Livestream #23: Google CTF Quals 2017