Oracle iStore security vulnerability

Some time ago I published a paper on my website about a bug in Oracle Store. Now I like to repost it on my weblog also. The bug is a combination of bad coding from the side of Oracle and not applied security settings. When the bug is exploited a user is able to view all the orders ever placed in an oracle iStore installation.

For those who are not aquatinted with Oracle iStore, iStore is the Oracle webshop application.


Preface:
Current versions of Oracle iStore have a known bug, which enables users to view orders in order tracker placed by other customers. The root cause is bad coding from Oracle. When a order is queried from the Oracle iStore order tracker the only reference key is the order number.


Reproducing the problem:
Login to Oracle iStore and go to the order tracker page [/ibeCOtdOrdSumMain.jsp?a=b]. This page will give you an overview containing all the orders placed by this customer. When selecting one of the orders the number parameters will change and [ibeCOtdOrdSumMain.jsp] will contain the following parameters and possibly the following values depending on your implementation: ?qsr=0&qob=5&qia=false&qc0=13&qo0=AIS&qv0=4077&qa=details&qid=

If qid contains a long string of alphanumeric characters you have encryption enabled however if it contains a numeric string your iStore implementation is vulnerable of URL manipulation.

If qid contains a numeric string you can shift between orders by changing the number. This will enable the user to view ALL orders available in IBE_ORDER_HEADER_V.


Root cause:
When a order detail page is queried iStore is executing the following query where the value of qid relates to the column HEADER_ID in IBE_ORDER_HEADER_V. This is the only binding value between the record and the user request. There is no validation done to determine if the order is placed by the same customer as the one requesting the details of the order.


Quick fix:
Preventing the user from manipulating the URL is to enable encryption to encrypt the parameter values used in the URL. This is a standard functionality. To enable the encryption take the following steps:

(1) Login to Oracle e-business suite using the sysadmin account.
(2) Go to Setings - System - Cookies.
(3) Make sure there is a value entered in the [Encryption Key] field. If not enter a random encryption key.
(4) Reboot and check if the URL parameters are encrypted. Please note NOT ALL parameters will be encrypted.

NOTE:
It is possible that you have done some customizations to Oracle iStore which will cause errors after enabling encryption. The reason for this is that you probably do not a decrypt function for some of the parameters which are now encrypted. This results in iStore trying to use the encrypted strings as a value instead of using the real decrypted value. (Example: instead of using the values 5 it is now using the value G57FHSYEGE3H2J83GA8E3K3H37)

If this is the case you will have to add decryption and encryption routines into your code to make it work with the new encryption. The best way to do this is to catch this in a if statement which enables you to create code that will encrypt and decrypt only if the encryption option is turned on. This will prevent you from having to change code again if you ever have to turn encryption off again.

Please find an example of this below:
//If encryption is active encrypt URL parameter.
String retrieveKey = SiteProperty.getValue("cookie_encryption_key");
IBEUtil.log("ibeCOtdOrdSumMain.jsp","retrieve Key = "+retrieveKey);
if (retrieveKey != null)
{
pageContext.setAttribute("retrieveKey",retrieveKey,PageContext.REQUEST_SCOPE);
}
String key = (String)pageContext.getAttribute("retrieveKey",PageContext.REQUEST_SCOPE);
String xxEncOrder_number = cartIdStr;
if (key != null && cartIdStr != null )
{
AolSecurity security = new AolSecurity();
xxEncOrder_number = security.encrypt(key, cartIdStr,cartIdStr.length());
}

Stable fix:
To fix this in a stable way you will have to change a little more. The enabling of the encryption is a good thing, and advertised and promoted by Oracle in their implementation guide. However a better fix is to change the query and the way the query is called. The best way is to add a check on customer ID to make sure that the customer requesting the details of the order is the same customer who placed the order.