IBM WebSphere Commerce: Encrypted URL Parameter Vulnerable to Padding Oracle Attacks
|Application||IBM WebSphere Commerce|
|Discovered by||Timothy D. Morgan <tmorgan (at) vsecurity.com>
George D. Gal <ggal (at) vsecurity.com>
|Vendor Status||Patch Available by Request|
From : "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."
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.
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 .
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  to analyze the tokens in a black box manner. The
following is a partial transcript of using
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 . (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.
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 188.8.131.52 to 184.108.40.206
- WebSphere Commerce versions 220.127.116.11 to 18.104.22.168
- WebSphere Commerce 22.214.171.124 to 126.96.36.199
- Earlier out of support versions may be affected
The following timeline details IBM's response to the reported issue:
|IBM was provided a draft security advisory with recommendations for remediation.|
|IBM acknowledged receipt of advisory.|
|IBM acknowledged the vulnerability exists.|
|IBM obtained a CVE identifier and estimated patch availability in mid-June.|
|VSR requested an update for the patch release. IBM indicated it was still expected for mid-June.|
|IBM indicated a fix would be released the following day and would notify VSR upon release.|
|IBM released an advisory .|
|IBM notified VSR that the advisory was made available.|
|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.
Recommendations for Users
Apply the security update released by IBM as soon as possible. The following instructions are provided in :
"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 candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems.
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.