Capture the Flag - Mindreader

2017 was a tough one. Nonetheless, big thanks to for hosting an event.


Can you read my mind?

No hints.

All you get is an input box:

sql error

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)

  <head> </head>
    <p>Hello, what do you want to read?</p>
    <form method="GET">
      <input type="txt" name="f" />
      <input type="submit" value="Read" />

Moving on, let's check the input box. Entering abc returns a 404:

Not Found

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, 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.

Entering /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 /etc:

Debian GNU/Linux 8 \n \l

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

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
  • /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 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.

$ 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 /dev symlinks?

At this point it was getting frustrating 1. stderr and stdout also returned 403. mindreader was not liking specific keywords. stdin was an okay keyword but cannot be used.

The thing that finally got me out of this rabbit hole was Advanced Programming in the UNIX Environment specifically 3.16 /dev/fd.

$ 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 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 /proc

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:




  1. I never got to the bottom of why some keywords were filtered. Here is a great explanation Hacking Livestream #23: Google CTF Quals 2017