Silo Writeup w/o Metasploit
Reconnaissance
Run the nmapAutomator script to enumerate open ports and services running on those ports.
All: Runs all the scans consecutively.
We get back the following result.
We have fifteen open ports.
Port 80: running Microsoft-IIS/8.5
Ports 135, 49152, 49153, 49154, 49155,49158, 49161 & 49162: running Microsoft Windows RPC
Ports 139 & 445: running Samba
Ports 1521 & 4196: running Oracle TNS listener
Ports 5985 & 47001: running Microsoft HTTP API httpd 2.0
Before we move on to enumeration, let’s make some mental notes about the scan results.
Port 80 is running a Microsoft IIS server. A quick google search tells us that the OS is probably Windows Server 2012 R2. The gobuster scan didn’t really find anything useful for this web server.
The nmap scan reported a “guest” account for SMB, however, the smbclient scan reported an “NT_STATUS_ACCOUNT_DISABLED” status, so I doubt we’ll be able to access any of the shares. We can check this manually.
Ports 1521 & 4196 are running Oracle TNS listener. This is the database server software component that manages the network traffic between the Oracle Database and the client. If we manage to get access to this service with an account that has administrative privileges, we can potentially execute code on the box. The nmapAutomator script uses the Oracle Database Attacking Tool (ODAT) to enumerate the system ID and usernames/passwords. However, since the box kept crashing, I terminated the scan. We’ll do our own manual enumeration using this tool.
Enumeration
If you don’t have ODAT installed on kali, the installation instructions can be found here.
The first thing we need to enumerate is the Oracle System ID (SID) string. This is a string that is used to uniquely identify a particular database on a system. This can be done using the sidguesser module in ODAT.
This takes a while, but it does find 4 valid SID strings.
We’ll use the first one: XE.
The second thing to do is enumerate valid credentials. This can be done using the passwordguesser module in ODAT. I tried both account files that come with the ODAT installation, however, the tool didn’t find any valid credentials. So instead, let’s locate the credential list that the Metasploit framework uses.
Copy it into the ODAT accounts directory.
The username and passwords in this list are separated by a space instead of a forward slash (/). We’ll have to change it to forward slash so that the ODAT tool is able to parse the file. This can be done in vi using the following command.
Now that we have a proper list, we can use the passwordguesser module to brute force credentials.
Again, this also takes a while but it ends up finding credentials!
If you look at the Oracle documentation, the username/password that we found are actually one of the default credentials used when setting up Oracle. Now that we have a valid SID and username/password, let’s see if we can get code execution on the box.
Exploitation
ODAT has a utlfile module that allows you to upload, download or delete a file. Since we are trying to get code execution on the box, let’s upload a malicious executable that sends a reverse shell back to our attack machine.
First, generate the executable using msfvenom.
Next, upload the file using the utlfile module.
We get the following error.
We don’t have sufficient privileges to upload a file. Let’s see if the user was given sysdba privileges by adding the sysdba flag to our command.
Now we need to execute the file. We can do that using the externaltable module in ODAT.
First setup a listener on the attack machine to receive the reverse shell.
Next, execute the file using the following command.
We get a shell!
The database must have been running with SYSTEM privileges and so we got a shell as SYSTEM.
Grab the user.txt flag.
Grab the root.txt flag.
Note: IppSec has a great video explaining how to do this manually without having to use ODAT or Metasploit. He also goes through the intended solution for the box which is much harder than the way I solved it.
Lessons Learned
To get SYSTEM on this box, we exploited two vulnerabilities.
Use of Default Credentials. There was an exposed port that was running Oracle TNS listener. The administrator had used default credentials for a user that had sysdba (privileged) access. This allowed us to login as that user and execute malicious code on the box. Since default credentials are publicly available and can be easily obtained, the administrator should have instead used a sufficiently long password that is difficult to crack.
Least Privilege Violation. Oracle doesn’t need SYSTEM privileges to function properly. Instead it should have been run under a normal user account that has limited privileges. This way, even if we did get access to the box, we would have needed to find a way to escalate privileges, instead of immediately getting SYSTEM access without having to work for it. The administrator should have conformed to the principle of least privilege.
Last updated