Sunday Writeup w/o Metasploit
Last updated
Last updated
First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
-sC: run default nmap scripts
-sV: detect service version
-O: detect OS
-oA: output all formats and store in file initial
We get back the following result showing that 2 ports are open:
Port 79: running Sun Solaris fingerd
Port 111: running rpcbind
Before we start investigating these ports, let’s run more comprehensive nmap scans in the background to make sure we cover all bases.
Let’s run an nmap scan that covers all ports. Since the full nmap scan takes too long to run, let’s first run a quick scan to figure out which ports are open.
— max-retries: number of port scan probe retransmissions
We get back the following result showing that two other ports are open.
Then we run a more comprehensive scan to identify services running on the above ports.
We get back the following result showing that:
Port 22022: is running SunSSH 1.3
Port 55029: is running a service that nmap was not able to identify
Since the UDP scan took too long to run, we don’t have UDP scan results for this blog.
We’ll start off with enumerating port 79. A quick google search on the “Finger service” tells us that the finger protocol is used to find out information about users on a remote system. Therefore, we can use it to enumerate usernames.
First, check if there are any logged in users.
No one is currently logged in. Let’s check if the user “root” exists.
It does exist. Now, let’s enumerate more usernames. The seclists project has a list of usernames that we can use in order to guess the usernames that are available on the server.
Pentestmonkey has a finger-user-enum script that is used to enumerate OS-level user accounts via the finger service. Let’s run that on our host.
-U: file of usernames to check via finger service
-t: server host running finger service
We get the following result showing us that “sammy” and “sunday” are users of the system.
Since SSH is open and we have two valid usernames, let’s try brute-forcing the users’ credentials using hydra. We’ll start off with Sunny.
-l: username
-P: password file
-s: port
We get back the following result showing us that Sunny’s password is “sunday”.
SSH into Sunny’s account.
We get the following error.
The error tells us that the client and server were unable to agree on the key exchange algorithm. The server offered three legacy algorithms for key exchange. So we’ll have to choose one of these algorithms in order to login.
-oKexAlgorithms: enable a key exchange algorithm that is disabled by default
We’re in! Locate the user.txt flag and try to view it.
We need to escalate our privileges to Sammy.
Run the following command to view the list of allowed commands that the user can run with root privileges.
We can run the /root/troll command as root. This is obviously a custom command so let’s run it to see what it’s doing (we don’t have read access to it).
It seems to be a script that prints the id of the user running it. Since we ran it with the ‘sudo’ command, it prints the id of root. We don’t have write access to the script, so we can’t escalate our privileges using it.
After a bit of digging, I found a backup file in the following directory.
It contains two files agen22.backup and shadow.backup. The former we don’t have access to, however, we can view the latter.
It’s a backup of the shadow file. We already know Sunny’s password so we’re not going to attempt to crack it. Instead, copy Sammy’s password and save it in the file sammy-hash.txt. Then use John to crack the hash.
We got a password! Let’s su into Sammy’s account.
Now we can view the user.txt flag.
Let’s try to escalate to root privileges. Run the sudo command again to view the list of allowed commands the user can run as root.
We can run wget with root privileges! If you’re familiar with the “-i” flag in wget, you’ll know that we can use it to output the content of files. Therefore, we can run the following command to get the root flag.
However, in this scenario we’re simply reading the content of the flag and not really escalating privileges. To get a root shell we need to chain the following two vulnerabilities:
The user Sunny can execute the /root/troll file with root privileges, and
The user Sammy can overwrite any root owned file using the wget command.
Therefore, we’ll use Sammy’s sudo privileges to overwrite the /root/troll file and include a shell in it. Then we’ll use Sunny’s sudo privileges to run the /root/troll file and convert our shell to a root shell.
Alright, let’s do this! In the attack machine, create a file called “troll” and add the following code to it.
Then start up a simple Python server in the directory the file is in.
Go back the target machine running with the Sammy user privileges, and run the wget command to overwrite the /root/troll file.
In another SSH session running with the Sunny user privileges, execute the troll file.
Since we added a bash shell in the troll file and the troll file is being executed with root privilege, we get a root shell!
Note: Something on the server seems to be resetting the /root/troll file every couple of seconds, therefore you only have small window of time between overwriting the troll file as Sammy and executing the troll file as Sunny.
To gain an initial foothold on the box we exploited two vulnerabilities.
Username enumeration of the finger service. The finger protocol is used to get information about users on a remote system. In our case, we used it to enumerate usernames that we later used to SSH into the server. The remediation for this vulnerability would be to disable this service.
Weak authentication credentials. After getting a username from the finger service, we ran a brute force attack on SSH to obtain a user’s credentials. The user should have used a sufficiently long password that is not easily crackable.
To escalate privileges we exploited three vulnerabilities.
Information disclosure. As a non privileged user, we had access to a backup of the shadow file that leaked hashed passwords. Any file that contains sensitive information should not be available to non privileged users.
Weak authentication credentials. Although the passwords were hashed in the backup shadow file, we were able to obtain the plaintext passwords by running john on the hashes. Again, the users should have used sufficiently long passwords that are not easily crackable.
Security Misconfigurations. Both Sammy and Sunny were configured to run commands as root. Chaining these two commands together allowed us to escalate our privileges to root. The administrators should have conformed to the concept of least privilege when configuring these users’ accounts.
