Friday, 27 April 2012

TeamMentor.net vulnerable to BEAST and SSL 2.0, now what?

Ok, so from https://www.ssllabs.com/ssltest/analyze.html?d=teammentor.net&source=tim we can see that https://teammentor.net gets a B rating because it is vulnerable to the 'BEAST Attack' (whoohh that sounds scary :) )

The link on that page points to Mitigating the BEAST attack on TLS which provides some background info on the problem, but it doesn't answer the questions I have at the moment, which are:

  • What is the risk impact of this vulnerability on a site like http://teammentor.net?
  • What are the exploit scenarios?
  • Is there any mitigation (or not) by the use of IIS 7.0?
  • How do I fix this in IIS 7.0?
  • Can anything been done at the Application Layer?
In a way this is where security fails. Instead of giving me a solution, SSL Labs (which rocks btw) is giving me a problem.

Another good example of 'Security as TAX' vs 'Security as Enabler'.

We are going to have to spend resources to understand, fix, test, validate this problem (i.e. pay a TAX) with very little return

The other issue to solve is to remove SSL 2.0 support is IIS7. As per this post How to Disable SSL 2.0 in IIS 7 , it looks like it needs to be done by changing the registry. Is that the only way to do this?

Also asked this question on:

11 comments:

Arnaud SOULLIÉ said...

Hi Denis,

I would like to hear your opinion on these BEAST attacks.

From my point of view, you need at least remote code exec on the target and SOP bypass to exploit it. Doesn't look really likely to me ...

Dinis Cruz said...

I also want to know more, which is why I'm asking this question publicly :)

As security researcher I know that I if I took the time I would be able to understand it and figure out the real impact, but as a developer I don't have that time right now.

Which is why I want the answers to the questions I asked above.

So if you have more if info on this topic, please paste it here, so that we can build a full picture of what is the real threat profile of BEAST in an app like TeamMentor (when hosted in IIS)

Romich said...

Unfortunately many security testing applications tend to pride themselves on the number of vulnerabilities they find, number of risks they identify and how much FUD they generate. (nothing against ssllabs)
We need researches to spend time not only increasing number of issues detectable, but what is the actual exploitability of each, the risk, and specific remediation steps.

markwoan said...

There is some research Context have done on the issue:

http://www.contextis.com/research/blog/beast/

Ivan Ristić said...

Dinis,

The SSL Labs assessment tool solves one part of your problem: you now know that you're vulnerable and you can start looking for a solution.

Talking about risk, there is little automated tools can do, because they all lack context. What is risky for some, many not be at all for someone else.

In this particular instance (BEAST), fixing the problem in configuration is cheap, while trying to understand the risk is expensive. So just fix it.

Erlend Oftedal said...

The attacker needs to own (hack) a website A. When a use B opens this web page, the webpage at A opens a connection to teammentor.net and keeps that connection open (the original was using a java exploit). By sniffing the encrypted traffic between the browser visiting A and teammentor, and carefully injecting known data into the encrypted stream (by controlling A and sending data from A to the browser, which the browser then passes through the connection to teammentor), the attacker can reveal encrypted data (session cookies etc.) sent from the browser team mentor.
So the attacker needs to:
* trick the user into visiting a website he owns
* sniff the users traffic to teammentor
And the risk is the ability to steal credentials.

Ivan Ristić said...

Erlend, there's no need for the attacker to trick the victim into visiting a web site. He can simply intercept traffic to any non-encrypted web site and inject malicious code into it.

Erlend Oftedal said...

@Ivan: Good point. The "attacking" website does not need to be served over https, and can thus just have the payload injected into the http traffic of any site.
Anyways the attacker needs to be able to sniff and inject traffic, so the attacker is typically on the same wlan.

Dinis Cruz said...

@Ivan The risk discussion is important since that is what dictates action. I'm just trying to be pragmatic and enable decisions to be made.

And in this case, I do want to fix it. But I need specific information (i.e. how to do it step by step)

The Scan from SSLLabs is great since in a way that is a UnitTest that I can use to validate the fix :)

To be honest my main issue at the moment is exactly how to fix this, and its real impact (for example what are the browsers that will be affected). I also would like to know what I could do for the users that use browsers that don't support the secure version.

The article at http://www.contextis.com/research/blog/beast looks great (which I still have to read properly) and the solution seems to be some registry hack.

Btw, is this the most cryptic of MS KB articles? http://support.microsoft.com/kb/245030 (this article is supposed to have the solution)

Question: Have there been any documented attacks exploiting BEAST?

Rovastar said...

Hi Dinis,

As far as I am concerned the BEAST exploit has been fixed in IIS with this security bulletin MS12-006 (Jan 2012)

http://technet.microsoft.com/en-us/security/bulletin/ms12-006

Is the server patched? Surely it has been this year?

If you really want to get to the details about what it is doing then check these Microsoft blogs.

http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx

http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx

I think when this first was announced (before the patch came out) that I reordered the ciphers for on the server and the SSLlabs error disappeared...
I mean if you use the solution/workaround at the time (and SSL blog) about pushing the RC4 ciphers up the chain.
Although I am not sure that even works as I read from the above blogs.
"Warning: Web clients that don’t support TLS 1.1 or 1.2 will perform the SSL negotiation with lower SSL/TLS versions, voiding the workaround."


Also I always use this brilliant free app to change the cipher settings.

https://www.nartac.com/Products/IISCrypto/Default.aspx

not messing around with direct registry hacks.

So I concluded that the SSLlabs test is a problem (for me it is only looking at the cipher order if SSL3/TLS1.0 is enabled) and you are not vulnerable.

Hope that helps.

(We have actually met before, a couple of years ago when the OWASP london/city were regular meetings. I remember eating a curry or two with you.

I was the non-security IIS server guy hanging on....).

John Baker
IIS consultant

Dinis Cruz said...

Romich, great answer!!!!

Do you have some (paid if needed) cycles to help? We're trying to nail down TeamMentor IIS deployment, and could do with some extra brain power.