Security Vulnerabilites in Customer Portal pagesets

If your Customer Portal site has a "mobile" or "basic" directory and associated pages in your "views/pages" directory your site might be at risk; especially if you don't use these pages! For nearly all sites created since the release of CP2, this will be the case unless you've taken manual steps to remove them.

What is the vulneraility?

This vulnerability puts at risk any site that has a protected Knowledgebase or has a privileged Account Create process; a malicous user could potentially:

  • Create an account on your site and manually set all Custom Field values
  • View protected Knowledgebase content.
  • Submit Incidents and manually set all Custom Field values

In my opinion, the KB access is the most obviously problem; internal interfaces not using IP restrictions are especially problematic. In the quick testing I did, I could access the internal KB for some very large, visible organizations without ever having to create an account.

The ability to create an account itself is not a major problem, but this can be seen as a gateway to other protected items. This is additionally problematic for organizations that have a customized Create Account process. Depending on how the customization was created, a malicous user could side-step the process and associated safegards.

Additionally, this vulnerability will often gives a user the ability to manually set Contact Custom Field values. If your site uses Custom Field values to drive priviledged access or functionality, you could have a problem.

Not even Oracle is safe

If your site is exposed to this vulnerability, don't feel bad; Oracle's own cx.rightnow.com site has the same problem. Prior to the publishing of this article I let them know about this vulnerability, which after two weeks they still haven't fixed. I tried.

What are pagesets and how do they work

Pagesets are Oracle's attempt at supporting mobile devices. Inside of your pages folder you maintain another set of PHP view files specifically designed for mobile browsers. On most sites, this folder exists by default and contains a full set of mobile friendly pages as a starting point. You can check your site via WebDAV and look for a folder named "mobile" and/or "basic" inside of your "views/pages" directory. You likely didn't even notice they were there, not bother touching them.


By default, all sites contain a mobile and basic pageset directory

When you activate a pageset mapping during the CP deploy process, you create a "rule" that compares a regular expression to the visitor's User Agent value of their browser. If the regex matches, the visitor is shown a different set of pages than the standard pages in the "views/pages" directory. The most common use case is to search the User Agent string for "iPhone", "iPad", or "Android" and map these to a "mobile" set of pages.

As a side note, for mobile support I prefer to use responsive design instead of page sets... but that is a topic for a different time.

The alternative set of pages is contained in a directory in the "views/pages" folder and contains a file-for-file equivelent for every page in the "views/pages" directory. The "rule" effectively maps the visitor to this alternative directory; in most cases to "mobile". When CP renders the page, it first looks in the mapped pageset directory (i.e. mobile) for the page. If it is found, it is displayed. If it is not found, it then looks in the "views/pages" directory for the requested page. In this way there is a fallback for pages without a mobile-optimized equivelent.

For example, if I requested the /app/home page of mobile enabled site from my iPhone, the CP engine would:

  • Look for a file at "views/pages/mobile/home.php"
  • If not found, look for a file at "views/pages/home.php"

Pretty simple, right?

The (security) problem with pagesets

So where is there a problem? The key to this issue is that since pagesets are nothing more than normal CP pages contained in a subfolder in the "views/pages" directory, there is nothing preventing you from accessing them directly using the correct URL, regardless of the existence or non-existence of deployed page-set mapping rules. If the files exist, you can access them.

If you know anything about Customer Portal, the page path is very easy to guess. For my example above, I could view the mobile pageset's home.php file at this URL:

  • /app/mobile/home

The mobile pageset doesn't need to be active or deployed; I can hit this page regardless.

How can this be abused?

Many sites don't require mobile support (at least initially) so their developers don't touch the "mobile" or "basic" directories. They deploy their project/site using just the standard pages. They usually aren't aware that the OOTB pages provided by Oracle are fully functioning pages using a default "open" configuation. This means that:

  • KB pages aren't login protected
  • Account Create is available for anyone
  • The Create Account and Ask pages use the HORRIBLE "CustomAllInput" widgets

They also may think that those pages are only accessible if you deploy a page-set mapping; this is, as we've seen, not the case.

If a user were so inclined, they could visit the sites of various Oracle Service Cloud customers and check to see if the mobile "Account Create" page was accessible at the following URL: "/app/mobile/utils/create_account". They would then be able to create accounts and populate all custom field values as desired.

A user could also visit the "/app/mobile/answers/list" page to see if a protected knowledgebase was suddenly very accessible and public. In the quick tests I did, I found this to be the case with some very high profile customer's internal knowledgebases.

How can I protect my site

Fortunately, the fix options are very simple but they all require a code change.

Option 1: If you aren't using mobile pages, you can simply delete the "mobile" and "basic" directories. You'll need to do a CP deploy as well.

Option 2: If you aren't using any mobile pages, you can add the following code to the top of the "views/templates/mobile.php" and "views/templates/basic.php" files.

<?php header("Location: /app/error/error_id/4"); exit(); ?>

This code will redirect the visitor to the standard error page. Since all OOTB mobile and basic pageset pages use these two templates, you can effectively shut down access to these pages.

Option 3: If you are using some mobile pages:

  • A): Delete the pages you aren't using. This is safe because the framework will automatically use the standard version of the page.
  • B): Apply the PHP code from Option 2 to the mobile.php and basic.php template files. This would only work if the mobile pages you do want to use are assigned to a different custom template.

NOTE: In all cases, don't forget to also protect your clone sites. It is VERY easy to guess the clone URL patterns for most sites.

Conclusion

This is not a security bug, but a vulnerability in the standard OOTB pages that are present for every single site created since CP2. By simply doing nothing with mobile/basic pages, you are potentially exposed. The level of exposure will be different for every single site, so a certain level of triage is necessary to evaluate your specific scenario.

Even if your site doesn't have anything abusable exposed by this vulnerability, I'd suggest patching the problem now. I've only described a couple abuse scenarios in this article; there are likely more area's of abuse that I haven't thought of. Without hard numbers, I'd anticipate that most sites are subject by this problem. We've reached out to all of our (45 North Solutions) clients and have ensured that everyone is patched; take the time now to check your site to make sure you too are protected.

Comments

Once the fix has been completed, you may want to cleanup the following template and asset files from your CP codebase (they can always be referenced later in "cp/core"):

  • views/templates/basic.php
  • views/templates/mobile.php
  • assets/themes/basic/*
  • assets/themes/mobile/*
Zircon - This is a contributing Drupal Theme
Design by WeebPal.