The SEC Consult team discovered an interesting encryption format on Oracle Access Manager (OAM), and in this article, we demonstrate how small feature changes to this encryption can have an impact on the security of the actual product. Ultimately, this security impact vulnerability can be exploited to construct arbitrary authentication tokens to impersonate arbitrary users to achieve malicious compromise of OAM functionality.

Oracle Access Manager (OAM) is a key component of Oracle's Oracle Fusion Middleware family of middleware that addresses authentication for a variety of Web application environments, such as Oracle WebGate, its built-in access authentication component in Web server applications. When a user initiates an access request to a restricted resource on the server, the request is forwarded to the authentication endpoint of the OAM. The OAM endpoint then verifies the user's identity and, once the verification is complete, forwards the request to the appropriate web application on the server. Since all authentication is implemented by a core application of OAM, users only need OAM authentication once to access all restricted resources of OAM at will (in case of single sign-on).

In a research analysis, we found that the encryption format of OAM is severely vulnerable, and that by exploiting this vulnerability we can construct a session token that bypasses WebGate, impersonate a legitimate user and access arbitrary restricted resources. In addition, we can implement user cookie forgery to impersonate any legitimate user of OAM.

Oracle products involved in the vulnerability

Both supported versions 11g and 12c, which are currently in common use in the market, are affected by this vulnerability. In this article, we only tested version 12c. A simple Google search reveals that a large number of well-known companies have OAM products deployed on their websites, including Oracle itself, and that's just a fraction of what's exposed on the Internet.

After we notified Oracle of the vulnerability in late 2017, a patch for the vulnerability was only released in late April of this year. We would like to ask OAM users to update their patches to close the vulnerabilities. It is also recommended that OAM administrators analyze historical log records to identify preemptive attack clues. An attack exploiting this vulnerability results in a large number of decryption failure logs due to a padding attempt (javax.crypto.BadPaddingException). Affected users are advised to keep up to date with the critical patches released by Oracle in April, and for detailed remediation recommendations, please see our remediation guide here.

Vulnerability Technical Analysis

The following technical analysis requires some foundation in encryption and decryption and Padding Oracle technology, and you can go directly to the bottom of the article to watch the demo video. In technical terms, during the OAM authentication phase, the following series of processes occur.

Users initiate access requests to restricted resources

The OAM Webgate component in the web server validates the request and forwards it to the OAM, which then generates an encrypted message passed in the URL parameters ("encquery")

The user then authenticates at the OAM based on the username password

With a successful login message "encreply", OAM redirects the user to the web server

The web server redirects the user to the initially requested restricted resource and generates an encrypted authentication token in a cookie ("OAMAuthnCookie")

The user becomes legitimate with the token in this cookie and has subsequent arbitrary authentication privileges via

To prevent tampering, the values of the encrypted messages "encquery", "encreply" and OAMAuthnCookie are protected by encryption, so that when OAM or WebGate receives these values, even if they come from a user, they are ensured that they have not been tampered with. OAM uses a single encryption format to encrypt all of these messages, and OAM and WebGate share the keys for this encryption method.

encryption format

Combined with the previous analysis, it is clear that the cause of the vulnerability lies in the way the encryption format is implemented; the algorithm that creates the encrypted message uses a shared key when processing key-value pairs and generates a base64-encoded output string, which is intended to provide integrity and security. The following is its working mechanism.

Input form.

where salt is a randomly generated value and the validity parameter validate a fixed set of MD5 hashes; after that, the string is encrypted using a grouped password.

Vulnerability Analysis

When analyzing this encryption format, the first thing that comes to mind is that the encryption algorithms used in it (i.e., hashing and CBC grouping ciphers) are used for authenticity purposes. It can be assumed that since the shared key is not known, the attack is also not possible.

Those with a cryptographic base may notice that the CBC encryption mode can be vulnerable, e.g. it can be corrupted using Padding padding. A classic padding oracle attack requires encrypted input and character padding in the form of padding oracle. Padding oracle will expose whether the encrypted string provided has valid padding when decrypted.

Simply put, packet encryption requires padding in order to encrypt a message of arbitrary length. Also, packet encryption can only handle fixed size messages (e.g. 16 bytes). If we want to encrypt a message that is say 25 bytes long, we will encrypt the first 16 bytes and leave 9 bytes. Since packet encryption cannot handle 9 bytes of input, we need to append 7 padding bytes. A typical way to implement this is to add padding bytes, where each byte contains the number of padding bytes (as defined in PKCS#7 padding). For example if the length added in this case is 7 bytes, each byte will have a value of 7 or 0x7. When exactly no fill is needed, the complete fill block is appended, at which point the fill block is 16 bytes and each byte contains the value 16.

Padding oracle attack attacks are not the focus of this paper here, we just need to find a way to determine if the encrypted string has proper padding when decrypted.

To determine whether a Padding oracle attack is feasible, we need to observe the different reactions of the system to padding elimination, such as to messages that cannot correctly eliminate padding, and messages that can correctly eliminate padding but subsequently fail inspection (e.g., when the elimination padding text cannot be correctly parsed). When we try both test cases with the encquery parameter we mentioned before, OAM responds with a 'system error' both times, so we can't clearly distinguish between the two cases. When this is the case, the OAM displays a 'system error', so one way to distinguish between correctly populated messages and incorrectly populated messages is to make all the correctly populated messages we use in the attack look perfectly legitimate. Obviously, when the OAM encounters a valid message, it will not report an error, and conversely, we will see an error message if the system fails to eliminate the fill.

Constructing Padding Oracle Attacks

It turns out that OAM ignores any garbage characters attached to the decrypted message, such as some spaces, and we can try to create a valid message with a space character at the end. We then add the blocks that go into testing the validity of the padding.

A decrypted message with valid padding is shown below.

Here, the OAM will first check for padding and then parse the valid message, ignoring the rest of the message.

The decrypted message with invalid padding is shown below:

OAM will check the fill validity and throw a system error.

Space: The Final Frontier has everything to do with the spacebar.

So, how do you use brute force to determine that a valid message is followed by a space character?

First, we want to create a valid message whose length is divisible by the grouping length unit, where it is necessary to find a way to affect the plaintext in such a way that the ciphertext it generates satisfies that criterion. It turns out that the encrypted request encquery contains the initial protected URL link requested by the user, and we are able to capture such encquery values under URLs of different lengths.

http://example.com/protected/?

http://example.com/protected/?a

http://example.com/protected/?aa

http://example.com/protected/?aaa

Once the length of the encquery has been increased by 16 bytes, we know that the length of the encrypted message is divisible by 16 and that the last packet block consists of padding bytes.

This way, we can discard the last grouping block and continue with the encrypted string that does not contain padding, and then, we make sure that the following grouping block contains the space character in the first position.

We can create a valid encrypted message that does not contain padding, but the grouping blocks we choose and the last two blocks of the original message keep the padding valid. Without intentionally affecting the decrypted result text, we can arbitrarily select the grouped blocks in the encrypted message. However, we can continue to try random encryption blocks until the plaintext block meets our needs.

If a decrypted valid message is not followed by a space character, the message is invalid and a "System Error" is displayed. We will continue to construct messages using random grouping blocks until they are finally accepted by the OAM. We then find that the decrypted packet block we chose incidentally contains a space character in the first byte: the

After this step, the attack becomes simple: we simply use the message we constructed as the prefix of the grouping block to be tested for valid padding. If the fill is incorrect, the system eliminate fill step will fail, resulting in a system error message. If the padding is correct, the OAM will receive the padding message correctly, start parsing the valid message, and the system will not report an error

combo attack

Padding oracle allows us to decrypt arbitrary messages, and since all encrypted messages ( encquery, enceply, oamauthnokoie ) are encrypted using the same key, we can decrypt any of these messages.

What few people here know is that the Padding Oracle attack can also be used to encrypt messages, so if we construct a valid authentication cookie and encrypt it with our Padding Oracle attack, we can pass it to the web server as a legitimate message. In fact, the attack is created unconsciously, because the validate value in the encrypted string is a simple hash, not generated by the HMAC algorithm, so we can simply compute a crack on it without any key. An attack exploit script for this vulnerability has been developed, but is not being released publicly for security reasons.

DEMO

We demonstrate the exploitation of this vulnerability, where an attacker can impersonate any user, including admin, in restricted resources and applications.

Recommended>>
1、Linux Raising Program I
2、A New Approach to Precision Testing Mining Code Risk Based on Criminal Psychology
3、How does JS implement multithreading
4、Linux Raising Program II
5、Floyds algorithm

已发送

发送中