nCircle VERT Blog: June 2010 Archives

The "full disclosure" vs "responsible disclosure" debate has been going on for years, and I doubt it will ever end but recently we seem to have hit a point of critical mass. First we had the "no more free bugs" movement and more recently we have had a series of 0-day vulns dropped under the guise of "full disclosure". I say that it's under the guise of full disclosure because it's not full disclosure. FD is about making companies that refuse to acknowledge vulnerabilities stand up and deal with them... it's not about tooting your own horn and saying "hey look at me". I'd like to think that my arguments in favour of FD in the past give me some ground to stand on as I begin this little diatribe.

Things that are happening lately, and by things, I mean Tavis dropping the Help and Support Center 0-day 5 days after notifying Microsoft, do not qualify as FD. It's being called FD but it's not. Full Disclosure is not the absence of Responsible Disclosure, it is, in the end, an extension of it, designed to call out companies that are not responsive to RD.

Dropping this 0-day was a stupid thing to do... there's no room for additional discussion to be had; it's a plain and simple point. If Microsoft had not acknowledged it after a month, or refused to fix it, then sure... use FD as it is intended... but that's not what happened. My comment is the office after the 0-day was dropped was that my next blog post should be entitled "Tavis is the new Gobbles".

I've been, on occasion, a fairly harsh critic of Microsoft, but in this situation I imagine I was doing the same thing that they were doing. If I were in a cartoon, I'd have had a thought bubble that simply read, "WTF?" but I suppose that people will do what they want to do.

I had intended to leave this topic alone but Brad Spengler posted to DailyDave yesterday and inspired me to write this post. In his post he decided to take the FD another step backwards and present Tavis with kudos for waiting only 5 days. He also called out a number of individuals for speaking against the claimed "FD". This list included Robert Hansen and Andrew Storms, two people I respect and consider to be good friends.

Robert's post on the subject was one of the first I read, and I found myself agreeing with it. I tend to run things by my employer before I discuss them if I expect controversy, whether I'm writing about them here or on my personal blog. We then look at the best way to approach something and handle it in a responsible manner.

As for Andrew, Brad chose to simply insult him and his intelligence. I've worked with Andrew for four years and we don't always see eye to eye (he's responsible for protecting our network and I want to break it :) ) but we're always chatting about things that are happening in the industry and our thoughts on them. On Patch Tuesday, if Andrew points to a patch as being an important one to apply, you can be damn sure that, from the enterprise point of view, it's the first one you want to apply. He's not pointing to specific vulnerabilities and talking about their inner workings, he's speaking as an experienced Director of Security Operations with regard to enterprise networks. It is unfortunate that Brad decided to ignore this and simply made a personal attack.

In the end I think that both Tavis and Brad brought us back a step. The actions that Tavis took indicate that he feels that Full Disclosure and Responsible Disclosure are completely disjoint from each other, while Brad resorted to personal attacks as a defense mechanism.

In the end, until the security community can accept that Full Disclosure exists within Responsible Disclosure we're going to have continuous FD debates. Personally, I'm getting tired of reading them and wish people would acknowledge that tagging something with "Full Disclosure" doesn't absolve them of all responsibility.

On Friday, Chris posted an excellent technical write-up on the TLS Session Renegotiation vulnerability. As he mentioned, nCircle has recently experienced an influx of questions from customers regarding the vulnerability, specifically with regard to PCI.

The most important thing to understand is that the existence of this vulnerability will result in PCI non-compliance from an ASV's point of view. The reason for this is fairly self-explanatory: the CVE (CVE-2009-3555) has a CVSS score of 6.4 and anything over a 4.0 is a fail in PCI-land.

When this vulnerability was first announced I was one of the first to say that it wasn't a "sky is falling" situation (like Conficker was) and I still believe that I was correct. That doesn't mean that I feel this vulnerability is insignificant and from a PCI standpoint, I think it addresses one of the key security aspects that merchants need to focus on; TLS, aka securing communication between the customer and the merchant website.

Q: What is the primary goal of PCI?
A: If you said, "The protection of cardholder data", then you're theoretically correct.

The primary means of protecting that data when it is entered into a website is that little technology that we call TLS. Many years have been spent trying to teach users to check for that yellow lock (and now the green bar) and to get them to trust it. It's not enough that merchants undermine these teaching attempts to save a buck or due to incompetence, now we have a flaw that undermines the protocol itself.

So how do we protect users at this point? We turn off legacy TLS Session Renegotiation and remove the flaw from the protocol implementation. The IETF is working on the latter and it's up to ASVs everywhere to ensure the former while we wait. So if you're dealing with nCircle, or any competent ASV and have this vulnerability, expect us to document it and report you as non-compliant until you resolve it.

There has recently been a couple questions from our customers regarding in-depth technical details of how nCircle detects if TLS Legacy Session Renegotiation is enabled on a server, and so it was suggested to me that I write a blog post about it. Since I've been meaning to set aside some time to write my first blog post since transitioning from being a Software Engineer here at nCircle to a Security Research Engineer on VERT, I figured this would be a great excuse to do just that.

First, I figure some background information would be appropriate. Session Renegotiation was defined by the IETF in RFC 2246 for the TLS protocol. This standard specified that either the client or server can initiate a renegotiation request during an established TLS session. Renegotiation allows new cryptographic parameters to be established for that session, meaning new keys can be used and new cipher suites can be chosen. Why is this bad? Because the server doesn't keep track, nor does it care, about which TLS session a renegotiation is being performed over. This opens up the door for a man-in-the-middle to hijack TLS sessions, meaning the attacker can potentially view confidential information such as credentials or credit card information being transmitted over the session, a big no-no for PCI. Though he cannot simply read the communications in plaintext, since the communication between the victim client and server will be encrypted after the renegotiation has taken place; by exploiting this feature of TLS, a man-in-the-middle may be able to modify the requests themselves in order to obtain confidential information. This vulnerability can defeat the entire point of using TLS, and so it's very important that TLS session renegotiation be detected by IP360 so that it can be disabled on the server before it has the chance to be abused. If nCircle detects this vulnerability on your system, you will not pass PCI compliance. In response to this problem, the IETF has created RFC 5746 to define a TLS extension that cryptographically ties a renegotiation to the TLS connection that established the initial encrypted tunnel. Making use of the renegotiation extension defined in RFC 5746 is commonly referred to as secure renegotiation, whereas the insecure method of renegotiating is known as legacy renegotiation.

In order to take advantage of legacy session renegotiation, an attacker first establishes a connection with the TLS server, and then intercepts a victim's TLS communications and tunnels them through his own session. The attacker can either establish a TLS session ahead of time and wait for another client to attempt to connect, or the attacker can establish the connection on the fly. Either way, the Client Hello sent by the victim client is intercepted by the attacker, and sent encrypted over the attacker's session as if the attacker was initiating a renegotiation. After the victim client finishes its' handshaking process, the attacker then acts solely as a proxy between the victim client and the server. Communication between the victim client and server from this point on is encrypted. Even though the attacker may not be able to read the communications directly, he can inject his own content into the session in an attempt to obtain confidential information or make the server behave in a way that was not intended by the victim client.

An example attack that made use of the legacy session renegotiation flaw is the famous Twitter exploit where a researcher was able to obtain a user's login credentials by injecting text into the https requests. This caused Twitter to dump the contents of the web request into a Twitter message after it had been decrypted by the server. If the same attack was attempted today, and Twitter's servers only allowed secure renegotiation, this attack would not be possible. The server would have rejected the attacker's renegotiation request if he attempted to use the victim client's Client Hello since the attacker's TLS session would have been cryptographically tied to himself.

Since I'll be diving headfirst into the inner-workings of the TLS protocol, this post is geared toward a more technical audience. We have had some positive feedback from our customers regarding our detection of this vulnerability, mostly in cases where the customer thought renegotiation was disabled on their server only to find out that it actually wasn't. Here at nCircle, VERT has put in a lot of work toward detecting this issue. Considering the critical nature of this vulnerability and how many potential people it impacts, we would like a chance to share our knowledge with other security researchers in the hopes that they may write or improve their own detection for it. At the same time, it would be great to hear feedback regarding our detection that may help us to make improvements to it.

Click here to read about how nCircle detects TLS Legacy Session Renegotiation.

I'm going to talk about something I don't normally discuss; smart phones.

I'm an avid BlackBerry user and would probably be lost without access to it but I've been thinking more and more about the security implications of using a smart phone for enterprise applications.

The BlackBerry is the king of enterprise phones, designed with the enterprise in mind and end-user features tacked as an afterthought. The iPhone, on the other hand, cleans up with average users and enterprise features were thrown in afterward. Either way, both phones ended up with a feature that has lead to them being declared "fit for the enterprise"; remote wipe capabilities. This feature, for those that don't know, allows you to remotely wipe a phone that has been lost or stolen.

I can't help but wonder if we rely too heavily on this feature. The concept of a remote wipe requires remote connectivity. Remote wipe might be sufficient for a phone that is accidentally lost, or randomly stolen, but this isn't really the cases where your data is at risk. The real risk comes from targeted attacks, where the thieves know exactly who's phone they're taking.

It's really no different from any other aspect of enterprise security in the cyber age. Targeted attacks contain the most risk -- Aurora was a great example of this. So how useful is a remote wipe when you're looking at a targeted attack? The answer is pretty simple, it's not.

Let's set up a scenario. If I'm an attacker and I know the phone I'm going after, I'm going to do my homework. I'm going to identify my target, find the best time to grab the phone and try to get it without the victim noticing.

My first move after acquiring the phone (or possibly even before acquiring it) is going to be to neutralize the remote wipe capabilities. I can do this with a $20 cell phone jammer easily purchased on the internet. If there's no signal to the phone, there's no way to remote wipe it. Since this is a targeted attack, I'm not going for the phone as a device to get free calls. I'm going after the data stored on that phone.

One of my colleagues pointed out that most of these devices have passwords and these passwords will wipe the machine after a specific number of failed attempts. My counter to this logic is as follows: In a targeted attack, I'm going to be watching you and paying attention, I'm going to finding out as much information about you as possible. I imagine I'd have a fairly good idea of what your password is, either by learning about you (how many employees passwords can be found by viewing their Facebook page?) or by watching you. Mobile devices don't do much to prevent shoulder surfing. In fact, given their constant use in public, they actually encourage it. With the numeric option on the iPhone or even the alphanumeric option of the BlackBerry, I won't have to watch you for long to determine your password, or at least a close guess at it.

The original iPhone release was deemed "not ready for the enterprise" because it lacked a remote wipe capability. Once Apple added this feature there were a lot of articles saying the iPhone was "now an enterprise tool".

I think that this mind set offers a false sense of security. If we're really relying only on remote wipe as a valid security method for targeted attacks we aren't very well protected. We have to come up with something better. Remote wipe provides peace of mind only for accidental loss or random theft of a smart phone and nothing more.