Private key for *.xboxlive.com certificate disclosed | Hacker News Reader

Private key for *.xboxlive.com certificate disclosed

technet.microsoft.com

215 pointshannob41 comments

Personally, this makes for funny timing. As a first-time Xbox (One) owner (who never owned any PlayStation), I was telling a friend with a PS4 how damn buggy everything seemed to be, from setup to games themselves. She said she doesn’t have those problems on PS4. “Maybe you should’ve gotten a PlayStation!”

“Yes, but isn’t Sony always getting hacked? Maybe the ideal thing would be a PlayStation that uses Microsoft’s web services!”

sigh

It's always funny to me when people say that sort of thing. Highly publicized attacks/vulns are bad, but it's likely that any given thing we use is getting owned all the time.

Surely many hacks happen that we never find out about; nonetheless, the real world consequences of both the recent Sony (Pictures) hack and the older PSN hack were quite significant. The latter was quite relevant as it meant no one could play online games on their PlayStations for… weeks? months? if my understanding and recollection are correct.

Well when we see vulnerabilities that can be traced back to boneheaded security, it seems reasonable to have some extra concern. Like when Sony decided to roll it's own crypto implementation for the PS3 and forgot to use different random numbers in one part, leading to the root private keys for the device being broken.

They weren't actually hacked as far as anyone knows. They just discovered a private key had been leaked and invalid the certificate.

But yeah, their services are buggy as crap.

I work with both PlayStation and Xbox network services (such as the ones affected by this leak) -- Microsoft's APIs are in a different league than the PlayStation ones. API versioning, contracts, solid SDKs, really solid separation of functionality and great coverage of core features. Sony's PlayStation API was clearly an afterthought at best, and a late night project after a drinking binge at worst.

Another instance that reminded me Sony is indeed not a software company is their mobile app. MITM'd it to discover that they were sending something like 500 requests (totalling over 100MB IIRC) every time I opened the app. Wtf?

But yeah, their services are buggy as crap.

Both PS4 and Xbox One network documentation is bordering on useless. I've had a case once where the method copied straight from documentation wouldn't work, we spent half a day debugging it, no dice - we sent an email to a developer support address, they got back with "oh actually, it's not implemented, sorry".

This sounds almost exactly like my experience attempting to develop an app for MySpace back in the day. "Oh shit, Facebook has apps! We need apps!" → I copy and paste their example code, and try to run it → Nothing happens; no hello world, no errors.

Xbox is still not an affected device in this.

That security advisory is the longest possible way to say "Private key for *.xboxlive.com certificate disclosed." In my half-asleep mindset, I was expecting it to include the private key.

Has it changed since you read it? The title says one was inadvertently disclosed, and the first line says the one was that for *.xboxlive.com.

Thank goodness for revocation lists.

It's too bad -- they list "Affected Software" but they don't seem to disclose when the earliest time that xboxlive.com shouldn't have been trusted.

Certificate was disallowed from December 1st.

The current certificate that I can see on (star).xboxlive.com is valid between December 1st 2014 and December 1st 2016.

Is it common to issue a certificate for a year, but make it active for the previous year as well?

I suspect that they need to worry about xboxes using default time settings.

An Xbox One can easily sit on the shelf for 3-4, or even more, years before being sold. Not quite the typical use-case...

Using your powers of divination, given that the platform has only just had its second birthday?

Probably entrail reading, which is more applicable to the games industry than divination. That, and the 30 years of console sales patterns to draw on.

Huh?

Look, I guarantee there's a game shop in Small Town, USA, right now with more Xbox One consoles on their shelf than they'll sell in three or more years. And I guarantee you'll find "new in box" Xbox Ones on Ebay 8-10 years from now.

Even if Microsoft stopped producing new Xbox Ones this afternoon, it wouldn't magically make those ones disappear.

Heartbleed showed us that many certificate authorities reissue certificates from the original date they were first issued.

And that's why you use an HSM kids!

How come "Xbox" is not in the list of affected devices?

I suspect that the Xbox's communication with servers is validated using an entirely different certificate; it almost certainly doesn't use DNS to lookup Microsoft servers to connect to (I remember the Xbox 360 didn't). At the very least updates are (and I would be shocked if that key wasn't in an HSM inside a safe).

It uses Windows 10 since November 2015.

Yes, and Windows 10 was affected, just like all the other listed OSes.

However, xbox users might not be able to make the connection. Explicit is better than implicit for security announcements, I daresay.

> An automatic updater of certificate trust lists is included in supported editions of ... Windows 10 ...

Can anyone elaborate on how this affects non-windows products? If I go to https://developer.xboxlive.com I see a valid certificate, so my non-windows system trusts them. Have they revoked the old certificate?

They only mention the certificate trust list, which I believe is a hardcoded list of certificates that Windows trusts. I understand that they should remove it from there but don't they also have to revoke the certificate for non-windows systems that use the standard verification methods?

What's the certificate info? Most likely, you got a valid cert. MS can give a bit extra security for mistakes like this in their own products because they have the keys to the castle, but everyone else will have to use the normal infrastructure, most likely OCSP. But from the sound of things, you're already using the new cert.

https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...

I imagine I am using the new cert. My question is that if an attacker got a hold of the past one, could I be MitM'd? They removed it from the Windows CTL but didn't mention anything explicitly about revoking it for everyone else...

Microsoft issues its own certificates, so if they add it to their own OCSP revocation list it will fail an OCSP check from any device. That said, many browsers don't do OCSP checks or will just accept a certificate if the OCSP server cannot be reached, although this was presumably an EV certificate where that attitude is less common. I'm also guessing this made it into Chrome's CRLSet (this kind of high profile EV revocation is exactly what it was designed for), so if you use Chrome you're pretty likely to be okay.

edit: Actually I just checked the Chrome CRLSet, it doesn't appear to have revocations for any certificates from "Microsoft IT SSL SHA2" :(. You can turn on OCSP verification in most browsers, which should do it.

EV certificates can't be issued for wildcard domains, so probably not EV :)

:P forgot they said it was a wildcard (it was only in the title, you know).

How exactly does this happen?

It happens. Engineer goes to upgrade the cert and copies it to a file share they didn't realize wasn't locked down. There's no evidence anyone malicious got the file but it's pretty standard protocol to just assume it's tainted and get a new cert.

I wish they would say how it was disclosed. Your scenario is bad, but less bad than actually sending it out to the Internet, or some malware on a dev's machine grabbing it.

I give equal likelihood to it being malware related, to somebody moving just disabling a settings on some server that can potentially connect to the server hosting the key.

I don't think it's somebody just posting it online, or moving it.

My money would be on somebody commiting something to an externally facing and not security certified system. You see it quite a lot things that should be in gitignore for example.

Eh, shit happens. Everything can't be perfect all the time. Especially in security.

Pretty dangerous line of thinking when it comes to private keys for a wildcard cert on such a high traffic (and probably high value) target...

I didn't say "Don't try to get it right" I said "eh, shit happens."

This might seem unusual, but having thought about this a lot, I think the issue was with naming PKI concepts. Calling the public part of the keypair a 'public key' has conditioned people that 'uploading a key' is a normal thing to do. Once 'uploading keys' is normal, it's not a huge step for a user who doesn't know PKI well to go from uploading their public key to uploading their private key.

One word summary:

"Whoops!"

Reply on news.ycombinator.com