Capture the Flag - Mindreader
2017 was a tough one. Nonetheless, big thanks to for hosting an event.
Challenge:
Can you read my mind?
No hints.
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="txt" name="f" />
<input type="submit" value="Read" />
</form>
</body>
</html>
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:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
[..]
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
:
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
/proc/version
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/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.
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.
We can use /dev/fd
symlink to access /proc/
without .. typing .. in .. 'proc'
/dev/fd/../../version
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:
/dev/fd/../environ
Flag:
CTF{ee02d9243ed6dfcf83b8d520af8502e1}
-
I never got to the bottom of why some keywords were filtered. Here is a great explanation Hacking Livestream #23: Google CTF Quals 2017 ↩