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

[Jeremy Rowley via dev-security-policy]

BTW - this certificate was revoked.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Mark Steward via dev-security-policy
Sent: Friday, December 29, 2017 11:30 AM
To: Matthew Hardeman <mharde...@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-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 overridden to mean other things.
>
>
The main issue I see is that it effectively breaks SOP. It's not reasonable
to expect a user to know what app is listening on what port whenever a
browser connects, or to ensure that only Battle.net could listen on 28866.


> ...



If I recall correctly, this is actually more of a thing for WebSockets.
>
> If my recollection is correct, Chrome already considers 
> http://localhost or is it http://127.0.0.1 to be a secure origin in 
> nature.  Thus, code which arises from a request to localhost is 
> treated as running within a secure context, even if it is not wrapped 
> in a TLS connection.  (You can run javascript and access APIs in such 
> circumstances on localhost via HTTP when ordinarily Chrome would 
> require HTTPS to enable that access.)
>
> However...  That doesn't help the web developer who is trying to 
> access a WebSocket service on localhost.  While Chrome regards the 
> localhost as a secure origin, WebSockets in Chrome (and every other 
> mainstream browser?) require the connection to be a TLS wrapped one, 
> regardless of whether or not it's from a secure origin.
>
> (I wonder if they even wrote a protocol handler for non-secure web 
> sockets?  At the moment, it's Christmas and I'm being too lazy to 
> look.)
>
>
If by non-secure websockets you mean ws://, then yes, and Chrome is lax here
in that it allows access to ws://localhost from https:// without logging a
Mixed Content warning (Firefox only allows ws://localhost from http://).

I think the real issue is (anticipated) fallout of the move to HTTPS by
default, possibly along with the deprecation of Flash. I don't think there's
a clean solution for creating a socket from a website to an app on the local
machine, except maybe via WebRTC?


Mark
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Mark Steward via dev-security-policy]

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 overridden to mean other things.
>
>
The main issue I see is that it effectively breaks SOP. It's not reasonable
to expect a user to know what app is listening on what port whenever a
browser connects, or to ensure that only Battle.net could listen on 28866.


> ...



If I recall correctly, this is actually more of a thing for WebSockets.
>
> If my recollection is correct, Chrome already considers http://localhost
> or
> is it http://127.0.0.1 to be a secure origin in nature.  Thus, code which
> arises from a request to localhost is treated as running within a secure
> context, even if it is not wrapped in a TLS connection.  (You can run
> javascript and access APIs in such circumstances on localhost via HTTP when
> ordinarily Chrome would require HTTPS to enable that access.)
>
> However...  That doesn't help the web developer who is trying to access a
> WebSocket service on localhost.  While Chrome regards the localhost as a
> secure origin, WebSockets in Chrome (and every other mainstream browser?)
> require the connection to be a TLS wrapped one, regardless of whether or
> not it's from a secure origin.
>
> (I wonder if they even wrote a protocol handler for non-secure web
> sockets?  At the moment, it's Christmas and I'm being too lazy to look.)
>
>
If by non-secure websockets you mean ws://, then yes, and Chrome is lax
here in that it allows access to ws://localhost from https:// without
logging a Mixed Content warning (Firefox only allows ws://localhost from
http://).

I think the real issue is (anticipated) fallout of the move to HTTPS by
default, possibly along with the deprecation of Flash. I don't think
there's a clean solution for creating a socket from a website to an app on
the local machine, except maybe via WebRTC?


Mark
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Mark Steward via dev-security-policy]

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. Happy to share more details if
you email me from your digicert.com email address (or wait for Battle.net
to be patched).

I've signed Hanno's Bugzilla report:

  wget https://rack.ms/b/0F0GSbo1c33A/msg.txt{,.sig-sha256.b64}
  wget https://crt.sh/?d=287530764 -O 287530764.crt
  openssl dgst -sha256 -verify <(openssl x509 -in 287530764.crt -pubkey
-noout) -signature <(base64 -d msg.txt.sig-sha256.b64) msg.txt


Mark

On Wed, Dec 27, 2017 at 2:51 PM, mkhouta--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
> or with ‘openssl s_client -connect 127.0.0.1:22886’ without logging in.
> As soon as you close the app the server shuts down.
>
> I did a memory dump on the process for battle.net.exe and parsed it with
> some tools to extract the private key but no keys found.
>
> Not sure how Mark Steward managed to find the key but would be interested
> to know the steps to reproduce.
>
> I think also if Mark can share the password to the encrypted key or prove
> ownership of the key by producing a signature hash signed by the private
> key and is verifyable with the ssl cert then that is hard proof of a
> compromise.
>
> Thanks,
> Moustafa
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[mkhouta--- via dev-security-policy]

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 or with 
‘openssl s_client -connect 127.0.0.1:22886’ without logging in. As soon as you 
close the app the server shuts down.

I did a memory dump on the process for battle.net.exe and parsed it with some 
tools to extract the private key but no keys found.

Not sure how Mark Steward managed to find the key but would be interested to 
know the steps to reproduce.

I think also if Mark can share the password to the encrypted key or prove 
ownership of the key by producing a signature hash signed by the private key 
and is verifyable with the ssl cert then that is hard proof of a compromise.

Thanks,
Moustafa

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Mark Steward via dev-security-policy]

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
> >  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 are people here who feel capable feel free. (I already
> > tried the "simple" means, e.g. grepping through files.)
>
> As Mr. Bowen pointed out, there are several mechanisms which would allow
> for the key not to be on the localhost, although it almost certainly is.
>
> Someone will have to bring out the debugger, watch for the appropriate
> calls, etc.  If they're using system libraries, it'll be really easy.  If
> they built in their own TLS stack natively and obfuscated it carefully,
> it'll be possible but harder to decipher.
>
>
They're using OpenSSL, so it's actually pretty easy. Cert and the encrypted
private key passed in are at
https://rack.ms/b/localbattle.net.20171213.{crt,key}.pem.

The md5sum of the password is a521813def68e89e898333695d8f508a. If people
think this should be shared, let me know.


Mark
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 confirm
>> key compromise. 
> 
> I've pinged a few people with the right skillset to try to extract the
> key. But if there are people here who feel capable feel free. (I already
> tried the "simple" means, e.g. grepping through files.)
> 
> But one question: In the case of EA the cert got revoked and nobody
> asked for the key as evidence. What happened there? Did EA ask for the
> revocation? (I made them aware, but I have no knowledge of what happened
> afterwards.)
> 
> -- 
> Hanno Böck
> https://clicktime.symantec.com/a/1/7E2647SolTSFOrmTr1pTA6SaNlzWBEeOvNPzQjcoj-Q=?d=umuIBG9-qCSr0Ylk6iYyIG3WeDTsVZikMcWOz_90PD3etIywoX7mdbgM5-o7RmsLsolZOKJ5Yd7icx5CeHssMAD1UiN3APXXUDDjiwPDtMurIvGC1HUEmDwsAqBNjurJb-MIs_jopfZdcgY8mxha-DU3cggVxUKUpNesVOFzY4crbfh1T7v41ePXIqcjijQ5aiIrkZW7KPQhtK0KI34OyF_MPpj2n6Qwe3uXjjiKkflcD6tc0TslmbWo45ySkZr4IN9bmDJwyvSkZBodxAx7nt14NKzoWv2Mva865UkPqyNQF_sU7EOLF98PY4vHaeQFD-z9YZXHQxZjsTCqILJKF6XLJBIUOlZRa_LrXPQ8DxHY7YqNM4c8olIBYR8DWed9-LY-7juzWP3pT-3XoQanCUnEbUsgq1BNL8yQ_OU%3D=https%3A%2F%2Fhboeck.de%2F
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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 or not the target I am attempting to attach
to is "me", from the perspective of the local host.

I am aware that work is ongoing to address that.  Furthermore, I'm sure
each individual browser could just consider the string "localhost", when
positioned in the URL as a host name, to be treated specially -- achieving
the same goal.  I'm not certain whether or not they are doing so as yet.

The trouble the various software developers will have with the Chrome flag,
of course, is that external software is not allowed to directly change
Chrome flags.  (I believe I recall that they made that sort of a pain on
purpose.  I applaud that.)

This isn't about developer workstations, it's about real world end users.
If the end user has to go into Chrome settings and flip a flag, the
developer isn't going to tolerate that.  (It's not trivially easy and lots
of real world end users would get lost, even with good instructions and
screen shots.)   Instead the developer will just install a certificate and
make it trusted themselves.  Hopefully, they would do so in a reasonably
sensible way: (like locally creating a name-constrained CA with proper
extended key usages and marking it trusted with proper trusts, followed by
locally created certificate for the needed name, signed by the local CA).
But that's a lot of work (relative to doing it the wrong way).

If I recall correctly, this is actually more of a thing for WebSockets.

If my recollection is correct, Chrome already considers http://localhost or
is it http://127.0.0.1 to be a secure origin in nature.  Thus, code which
arises from a request to localhost is treated as running within a secure
context, even if it is not wrapped in a TLS connection.  (You can run
javascript and access APIs in such circumstances on localhost via HTTP when
ordinarily Chrome would require HTTPS to enable that access.)

However...  That doesn't help the web developer who is trying to access a
WebSocket service on localhost.  While Chrome regards the localhost as a
secure origin, WebSockets in Chrome (and every other mainstream browser?)
require the connection to be a TLS wrapped one, regardless of whether or
not it's from a secure origin.

(I wonder if they even wrote a protocol handler for non-secure web
sockets?  At the moment, it's Christmas and I'm being too lazy to look.)

All of this leads to the reasons which I think if the sub resource is local
while the main page URI is not, just decline to even attempt the connection.

The real trouble I have is that shoddy certificate and key handling are
likely the tip of the iceberg when further scrutiny and examination is made
of these various daemons listening on the local machine.  The browsers have
an opportunity to foreclose any possibility of those daemon's being exposed
to external web resources.

The mechanism I propose would still permit a remote website to redirect the
browser to a full page and resource load on localhost and would allow
localhost sub-resources to load in that context.  So it does not entirely
shut down the use case the various developers want, it just requires them
to move more of the UI and logic to the client side.

More importantly, it prevents a remote website from "port scanning"
(whether broadly or for more specific target ports)  the local host for
anything stupid enough to answer with an Access-Control-Allow-Origin: *
header.  (Far too often, you see, the actual marketing name website origin
from which the legit requests will arise is not yet decided or known for
the developer at development time to incorporate it in the CORS mechanism
properly.)

Thanks,

Matt Hardeman


On Mon, Dec 25, 2017 at 1:04 PM, Adrian R. via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 trusted ones before.  Only
> now, the developer has to annoyingly ask for admin permission to install
> the certificate to the trust store.  All because they want to be able to
> run web-sockets or HTTP(s) to the local host at the command of the browser,
> as directed by a remote web site.  Mere revocation of the trusted
> certificates is not sufficient to stop the bad practices which will arise
> (and have already arisen) in response to revoked certificates.
> >
> > 7.  My proposal would almost certainly halt the interest in trusted
> certificates which refer back to the local endpoint -- particularly for
> shared certs/keys.
> >
> > Thanks,
> 

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

[Adrian R. via dev-security-policy]

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 trusted ones before.  Only now, the developer 
> has to annoyingly ask for admin permission to install the certificate to the 
> trust store.  All because they want to be able to run web-sockets or HTTP(s) 
> to the local host at the command of the browser, as directed by a remote web 
> site.  Mere revocation of the trusted certificates is not sufficient to stop 
> the bad practices which will arise (and have already arisen) in response to 
> revoked certificates.
> 
> 7.  My proposal would almost certainly halt the interest in trusted 
> certificates which refer back to the local endpoint -- particularly for 
> shared certs/keys.
> 
> Thanks,
> 
> Matt Hardeman

In the case of "localhost" there's even no need to import the certificate to 
the certificate store: browsers can be told to automatically skip certificate 
validation for 'localhost'.

Chrome is one of the browsers that implemented this validation bypass for 
localhost, you need only to set a flag in settings to enable it and you don't 
need to mess with the certificate store after that:
chrome://flags/#allow-insecure-localhost
*Allow invalid certificates for resources loaded from localhost.*
Allows requests to localhost over HTTPS even when an invalid certificate is 
presented. Mac, Windows, Linux, Chrome OS, Android

Also, these restrictions should fit in nicely with the upcoming standard
https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02


Adrian R.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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 then only reserved names 
> from 
> https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
> should be allowed to continue with the certificate validation logic.

Yes, though I would take it further, as you noted in your next message, than in 
just the PKI logic.

Specifically, the fix I would propose is:

The browser should calculate and retain (how often and at what lifecycle points 
remains debatable, as best practice may vary by platform and be constrained by 
performance characteristics of some platforms) the full set of IPv4 and IPv6 
listening points which are known to terminate on the browser's host.

The IPv4 or IPv6 address from which the page root resource loads should be 
noted.

If the IPv4 or IPv6 address from which the page root resource loaded is any one 
of the locally terminated (here I mean on-the-host)  IPv4 or IPv6 addresses, 
then the page and the sub-resources which descend may continue in current logic 
as to what further sub-resources may load.  If, however, the page root resource 
loads over IP from any other address (not part of the set of local IP 
endpoints), the sub-resource should be denied without attempt before 
considering any of the current logic.

Rationale:

1.  Workflows incorporating locally hosted sub-resources accessed via external 
websites have demonstrably led to numerous issuances of shared trusted 
certificate/keypairs.

2.  It is apparent that the community has regarded the existence of known 
shared private keys for publicly trusted certificates to be an unacceptable 
security risk worthy of immediate revocation.  It would appear that the CA 
community agrees (whether reluctantly or not I can not speak to).  The point 
that I make is that I can find no legitimate controversy as to the negative 
security ramifications of these certificates.

3.  If we accept that the existence of the certificates as in #2 are bad and 
that reliance upon these certificates is bad, then we must conclude that the 
party causing this issuance and reliance is not exercising best (perhaps not 
even acceptable) practices as pertains security.  I submit that this requires 
that we consider that this party, the software developer, may also be remiss in 
other areas of security practice.

4.  If we accept that the developer is not exercising best judgement in 
security practice and design, we must consider what other issues may be present 
in these daemon's listening on the local loopback (or *shudder* other local IP 
endpoints).

5.  Recognize that this is about cost: The goal of the developer playing these 
tricks is to allow for "control" of the developer's software running on the 
local system from the developer's website.  The standard way to do this would 
be for the software on the client to maintain a persistent or periodic 
command-and-control channel back to centralized infrastructure of the 
developer.  This trick allows a much cheaper way to avoid that infrastructure 
cost.  While the economic incentive exists, the developer will continue to use 
any and all necessary workarounds to make this work.

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 trusted ones before.  Only now, the developer 
has to annoyingly ask for admin permission to install the certificate to the 
trust store.  All because they want to be able to run web-sockets or HTTP(s) to 
the local host at the command of the browser, as directed by a remote web site. 
 Mere revocation of the trusted certificates is not sufficient to stop the bad 
practices which will arise (and have already arisen) in response to revoked 
certificates.

7.  My proposal would almost certainly halt the interest in trusted 
certificates which refer back to the local endpoint -- particularly for shared 
certs/keys.

Thanks,

Matt Hardeman
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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
> should be allowed
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

+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 
https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
should be allowed to continue with the certificate validation logic.

I think that would be the best approach that also allows continued use of 
internal names for local ip addresses.

Adrian R.


Matthew Hardeman  wrote:
> The only way that will ever happen is to fix the browser to kill the 
> capability to hit a local IP endpoint if the main resource is non-local.  
> Once that change is made, the software developers will have far less 
> incentive to do things like this.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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. 
> 
> I've pinged a few people with the right skillset to try to extract the
> key. But if there are people here who feel capable feel free. (I already
> tried the "simple" means, e.g. grepping through files.)

As Mr. Bowen pointed out, there are several mechanisms which would allow for 
the key not to be on the localhost, although it almost certainly is.

Someone will have to bring out the debugger, watch for the appropriate calls, 
etc.  If they're using system libraries, it'll be really easy.  If they built 
in their own TLS stack natively and obfuscated it carefully, it'll be possible 
but harder to decipher.

Ultimately, it's eminently solvable, but will take someone time.

If this type of key compromise is actually worth getting the revocation for, 
then it's worth preventing the issue in the first place...

The only way that will ever happen is to fix the browser to kill the capability 
to hit a local IP endpoint if the main resource is non-local.  Once that change 
is made, the software developers will have far less incentive to do things like 
this.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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) try to access the same site: https://127.0.0.1:22886

result: https://imgur.com/A9kW8nh

since the local web server still works and there is no connection to the 
outside world, the private key must be here, somewhere.

Adrian R.


On Monday, 25 December 2017 17:59:24 UTC+2, Peter Bowen  wrote:
> The problem is that this is not true.  I've not investigated this
> software at all, but there are two designs I have seen in other
> software:
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Hanno Böck via dev-security-policy]

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 are people here who feel capable feel free. (I already
tried the "simple" means, e.g. grepping through files.)

But one question: In the case of EA the cert got revoked and nobody
asked for the key as evidence. What happened there? Did EA ask for the
revocation? (I made them aware, but I have no knowledge of what happened
afterwards.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kurt Roeckx via dev-security-policy]

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 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 haven't actually got to the 
> > key itself yet.
> 
> The problem is that this is not true.  I've not investigated this
> software at all, but there are two designs I have seen in other
> software:
> 
> 1) TCP Proxy: A pure TCP proxy could be forwarding all the packets to
> another host which has the key.
> 
> 2) "Keyless" SSL: https://www.cloudflare.com/ssl/keyless-ssl/ - they
> key is on a different host from the content
> 
> I'm sure there are other designs which would end up with the same
> result: 127.0.0.1 does not have the private key.  Given this,
> conjecture that there "must" be a private key compromise seems
> exaggerated.

In theory it could also be something like Intel SGX, but that seems
very unlikely.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

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.
>
> 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 haven't actually got to the 
> key itself yet.

The problem is that this is not true.  I've not investigated this
software at all, but there are two designs I have seen in other
software:

1) TCP Proxy: A pure TCP proxy could be forwarding all the packets to
another host which has the key.

2) "Keyless" SSL: https://www.cloudflare.com/ssl/keyless-ssl/ - they
key is on a different host from the content

I'm sure there are other designs which would end up with the same
result: 127.0.0.1 does not have the private key.  Given this,
conjecture that there "must" be a private key compromise seems
exaggerated.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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 haven't actually got to the key 
>itself yet.

On Monday, 25 December 2017 16:58:42 UTC+2, Jeremy Rowley  wrote:
> 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?
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 25, 2017, at 7:52 AM, Adrian R. via dev-security-policy 
>
 wrote:

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 interface appears and shows that the user is 
properly logged in to their BattleNet account, open
https://127.0.0.1:22886/
in a web browser on the same virtual machine

result: this screen appears: 
https://clicktime.symantec.com/a/1/H8EylvFRu5AobRkYFh6nEMe_PZIqmSax2Rvqek2FeJs=?d=1yfch_0HocrSV8WeVgZeGsaOOneJ-8cF9bP7yzmp3HXKFGdjeJepYJf6HznnulZj_1Hv1P6Nn-z52PWlor45BiQi65emSMiq-1FjmlLPbEJBtMBbrUogI-Fp6ObsZErl07MAEKeXnIGAYXu493v19485GnXENM8m8015gWJTQdTruz3ruoXnJWdgFJOmflAh0pAb96BgaUR0o3r4BfbPSjVEuaW3jwhMObKUSCA8KQhf20VbylP8ssdWsAlXVpURT5gn4xW12jWxlyLw8Wdo-O5i5iN42A0yKRO3nel-TAJKnwHG0jjPGK9JrCbzjOttwrRwEpdAsa0nBiwHtSqNpBTHtj4vUi-H1XO01dG2eqm6SJgI-ZhQBPSRUgjoHicpibap-jFCjemQVsIxzJMxH_mrPbvx2JXc3bPaMsi5Qyu97ZVLxNl9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D=https%3A%2F%2Fimgur.com%2Fv5vqedX


On Monday, 25 December 2017 16:44:03 UTC+2, Jeremy Rowley  wrote:
Without the private key, im not sure how we're supposed to confirm key 
compromise.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/7yhaM2O2nJci9TxwV_RD8qfnr-mmoGnbt-5pz2kQ8pA=?d=1yfch_0HocrSV8WeVgZeGsaOOneJ-8cF9bP7yzmp3HXKFGdjeJepYJf6HznnulZj_1Hv1P6Nn-z52PWlor45BiQi65emSMiq-1FjmlLPbEJBtMBbrUogI-Fp6ObsZErl07MAEKeXnIGAYXu493v19485GnXENM8m8015gWJTQdTruz3ruoXnJWdgFJOmflAh0pAb96BgaUR0o3r4BfbPSjVEuaW3jwhMObKUSCA8KQhf20VbylP8ssdWsAlXVpURT5gn4xW12jWxlyLw8Wdo-O5i5iN42A0yKRO3nel-TAJKnwHG0jjPGK9JrCbzjOttwrRwEpdAsa0nBiwHtSqNpBTHtj4vUi-H1XO01dG2eqm6SJgI-ZhQBPSRUgjoHicpibap-jFCjemQVsIxzJMxH_mrPbvx2JXc3bPaMsi5Qyu97ZVLxNl9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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 interface appears and shows that the user is 
properly logged in to their BattleNet account, open
https://127.0.0.1:22886/
in a web browser on the same virtual machine

result: this screen appears: https://imgur.com/v5vqedX


On Monday, 25 December 2017 16:44:03 UTC+2, Jeremy Rowley  wrote:
> Without the private key, im not sure how we're supposed to confirm key 
> compromise. 
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 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 CERTIFICATE-
> MIIFbTCCBFWgAwIBAgIQCn+uUpLudsH09lYYIPTK5DANBgkqhkiG9w0BAQsFADBw
> MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
> d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
> dXJhbmNlIFNlcnZlciBDQTAeFw0xNzEyMTMwMDAwMDBaFw0xODEyMTgxMjAwMDBa
> MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZJ
> cnZpbmUxJTAjBgNVBAoTHEJsaXp6YXJkIEVudGVydGFpbm1lbnQsIEluYy4xGDAW
> BgNVBAMTD2xvY2FsYmF0dGxlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
> AQoCggEBAL7pCsdGFhOe0aTk/1zPuBhD+5dc4Lg6VMg+Y+HRfJv9nlLfFoDKS2dy
> 3cwPTW3NaQqNRhGug5ODBsoLUOI7heT4tiv91yQ+OlIFENsS1vWgba85ifIKt3pS
> PG6kLc96nZ3JLpU4qjXOiF14/BECtNfBnIRsq60Vd/STWSNo84XrEvYBraTXT7Pg
> kkU2DFeUcl9pvfcsLmtJ4tUk1E1euL7cqQxN5LRr+6hPyhN1rqB5SEaWoIaUd4OD
> stR4H8RbxCXunIUS3o1O12cWAt4q4jDTay+8Bqy0sYGPvlLSOHMSrWHshpMGMVUL
> Plh5pKpXQn78usEyTw4O3hDPFnHv4McCAwEAAaOCAf0wggH5MB8GA1UdIwQYMBaA
> FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBTlPRA/nSH/T/W5QfGmpEwp
> YI/YEzAvBgNVHREEKDAmgg9sb2NhbGJhdHRsZS5uZXSCE3d3dy5sb2NhbGJhdHRs
> ZS5uZXQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
> BQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20v
> c2hhMi1oYS1zZXJ2ZXItZzYuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2Vy
> dC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9
> bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMw
> CAYGZ4EMAQICMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAh0dHA6Ly9v
> Y3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMuZGln
> aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5jcnQw
> DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAaAidMTizU/KDox3Rd/Ak
> 9u/iGbGjwssc9582FoRQVBdOxVkvxNWy/+9As/v6HUhZhWRBYOPMwvMSYBufNcdq
> +zrEK8uJU4T0zI684pqzVsPwpFw3t9JzcdTZGScrD5//7fAkTql4YW9FGTyWz4ka
> qXwt19R615xxFBGPt25jaB2vZHXrHl3v49GkntFpvlKLwhlidcrVg1F3px4di7c3
> OR82PbAnjipHzg0KXZWZdbRh3IliYgoH31ygkuVKLd3HrmsDIXYe+zN/nWLA6tw0
> O9NKI7THpe62be+Anarbvj9x3/78+rojqMl/oXpiNEKl/lOYuFKomtt+sA7NxNL0
> kg==
> -END CERTIFICATE-
> 
> 
> 
>> On Monday, 25 December 2017 12:17:36 UTC+2, Hanno Böck  wrote:
>> 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
>>> crt.sh yet
>> 
>> I'm not able to reproduce this. Right now if I install battle.net I
>> don't get a listening port on 22886 at all. Can you please export the
>> certificate and send it here?
>> 
>> 
>> -- 
>> Hanno Böck
>> https://clicktime.symantec.com/a/1/KJ0TLgnYKZG-ejHetbcPBoY5C8CMG9KRMt9YyMceby0=?d=fO2IqqaZwQxg4Bl6je7HihqX4BwX3heoNAZ6Ao3Bbh-ZpLB4qQgiU5CmyPuOD8NWCz9gv85sYbbcZ1l1t8R3UTKhyDW52L-jg9Vz2Hyl9vfOgHz_AA9HJQHNOcb2eZ4OhJR5fnPamqCiwKn8b1nV0pu3xM2zoa4Q0lb4ATr99pNs_wVygwgGJQ5eaO6zSL9wsXXNl9AatjLXtzFyGDgWy1yQd34gBaX4k_nzBA4nU0Pq4ZiA9h-VPA_zmRkR5eDje0sj16DMWt25rv6JF1kWlONq20bzzGc8lUw1WXoO26AHtVdjGzQYYW33-MOaaablM8Ka4yXt81k8DvnPhuS3CI36-dY5vwg5IbGzdLcur26YRYofF9jujrtV8NSkEPsUjS3VuwYXPwsZJk4NRq8350X8PFMC6Ij8P537O4KivC9qADjbjoJod8hYsDHq-yBH6OAoqtUk2sa-RFDa2jJL2iCOahUFGPrzI3nS7hUytgV8nLz-im2zgmlj8SugEWHP3uti6uJLAnqu5H4ncJhMQLvmYQ%3D%3D=https%3A%2F%2Fhboeck.de%2F
>> 
>> mail/jabber: ha...@hboeck.de
>> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/5e71ho7sLxNPxkirDsU3_VlvVsHU9OQ7rJ9O5JzCRNo=?d=fO2IqqaZwQxg4Bl6je7HihqX4BwX3heoNAZ6Ao3Bbh-ZpLB4qQgiU5CmyPuOD8NWCz9gv85sYbbcZ1l1t8R3UTKhyDW52L-jg9Vz2Hyl9vfOgHz_AA9HJQHNOcb2eZ4OhJR5fnPamqCiwKn8b1nV0pu3xM2zoa4Q0lb4ATr99pNs_wVygwgGJQ5eaO6zSL9wsXXNl9AatjLXtzFyGDgWy1yQd34gBaX4k_nzBA4nU0Pq4ZiA9h-VPA_zmRkR5eDje0sj16DMWt25rv6JF1kWlONq20bzzGc8lUw1WXoO26AHtVdjGzQYYW33-MOaaablM8Ka4yXt81k8DvnPhuS3CI36-dY5vwg5IbGzdLcur26YRYofF9jujrtV8NSkEPsUjS3VuwYXPwsZJk4NRq8350X8PFMC6Ij8P537O4KivC9qADjbjoJod8hYsDHq-yBH6OAoqtUk2sa-RFDa2jJL2iCOahUFGPrzI3nS7hUytgV8nLz-im2zgmlj8SugEWHP3uti6uJLAnqu5H4ncJhMQLvmYQ%3D%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Hanno Böck via dev-security-policy]

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 requirement for CT logging yet. 

Right now certs can end up in the CT log because:
1. the CA voluntarily submits them (LE does).
2. there's been a special situation that the CA needs to log certs
(e.g. this happened to Symantec after the first issues with them)
3. it's submitted by some third party. (everyone can do so.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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:
> 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Hanno Böck via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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 CERTIFICATE-
MIIFbTCCBFWgAwIBAgIQCn+uUpLudsH09lYYIPTK5DANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNzEyMTMwMDAwMDBaFw0xODEyMTgxMjAwMDBa
MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZJ
cnZpbmUxJTAjBgNVBAoTHEJsaXp6YXJkIEVudGVydGFpbm1lbnQsIEluYy4xGDAW
BgNVBAMTD2xvY2FsYmF0dGxlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAL7pCsdGFhOe0aTk/1zPuBhD+5dc4Lg6VMg+Y+HRfJv9nlLfFoDKS2dy
3cwPTW3NaQqNRhGug5ODBsoLUOI7heT4tiv91yQ+OlIFENsS1vWgba85ifIKt3pS
PG6kLc96nZ3JLpU4qjXOiF14/BECtNfBnIRsq60Vd/STWSNo84XrEvYBraTXT7Pg
kkU2DFeUcl9pvfcsLmtJ4tUk1E1euL7cqQxN5LRr+6hPyhN1rqB5SEaWoIaUd4OD
stR4H8RbxCXunIUS3o1O12cWAt4q4jDTay+8Bqy0sYGPvlLSOHMSrWHshpMGMVUL
Plh5pKpXQn78usEyTw4O3hDPFnHv4McCAwEAAaOCAf0wggH5MB8GA1UdIwQYMBaA
FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBTlPRA/nSH/T/W5QfGmpEwp
YI/YEzAvBgNVHREEKDAmgg9sb2NhbGJhdHRsZS5uZXSCE3d3dy5sb2NhbGJhdHRs
ZS5uZXQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20v
c2hhMi1oYS1zZXJ2ZXItZzYuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2Vy
dC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9
bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMw
CAYGZ4EMAQICMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAh0dHA6Ly9v
Y3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMuZGln
aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5jcnQw
DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAaAidMTizU/KDox3Rd/Ak
9u/iGbGjwssc9582FoRQVBdOxVkvxNWy/+9As/v6HUhZhWRBYOPMwvMSYBufNcdq
+zrEK8uJU4T0zI684pqzVsPwpFw3t9JzcdTZGScrD5//7fAkTql4YW9FGTyWz4ka
qXwt19R615xxFBGPt25jaB2vZHXrHl3v49GkntFpvlKLwhlidcrVg1F3px4di7c3
OR82PbAnjipHzg0KXZWZdbRh3IliYgoH31ygkuVKLd3HrmsDIXYe+zN/nWLA6tw0
O9NKI7THpe62be+Anarbvj9x3/78+rojqMl/oXpiNEKl/lOYuFKomtt+sA7NxNL0
kg==
-END CERTIFICATE-



On Monday, 25 December 2017 12:17:36 UTC+2, Hanno Böck  wrote:
> 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
> > crt.sh yet
> 
> I'm not able to reproduce this. Right now if I install battle.net I
> don't get a listening port on 22886 at all. Can you please export the
> certificate and send it here?
> 
> 
> -- 
> Hanno Böck
> https://hboeck.de/
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Hanno Böck via dev-security-policy]

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
> crt.sh yet

I'm not able to reproduce this. Right now if I install battle.net I
don't get a listening port on 22886 at all. Can you please export the
certificate and send it here?


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

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 
specified at https://www.digicert.com/certificate-revocation.htm


Adrian R.


> Bug Blizzard:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
> Cert Blizzard:
> https://crt.sh/?id=26142
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Adrian R. via dev-security-policy]

> 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 uses this certificate... which doesn't appear on crt.sh yet

https://crt.sh/?q=%25localbattle.net


Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0a:7f:ae:52:92:ee:76:c1:f4:f6:56:18:20:f4:ca:e4
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 
High Assurance Server CA
Validity
Not Before: Dec 13 00:00:00 2017 GMT
Not After : Dec 18 12:00:00 2018 GMT
Subject: C=US, ST=California, L=Irvine, O=Blizzard Entertainment, Inc., 
CN=localbattle.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:be:e9:0a:c7:46:16:13:9e:d1:a4:e4:ff:5c:cf:
b8:18:43:fb:97:5c:e0:b8:3a:54:c8:3e:63:e1:d1:
7c:9b:fd:9e:52:df:16:80:ca:4b:67:72:dd:cc:0f:
4d:6d:cd:69:0a:8d:46:11:ae:83:93:83:06:ca:0b:
50:e2:3b:85:e4:f8:b6:2b:fd:d7:24:3e:3a:52:05:
10:db:12:d6:f5:a0:6d:af:39:89:f2:0a:b7:7a:52:
3c:6e:a4:2d:cf:7a:9d:9d:c9:2e:95:38:aa:35:ce:
88:5d:78:fc:11:02:b4:d7:c1:9c:84:6c:ab:ad:15:
77:f4:93:59:23:68:f3:85:eb:12:f6:01:ad:a4:d7:
4f:b3:e0:92:45:36:0c:57:94:72:5f:69:bd:f7:2c:
2e:6b:49:e2:d5:24:d4:4d:5e:b8:be:dc:a9:0c:4d:
e4:b4:6b:fb:a8:4f:ca:13:75:ae:a0:79:48:46:96:
a0:86:94:77:83:83:b2:d4:78:1f:c4:5b:c4:25:ee:
9c:85:12:de:8d:4e:d7:67:16:02:de:2a:e2:30:d3:
6b:2f:bc:06:ac:b4:b1:81:8f:be:52:d2:38:73:12:
ad:61:ec:86:93:06:31:55:0b:3e:58:79:a4:aa:57:
42:7e:fc:ba:c1:32:4f:0e:0e:de:10:cf:16:71:ef:
e0:c7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier: 

keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B

X509v3 Subject Key Identifier: 
E5:3D:10:3F:9D:21:FF:4F:F5:B9:41:F1:A6:A4:4C:29:60:8F:D8:13
X509v3 Subject Alternative Name: 
DNS:localbattle.net, DNS:www.localbattle.net
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: 
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points: 

Full Name:
  URI:http://crl3.digicert.com/sha2-ha-server-g6.crl

Full Name:
  URI:http://crl4.digicert.com/sha2-ha-server-g6.crl

X509v3 Certificate Policies: 
Policy: 2.16.840.1.114412.1.1
  CPS: https://www.digicert.com/CPS
Policy: 2.23.140.1.2.2

Authority Information Access: 
OCSP - URI:http://ocsp.digicert.com
CA Issuers - 
URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: sha256WithRSAEncryption
 68:08:9d:31:38:b3:53:f2:83:a3:1d:d1:77:f0:24:f6:ef:e2:
 19:b1:a3:c2:cb:1c:f7:9f:36:16:84:50:54:17:4e:c5:59:2f:
 c4:d5:b2:ff:ef:40:b3:fb:fa:1d:48:59:85:64:41:60:e3:cc:
 c2:f3:12:60:1b:9f:35:c7:6a:fb:3a:c4:2b:cb:89:53:84:f4:
 cc:8e:bc:e2:9a:b3:56:c3:f0:a4:5c:37:b7:d2:73:71:d4:d9:
 19:27:2b:0f:9f:ff:ed:f0:24:4e:a9:78:61:6f:45:19:3c:96:
 cf:89:1a:a9:7c:2d:d7:d4:7a:d7:9c:71:14:11:8f:b7:6e:63:
 68:1d:af:64:75:eb:1e:5d:ef:e3:d1:a4:9e:d1:69:be:52:8b:
 c2:19:62:75:ca:d5:83:51:77:a7:1e:1d:8b:b7:37:39:1f:36:
 3d:b0:27:8e:2a:47:ce:0d:0a:5d:95:99:75:b4:61:dc:89:62:
 62:0a:07:df:5c:a0:92:e5:4a:2d:dd:c7:ae:6b:03:21:76:1e:
 fb:33:7f:9d:62:c0:ea:dc:34:3b:d3:4a:23:b4:c7:a5:ee:b6:
 6d:ef:80:9d:aa:db:be:3f:71:df:fe:fc:fa:ba:23:a8:c9:7f:
 a1:7a:62:34:42:a5:fe:53:98:b8:52:a8:9a:db:7e:b0:0e:cd:
 c4:d2:f4:92
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[andrew--- via dev-security-policy]

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 running in the
> background on one of a number of chosen TCP ports.  Usually it implements
> WebSockets.
> 
> When a user in a regular browser comes across an appropriate website, that
> website is able to cause the browser to load resources from the daemon on
> the localhost system.  They use this for things like determining whether
> the rich-client is installed and if so, what version.  Also for exercising
> simple control over the software on the PC.
> 
> These certs started being used because Chrome would not allow WSS
> connections on non-https.
> 
> It would be incredible if a page that loads from a URI not resolving to an
> IP endpoint on the local host were unable to load any sub-resources, any
> time, under any further conditions via connections to any IP endpoint on
> the local host.
> 
> That change to the browser will kill the use case that keeps causing
> software companies to get certificates like this.
> 
> It will also kill of a lot of use cases that should probably be killed.
> 
> For example, is there ever a legitimate reason that visiting a website
> should be able to quietly access services running on various TCP sockets on
> your PC?  (Yes, theoretically there are, but the risks seem to way outweigh
> the reward.)
> 
> On Thu, Dec 21, 2017 at 9:18 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Hi,
> >
> > Tavis Ormandy recently tweeted this:
> > https://twitter.com/taviso/status/938503794098180096
> >
> > What's happening here: The software battle.net by Blizzard has a domain
> > localbattle.net that points to localhost, allowing the software to
> > serve content there. The content is served via HTTPS with a valid cert,
> > making it obvious that the private key is part of the software.
> >
> > I talked to Tavis, reported the issue to the CA and to Mozilla's
> > bugtracker. I learned that there's a practically identical issue with
> > EAs origin.net software.
> > I also heard a claim that "everyone does this", however this seemed to
> > refer to examples from the past that are already known. I briefly
> > checked other gaming software (steam, uplay), but didn't find anything
> > alike. (Which doesn't mean it's not there - but I didn't see open
> > ports after running the software that were served with TLS.)
> >
> > Both certificates have been revoked. I don't have any detailed
> > information about what these local connections were used for, if they
> > changed anything and if anything broke due to the revocations, but I
> > haven't seen any reports of breakage (I checked twitter for signs of
> > it).
> > I also was not able to extract the private keys with simple methods
> > (grep), but it is almost certainly possible. (Full disclosure: Doing
> > anything on a Windows system is not my strength.)
> >
> > In any case: If you are aware of other software doing something alike
> > please report it. This is a key compromise.
> >
> > Bug EA:
> > https://bugzilla.mozilla.org/show_bug.cgi
> > Cert EA:
> > https://crt.sh/?id=54134792
> >
> > Bug Blizzard:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
> > Cert Blizzard:
> > https://crt.sh/?id=26142
> >
> > --
> > Hanno Böck
> > https://hboeck.de/
> >
> > mail/jabber: ha...@hboeck.de
> > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

>For example, is there ever a legitimate reason that visiting a website 
should be able to quietly access services running on various TCP sockets on 
your PC?

Yes, there is and isn't this entirely the point of CORS/RFC1918? Nonetheless, 
web applications that offer remote desktop capabilities are going to need to 
eventually access resources on a local network. 

It is possible to do this properly. Building a PKI around Lets Encrypt is 
exactly how we avoided contributing to this mess; the suggestion of breaking 
websockets and removing all ability to connect to local resources in the name 
of "security" is pretty backwards.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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 that isn't, there is no end to what various
software vendors will do to keep these use cases working.

(It saves them a whole server-side infrastructure for controlling the
software from a client's web browser.)



On Thu, Dec 21, 2017 at 4:04 PM, Andrew via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> For the record: Blizzard's response to these certs being revoked was to
> deploy a software update which installs their own root CA on their
> customer's computers: https://www.reddit.com/r/heroesofthestorm/comments/
> 7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

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
WebSockets.

When a user in a regular browser comes across an appropriate website, that
website is able to cause the browser to load resources from the daemon on
the localhost system.  They use this for things like determining whether
the rich-client is installed and if so, what version.  Also for exercising
simple control over the software on the PC.

These certs started being used because Chrome would not allow WSS
connections on non-https.

It would be incredible if a page that loads from a URI not resolving to an
IP endpoint on the local host were unable to load any sub-resources, any
time, under any further conditions via connections to any IP endpoint on
the local host.

That change to the browser will kill the use case that keeps causing
software companies to get certificates like this.

It will also kill of a lot of use cases that should probably be killed.

For example, is there ever a legitimate reason that visiting a website
should be able to quietly access services running on various TCP sockets on
your PC?  (Yes, theoretically there are, but the risks seem to way outweigh
the reward.)

On Thu, Dec 21, 2017 at 9:18 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> Tavis Ormandy recently tweeted this:
> https://twitter.com/taviso/status/938503794098180096
>
> What's happening here: The software battle.net by Blizzard has a domain
> localbattle.net that points to localhost, allowing the software to
> serve content there. The content is served via HTTPS with a valid cert,
> making it obvious that the private key is part of the software.
>
> I talked to Tavis, reported the issue to the CA and to Mozilla's
> bugtracker. I learned that there's a practically identical issue with
> EAs origin.net software.
> I also heard a claim that "everyone does this", however this seemed to
> refer to examples from the past that are already known. I briefly
> checked other gaming software (steam, uplay), but didn't find anything
> alike. (Which doesn't mean it's not there - but I didn't see open
> ports after running the software that were served with TLS.)
>
> Both certificates have been revoked. I don't have any detailed
> information about what these local connections were used for, if they
> changed anything and if anything broke due to the revocations, but I
> haven't seen any reports of breakage (I checked twitter for signs of
> it).
> I also was not able to extract the private keys with simple methods
> (grep), but it is almost certainly possible. (Full disclosure: Doing
> anything on a Windows system is not my strength.)
>
> In any case: If you are aware of other software doing something alike
> please report it. This is a key compromise.
>
> Bug EA:
> https://bugzilla.mozilla.org/show_bug.cgi
> Cert EA:
> https://crt.sh/?id=54134792
>
> Bug Blizzard:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
> Cert Blizzard:
> https://crt.sh/?id=26142
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Andrew via dev-security-policy]

For the record: Blizzard's response to these certs being revoked was to deploy 
a software update which installs their own root CA on their customer's 
computers: 
https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Hanno Böck via dev-security-policy]

Hi,

Tavis Ormandy recently tweeted this:
https://twitter.com/taviso/status/938503794098180096

What's happening here: The software battle.net by Blizzard has a domain
localbattle.net that points to localhost, allowing the software to
serve content there. The content is served via HTTPS with a valid cert,
making it obvious that the private key is part of the software.

I talked to Tavis, reported the issue to the CA and to Mozilla's
bugtracker. I learned that there's a practically identical issue with
EAs origin.net software.
I also heard a claim that "everyone does this", however this seemed to
refer to examples from the past that are already known. I briefly
checked other gaming software (steam, uplay), but didn't find anything
alike. (Which doesn't mean it's not there - but I didn't see open
ports after running the software that were served with TLS.)

Both certificates have been revoked. I don't have any detailed
information about what these local connections were used for, if they
changed anything and if anything broke due to the revocations, but I
haven't seen any reports of breakage (I checked twitter for signs of
it).
I also was not able to extract the private keys with simple methods
(grep), but it is almost certainly possible. (Full disclosure: Doing
anything on a Windows system is not my strength.)

In any case: If you are aware of other software doing something alike
please report it. This is a key compromise.

Bug EA:
https://bugzilla.mozilla.org/show_bug.cgi
Cert EA:
https://crt.sh/?id=54134792

Bug Blizzard:
https://bugzilla.mozilla.org/show_bug.cgi?id=1425166
Cert Blizzard:
https://crt.sh/?id=26142

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy