Abusing Oracles

Published: 2016-03-23
Last Updated: 2016-03-23 08:21:37 UTC
by Bojan Zdrnja (Version: 1)
4 comment(s)

No, no – this has nothing to do with Oracle Corporation! This diary is about abusing encryption and decryption Oracles. First a bit of a background story.

Most of the days I do web and mobile application penetration testing. While technical vulnerabilities, such as SQL Injection, XSS and similar are still commonly found, in last couple of years I would maybe dare to say that the Direct Object Reference (DOR) vulnerabilities have become prevalent.

With these vulnerabilities, it is typical that an attacker can directly manipulate parameters – by changing an ID submitted to the application, if no sufficient security controls have been implemented on the server side, the attacker can retrieve (or modify) arbitrary data.

Same parameters are key to exploiting other vulnerabilities: in case of SQL injection vulnerabilities, contents of parameters submitted by users are directly used in SQL queries, allowing an attacker to carefully modify the resulting SQL query and perform unexpected activities on the database.

We all know how these vulnerabilities should be mitigated: by implementing proper security controls on the server side.

In last couple of months, I actually encountered couple of interesting security mechanisms (or at least attempts to secure applications): the developers decided that they will encrypt contents of parameters.
This sounds like a cool idea – by encrypting contents of parameters we will (hopefully) prevent attackers from modifying them.

So, in other words, instead of a query such as this one:

http://my.web.application.local/process.aspx?ID=23531

the request will look like this:

http://my.web.application.local/process.aspx?ID=FBBFA70485E12DC2

In this second case, the application actually encrypted the ID (number 23531) and the user was able to see only the encrypted content.

Notice that such way of handling parameters also prevents SQL injection attacks – the attacker cannot (simply) add dangerous characters such as ' or " into the ID parameter since that will simply break encryption (the server side will fail to decrypt the contents, and automated vulnerability scanners won't really find anything here).

However, one thing that developers forget is that encryption != security. Those experienced among our readers will immediately notice that this does not prevent DOR attacks – if the key is static for the whole application we can simply copy another user’s ID parameter and exploit a DOR vulnerability – however, we still cannot (easily) brute force ID’s in this example.

Oracles to the rescue

So what are encryption or decryption Oracles? They are simply any interfaces that allow us to encrypt or decrypt arbitrary (or almost arbitrary) data, without knowing the secret key or maybe even the encryption algorithm that is used.
The most famous usage of such Oracles was in BEAST and POODLE attacks (where POODLE stands for Padding Oracle On Downgraded Legacy Encryption), where such an Oracle is abused to let us know if certain content has been successfully decrypted or not.

In this case I am referring to much simpler Oracles – those that will perform encryption or decryption activities on our behalf.
If we go back to the example above, let’s imagine that there is a different screen in the application that takes another encrypted parameter but for some reason prints it somewhere on the web page (maybe even hidden in HTML). If the key and the algorithm are the same an attacker can simply copy the encrypted string from any other request and see the plain text contents. And this is exactly what a decryption Oracle will do.

An encryption Oracle will, on the other side, allow encryption of arbitrary content. This can be even more dangerous – in the example above, the attacker encrypt the content 23531’ OR ‘1’=’1 and try to exploit a SQL injection vulnerability.

This can be particularly devastating for couple of reasons:

  1. In most cases where I’ve seen such encryption being used to “protect” contents of parameters the developers did not pay a lot of attention on the real security thinking that no one can tamper the parameters (after all, they are encrypted). This means that proper filtering is probably missing.
  2. Such encryption will even prevent some network based IPS/WAF products to work – they will not be able to inspect parameters and will be effectively blind in front of such attacks.

A question you may ask now is how are such Oracles possible? Well, while normally the developer can control what is printed (encrypted/decrypted) where, in larger applications it is easy to make a mistake and inadvertently create such an Oracle, and an attacker only need one such vulnerability.

Lessons learned

Correct usage of cryptographic protocols is not a trivial thing and should be carefully assessed and designed before implementation in any application.

In the example above, even if the application uses a strong key, due to existence of both encryption and decryption Oracle, an attacker does not need to crack the key at all since he can freely perform both encryption and decryption of arbitrary content.

While encryption can provide confidentiality and integrity, if used properly, it is by no means a security control. Any application must not rely on encryption for security controls. Additionally, every security control must be carefully implemented, on any parameter received from the client.

--
Bojan
@bojanz
INFIGO IS

4 comment(s)

Comments

Hi Bojan,

Great article! But I missed something: how exactly would you go about encrypting the content "23531' OR '1'='1"?


Thanks,
Joris
Hi Joris,

[quote=comment#36757]Hi Bojan,

Great article! But I missed something: how exactly would you go about encrypting the content "23531' OR '1'='1"?


Thanks,
Joris[/quote]


Thanks, glad you liked it!

In order to encrypt this I had to find an encrypting Oracle that somehow leaked encrypted content.
So let's say that there is an interface that takes ID=12345 and somewhere in the HTML returned prints the encrypted string (i.e. FA3C459BDE4511DA).
Then we modify the ID parameter to contain 23531' OR '1'='1 and use the same page - the HTML returned will give the encrypted string to us.
In this case we can use the encrypted string on another screen since the application will happily decrypt it (and probably circumvent security controls since developers typically think that noone can modify the encrypted string).

It might seem that finding such an encryption Oracle is difficult, however in couple of penetration tests where I encountered applications that encrypted parameters it turned out that sooner or later such an Oracle pops up.

Cheers,

Bojan
The next question I would have.... now, having found a nice Oracle...

Let's say the algorithm is 3DES-CBC, and you don't know the key, but the Oracle allows you to act as if you
have it, by feeding an arbitrary input to the cipher --- even an Empty input.

Is there a way to ask the Oracle a carefully chosen sequence of a number of different questions to eventually discover the original encryption key,
so you can encrypt and decrypt more things on your own later, without needing the Oracle anymore?
[quote=comment#36783]The next question I would have.... now, having found a nice Oracle...

Let's say the algorithm is 3DES-CBC, and you don't know the key, but the Oracle allows you to act as if you
have it, by feeding an arbitrary input to the cipher --- even an Empty input.

Is there a way to ask the Oracle a carefully chosen sequence of a number of different questions to eventually discover the original encryption key,
so you can encrypt and decrypt more things on your own later, without needing the Oracle anymore?[/quote]

Sorry for the delay - didn't notice this post.

So, what you're talking about is a chosen-plaintext attack. A good crypto algorithm, such as 3DES-CBC should be resistant against such attacks so the only way to launch it would be by choosing some plain text, encrypting it and then launching a brute force attack against what you have - if the key is weak, you could in theory break it.

Bojan

Diary Archives