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. 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. In this case I am referring to much simpler Oracles – those that will perform encryption or decryption activities on our behalf. 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:
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. I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Pen Test Hackfest Europe 2022 - Berlin |
Bojan 403 Posts ISC Handler Mar 23rd 2016 |
Thread locked Subscribe |
Mar 23rd 2016 6 years ago |
Hi Bojan,
Great article! But I missed something: how exactly would you go about encrypting the content "23531' OR '1'='1"? Thanks, Joris |
j00ris 1 Posts |
Quote |
Mar 24th 2016 6 years ago |
Hi Joris,
Quoting j00ris:Hi Bojan, 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 |
Bojan 403 Posts ISC Handler |
Quote |
Mar 24th 2016 6 years ago |
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? |
Mysid 146 Posts |
Quote |
Mar 28th 2016 6 years ago |
Quoting Mysid:The next question I would have.... now, having found a nice Oracle... 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 |
Bojan 403 Posts ISC Handler |
Quote |
Apr 2nd 2016 6 years ago |
Sign Up for Free or Log In to start participating in the conversation!