Friday, 16 March 2012

Valve fixes HTTPS vulnerability in Steam client

Valve has fixed a man-in-the-middle vulnerability in the Windows Steam client, which would have allowed a correctly-positioned attacker to divert and decrypt HTTPS traffic without the victim's knowledge. This made sensitive payment details, such as PayPal credentials, vulnerable to eavesdropping.

First, I'll get my grumbles out of the way: Steam has a huge number of users, and I don't like the idea of anyone being vulnerable to this type of thing. That's why I responsibly disclosed this vulnerability to Valve in November last year (although I suspect it may have been vulnerable for more than a year in total). My hope was that they would fix it quickly, and certainly before anyone tried to exploit the vulnerability. They were impressively receptive at first, but then things started going a bit quiet and some of my later emails were ignored.

Anyway, it took more than 3 months(!) to get this fixed, which seems an unreasonably long time to me. It's tempting to say that I wouldn't bother trying this hard to report a vulnerability again, but hey, I use Steam too!

[Screenshot from]

Oh yes, that leads me on to my second grumble: Although Valve has credited me for pointing out this vulnerability, they have dressed it up as an "addition" rather than a "fix". I think that's a bit deceptive, and hides the fact that there were any security problems. It may not be intentional, however.

The real change is that it now validates certificates rather than simply displaying their status; previously, it did not validate the certificate at all, let alone display its status. The Steam client would happily display HTTPS content from any server, regardless of whether the provided SSL certificate had expired, was for the correct domain name, or was signed by a trusted certificate authority. There have been enough issues surrounding the whole PKI arena lately, without having to worry about clients that don't actually check certificates properly...

By controlling or hijacking DNS lookups for the domain "" (e.g. by providing gamers with an open wireless network which used a rogue DNS server), an attacker could have caused Steam clients to display arbitrary content instead of the expected PayPal payment flow (see screenshot above). This content could have been served from the attacker's own HTTPS server, configured to present a self-signed SSL certificate with an arbitrary common name. 
Steam displayed the spoof content without warning or indicating that the certificate was invalid. This provided a very plausible opportunity to steal a user's Steam credentials by prompting the user to re-enter them within the Steam client itself.
An attacker could also have carried out an undetectable man-in-the-middle attack by relaying Steam client requests to the legitimate PayPal website. This would have allowed the attacker to decrypt and view the user's login credentials and other sensitive details while still allowing the transaction to be processed successfully and thus avoiding any suspicion from either party. Unfortunately, that means there is no know way of knowing whether or not this vulnerability was actively exploited before it was eventually fixed.