RE: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

rde...@gmail.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net) On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy < dev-

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Part of the trouble in relying upon the name alone is that on many OS's > (maybe all -- at least all the ones that matter for client side work) can > have localhost

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I sent the key to Jeremy on Tuesday as Hanno suggested, and it was revoked at 9am the next morning. The encrypted private key information is only in memory during startup, so I identified that bit of code and broke into a debugger. You could pull the parameters out of OpenSSL's internals too.

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I found there is actually no need to sign-in to battle.net client. Simply running the battle.net client shortcut from the desktop opens the login screen. At this point the server has already and is listning on port 22886. Also confirmed ability to connect with browser to https://127.0.0.1:22886

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 5:01 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, December 25, 2017 at 10:24:30 AM UTC-6, Hanno Böck wrote: > > On Mon, 25 Dec 2017 14:43:21 + > > Jeremy Rowley via dev-security-policy > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I’m pretty sure EA revoked the cert. > On Dec 25, 2017, at 9:23 AM, Hanno Böck wrote: > > On Mon, 25 Dec 2017 14:43:21 + > Jeremy Rowley via dev-security-policy > wrote: > >> Without the private key, im not sure how we're supposed to

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Part of the trouble in relying upon the name alone is that on many OS's (maybe all -- at least all the ones that matter for client side work) can have localhost overridden to mean other things. Taking it back to the IP layer has the advantage of certainty for the constrained question of whether

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Matthew Hardeman wrote: > 6. Thus, the direction this goes is that the developer creates a self-signed > cert and imports it into the trust store. The developer may do this on the > software host, but historically is more likely to just create one and package > it just like they did with the

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Monday, December 25, 2017 at 11:27:00 AM UTC-6, Adrian R. wrote: > +1 > imho that would be the best idea, and the local/non-local check should happen > inside the same PKI-validation logic flow that is used for certificate > validation. > > If the url resource resolves to local IP addresses

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

P.S. i assumed only a TLS context, but the same rule should probably apply for any connection, whether plaintext or SSL/TLS: > If the url resource resolves to local IP addresses then only reserved names > from > https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

+1 imho that would be the best idea, and the local/non-local check should happen inside the same PKI-validation logic flow that is used for certificate validation. If the url resource resolves to local IP addresses then only reserved names from

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Monday, December 25, 2017 at 10:24:30 AM UTC-6, Hanno Böck wrote: > On Mon, 25 Dec 2017 14:43:21 + > Jeremy Rowley via dev-security-policy > wrote: > > > Without the private key, im not sure how we're supposed to confirm > > key compromise. > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

those cases can be easily ruled out like this: 1) after authentication in the BattleNet app and the app starts properly, disconnect the device from any network. In my case i physically unplugged the ethernet cable from the PC, and it has no other connection available, not even wireless. 2)

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, 25 Dec 2017 14:43:21 + Jeremy Rowley via dev-security-policy wrote: > Without the private key, im not sure how we're supposed to confirm > key compromise. I've pinged a few people with the right skillset to try to extract the key. But if there

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 07:59:12AM -0800, Peter Bowen via dev-security-policy wrote: > On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy > wrote: > > since it's a webserver running on the local machine and is using that > > certificate

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy wrote: > since it's a webserver running on the local machine and is using that > certificate key/pair, i think that someone more capable than me can easily > extract the key from it. > >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

since it's a webserver running on the local machine and is using that certificate key/pair, i think that someone more capable than me can easily extract the key from it. >From my point of view as an observer it's plainly obvious that the private key >must be on my local machine too, even if i

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

I think this raises a question on what level of investigation and assumption is required by the ca. Let's encrypt, for example, requires submission of the private key for revocation (https://letsencrypt.org/docs/revoking/). Is simply providing a reference rather than the key sufficient? On Dec

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

1) get a virtual machine 2) install windows, install the Blizzard BattleNet client. 3) create a BattleNet account with any email address - it's free, subscription/payment is not required for this. 4) login in the BattleNet app client with the account from step 3. 5) after the main BattleNet

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Without the private key, im not sure how we're supposed to confirm key compromise. > On Dec 25, 2017, at 3:32 AM, Adrian R. via dev-security-policy > wrote: > > The BattleNet app needs to be installed and running, i am logged in with a > battlenet

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Mon, 25 Dec 2017 04:19:58 -0800 (PST) "Adrian R. via dev-security-policy" wrote: > Side question: why wasn't the certificate from DigiCert logged into > Certificate Transparency logs when it was issued and it had to be > discovered this way? There's no

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Side question: why wasn't the certificate from DigiCert logged into Certificate Transparency logs when it was issued and it had to be discovered this way? On Monday, 25 December 2017 12:42:05 UTC+2, Hanno Böck wrote: > Thanks, I also got it in the meantime and submitted it to CT: >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Thanks, I also got it in the meantime and submitted it to CT: https://crt.sh/?id=287530764 Bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=1427034 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

The BattleNet app needs to be installed and running, i am logged in with a battlenet account. the public certificate is attached below and i don't know how to get the private key from inside the app, but it must be there since it runs as local webserver on 127.0.0.1 Adrian R. -BEGIN

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Sun, 24 Dec 2017 23:07:56 -0800 (PST) "Adrian R. via dev-security-policy" wrote: > on any computer with BattleNet installed and active go to this url: > > https://127.0.0.1:22886/ > and currently it uses this certificate... which doesn't appear on >

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

p.s. 1) i posted here because i don't even have access to viewing the Blizzard bug on Bugzilla, even if i'm logged in with a Bugzilla account I get the message " You are not authorized to access bug 1425166. " 2) i also sent the same message to the certificate problem-reporting address

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

> Bug Blizzard: > https://bugzilla.mozilla.org/show_bug.cgi?id=1425166 > Cert Blizzard: > https://crt.sh/?id=26142 > Blizzard went to DigiCert and got another certificate instead: on any computer with BattleNet installed and active go to this url: https://127.0.0.1:22886/ and currently it

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

On Thursday, December 21, 2017 at 7:38:59 PM UTC-5, Matthew Hardeman wrote: > Far too many do it. I think the technique is repugnant garbage that the > browsers themselves should solve. > > Spotify historically did this, too. > > The idea is that rich-client software on the PC has a daemon

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

This is nasty. Apparently, it's not actually a true Root CA cert (No CA: True) and it has an EKU that would not include signing certificates. That said, Blizzard's response is further to my point... As long as the browser can access resources of the localhost under the direction of a web page

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

Far too many do it. I think the technique is repugnant garbage that the browsers themselves should solve. Spotify historically did this, too. The idea is that rich-client software on the PC has a daemon running in the background on one of a number of chosen TCP ports. Usually it implements