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:
A Google search revealed that the software in use was in fact Oracle WebCenter Sites 184.108.40.206.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 220.127.116.11.0
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:
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:
This resulted in me unearthing first zero-day, a Cross-Site Scripting vulnerability in the "complexmakeasset.xml" file:
As I explored further down this road, I found two other Cross-Site Scripting vulnerabilities in the "WemUI" parameter:
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.
The authorization check was bypassed, so I tried the functionality of the page. Performing a search resulted in the following POST request:
And the response containing the search results:
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:
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:
This resulted in the application responding as expected, returning all entries from the webreferences table, indicating that the injection was successful:
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:
Further testing revealed that it was possible to perform a union-based SQL injection which made data extraction easier:
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):
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.