Vendor Description
“Oracle Access Management provides innovative new services that complement traditional access management capabilities. It not only provides Web SSO with MFA, coarse grained authorization and session management but also provides standard SAML Federation and OAuth capabilities to enable secure access to external cloud and mobile applications. It can be easily integrated with the Oracle Identity Cloud Service to support hybrid access management capabilities that can help customers to seamlessly protect on-premise and cloud applications and workloads.”
URL: http://www.oracle.com/technetwork/middleware/id-mgmt/index-090417.html
Business Recommendation
SEC Consult did not conduct a full security audit as only a cryptographic implementation was analyzed. However, since the vulnerability was found in such a central component of the OAM, we suspect that an insufficient amount of attention has been given to information security.
Given the central position in an organization’s security infrastructure, we recommend Oracle’s customers to either conduct a full audit of the component or to request the results of such audits from Oracle.
The security patches from the Oracle CPU April 2018 have to be applied immediately!
Vulnerability Overview/ Description
Due to an improper usage of the CBC encryption mode, Oracle Access Manager (OAM) is vulnerable to an authentication bypass vulnerability. An attacker can abuse this vulnerability to log in to any resource protected by the OAM using any user account, even administrative accounts! This security vulnerability completely breaks the main functionality of the OAM product.
An attacker can create a scenario in which the OAM replies differently depending on whether the PKCS#7 padding of an encrypted message is valid or invalid. This behavior can be used to mount a padding oracle attack. An attacker can decrypt and encrypt several messages used to communicate between the OAM and web servers. The attack described here allows an attacker to create arbitrary authentication cookies which are accepted by the OAM.
Proof Of Concept
A successful user authentication with Oracle Access Manager (OAM) involves the following steps:
- The user accesses a protected resource.
- A component in the web server (the Oracle Webgate) answers this request with a redirect to the OAM. An encrypted message (“encquery”) is passed to the OAM in a URL parameter.
- The user authenticates against the OAM (e.g. with username and password).
- The OAM redirects the user back to the web server. Information about the successful login is passed in the parameter “encreply”.
- The web server redirects the user to the resource that was initially requested. An encrypted authentication token is stored in a cookie (OAMAuthnCookie).
- The authentication token in the OAMAuthnCookie cookie is used from now on to authenticate the user.
All three encrypted messages (encquery, encreply, OAMAuthnCookie) are encrypted with a CBC cipher using the same key. This key is shared between the OAM and the web server.
The attack exploits step 2 of the authentication process: the attacker sends manipulated “encquery” parameters and observes the server’s response.
The following shows an example of a decrypted encquery:
salt=sF/vMVV0Gkr/k+IhbrXYWg== wh=agentid wu=%2F wo=1 rh=http://server:7777 ru=%2F reqtime=1510000000 ctx=<some base64 data> validate=<base64 hash>
where
- the “salt” is a randomly generated value
- “validate” is a hash over certain parts of the message (MD5)
To conduct a padding oracle attack, an attacker would modify the second last encrypted block of an encrypted message. Most of the time, this causes the padding in the decrypted message to be invalid. In case the padding is accepted, the attacker gains information about the plain text.
Therefore, a vulnerable application would leak whether the padding is correct. However, the OAM responds to any simple modification of the cipher text with the same error message. This even happens if the plain text can successfully be decrypted but contains a message with valid syntax. This is due to the fact that the “validate” parameter (i.e. the MD5 hash) becomes invalid.
Another approach is to send a valid unmodified “encquery” and append the message to be checked for valid padding. The decryption would either fail due to invalid padding or (if the padding is correct) the OAM would receive a plain text like this:
... validate=<base64 hash><garbage>
If the OAM would ignore the garbage suffix, an attack would be possible, since the attacker could distinguish between correctly padded messages (no error message) and incorrectly padded messages (error message). This, however, is not the case since the garbage data is considered to be part of the “validate” parameter. The expected validate hash would therefore differ from the calculated hash.
If the garbage message would contain a space character at the first position, the parser would correctly recognize the end of the validate hash:
... validate=<base64 hash> <garbage>
In order to achieve this the following approach was chosen:
1. Induce the web server to encrypt a message the length of which is divisible by the block length. This can be achieved by influencing one of the plain text values that is encrypted (e.g. URL of the requested resource). The last block would contain only padding bytes:
|---------------|---------------| < valid msg ><padding bytes >
2. Brute-force the block after the valid message. When the server does not respond with an error message, a block was found where the first byte of the decryption is a space character. The last two blocks of the original message are appended to always create a valid padding:
|---------------|---------------|---------------|---------------| < valid msg >< brute force >< last 2 blocks of orig. msg >
3. The message found can then be used as a prefix for a padding oracle attack. The only case in which the server would respond with an error message is if the padding was invalid.
SEC Consult developed a simple Python script that allows an attacker to create an arbitrary OAMAuthnCookie for any user. For now this script will not be published.
Our blog post contains further information including a demo video showing the attack.
Vulnerable / Tested Versions
The versions 11g (11.1.2.3.0) and 12c (12.2.1.3.0) of Oracle Access Manager were found to be vulnerable. The authentication bypass scenario was only verified in version 12c.