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

[Hanno Böck]

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=277776142

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

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

[Andrew]

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/

[Matthew Hardeman]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Matthew Hardeman]

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

[and...@rainway.io]

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.

[Adrian R.]

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

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

[Adrian R.]

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.

[Hanno Böck]

On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
"Adrian R. via dev-security-policy"

<dev-secur...@lists.mozilla.org> 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?

[Adrian R.]

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

[Hanno Böck]

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

[Adrian R.]

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?

[Hanno Böck]

On Mon, 25 Dec 2017 04:19:58 -0800 (PST)

"Adrian R. via dev-security-policy"
<dev-secur...@lists.mozilla.org> 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.)

[Jeremy Rowley]

Without the private key, im not sure how we're supposed to confirm key compromise.

>> On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
>> "Adrian R. via dev-security-policy"
>> <dev-secur...@lists.mozilla.org> 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&u=https%3A%2F%2Fhboeck.de%2F

>>
>> mail/jabber: ha...@hboeck.de
>> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Adrian R.]

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

[Jeremy Rowley]

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 <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> 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&u=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-secur...@lists.mozilla.org<mailto:dev-secur...@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&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Peter Bowen]

On Mon, Dec 25, 2017 at 7:10 AM, Adrian R. via dev-security-policy
<dev-secur...@lists.mozilla.org> 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

[Kurt Roeckx]

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


Kurt

[Hanno Böck]

On Mon, 25 Dec 2017 14:43:21 +0000
Jeremy Rowley via dev-security-policy

<dev-secur...@lists.mozilla.org> 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.)

[Adrian R.]

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.

[Matthew Hardeman]

On Monday, December 25, 2017 at 10:24:30 AM UTC-6, Hanno Böck wrote:
> On Mon, 25 Dec 2017 14:43:21 +0000
> Jeremy Rowley via dev-security-policy
> <dev-secur...@lists.mozilla.org> 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.

[Adrian R.]

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

[Adrian R.]

P.S. i assumed only a TLS context, but the same rule should probably apply for any connection, whether plaintext or SSL/TLS:

[Matthew Hardeman]

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

[Adrian R.]

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.

[Matthew Hardeman]

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-secur...@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,
> >
> > 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-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Jeremy Rowley]

I’m pretty sure EA revoked the cert.

> On Dec 25, 2017, at 9:23 AM, Hanno Böck <ha...@hboeck.de> wrote:
>
> On Mon, 25 Dec 2017 14:43:21 +0000
> Jeremy Rowley via dev-security-policy
> <dev-secur...@lists.mozilla.org> 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&u=https%3A%2F%2Fhboeck.de%2F
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Mark Steward]

On Mon, Dec 25, 2017 at 5:01 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@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 +0000
> > Jeremy Rowley via dev-security-policy
> > <dev-secur...@lists.mozilla.org> 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

[mkh...@gmail.com]

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

[Mark Steward]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Mark Steward]

On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@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

[Jeremy Rowley]

BTW - this certificate was revoked.