Last Updated: 2016-03-23 14:59:50 UTC
by Johannes Ullrich (Version: 1)
It got a catchy name, it got a logo... so it must be serious. Or at least that is what is implied with the "Badlock" vulnerability that was pre-announced this week.
At this point, there is only a vague pre-announcement. The details, and a patch, will be released on April 12th, Microsoft's next patch Tuesday. S
The vulnerability will affect systems running SAMBA (an open source implementation of the SMB protocol, commonly found on Unix systems) as well as Windows systems . The second group is probably easier to identify, and given that we should have a patch from Microsoft on April 12th, your normal patch procedures should have you covered.
The Unix part can be a bit more tricky. To get ready for April 12th, it may be worth-while to scan your environment for systems with SMB enabled. This will get you a head start once the patch is released. Due to the high-profile pre-announcement, I expect major Unix versions to release a patch on April 12th as well.
OS X started using its own implementation of the SMB protocol, sometimes referred to asm SMBX, With OS X 10.7 (Lion). You are probably not going to find a lot of pre-10.7 systems still around, and if you do, you probably wont get a patch from Apple. SMBX is not listed in the Badlock pre-announcement. We can assume at this point that it is not vulnerable.
A possible twist to this would be vulnerable clients. It is possible to trick a client to connect to an SMB share using the "smb:" protocol. Outbound traffic from clients is often less strictly controlled then inbound.
Short summary: What should you do before April 12th
- inventory SMB servers
- verify firewall rules to block SMB inbound AND outbound
- order some donuts/pizza for the patch team for April 12th. It could be a busy day.
Side note: Stefan Metzmacher, who is credited with discovering the vulnerability, is the author of the file "lock.c" in Samba. This file appears to deal with SMB2 lock requests. It is pretty short, but includes an "interesting" comment: "/* this is quite bizarre - the spec says we must lie about the length! */".
Last Updated: 2016-03-23 08:21:37 UTC
by Bojan Zdrnja (Version: 1)
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:
the request will look like this:
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:
- 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.
- 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.
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.