Some research was recently published that showed that Windows 8's SmartScreen feature sends certain details about every single application that you install to Microsoft.
Ignoring the obvious privacy violations, what other security issues might this cause? The article touches on some SSL issues, but says that they haven't been verified to be vulnerable.
Actually the article does not say that the SmartScreen client uses SSLv2; it just says that the server which SmartScreen contacts would be happy to accept incoming connections using the SSLv2 protocol. It would be surprising if SmartScreen indeed used SSLv2: most plausibly, Microsoft reused their own existing code for a SSL client, and that code does SSLv3+ by default. Using SSLv2 would imply extra effort for no gain.
Also, most of what is said about security of SSLv2 (in this article or elsewhere) is covered with a heavy layer of FUD. SSLv2 has issues, sufficient to warrant not using it (especially since SSLv3 and TLS are available), but not as dire than what is usually suggested. See for example this page; it is claimed that:
- Message integrity compromised. The SSLv2 message authentication uses the MD5 function, and is insecure.
- Man-in-the-middle attack. There is no protection of the handshake in SSLv2, which permits a man-in-the-middle attack.
- Truncation attack. SSLv2 relies on TCP FIN to close the session, so the attacker can forge a TCP FIN, and the peer cannot tell if it was a legitimate end of data or not.
- Weak message integrity for export ciphers. The cryptographic keys in SSLv2 are used for both message authentication and encryption, so if weak encryption schemes are negotiated (say 40-bit keys) the message authentication code uses the same weak key, which isn’t necessary.
The first point is downright FUD. It is a knee-jerk reaction: "MD5 ? BAD BAD BAD !". It is unsubstantiated. I am not saying that MD5 is rock solid; but I claim that the integrity check in SSLv2 is not that easy to defeat.
The second point is, at best, confusing and misleading. The "man-in-the-middle attacks" which are alluded to are the following: in SSL (v2, v3+...), both client and server may support several cipher suites; the client sends the list of suites it supports, and the server chooses one. With SSLv2, an attacker who is in position of doing a MitM can alter the list sent by the client, to force the client and server to use a specific cipher suite (within the set of suites that both supports, of course). The alteration is not detected later on (whereas, in SSLv3+, it would be detected at the end of the handshake). Then, the reasoning goes, SSLv2 is weak because the attacker can force client and server to use a "weak cipher suite" (e.g. one with 40-bit keys). But can it ? In fact, the attacker can force the use of a cipher suite that both client and server were already ready to accept -- and THAT is the weakness. What the attack breaks is the optimistic upgrading to stronger cipher suites when available; but the real weakness is when client and servers accept to use 40-bit keys.
The fourth point is more of the same: it says that if a key is weak and used for two usages, then breaking the key allows attacking the two usages. But the true weakness here is using a weak key.
Only the third point is really true: an attacker can force a connection close, and the machines cannot know whether the closure was intended by the peer. This is a serious problem with HTTP/1.0 without Content-Length attribute but not with other protocols, including HTTP as it is used nowadays.
Summary: SSLv2 is "broken", but not as much as is rumoured. No, a SSLv2 connection cannot be instantly decrypted by an attacker. And I personally deem it highly improbable that the SmartScreen client uses SSLv2; it would make too little sense.
(None of the above says anything about privacy issues with SmartScreen.)
Assume the SSL connection is safe If you assume the SSL connection is safe and the Microsoft server is good then not a whole lot.
But if we assume the device has been hacked or a application gets added permissions then an attacker could do bad things. Replace Microsoft's public key or eavesdrop at the endpoint. A lot of bad could come of it....but that comes after the user is already owned...
If this is just a vanilla SSL connection I can't think of any new attack vector this opens...only a new asset that hackers could be interested in.
Assume the SSL connection is not safe MITM attackers could get whatever information passed to microsoft that they wanted. Possibly deny users from downloading new applications, okaying the downloading and installation of malicious applications, or using the information to launch targeted attacks against the user.
I think I personally need to see a whitepaper or something on exactly what smartscreen does and exactly what information it sends before I can say or assume more...
Breaking it down, there are two general concerns I would be investigating - 1.) What data is being sent, and 2.) How it's being sent.
The article describes the method of transmission - SSLv2 to a Microsoft server in Redmond. Pretty basic security, but since SSLv2 is insecure, let's assume an attacker can break this.
Insecure SSLv2 connections are nothing new, nor are the attacks and exploits we could launch on them, so the next question is how does this differ from any other insecure SSLv2 connections from your system? That leads us to question 1 - what data is being sent. In this case, we know we're sending a neat inventory of all the applications on a system.
The obvious answer is that to an attacker, this is extremely helpful. Putting it all together, I have a broken SSL connection to a system whose software foot print I now know intimately. From there, it's just a matter of going down the list of known exploits for each of those pieces of software (or writing new ones).
In my opinion, this whole thing just adds another attack vector with the wonderful added benefit of being able to very quickly acquire a prepackaged fingerprint of a system's software load. I guess it's up to you whether you think that risk is worth the benefit of having Microsoft "screen your software for you!" For both privacy and security reasons, I'd turn it off, but if you're not concerned about privacy, I'd at least wait until they get a more secure method of transmission.
