TryHackMe Writeups: Pickle Rick CTF

I recently completed TryHackMe’s Rick and Morty themed capture the flag (CTF) called Pickle Rick. We need to find three different flags on a target web server which contain the three ingredients needed to change Rick back into a human! There are some other great writeups for this CTF which you can find at the end of this post, and also on TryHackMe’s website.

Concepts

This is a great CTF for practicing the following concepts:

• Command Injection (Formerly number 1 on the OWASP Top 10 list, and currently number 3 )
• Broken Access Control (Currently number 1 on the OWASP Top 10:2021 list)
• Privilege Escalation

Tools

Here are some ‘recommended’ tools for this CTF

• A Web-browser
• TryHackMe’s AttackBox (A Hosted virtual machine with several hacking tools preinstalled, and already connected to TryHackMe’s VPN)

My Solution

First, we can open up the webapp that is hosted on the server by simply typing its IP address into the browser’s URL bar.

Next, we can take a look at the page source (right click and select “View Page Source” in Firefox) to see if there are any obvious leads in the source code.

There isn’t much here, but we do see a “Note to self” from the developer to remember a username: “R1ckRul3s”. This will probably come in handy; however, there is no obvious “login” button on the front page of the web app. We can try to request our best guesses for a login URL (http://<server_IP>/<guess>) using a few guesses. We can start with simply “login” but that resulted in a 404 error. However, the 404 message revealed that the web server is running Ubuntu and the specific version of Apache (version 2.4.18) that is using.

A quick aside (feel free to skip this paragraph!): we don’t end up needing this information, but we can check if there are any common vulnerabilities and exposures (CVEs) for this specific version of Apache, for example using Mitre’s CVE database, and sure enough there are quite a few. CVE-2016-4979 looks particularly promising. The official description is ‘The Apache HTTP Server 2.4.18 through 2.4.20, when mod_http2 and mod_ssl are enabled, does not properly recognize the “SSLVerifyClient require” directive for HTTP/2 request authorization, which allows remote attackers to bypass intended access restrictions by leveraging the ability to send multiple requests over a single connection and aborting a renegotiation.’ (my emphasis). We don’t know if mod_ssl and mod_http2 are enabled or not, but It’s fun to think about these kinds of solutions!

Back to the solution. We can try accessing “login.php” which exists, and contains a login portal (see below). But we still need a password. We can guess a few common passwords (“password”,”1234″, etc. ), but that doesn’t end up working. We will need to do a bit more exploration.

Next, we can look at the “robots.txt” file for this website in case it points out any “hidden” resources. We can see that It contains only a single line with the txt “Wubbalubbadubdub“. This is very unusual, since there are no robots.txt directives, so this is probably useful information. Since we still need a password, and there is no other obvious use for this information, we can try entering “Wubbalubbadubdub” as password. That works, and, now we’re in! After logging in, there is a page with a “Command Panel”. We know that the server runs on Ubunutu, so we can try some common Linux commands in case the web app is vulnerable to command injection.

Typing in ‘ls’ and clicking ‘Execute’ lists the contents of the web apps’ running directory:

Sup3rS3cretPickl3Ingred.txt
assets
clue.txt
denied.php
index.html
login.php
portal.php
robots.txt

Obviously, we want to know what is inside of both ‘Sup3rS3cretPickl3Ingred.txt’, which should be one of the flags, as well as ‘clue.txt’. Typing in ‘cat Sup3rS3cretPickl3Ingred.txt’, leads to an entertaining surprise.

The ‘cat’ command is apparently disabled somehow (so is ‘more’). ‘less’ works, but we can be more creative. Using ‘grep’ and a regular expression with a one-character wildcard should work very similarly to ‘cat’ in practice. I used:

$ grep . <file>

or, using an empty match string:

$ grep "" <file>

Both of these allow us to read “Sup3rS3cretPickl3Ingred.txt”, revealing the first flag: “mr. meeseek hair”. By the way, now that we know that “clue.txt” and “Sup3rS3cretPickl3Ingred.txt” exist, we can simply retrieve them in our browser using a normal http request. As an example, we can use a browser to read “clue.txt”. We can actually read all .txt files in the webapp’s root directory without authentication here by requesting http://10.10.251.159/clue.txt (etc.) without ever logging in. I verified this with a completely fresh AttackBox instance and fresh browsing session. This is known as “broken access control”, which is the current number 1 most critical webapp vulnerability on the OWASP Top 10:2021 list.

Clearly, we need to take a look around the filesystem for the other ingredient(s). Going back to the command panel, we can check where we are with ‘pwd’. We are just in ‘/var/www/html’, which is the default root directory for Apache2. We can also check the contents of the root of the filesystem, ‘/’ that is, using ‘ls -al /’ (result below). We see the usual directories here, with no real surprises. Two likely places for a flag are in the home directories of various users (including regular users and the root user). We can see that the permissions of the ‘/home’ directory gives all users read access to the directory, while only the root user has at least read permissions on ‘/root’ (of course). We will start with ‘/home’.

Looking inside ‘/home’, we find two user directories, ‘ubuntu’ and ‘rick’. The user ‘rick’ seems quite topical, so we can start there. Using ‘ls -al \home\rick’ shows the contents of the home directory for ‘rick’ (shown in image below, with command re-entered into the command panel for clarity).

We can view the contents of the file with:

grep . "/home/rick/second\ ingredients"

which gives us the second flag: 1 jerry tear.

We can look around in the ‘ubuntu’ users home directory, but we don’t see anything out of the ordinary. This just leaves ‘/root’ to search. We can check which user is running the web app user using ‘whoami’ and, of course, the user is ‘www-data’. We need to try to escalate our privileges somehow to reach the root flag. We can try using ‘sudo whoami’ to see if we are able to become root (see below, command re-entered for clarity).

This means that ‘www-data’ is a ‘sudoer’, and may not even require a password for some commands. Thankfully, we can run ‘ls’ as root. After reviewing some other writeups, we can see that a better way to approach this would have been to simply use ‘sudo -l’ to list what commands we can run as root. It turns out that ‘www-data’ can run any commands as root without a password. Still, we can now easily look through ‘/root’ with ‘sudo ls -al /root’.

This reveals a file called ‘3rd.txt’ which probably contains the last flag. Using ‘sudo grep . /root/3rd.txt’ indeed reveals the third flag: fleeb juice

Post CTF Analysis

This blog is all about learning, and there is a lot to be learned from considering different ways to solve the same problem. If you did something different, I would love to hear about it. Connect with me on LinkedIn, and share your ideas. My favorite “writeup” for this TryHackMe room / CTF is John Hammond’s video walkthrough on YouTube. I also found one of the writeups linked from TryHackMe by “theFluffy007” to be useful. Here are some things that I learned from those writeups:

• Although it didn’t change much in this case, starting with an nmap of the target is typically a good initial move to generate some leads.
• I used a manual enumeration approach, especially to find the login portal and robots.txt. Again, this worked out just fine for this CTF, but for larger-scale CTFs or CTFs with fewer ‘bread crumbs’ it is easy to use a tool like ‘gobuster’ or ‘nikto’ to help with enumeration early on.
• I completely missed an entertaining “rabbit hole” which John Hammond goes over in his video. I also didn’t see this in any other writeups. He noticed some base64 string in the login.php source, and had to ‘decode’ it to several times in a row to reach the end. I’ll let you see this in his video for yourself, linked above. This was not essential for this specific CTF; but, it is best to be able to spot any potential leads in case we end up needing them.