Bypassing Siebel Authentication

Note: This vulnerability was disclosed to Oracle initially in early September 2016 and followed up on subsequently. My last communication with Oracle regarding this matter was on November 30th, 2016. Here is the discussion (with sensitive information removed):

• Oracle: “We have identified an existing patch to fix the issue”
• Me: “Thank you for the update. Do you have the patch number/notes available for this?”
• Oracle: “It is not as simple as a patch number.”
• Me: “If that patch already exists, it should have a version number or security alert tied to it so the public can be aware and protect themselves from this vulnerability.”
• Oracle: “If they have any question about that existing patch, they can work with Oracle support team (yes, through SR contact according to standard process).”
• Me: “Thank you, per your instructions, I will inform anyone using Siebel to reach out to their SR contact to find out if they need to apply an unknown existing patch to ensure they are not vulnerable to a remote authentication bypass vulnerability.”

Oracle has not  yet responded to my final email (over 30 days). Therefore, I gave a little over 90 days from the initial disclosure for Oracle to make a patch publicly available or at least point me in the direction of the existing patch. As I have not seen any update on that, I am providing my research for public consumption.

Requirements: 

I’m not completely sure on this as the only version of Siebel I had to work with was version 15 (and I’m not exactly sure of the revision on this either). This was discovered during a web application review on a pentest and I was not privy to the full details of the application.

However, some additional research I’ve done on this issue has lead me to believe that this vulnerability was introduced by porting code over from a previous version of Siebel during a migration.

A vulnerability that affected older versions of Siebel was abuse of the ‘GetCachedFrame’ command as seen here: https://www.cnsgroup.co.uk/media-hub/blog/cns—networks-security/2011/05/27/cns-advisory-oracle-seibel-suite-unauthenticated-access

If the customer had been on a version of Siebel that was vulnerable to this advisory and migrated to Siebel 15, they may have brought this vulnerability along with it.

The Attack: 

The attack itself is pretty simple, and while it involves some manual review, this could easily be scripted or built into an tool.

• Step 1: Look for a login page that has ‘start.swe?’ in the URL. This file is associated with the Siebel WebServe Component. Our example login page will be https://siebelprod/start.swe?SWECmd=Start&SWEHo=siebelprod
• Step 2: View the source code for the page.
• Step 3: Look for the following script “/scripts/swecommon_top.js”
• Step 4: Look for the function “Function SWEPersonalizationGotoview (viewName, extraParams)
• Step 5: Under this function you’ll see the following redirect, copy this to the clipboard “?SWEEP=1&SWEVI=&SWECmd=GotoView&SWEC=1&SWEView=”
• Step 6: Go back to the original login page and paste this before ‘start.swe’, in our example this would be https://siebelprod/?SWEEP=1&SWEVI=&SWECmd=GotoView&SWEC=1&SWEView=start.swe?SWECmd=Start&SWEHo=siebelprod
• Step 7: If successful, you will be logged in as the account that is running the Siebel WebServe Component (most likely an administrative account). If you get an error that the view does not exist, that is expected as we do not know what views exist inside the environment. If you can, click around and see what you can get to. (Note: Sometimes this errors out completely on the first try, but works fine on the second try. It also reacts differently in different browsers, so try switching browsers if it is not working in your preferred browser.)

But that is basically it. If you want to save some time you can just copy and paste the code from step 5 into the appropriate URL for your target.

How to protect yourself:

As is always recommended, make sure you are up to date with the most recent patches. Since I don’t have the exact details of what patch would resolve this and I don’t have access to other versions of Siebel, I can’t verify which versions this affects.

A mitigating factor for this as well would be to not give database privileges to the account running the WebServe Component. Any time an account has privileges that it does not need, bad stuff can happen. Always enforce the principle of least privilege!

Also, never copy code from an old version of an application to a new version of an application in an effort to make it work. This can introduce bad code to an environment and open up holes that otherwise would not be there.

And per Oracle’s recommendations, if you are a customer, contact them! If you have an SR representative, make sure they reach out to Oracle and request any patches that may not be publicly available.

Finally, as a programmer/developer, make sure you follow OWASP’s guidelines for testing against authentication bypass vulnerabilities found here: https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_(OTG-AUTHN-004)

Disclaimer\Legal:

I have only tested this vulnerability against the customer that had signed the agreement for the pentest. Other sites may be vulnerable to this attack-method as well. If you decide to use this methodology to test against your environment/other vendors, make sure you have written and legal authority to do so.

Do not use this tool against accounts or environments that you do not own or have express/strict written consent to test against. Do not use for illegal purposes!