Oracle Access Manager versions 11.1.2.3.0 and 12.2.1.3.0 suffer from an authentication bypass vulnerability.
b2d1fa8ff54174534c11d0df06d323ddWe have published an accompanying blog post to this technical advisory with
further information:
Blog:
https://www.sec-consult.com/en/blog/2018/05/oracle-access-managers-identity-crisis/
Demo video: https://www.youtube.com/watch?v=YK7_1NozAwQ
SEC Consult Vulnerability Lab Security Advisory < 20180503-0 >
=======================================================================
title: Authentication Bypass
product: Oracle Access Manager
vulnerable version: 11.1.2.3.0, 12.2.1.3.0
fixed version: April 2018 CPU
CVE number: CVE-2018-2879
impact: Critical
homepage: https://www.oracle.com/
found: 2017-11
by: W. Ettlinger (Office Vienna)
SEC Consult Vulnerability Lab
An integrated part of SEC Consult
Europe | Asia | North America
https://www.sec-consult.com
=======================================================================
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:
1. The user accesses a protected resource.
2. 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.
3. The user authenticates against the OAM (e.g. with username and password).
4. The OAM redirects the user back to the web server. Information about the
successful login is passed in the parameter "encreply".
5. The web server redirects the user to the resource that was initially
requested. An encrypted authentication token is stored in a cookie
(OAMAuthnCookie).
6. 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.
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.
Vendor contact timeline:
------------------------
2017-11-20: Sending encrypted advisory to [email protected];
communicating preliminary advisory release date 2018-01-09
2017-11-20: Initial response: Issue will be investigated
2017-12-14: Oracle: Patch will not be released in January CPU due to the
backporting, regression and integration testing process required;
asked for postponed release date
2017-12-15: Postponing release date to the April CPU
2017-12-24: Monthly status update from Oracle:
Under investigation / Being fixed in main codeline
2018-01-25: Monthly status update from Oracle:
Issue fixed in main codeline, scheduled for a future CPU
2018-02-22: Asking whether the release date can be held
2018-02-22: Oracle confirms April CPU date
2018-02-23: Monthly status update from Oracle:
Issue fixed in main codeline, scheduled for a future CPU
2018-03-12: Informing Oracle of second identified attack scenario (affecting
versions 11g and 12c); asking whether patch addresses this issue too
2018-03-13: Oracle: the patch addresses both issues
2018-03-23: Monthly status update from Oracle:
Issue fixed in main codeline, scheduled for a future CPU
2018-04-17: Oracle releases April 2018 CPU including the patch
2018-05-03: Release of the security advisory.
Solution:
---------
Apply the patch provided through the Oracle April 2018 Critical Patch Update:
http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
Moreover, the configuration of the affected services must be adapted as well.
More information can be found in the My Oracle Support Note 1967316.1.
Workaround:
-----------
None
Advisory URL:
-------------
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab
SEC Consult
Europe | Asia | North America
About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It
ensures the continued knowledge gain of SEC Consult in the field of network
and application security to stay ahead of the attacker. The SEC Consult
Vulnerability Lab supports high-quality penetration testing and the evaluation
of new offensive and defensive technologies for our customers. Hence our
customers obtain the most current information about vulnerabilities and valid
recommendation about the risk profile of new technologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your application https://www.sec-consult.com/en/career/index.html
Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https://www.sec-consult.com/en/contact/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: https://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult
EOF W. Ettlinger / @2018