Web

Posts related to web application vulnerabilities

OAMBuster – Multithreaded exploit for CVE-2018-2879

Oracle OAM is a widely used component that handles authentication for many web applications. Any request to a protected resource on the web application redirects to OAM, acting as middleware to perform user authentication.

Last year, a vulnerability was found in the login process which contains a serious cryptographic flaw. It can be exploited to:

  • Steal a session token
  • Create a session token for any user

Basically it allows to login to the website and impersonate any user. Bad stuff.

Technical Details

During login, Oracle OAM will send a value called encquery as part of the URL. This parameter contains some values like a salt and a timestamp, and is encrypted with AES-CBC. However:

  • There is no HMAC attached, to verify that the encrypted string wasn’t tampered with
  • The website responds with an error message when there is a padding error during decryption

This makes it vulnerable to a classic Padding Oracle Attack.

With AES-CBC, blocks of ciphertext are chained and dependent on each other. By adding blocks at the end and tampering with the second-to-last block, we can learn if the plain text is valid.

However, there is one extra challenge: We can not just add blocks of data to the end of the string because the decrypted value contains a validation hash at the end. When adding a block (that turns into gibberish when decrypted), the hash won’t be valid and we will not be able to use the oracle – it simply will always provide an error.

The fix to this problem is simple: we first have to search for the character that turns into a space (0x20) when decrypted. Now the hash will be untouched, and the gibberish we place behind it is interpreted as a new value.

For more in depth information, please read these excellent blog posts by SEC Consult:

Exploit

There have been exploits in the wild for some time, but they are single threaded. Because this attack requires to guess byte values one by one, it can take about 4 hours to complete (without rate limiting).

With RedTimmy, we have developed a multithreaded version of the exploit called OAMBuster. Source code is available on GitHub.

The first two stages of the attack, showing the verification of a target being vulnerable to CVE-2018-2879.

OAMBuster is able to perform the following actions:

  • Verify if the target is vulnerable to the attack (<30 seconds)
  • Decrypt the encquery string, using POA
  • Decrypt any given string, using POA
  • Encrypt any given string, using POA

The final two functions can be used for example to decrypt the OAMAuthnCookie containing the session token, and then re-encrypt it.

Benefits of the multithreaded implementation

Because OAMBuster has multiple threads running, it can decrypt multiple blocks at the same time. So for example, when there are 16 blocks in total, the tool can run 16 threads on the last byte of each block. When a thread is finished, it continues to work on the second-to-last byte of the block, and so forth, working from back to front. Bytes within a block can not be parallelized, as they are dependent on each other.

Links

https://github.com/redtimmy/OAMBuster

WordPress plugin vulnerabilities – four 0days

It’s a known fact that plugins are the weak spot in the security of WordPress. Even though the developer guide dedicates a full chapter on plugin security, it’s no guarantee that developers follow these guidelines. It’s not even guaranteed that plugin creators are professional developers. In fact, anybody can create a plugin and share it on wordpress.org/plugins.

How are these plugins verified? The developer FAQ indicates that a manual code review is done:

What happens after submission?What happens after submission?

You will get an automated email telling you about the submission immediately. At that point, someone will manually download and review your code. If we find no issues with the security, documentation, or presentation, your plugin will be approved. If we determine there are issues, you will receive a second email with details explaining what needs to be fixed.

However, consider this:

  • Currently there are 55,000 plugins available in the directory
  • Most plugins require an update after each update of the WordPress core (monthly)
  • WordPress is free software

How much time/budget do you think WordPress is able to allocate to review your custom Holiday Photo Slider plugin?

 

A little experiment

I wanted to find out how easy it would be to find vulnerabilities in WordPress plugins. So I downloaded around 30 random plugins (with a minimal active user count of >10.000) and start looking at the code.

  • I found 4 zero day vulnerabilities
    • 3x XSS
    • 1x CSV injection
  • The vulnerable plugins often had ugly badly written code
  • In one case, the rips-scanner was able to spot the vulnerability

As expected, the manual code review done by WordPress is insufficient. When even an automatic scan can find vulnerabilities, I’m wondering if they do any review at all.

Details and exploit code are available on exploit-db: