I often try to remind myself that it’s really important to share knowledge. Everyone starts off in a similar position – unfortunately, some people quickly forget they were once starting out, so they retain as much knowledge as possible without sharing this amongst the community.
Fortunately, for the most part, I find the Infosec community is really good at sharing lessons learnt.
Troy Hunt shares a very good resource where you can test your hacking skills – https://hack-yourself-first.com/ I decided to give it a go. Unfortunately, I broke the website unintentionally. Sorry Troy! 😳
What I found
The website appears to be a directory of super cars. You can visit any of the manufacturer pages which list different cars. There is also the ability to register for an account and vote for your favourite car.
I decided to register for an account. I input a random e-mail address, name, and password. The website warned me I could not register as the password I had chosen was in use by another user. Worse still, the website told me which user had that same password! This isn’t good security practice at all.
Instead of trying a different password, I used the username and password it gave me to log in.
Stored XSS Vulnerability
I proceeded to go and vote on a car.
Stored XSS is extremely dangerous. There’s a number of things you can do, but here are a few examples:
Redirect users to another website. You could potentially redirect users to a fake login page hosted elsewhere that is styled like the initial website. They may then be tricked into submitting their login details on your website.
Cookie theft – a lot of websites will store a session cookie on your computer to remember you when you return to the website. Ultimately, if someone else obtained this session cookie, they could log in without your password. You can steal cookies very easily using XSS.
Now I had identified the stored XSS vulnerability, I browsed the website further to see what I could find.
The next vulnerability I found was an SQL Injection. At the bottom of the main page are some links where you can display cars based on their cylinder count. Take a look at the URL:
As we can see, there is a parameter in the URL which specifies the number of cylinders.
At a guess, the query in the code that sits behind this will look something like this:
Speculative query: SELECT carID, carName FROM tableWithCars WHERE cylinders = $_GET['Cylinders']
I find it’s always helpful to try and predict the query you are trying to inject. If the code isn’t correctly sanitising the ‘Cylinders’ parameter, then perhaps we can add additional SQL code here and manipulate the query. If successful, we can bring back data we are not supposed to see.
Here are the injections I tried:
?Cylinders=V12' OR 1=1--
?Cylinders=V12' OR 1=1 UNION ALL SELECT '1' As t, table_name FROM information_schema.tables--
?Cylinders=V12' OR 1=1 UNION ALL SELECT '1' As t, column_name FROM information_schema.columns WHERE table_name = 'UserProfile'--
?Cylinders=V12' OR 1=1 UNION ALL SELECT '1' As t, Concat(Email, ' ', Password) COLLATE database_default FROM UserProfile--
These are just a few of the injection methods I found. Using these SQL Injections, you can:
See what databases are on the server
See the column and table names on the server
See the contents of other tables (such as the users table)
There are loads of things you can do. One of the things I attempted was to delete the contents of the users table. I presumed this would just flush the contents of the table meaning people would need to re-register. I won’t explain how I did this, as it seemed to break the pages where you can vote for a car. The pages were returning a server error – division by zero.
I tried to understand the reason for this. My assumption (which could be completely wrong) is as follows:
When truncating the users table, I believe it also dropped all rows in the Votes table. This is probably because the tables relate to each other and it will delete all related rows in other tables to avoid breaking referential integrity.
I then believe the pages where you vote for the car need at least one vote in order to function, potentially because it tries to calculate the rank based on the number of votes. If the car has zero votes, I guess it is trying to divide something by zero, which is a mathematical impossibility.
I tried finding other injection points on the website so I could attempt to fix this by inserting some vote rows for each car. Fortunately, I found a way! I inserted a test comment for each super car using another SQL Injection, and the website became functional again.
I recommend testing your skills on this website – Troy Hunt encourages users to do so, cordially. I certainly do not recommend deleting table contents though as I did – I didn’t think it would break the site quite like this. Sorry!
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.
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/
The above 4 were all interesting to check out – I started at the top and worked down.
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.
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.
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.
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.
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
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
recordset = getLogsFromSql(record.host)
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
Cookie warnings are really annoying - I agree, but sorry, I have you tell you about them; its the law.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.