Since this is my first blog post about capture-the-flag machines, I’ll give a little background information for anyone who isn’t familiar with them. Matrix : 1 is a vulnerable machine provided by https://vulnhub.com, an information security service whose goal is
To provide materials that allows anyone to gain practical ‘hands-on’ experience in digital security, computer software & network administration.
https://vulnhub.com
It’s a service that I’ve used often and it has helped me gain experience with different technologies and different vulnerabilities. It’s extremely useful and is a wonderful way to learn about information security. Matrix: 1 is a machine that I’ve recently compromised and the following is a walk-through for anyone who may be stuck and unsure about how to proceed. I’ve used walkthroughs like these whenever I have exhausted what I believe are all of my options on a machine and each one has helped me learn about new techniques and technologies. Hopefully, this will help someone else. I usually follow a modified version of the Penetration Testing Execution Standard ( http://www.pentest-standard.org/index.php/Main_Page) so that I can get used to following a method that is widely understood and accepted.
Passive
Before sending anything to the target machine, I usually set up a rule in iptables to keep track of how much traffic I’m actually sending. I think it’s a good habit.
# set it up - before any other processing
iptables -I OUTPUT -p tcp -d matrix.local
# view traffic
iptables -L OUTPUT -nvxUsually, I just open my favorite browser to test whether or not a server has port 80 or 443 open. You can usually use the developer tools to see response headers and such. Or curl. I had Wireshark open too.
Nice. I got a bit of information, i.e. the python version and web server being used by the target machine. Taking a look at the HTTP Stream on Wireshark, I can see that an image is being displayed on the landing page of the website. The server also allows directory listing so browsing to this location gives me the directory structure beneath the “/assets” folder.
I took a look in the vendors folder to enumerate the applications available on the target machine. Some of the applications looked interesting, but I decided to follow the port.
Active
Switching from port 80 to port 31337, I found a comment in the HTML code of the page.
The comment is encoded with Base64. I can tell because Base64 is encoded in 6-bit blocks and when there isn’t enough input data the output string is padded with “=” signs. After decoding the Base64 string, I can see that text was redirected to a file in the current directory. I’m going to leave out the name of the file.
After downloading the file, I was completely lost. The spacing made me think it was a hexdump of some sort. I had never seen this before. My next thought was that it was an encoded matrix. After doing research on matrices and how they are encoded, I decided to took for things that I may have missed on the server. In order to decode a matrix, I would need the original encoding matrix to decode it. I decided to perform a full port map on the target machine using Nmap.
I did learn about the available ssh port on the target machine, but other than that I didn’t learn about any ports that may be hiding important information. I decided to do a bit more research on the source file. I found exactly what I was looking for pretty quickly. It turns out that the file was an actual source file for the Brainf*** programming language. Take a look.
There are numerous compilers and interpreters for the Brainf*** language but if you’re using a linux-based distribution test system like Kali, you can use beef ( an interpreter ) for the language to compile and run the source file.
beef [source_file]
After decrypting the source file, I was presented with an incomplete password. As you can see, the final two characters of the password are not available. However, I do have the login user name: guest. As it stands, I have a way onto the target machine as long as I can create valid wordlists.
Exploit
Using crunch, I built multiple wordlists (keeping them small) substituting the final two characters with all printable ASCII characters.
Success! I found my way on to the target machine. However, I was slightly disappointed to find a restricted shell waiting for me.
Post Exploit
There were numerous restrictions on the actions I could perform after connecting to the target machine via ssh. All of the environment variables were read only, I could only execute scripts that I copied to the machine via scp via “source [script]” ( each restricted in the same way ), I couldn’t run compiled executables, and I couldn’t add slashes to the command line.
Echoing the directory location appended with the glob character “*”, I was able to find an instance of the vi program inside of the /home/guest/prog folder of my restricted shell. As a note, I did look in multiple places before listing my own directory; including looking for running scripts and setuid files in other locations on the target machine. The VI program has the ability to execute command line arguments. By using that escape, I was able to spawn a bash shell.
After getting a bash shell, I discovered that the guest user was able to execute the sudo command. Even better, getting root privileges via sudo required the guest password which I had already acquired!
Thanks to Ajay Verma @unknowndevice64 for providing this really cool vulnerable machine on VulnHub!