Skip to main content

Vulnerabilities discovered by Outpost24 in Oracle WebCenter Sites

07.Aug.2019
Jonas Mattsson, Ghost Labs
Ghost Labs
This post explains how the vulnerabilities in Oracle Webcenter Site were found and how they can be exploited.

As stated in one of our previous blog posts; occasionally during penetration testing there seems to be no issues worth reporting. In this case, the system is tested several times before, patches had been applied and there just did not seem to be any new issues. However, by combining determination to find new vulnerabilities, coffee, frustration, my bad sleeping habits and some more coffee, I managed to find several high-risk 0-days vulnerabilities in the customer's content management system. This post will explain how the vulnerabilities were found and how they can be exploited.

It's all in the head(ers)

After exploring and testing the web application’s functionalities thoroughly, I did not find any new issues worth reporting. The application was mostly static and most of our previously reported issues had been remediated. I went through the findings from our previous tests and looked at areas that could be worth exploring again, performed dictionary attacks to discover other files or folders and used Google to see if it had indexed anything of interest. These and various other attempts to expand the attack surface did unfortunately not result in any new vulnerabilities to report.

I did however note that the application returned a non-standard HTTP header called "host_service" exposing what looked like an application name and version number:

Response headers containing the ”host_service” header
Response headers containing the ”host_service” header

A Google search revealed that the software in use was in fact Oracle WebCenter Sites 11.1.1.8.0. The name in the “host_service” header had not been changed after Oracle bought the company that originally developed this software. Further googling resulted in me finding a post in The Exploit Database as well as a CVE Details page containing a list of 21 previously identified vulnerabilities linked with Oracle WebCenter Sites 11.1.1.8.0

https://www.exploit-db.com/exploits/44752

https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-33546/version_id-192565/Oracle-Webcenter-Sites-11.1.1.8.0.html

I noticed that the vulnerable version of Oracle WebCenter Sites had already been reported before, along with the published Cross-Site Scripting exploits from Exploit Database. I have tested these exploits against the customers application, but the payload did not trigger as these vulnerabilities had already been patched by the customer.

At this point I felt that both my patience and the web application had been thoroughly tested. However, I do not give up easily and I still had more time to spend on this test. Therefore I decided that it would probably be better to shift focus to the Oracle WebCenter Sites system in order to find zero days or figure out how to exploit the published vulnerabilities on CVE Detailes.

Not completely re-inventing the wheel

The Cross-Site Scripting exploits in The Exploit Database looks as follows:

  1. https://mirmine.net/cs/Satellite?c=qqqq&cid=qqqq&pagename=OpenMarket/Gator/FlexibleAssets/AssetMaker/confirmmakeasset&cs_imagedir=qqq"><script>alert(24)</script>
     
  2. https://mirmine.net/cs/Satellite?destpage="<h1xxx<scriptalert(1)</script&pagename=OpenMarket%2FXcelerate%2FUIFramework%2FLoginError

The vulnerable parameters are "cs_imagedir" and "destpage" with the "pagename" parameter set to different files, omitting the extensions. This gave me a brilliant idea, “What if I could find other files where the "cs_imagedir" or "destpage" parameter were present and see if I could execute the Cross-Site Scripting attack there as well?”

I used grep to search for other files where the "cs_imagedir" parameter was present and added the paths of these files to a list. The list was then used as input to Burp Proxy's Intruder with the "pagename" parameter set to each of the different paths to see if there were other pages where the value of the parameters were reflected in the response, for example:

https://mirmine.net/cs/Satellite?c=qqqq&cid=qqqq&pagename=[PATH_FROM_LIST]&cs_imagedir=qqq"><script>alert(24)</script>

This resulted in me unearthing first zero-day, a Cross-Site Scripting vulnerability in the "complexmakeasset.xml" file:

https://mirmine.net/cs/Satellite?c=qqqq&cid=qqqq&pagename=OpenMarket/Gator/FlexibleAssets/AssetMaker/complexassetmaker&cs_imagedir=qqq"><script>alert(24)</script>

Screenshot of successfully triggering cross-site scripting on the webpage
Screenshot of successfully triggering cross-site scripting on the webpage

As I explored further down this road, I found two other Cross-Site Scripting vulnerabilities in the "WemUI" parameter:

https://mirmine.net/cs/Satellite?pagename=OpenMarket%2FXcelerate%2FActions%2FSecurity%2FNoXceleditor&WemUI=qqq%27;}%3C/script%3E%3Cscript%3Ealert(24)%3C/script%3E

https://mirmine.net/cs/Satellite?pagename=OpenMarket%2FXcelerate%2FActions%2FSecurity%2FProcessLoginRequest&WemUI=qqq%27;}%3C/script%3E%3Cscript%3Ealert(24)%3C/script%3E

Exploring further

The same method that was applied earlier was then used for all files in the OpenMarket directory (omitting the file extension). In doing so, I could see which other files could be loaded using the pagename parameter. This resulted in finding the Webreferences.jsp and Slots.jsp files, amongst others.

https://mirmine.net/cs/Satellite?pagename=OpenMarket/Xcelerate/Admin/WebReferences
https://mirmine.net/cs/Satellite?pagename=OpenMarket/Xcelerate/Admin/Slots

Requesting these files returned a HTTP 200 OK status but had a JavaScript redirect to the login page, as I was not authorized to access these resources. However, looking at the response I could see that the content of the page was returned below the JavaScript redirection, also known as "Execution after Redirect". By simply removing the JavaScript redirection from the response, I got access to the page.

The JavaScript redirect-code
The JavaScript redirect-code

A match-and-replace filter was added in Burp Proxy in order to remove the JavaScript redirection from all responses automatically. Requesting the page again resulted in the page being loaded:

By removing the JavaScript redirect-code, it was possible to obtain unauthorized access to administrative pages
By removing the JavaScript redirect-code, it was possible to obtain unauthorized access to administrative pages

The authorization check was bypassed, so I tried the functionality of the page. Performing a search resulted in the following POST request:

performing a basic search
Performing a basic search

And the response containing the search results:

Vulnerabilities-discovered-in-Oracle-WebCenter-Sites-6.png

Reviewing the Source Code

The functionality of the webreferences and slots pages were unfortunately not that interesting. The source code of them however, was. After a quick review I noted that they should be vulnerable to SQL injection in several parameters as they construct SQL queries from raw parameter values.

As an example, the value of the search Text parameter in webreferences.jsp is used to construct a SQL query as follows:

Vulnerabilities-discovered-in-Oracle-WebCenter-Sites-7.png

By performing a search with ”qqq” in the searchText parameter, the query becomes as follows (the order by part is set to “createddate asc” per default):

select * from Webreferences where webroot like '%qqq%' order by createddate asc

To test the injection in the “searchText” parameter, I made a simple Boolean test by setting the searchText parameter to a true statement (' or '1'='1'-- ). This should result in the following SQL query being run and return all entries in the Webreferences table (everything after “--” will be ignored by the database as it is a line comment):

select * from Webreferences where webroot like '%' or '1'='1' -- %' order by createddate asc

Testing the SQL injection:

Testing the SQL injection:

This resulted in the application responding as expected, returning all entries from the webreferences table, indicating that the injection was successful:

Vulnerabilities-discovered-in-Oracle-WebCenter-Sites-9.png

To further validate the injection, I modified the payload so that the query would return no results by changing the “searchText” parameter to a false statement (' and '1'='2' --), which resulted in the following response:

Vulnerabilities-discovered-in-Oracle-WebCenter-Sites-10.png

Further testing revealed that it was possible to perform a union-based SQL injection which made data extraction easier:

Vulnerabilities-discovered-in-Oracle-WebCenter-Sites-11.png

The above request resulted in the application responding with the usernames and password hashes of the “Systemusers” table (the user table of Oracle WebCenter Sites):

Vulnerabilities-discovered-in-Oracle-WebCenter-Sites-13.png
Vulnerability Discovery Timeline


 

GET A PENTEST


 

ghost labs logo

About Ghost Labs 

Ghost Labs is the specialist security unit within Outpost24, offering enhanced security services such as advanced network penetration testing, (web)application testing, Red Teaming assessments and complex web application exploitation. In addition, the Ghost Labs team is an active contributor to the security community with vulnerability research and coordinated responsible disclosure programs.

Ghost Labs performs hundreds of success penetration tests for its customers ranging from global enterprises to SMEs. Our team consists of highly skilled ethical hackers, covering a wide range of advanced testing services to help companies keep up with evolving threats and new technologies.

Looking for anything in particular?

Type your search word here