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