Skip to navigation Skip to main content Skip to footer

Technical Advisory – IBM WebSphere Commerce: Encrypted URL Parameter Vulnerable to Padding Oracle Attacks

19 June 2013

By Christian Powills

 Virtual Security Research, LLC.
                  http://www.vsecurity.com/
                     Security Advisory

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

Advisory Name: Encrypted URL Parameter Vulnerable to Padding Oracle Attacks
 Release Date: 2013-06-19
  Application: IBM WebSphere Commerce
     Versions: 5.6.X, 6.0.X, 7.0.X, possibly others
       Credit: Timothy D. Morgan 
               George D. Gal 
Vendor Status: Patch Available by Request [5]
CVE Candidate: CVE-2013-0523
    Reference: http://www.vsecurity.com/resources/advisory/20130619-1/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Product Description
~-----------------~
From [1]:

"E-commerce is no longer simply about selling online, it's about delivering a
 consistent shopping experience across all customer touchpoints, including
 mobile, social and in-store. WebSphere Commerce allows you to deliver a
 seamless, cross-channel shopping experience through contextually relevant
 content, marketing and promotions, while extending your brand across all
 digital and physical customer touchpoints." 


Vulnerability Overview
~--------------------~
In February 2013, VSR identified a vulnerability in the IBM WebSphere Commerce
framework which could allow an attacker to tamper with values stored in the
"krypto" URL parameter.  This parameter is encrypted with a block cipher without
any independent integrity protection.  This, combined with observed  application
behavior, allows for padding oracle attacks which can be used to decrypt the
krypto token and forge new tokens with arbitrary embedded parameters.

Additionally, in various deployment scenarios these tokens are commonly sent to
third-party sites such as IBM Coremetrics, but may also be indirectly leaked to
third-party e-commerce partners or content acceleration providers such as Akamai
Edgesuite, etc.  Sensitive data, including user passwords and personally
identifiable information could be compromised in this process.  In addition,
modification of token plaintext could allow for a variety of
application-specific attacks, including injections and/or authorization
bypasses.


Product Background
~----------------~
IBM WebSphere Commerce is an extensive e-commerce framework implemented as a
J2EE application.  The framework passes some state information related to user
sessions inside a "krypto" URL parameter.  This parameter is encrypted using
triple-DES in CBC mode.  The plaintext of this encrypted token contains a set 
of name-value pairs which are formatted as URL parameters.  The values stored 
in this token can be configured by developers and administrators, meaning 
this will likely vary from one deployment to another.  More information on 
this parameter can be found in [2].


Vulnerability Details
~-------------------~
During preliminary analysis of krypto token values, VSR first collected several
samples of tokens from different pages in a given application and then used the
Bletchley tool set [3] to analyze the tokens in a black box manner.  The
following is a partial transcript of using bletchley-analyze:

tmorgan@mallory:/tmp$ cat krypto-samples.txt 
I6fnyg3itBEDqqEXA4iVh6pWX%2F1sV8cK%2F5EnIc4o7CO97FsqvYek69S6AeVC3AUNz1gPfhyFrOKW%0AOPRmUET6%2FI%2F9PmU8n3uqnVrCtwYc4mfA8H6P40AejGHeSc4i0JpQM%2B8iSOj8G9Yp09q%2BeuIiqbuT%0Af2zPnMoCn%2FnePOgwdxm1RwOxV0sr%2Btt98dq2dvliMgCeSGUh5NN5mlMTzabDjPz8MyevH%2BN4kv1h%0AAb%2FrasI8FYHpUwQvk%2BwXz56ORc4WvHLjZOChYTg2xmkiz9c1cHRizvcRTSiAZhtYr2bJlm0%3D
I6fnyg3itBEDqqEXA4iVh8EA%2BplSfftJ%2FiI7fedFhotK2UQO6R5GrtcU%2FTBgrikkzJnc4aGbRJBJ%0ACYhQPdJ30jywWbF7bhagi7sCp7gY3AYGmKguu4T9WZFOGQInC1SZZ7Bd5te42htqd2zwvGK4JwML%0AGPAFpvkRiVJ942TZjY7oiOMoPLn6m11fh%2BzJ6EIf5rJA4OLEs%2FvCyOGYAf%2BIsK1lZos6lhRm
CQ2t4AN6010sy2%2F%2Bu9qQNHX8Qp6yRJFze5o6la5k7qfUjXL%2BY8lWvGx5%2BdZKVmwU4N%2F020srhSN1%0A%2BLboqUj7qWg0DssiH1MZO1ZNxZ0lnrlXc7%2B6jfUOlSnoPiNKVwPaig%2FmKyU376c%3D
CQ2t4AN6010sy2%2F%2Bu9qQNHX8Qp6yRJFze5o6la5k7qeHDyGuXbwAJYvXlwM7yoEnWLXpyh%2BKP2qY%0AoCW66GPT4T1OCLehYCwMyvICI2PQ%2FgoVt81WF29eINhC0QwIbg5p

tmorgan@mallory:/tmp$ bletchley-analyze krypto-samples.txt 
...
Beginning analysis after decoding by chain: percent/upper-plus,base64/rfc3548-newline
Unique Lengths: 96,104,168,224
Maximum Possible Block Size: 8
Matching Common Block Sizes: 8
Possible Encodings: 
Best Encoding: None
First 4 Values:
0000: 23a7e7ca0de2b411 03aaa11703889587 aa565ffd6c57c70a ff912721ce28ec23 | "#xa7xe7xcarxe2xb4x11x03xaaxa1x17x03x88x95x87xaaV_xfdlWxc7nxffx91'!xce(xec#"
0040: bdec5b2abd87a4eb d4ba01e542dc050d cf580f7e1c85ace2 9638f4665044fafc | 'xbdxec[*xbdx87xa4xebxd4xbax01xe5Bxdcx05rxcfXx0f~x1cx85xacxe2x968xf4fPDxfaxfc'
0080: 8ffd3e653c9f7baa 9d5ac2b7061ce267 c0f07e8fe3401e8c 61de49ce22d09a50 | 'x8fxfd>e#JWx03xda'
00C0: 8a0fe62b2537efa7                                                    | 'x8ax0fxe6+%7xefxa7'

0000: 090dade0037ad35d 2ccb6ffebbda9034 75fc429eb2449173 7b9a3a95ae64eea7 | 'trxadxe0x03zxd3],xcboxfexbbxdax904uxfcBx9exb2Dx91s{x9a:x95xaedxeexa7'
0040: 870f21ae5dbc0025 8bd797033bca8127 58b5e9ca1f8a3f6a 98a025bae863d3e1 | "x87x0f!xae]xbcx00%x8bxd7x97x03;xcax81'Xxb5xe9xcax1fx8a?jx98xa0%xbaxe8cxd3xe1"
0080: 3d4e08b7a1602c0c caf2022363d0fe0a 15b7cd56176f5e20 d842d10c086e0e69 | '=Nx08xb7xa1`,x0cxcaxf2x02#cxd0xfenx15xb7xcdVx17o^ xd8Bxd1x0cx08nx0ei'


These 4 samples have decoded lengths which are consistent with a 64-bit 
(8 byte) block cipher (such as DES, 3DES, or blowfish).  In addition, the 
first two samples share the first two blocks in common (but no others), 
while the third and fourth samples have the first four blocks in common.  
This pattern is a sign that the ciphertext may be encrypted using CBC mode 
with a static IV, which is a very common implementation mistake.  Use of
a static IV can allow for information leaks, and while it is typically not
a critical flaw in this context, it does provide an indication that CBC
mode encryption may be in use.

From there, IBM fix packs were obtained for WebSphere Commerce and the relevant
classes were decompiled.  Analysis of the decryption process revealed that the
received krypto token is first base64 decoded, then decrypted, and finally
decoded from UTF-8 (all prior to interpretation as a set of name-value pairs).
In most cases, if an error occurs during these first few steps, the decryption
routine returns a null value, which is interpreted by the application as if the
krypto parameter were never provided by the user.  However, if execution 
arrives at the UTF-8 decoding step and an error occurs in the interpretation 
of UTF-8 code points, the method uses System.exit() to end the process.  
In practice, this exit condition causes the server to return an HTTP response 
with a zero-length body.  This difference in behavior can be utilized to 
create a "padding oracle", which allows one to determine if a given 
ciphertext's padding (after decryption) is correct.  Given that the 
encryption mode is CBC, this makes the application vulnerable to padding 
oracle attacks which are discussed further in [4].  (Note that this is not 
the only way in which a padding oracle can be constructed based on 
application behavior, but merely the most reliable known method.)

A script was developed using Bletchley's POA class to validate that this flaw
exists in a real-world deployment. Encrypted tokens were successfully decrypted.
In some cases, sensitive information (including a user password) was observed
to exist in the recovered plaintext. 

Note that it would also be possible to craft malicious krypto token values that
specify nearly arbitrary plaintext name/value pairs after decryption.  The
implementation of this attack would be somewhat tricky, given the static nature
of the initialization vector, but the plaintext format of the krypto tokens is
fairly forgiving, which would allow an attacker to work around this limitation.



Versions Affected
~---------------~
VSR confirmed that WebSphere Commerce versions 5.6.X and 6.X are vulnerable.
IBM indicates the following specific versions are affected:

* WebSphere Commerce versions 7.0.0.0 to 7.0.0.7
* WebSphere Commerce versions 6.0.0.0 to 6.0.0.11
* WebSphere Commerce 5.6.1.0 to 5.6.1.5
* Earlier out of support versions may be affected


Vendor Response
~-------------~
The following timeline details IBM's response to the reported issue:

2013-02-14    IBM was provided a draft security advisory with recommendations
              for remediation.

2013-02-15    IBM acknowledged receipt of advisory.

2013-02-25    IBM acknowledged the vulnerability exists.

2013-03-20    IBM obtained a CVE identifier and estimated patch availability in
              mid-June. 

2013-06-04    VSR requested an update for the patch release.  IBM indicated it
              was still expected for mid-June.

2013-06-13    IBM indicated a fix would be released the following day and would
              notify VSR upon release.

2013-06-14    IBM released an advisory [5].

2013-06-15    IBM notified VSR that the advisory was made available.

2013-06-19    VSR advisory released



Technical Recommendations Provided to IBM
~---------------------------------------~
IBM should update the WebSphere Commerce implementation to add a message
authentication code (MAC) to the existing krypto token.  This MAC should be
applied to the full ciphertext of the parameter and verified before any
decryption is attempted.  In addition, the initialization vector (IV) of the
encrypted data should be randomized to prevent information leaks.  Ensure the IV
is included along with the ciphertext in the token and that the MAC is applied
to this value along with the ciphertext.  For instance, a safer implementation
might read (in pseudocode):

  iv = get_random_bytes(8)
  ciphertext = encrypt(cipher_key, iv, plaintext)
  integrity = mac(mac_key, iv + ciphertext)
  krypto = base64(iv + ciphertext + mac)

Once again, the mac should be verified prior to any decryption operation.



Recommendation for Users
~----------------------~
Apply the security update released by IBM as soon as possible.  The following
instructions are provided in [5]:

"For supported versions, open a Problem Management Record (PMR) with IBM
WebSphere Commerce Support to request an Interim Fix for APAR JR46386 and
include your WebSphere Commerce version including Fix Pack level. For out of
support versions, we recommend that you upgrade to a supported version."



Common Vulnerabilities and Exposures (CVE) Information
~----------------------------------------------------~
The Common Vulnerabilities and Exposures (CVE) project has assigned
the number CVE-2013-0523 to this issue.  This is a candidates for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


References:

1.  http://www.ibm.com/software/products/us/en/websphere-commerce

2.  http://pic.dhe.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.commerce.admin.doc%2Ftasks%2Ftdc_encryparam.htm

3.  http://code.google.com/p/bletchley/

4.  http://www.skullsecurity.org/blog/2013/padding-oracle-attacks-in-depth

5.  http://www-01.ibm.com/support/docview.wss?uid=swg21640597


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This advisory is distributed for educational purposes only with the sincere 
hope that it will help promote public safety.  This advisory comes with 
absolutely NO WARRANTY; not even the implied warranty of merchantability or 
fitness for a particular purpose.  Neither Virtual Security Research, LLC nor
the author accepts any liability for any direct, indirect, or consequential
loss or damage arising from use of, or reliance on, this information.

See the VSR disclosure policy for more information on our responsible 
disclosure practices:
  http://www.vsecurity.com/company/disclosure

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     Copyright 2013 Virtual Security Research, LLC.  All rights reserved.

To view the advisory as a txt. click here.

Editor’s note: This work was originally published by VSR on their website at https://www.vsecurity.com/resources/advisories.html. VSR is now a part of NCC Group, so we have migrated this content to research.nccgroup.com. The advisory text as above has been copy-pasted to this blog for historical reference.