Message-ID: <51C1EA5C.4050305@vsecurity.com>
Date: Wed, 19 Jun 2013 10:29:00 -0700
From: VSR Advisories <advisories@...curity.com>
To: full-disclosure@...ts.grok.org.uk
Subject: [CVE-2013-0523] IBM WebSphere Commerce: Encrypted
 URL Parameter Vulnerable to Padding Oracle Attacks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


                         VSR Security Advisory
                       http://www.vsecurity.com/

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

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 <tmorgan (a) vsecurity . com>
               George D. Gal <ggal (a) vsecurity . com>
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@...lory:/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@...lory:/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 |
"#\xa7\xe7\xca\r\xe2\xb4\x11\x03\xaa\xa1\x17\x03\x88\x95\x87\xaaV_\xfdlW\xc7\n\xff\x91'!\xce(\xec#"
0040: bdec5b2abd87a4eb d4ba01e542dc050d cf580f7e1c85ace2 9638f4665044fafc |
'\xbd\xec[*\xbd\x87\xa4\xeb\xd4\xba\x01\xe5B\xdc\x05\r\xcfX\x0f~\x1c\x85\xac\xe2\x968\xf4fPD\xfa\xfc'
0080: 8ffd3e653c9f7baa 9d5ac2b7061ce267 c0f07e8fe3401e8c 61de49ce22d09a50 |
'\x8f\xfd>e<\x9f{\xaa\x9dZ\xc2\xb7\x06\x1c\xe2g\xc0\xf0~\x8f\xe3@\x1e\x8ca\xdeI\xce"\xd0\x9aP'
00C0: 33ef2248e8fc1bd6 29d3dabe7ae222a9 bb937f6ccf9cca02 9ff9de3ce8307719 |
'3\xef"H\xe8\xfc\x1b\xd6)\xd3\xda\xbez\xe2"\xa9\xbb\x93\x7fl\xcf\x9c\xca\x02\x9f\xf9\xde<\xe80w\x19'
0100: b54703b1574b2bfa db7df1dab676f962 32009e486521e4d3 799a5313cda6c38c |
'\xb5G\x03\xb1WK+\xfa\xdb}\xf1\xda\xb6v\xf9b2\x00\x9eHe!\xe4\xd3y\x9aS\x13\xcd\xa6\xc3\x8c'
0140: fcfc3327af1fe378 92fd6101bfeb6ac2 3c1581e953042f93 ec17cf9e8e45ce16 |
"\xfc\xfc3'\xaf\x1f\xe3x\x92\xfda\x01\xbf\xebj\xc2<\x15\x81\xe9S\x04/\x93\xec\x17\xcf\x9e\x8eE\xce\x16"
0180: bc72e364e0a16138 36c66922cfd73570 7462cef7114d2880 661b58af66c9966d |
'\xbcr\xe3d\xe0\xa1a86\xc6i"\xcf\xd75ptb\xce\xf7\x11M(\x80f\x1bX\xaff\xc9\x96m'

0000: 23a7e7ca0de2b411 03aaa11703889587 c100fa99527dfb49 fe223b7de745868b |
'#\xa7\xe7\xca\r\xe2\xb4\x11\x03\xaa\xa1\x17\x03\x88\x95\x87\xc1\x00\xfa\x99R}\xfbI\xfe";}\xe7E\x86\x8b'
0040: 4ad9440ee91e46ae d714fd3060ae2924 cc99dce1a19b4490 490988503dd277d2 |
'J\xd9D\x0e\xe9\x1eF\xae\xd7\x14\xfd0`\xae)$\xcc\x99\xdc\xe1\xa1\x9bD\x90I\t\x88P=\xd2w\xd2'
0080: 3cb059b17b6e16a0 8bbb02a7b818dc06 0698a82ebb84fd59 914e1902270b5499 |
"<\xb0Y\xb1{n\x16\xa0\x8b\xbb\x02\xa7\xb8\x18\xdc\x06\x06\x98\xa8.\xbb\x84\xfdY\x91N\x19\x02'\x0bT\x99"
00C0: 67b05de6d7b8da1b 6a776cf0bc62b827 030b18f005a6f911 89527de364d98d8e |
"g\xb0]\xe6\xd7\xb8\xda\x1bjwl\xf0\xbcb\xb8'\x03\x0b\x18\xf0\x05\xa6\xf9\x11\x89R}\xe3d\xd9\x8d\x8e"
0100: e888e3283cb9fa9b 5d5f87ecc9e8421f e6b240e0e2c4b3fb c2c8e19801ff88b0 |
'\xe8\x88\xe3(<\xb9\xfa\x9b]_\x87\xec\xc9\xe8B\x1f\xe6\xb2@\xe0\xe2\xc4\xb3\xfb\xc2\xc8\xe1\x98\x01\xff\x88\xb0'
0140: ad65668b3a961466                                                    |
'\xadef\x8b:\x96\x14f'

0000: 090dade0037ad35d 2ccb6ffebbda9034 75fc429eb2449173 7b9a3a95ae64eea7 |
'\t\r\xad\xe0\x03z\xd3],\xcbo\xfe\xbb\xda\x904u\xfcB\x9e\xb2D\x91s{\x9a:\x95\xaed\xee\xa7'
0040: d48d72fe63c956bc 6c79f9d64a566c14 e0dff4db4b2b8523 75f8b6e8a948fba9 |
'\xd4\x8dr\xfec\xc9V\xbcly\xf9\xd6JVl\x14\xe0\xdf\xf4\xdbK+\x85#u\xf8\xb6\xe8\xa9H\xfb\xa9'
0080: 68340ecb221f5319 3b564dc59d259eb9 5773bfba8df50e95 29e83e234a5703da |
'h4\x0e\xcb"\x1fS\x19;VM\xc5\x9d%\x9e\xb9Ws\xbf\xba\x8d\xf5\x0e\x95)\xe8>#JW\x03\xda'
00C0: 8a0fe62b2537efa7                                                    |
'\x8a\x0f\xe6+%7\xef\xa7'

0000: 090dade0037ad35d 2ccb6ffebbda9034 75fc429eb2449173 7b9a3a95ae64eea7 |
'\t\r\xad\xe0\x03z\xd3],\xcbo\xfe\xbb\xda\x904u\xfcB\x9e\xb2D\x91s{\x9a:\x95\xaed\xee\xa7'
0040: 870f21ae5dbc0025 8bd797033bca8127 58b5e9ca1f8a3f6a 98a025bae863d3e1 |
"\x87\x0f!\xae]\xbc\x00%\x8b\xd7\x97\x03;\xca\x81'X\xb5\xe9\xca\x1f\x8a?j\x98\xa0%\xba\xe8c\xd3\xe1"
0080: 3d4e08b7a1602c0c caf2022363d0fe0a 15b7cd56176f5e20 d842d10c086e0e69 |
'=N\x08\xb7\xa1`,\x0c\xca\xf2\x02#c\xd0\xfe\n\x15\xb7\xcdV\x17o^
\xd8B\xd1\x0c\x08n\x0ei'


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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBUcHqSNaINF9fnpkCAQLJPhAAia0V1bRnJHK6Rj70RvxOKhfOD6TaXdx3
IJeDEV8+G9/Ee1/eVbNlHtBgVtQfJA887byV0u93s7jZfOfgFllxwR0xkAvpkADY
N5n2B33/f/JT1YOx2zbKAMxpkOAAFXz/TQzeeiuw5ZaV5Z54tMq0dYOlh2BWx1BI
Wsqp/Ijdd234PCtgUSvqJUmr29+m2BQbc2Q5MfVJblM+YEFmqaf0q9YFa2tieSaj
KYLmmd206OKqJLA69guRAp0hDJO4tQLEEd4I2NeVE20vYpq5TiHlX34hoF2ZOtwK
ljPdNsrhhNJvb5VIqu93JIcCdJQ3sVjbEz9Ge1WJVngwzSJvb6EBJUiEzKdnUs9/
IMh59znhfnovozo02h7YHWhlQlcgnrRyFahriyYwsZKbZT0uLziWGDEUFyqxqmjE
t4iN9r7T47vi0jEmXIvRFNFCJqG8ig+VtSrRJD7MBUM5AZJ/WvrnpK1p1jW+OsJr
BfsNtuIspCUZMQypdfL20wDxUwqqBvRWjKh0ivnFx9Z191A66q6DFlFYsb/hshzI
xC7tZK4uRnDtHsBm/YJuOblijDMWjB/89UyAtJQOjsmZmLHU/FKZdideM4ZpBePH
DUbL3J/BwkOLzm0S8NWulR4i6Frf9a87sBdiUJY72IbeRI16tGFAFVOqMcqOG2IZ
jZuSvm3VQbw=
=6uuB
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists