Let's take a breath for a moment, it is 2017. And Still SQL Injection, 17-18 years since its inception is an issue!

This post will follow the journey I took to combine 3 (technically 4 or 5) different issues which the end result was remote code execution; or more I gained a shell as an Administrator user on 'doze. And if we're being honest here, what hacker doesn't like getting admin privs.

TL;DR

If you can't be bothered reading the entire post, the too long didn't read version is, I found a misconfigured host & leveraged a few vulnerabilities to gain the final end goal of remote code execution!

1. Auth bypass -> Blind XXE
2. Blind XXE -> Information Disclosure -> SQL Injection
3. SQL Injection -> Command Execution -> RWX Permissions as Administrator
4. Profit.

The Beginning

The chain of issues started with an outdated instance of Oracle E-Business Suite which has many publicly disclosed issues, two of which were an authentication bypass & a blind XXE vulnerablity. For anyone who's ever come across Oracle EBS you'll know if it's outdated often it'll be riddled with holes, which is great from a bug bounty & pentesting perspective but not so great for companies who are using it.

Various Issues

Starting off with the authentication bypass, it was posssible to dump out debug information by first browsing to OA.jsp which in the installed version of EBS enabled an authentication bypass as the guest user.

http://targethost/OA_HTML/OA.jsp

Which results in an error similar to: You have encountered an unexpected error, from here I was granted a valid session as the guest user allowing me to view debug information from the login form. This debug information disclosed a few things:

1. The host operating system
2. The path in which the application(EBS) was installed
3. The Backend database

There are a lot of little details in the debug information which when combined with other bugs resulted in some interesting details.

So armed with the OS, Application Path AND the DB architecture, I had a sweet authentication bypass with some information disclosure. Which by itself is a nice little bug however I wanted more.

Digging Deeper

Parking the info disclosure for a second and traversing the EBS instance I came across another endpoint which was vulnerable to blind xxe. Blind XXE is an interesting vulnerablity as my initial thoughts were it's not much just some port scanning and file identification. Following some research(detailed in another upcoming post), I was able to leverage the blind XXE to extract another endpoint from /etc/hosts.

This endpoint was not accessible via the Internet as it was found to be an internal IP. However via the XXE it was possible to read users' .bash_history files, by leveraging this a line in this file was found to link the internal IP to an external domain which when I carried out a DNS lookup against provided me with an internet IP! Great.

Now a quick reference back to the program to confirm the scope and sure enough, the domain was covered under the scope *.example.com. However it had not shown up in my original recon which made it more of an interest to me now, especially as its internal hostname was ExperimentDB-92Hn192, the external domain had no reference to DB at all meaning if it was found in the wild on its own it wouldn't be as exciting. The external hostname was my.example.com.

Fast forward recon against this domain I found this particular host happened to have an obscure dashboard running that showed by default a guest user logged in. This was outlined with a paramater guest=1, naturarly I tried flipping this to 0, itterating the number & fuzzing the different options however with no luck.

Following this I tried to blindly fuzz other parameters, which is when I found the parameter tabl=default, now this could mean anything really but after a few rounds of playing with this one paramater it became clear this was loading information from some form of database.

Drum roll...

Yep, you guessed it... heavy breathing intensifies SQL INJECTION. Throwing a few generic SQL strings at it allowed me to determine the database to be Microsoft SQL(mssql).

Armed with this information my next task was to try and identify the version using manual SQLi:

'+AND+SELECT+@@version+--

This returned the version in use as:

Microsoft SQL Server 2005 - 9.00

Which was surprisingly easy to acomplish based upon almost any SQL queries being accepted after '+ as + was used instead of spaces due to the little filtering that was in place. Following other enumeration from here I identified that this version supported xp_cmdshell however when running a basic command nothing was returned.

This made me think maybe today wasn't the day for mass pwnage from SQLi.

Fear Not!

If something is disabled, surely there must be a way to enable it. Enter stack overflow, the answer to (almost) all questions! Via the SQL injection I was able to re-enable xp_cmdshell:

'+AND+EXEC+sp_configure+'show advanced options',+1
'+AND+RECONFIGURE
'+AND+EXEC+sp_configure+'xp_cmdshell',+1
'+AND+RECONFIGURE

Executing these four queries enabled me to run xp_cmdshell queries! So to now prove I had command execution I initiated the query:

'+AND+EXEC+master.dbo.xp_cmdshell+'net users'

Which showed that there were two users on the system, Administrator & Guest, now this allowed me to identify two things, 1) there wasn't a seperate user for the DB instance meaning that this might be running as admin & 2) command execution was successful!

It did however only prove that there was read access to the system, I wanted more, so I created a temp file on the C:\ drive to show writing files were possible.

'+AND+EXEC+master.dbo.xp_cmdshell+'echo 1 > C:\Zephr.txt'

Which appeared to be successful as no errors were disclosed however to confirm I listed the directory and the file was there. Great! read, write & clearly execute permissions. To tidy up I also confirmed I could delete the file using:

+AND+EXEC+master.dbo.xp_cmdshell+'rm C:\Zephr.txt'

A quick directory list showed that the file had also been deleted, at this stage I began writing up my findings and reported them back to the program, they have since patched this issue by removing the endpoint.

So to round it up, essentially I chained four vulnerabilites to get command execution, not a bad few days work!

• Auth Bypass + XXE + Information disclosure + SQLi = RCE