Private key corresponding to public key in trusted Cisco certificate embedded in executable

Hi all,

Last weekend, in an attempt to get Sky's NOW TV video player (for Mac) =
to work on my machine, I noticed that one of the Cisco executables =
contains a private key that is associated with the public key in a =
trusted certificate for a cisco.com <http://cisco.com/> sub domain =
(drmlocal.cisco.com <http://drmlocal.cisco.com/>). This certificate is =
used in a local WebSocket server, presumably to allow secure Sky/NOW TV =
origins to communicate with the video player on the users' local =
machines.

I read the Baseline Requirements document (version 1.4.5, section =
4.9.1.1), but I wasn't entirely sure whether this is considered a key =
compromise. I asked Hanno B=C3=B6ck on Twitter =
(https://twitter.com/koenrh/status/873869275529957376 =
<https://twitter.com/koenrh/status/873869275529957376>), and he advised =
me to post the matter to this mailing list.

The executable containing the private key is named =
'CiscoVideoGuardMonitor', and is shipped as part of the NOW TV video =
player. In case you are interested, the installer can be found at =
https://web.static.nowtv.com/watch/NowTVPlayerInstaller.pkg =
<https://web.static.nowtv.com/watch/NowTVPlayerInstaller.pkg> (SHA-256: =
56feeef4c3d141562900f9f0339b120d4db07ae2777cc73a31e3b830022241e6). I =
would recommend to run this installer in a virtual machine, because it =
drops files all over the place, and installs a few launch items =
(agents/daemons). The executable 'CiscoVideoGuardMonitor' can be found =
at =
'$HOME/Library/Cisco/VideoGuardPlayer/VideoGuardMonitor/VideoGuardMonitor.=
bundle/Contents/MacOS/CiscoVideoGuardMonitor'.

Certificate details:

Serial number: 66170CE2EC8B7D88B4E2EB732E738FE3A67CF672
DNS names: drmlocal.cisco.com <http://drmlocal.cisco.com/>
Issued by: HydrantID SSL ICA G2

Leaf certificate + HydrantID intermediate:
=
https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-certi=
ficates-pem =
<https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-cert=
ificates-pem>

As proof, I have published a verification message in a GitHub Gist, and =
signed the message using the compromised private key. See: =
https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-messa=
ge-txt =
<https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-mess=
age-txt> (verify using: 'openssl dgst -sha256 -verify public-key.pem =
-signature message.txt.sig message.txt')

If this is indeed considered a key compromise, where do I go from here, =
and what are the recommended steps to take? Do I need to contact the =
subscriber (Cisco), and ask them to send a revocation request for this =
certificate to the issuer? Or do I need to notify the issuer =
(HydrantID), and ask them to revoke this certificate?

Thanks.

Best regards,
Koen Rouwhorst


0
Koen
6/18/2017 9:17:42 AM
mozilla.dev.security.policy 1075 articles. 1 followers. Post Follow

25 Replies
31 Views

Similar Articles

[PageSpeed] 20

This is now on crt.sh here: https://crt.sh/?id=156475584&opt=cablint,x509lint

This is indeed a key compromise event, thanks for the level of detail provided.

An attacker in control of a network could use this to impersonate https://drmlocal.cisco.com/ and leverage that to potentially steal a user's secure cookies from other Cisco subdomains if they were scoped to the whole cisco.com domain.
0
Daniel
6/18/2017 10:29:24 AM
As Daniel noted, this is considered a key compromise event, and a violation
of the subscriber agreement that all CAs are required to adhere to, with
respect to the protection of the private key.

The issuing CA is obligated to revoke this certificate within 24 hours of
being made aware of this.

Thank you for bringing it to the community's attention.

On Sun, Jun 18, 2017 at 12:29 PM Daniel Cater via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is now on crt.sh here:
> https://crt.sh/?id=156475584&opt=cablint,x509lint
>
> This is indeed a key compromise event, thanks for the level of detail
> provided.
>
> An attacker in control of a network could use this to impersonate
> https://drmlocal.cisco.com/ and leverage that to potentially steal a
> user's secure cookies from other Cisco subdomains if they were scoped to
> the whole cisco.com domain.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
0
Ryan
6/18/2017 2:23:01 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen,

   The compromised certificate for drmlocal.cisco.com serial number 6170CE2=
EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked.  A new certificate is be=
ing reissued to drmlocal.cisco.com and we will work with the developers of =
the YES video  player to ensure that the issue does not happen again. =20

If you should find such an issue again in a Cisco owned domain, please repo=
rt it to psirt@cisco.com and we will ensure that prompt and proper actions =
are taken.

Regards,
- -Troy

- --=20
Troy Fridley, CISSP
Incident Manager, Cisco PSIRT
Phone: 614-336-4385
E-Mail: troy.fridleyATcisco.com
PGP Key ID: 0x7B31ED20
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAllGmSwACgkQ1ANYX3sx7SASCgCg/ABvJQZSZf+pIG16AMgMPwF8
z4oAnRrpx2I5NJizxg2H1aftlwyJ15fT
=3Dayil
-----END PGP SIGNATURE-----





On Sunday, June 18, 2017 at 5:18:23 AM UTC-4, Koen Rouwhorst wrote:

>=20
> If this is indeed considered a key compromise, where do I go from here, a=
nd what are the recommended steps to take? Do I need to contact the subscri=
ber (Cisco), and ask them to send a revocation request for this certificate=
 to the issuer? Or do I need to notify the issuer (HydrantID), and ask them=
 to revoke this certificate?
>=20
> Thanks.
>=20
> Best regards,
> Koen Rouwhorst

0
troy
6/18/2017 3:17:07 PM
One question though, is whether the key was compromised at the time of
intentionally shipping=E2=80=8B it in a distributed executable. That choice
knowingly exposed the key to arbitrary public users, even if they didn't
expect this to happen from doing so.

-- Eric

On Jun 18, 2017 10:24 AM, "Ryan Sleevi via dev-security-policy" <
dev-security-policy@lists.mozilla.org> wrote:

> As Daniel noted, this is considered a key compromise event, and a violati=
on
> of the subscriber agreement that all CAs are required to adhere to, with
> respect to the protection of the private key.
>
> The issuing CA is obligated to revoke this certificate within 24 hours of
> being made aware of this.
>
> Thank you for bringing it to the community's attention.
>
> On Sun, Jun 18, 2017 at 12:29 PM Daniel Cater via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This is now on crt.sh here:
> > https://crt.sh/?id=3D156475584&opt=3Dcablint,x509lint
> >
> > This is indeed a key compromise event, thanks for the level of detail
> > provided.
> >
> > An attacker in control of a network could use this to impersonate
> > https://drmlocal.cisco.com/ and leverage that to potentially steal a
> > user's secure cookies from other Cisco subdomains if they were scoped t=
o
> > the whole cisco.com domain.
> > _______________________________________________
> > 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
>
0
Eric
6/18/2017 3:36:31 PM
On Sunday, 18 June 2017 16:37:13 UTC+1, Eric Mill  wrote:
> One question though, is whether the key was compromised at the time of
> intentionally shipping=E2=80=8B it in a distributed executable. That choi=
ce
> knowingly exposed the key to arbitrary public users, even if they didn't
> expect this to happen from doing so.

Yes, the subscriber intentionally compromised this key when they implemente=
d this decision. This was a foreseeable consequence. If they didn't foresee=
 it, that's not because it wasn't foreseeable but because they're foolish. =
A reasonable person who understood what was going on here (public key crypt=
ography, the purpose of certificates in the Web PKI) should have understood=
 they were intentionally compromising their key.
0
Nick
6/18/2017 10:27:36 PM
On Monday, June 19, 2017 at 1:27:46 AM UTC+3, Nick Lamb wrote:
> On Sunday, 18 June 2017 16:37:13 UTC+1, Eric Mill  wrote:
> > One question though, is whether the key was compromised at the time of
> > intentionally shipping=E2=80=8B it in a distributed executable. That ch=
oice
> > knowingly exposed the key to arbitrary public users, even if they didn'=
t
> > expect this to happen from doing so.
>=20
> Yes, the subscriber intentionally compromised this key when they implemen=
ted this decision. This was a foreseeable consequence. If they didn't fores=
ee it, that's not because it wasn't foreseeable but because they're foolish=
.. A reasonable person who understood what was going on here (public key cry=
ptography, the purpose of certificates in the Web PKI) should have understo=
od they were intentionally compromising their key.

You assume too much about a "reasonable person".
Yes, most developers understand PKI / key management to a point, but many (=
many) just don't, or do and simply make the mistake of not thinking it thro=
ugh, like many other software defects. Bottom line - could happen unintenti=
onally.
0
qwerty123456
6/19/2017 8:16:41 AM
Section 9.6.3, Items 2, 4, and 5, of Baseline Requirements 1.4.5 (current
version)

On Sun, Jun 18, 2017 at 11:36 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> One question though, is whether the key was compromised at the time of
> intentionally shipping=E2=80=8B it in a distributed executable. That choi=
ce
> knowingly exposed the key to arbitrary public users, even if they didn't
> expect this to happen from doing so.
>
> -- Eric
>
> On Jun 18, 2017 10:24 AM, "Ryan Sleevi via dev-security-policy" <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > As Daniel noted, this is considered a key compromise event, and a
> violation
> > of the subscriber agreement that all CAs are required to adhere to, wit=
h
> > respect to the protection of the private key.
> >
> > The issuing CA is obligated to revoke this certificate within 24 hours =
of
> > being made aware of this.
> >
> > Thank you for bringing it to the community's attention.
> >
> > On Sun, Jun 18, 2017 at 12:29 PM Daniel Cater via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > This is now on crt.sh here:
> > > https://crt.sh/?id=3D156475584&opt=3Dcablint,x509lint
> > >
> > > This is indeed a key compromise event, thanks for the level of detail
> > > provided.
> > >
> > > An attacker in control of a network could use this to impersonate
> > > https://drmlocal.cisco.com/ and leverage that to potentially steal a
> > > user's secure cookies from other Cisco subdomains if they were scoped
> to
> > > the whole cisco.com domain.
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
0
Ryan
6/19/2017 9:56:06 AM
On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com  wrote:
>    The compromised certificate for drmlocal.cisco.com serial number 6170C=
E2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked.  A new certificate is =
being reissued to drmlocal.cisco.com and we will work with the developers o=
f the YES video player to ensure that the issue does not happen again. =20

Troy, the name makes me suspicious, what - other than this trick which isn'=
t a permissible use - was the drmlocal.cisco.com name ever for in the first=
 place? If it doesn't have any legitimate use, there was no purpose in seek=
ing a re-issue of the certificate.

The right way to approach this problem will be to issue unique keys and cer=
tificates to individual instances of the system, this both satisfies the BR=
s and (which is why) achieves the actual security goal of partitioning each=
 customer so that they can't MitM each other.

It is a little surprising to me that (at least so far as I know) no manufac=
turer has an arrangement with a CA to issue them large volumes of per-devic=
e certificates in this way. I expect that Comodo (to name one which definit=
ely has business issuing very large volumes) would be able to accommodate a=
 deal to issue say, a million certificates per year with an agreed suffix (=
say, .nowtv.cisco.com) for a fixed fee. The first time it's attempted there=
 would be some engineering work to be done in production and software for t=
he system, but nothing truly novel and that work is re-usable for future pr=
oducts.
0
Nick
6/19/2017 12:50:14 PM
TmljaywKICAgV2UgZG8gZXhhY3RseSB0aGF0IGZvciBzb21lIGRldmljZSBwcm9kdWNlcnMgYWxy
ZWFkeS4KClJvYmluIEFsZGVuLCBDb21vZG8uICAoU2VudCBmcm9tIG15IHBob25lKQoKLS0tLSBO
aWNrIExhbWIgdmlhIGRldi1zZWN1cml0eS1wb2xpY3kJIHdyb3RlIC0tLS0KCj5PbiBNb25kYXks
IDE5IEp1bmUgMjAxNyAwOTozMjoyMCBVVEMrMSwgdHJveS5mLi4uQGNpc2NvLmNvbSAgd3JvdGU6
Cj4+ICAgIFRoZSBjb21wcm9taXNlZCBjZXJ0aWZpY2F0ZSBmb3IgZHJtbG9jYWwuY2lzY28uY29t
IHNlcmlhbCBudW1iZXIgNjE3MENFMkVDOEI3RDg4QjRFMkVCNzMyRTczOEZFM0E2N0NGNjcyIGhh
cyBiZWVuIHJldm9rZWQuICBBIG5ldyBjZXJ0aWZpY2F0ZSBpcyBiZWluZyByZWlzc3VlZCB0byBk
cm1sb2NhbC5jaXNjby5jb20gYW5kIHdlIHdpbGwgd29yayB3aXRoIHRoZSBkZXZlbG9wZXJzIG9m
IHRoZSBZRVMgdmlkZW8gcGxheWVyIHRvIGVuc3VyZSB0aGF0IHRoZSBpc3N1ZSBkb2VzIG5vdCBo
YXBwZW4gYWdhaW4uICAKPgo+VHJveSwgdGhlIG5hbWUgbWFrZXMgbWUgc3VzcGljaW91cywgd2hh
dCAtIG90aGVyIHRoYW4gdGhpcyB0cmljayB3aGljaCBpc24ndCBhIHBlcm1pc3NpYmxlIHVzZSAt
IHdhcyB0aGUgZHJtbG9jYWwuY2lzY28uY29tIG5hbWUgZXZlciBmb3IgaW4gdGhlIGZpcnN0IHBs
YWNlPyBJZiBpdCBkb2Vzbid0IGhhdmUgYW55IGxlZ2l0aW1hdGUgdXNlLCB0aGVyZSB3YXMgbm8g
cHVycG9zZSBpbiBzZWVraW5nIGEgcmUtaXNzdWUgb2YgdGhlIGNlcnRpZmljYXRlLgo+Cj5UaGUg
cmlnaHQgd2F5IHRvIGFwcHJvYWNoIHRoaXMgcHJvYmxlbSB3aWxsIGJlIHRvIGlzc3VlIHVuaXF1
ZSBrZXlzIGFuZCBjZXJ0aWZpY2F0ZXMgdG8gaW5kaXZpZHVhbCBpbnN0YW5jZXMgb2YgdGhlIHN5
c3RlbSwgdGhpcyBib3RoIHNhdGlzZmllcyB0aGUgQlJzIGFuZCAod2hpY2ggaXMgd2h5KSBhY2hp
ZXZlcyB0aGUgYWN0dWFsIHNlY3VyaXR5IGdvYWwgb2YgcGFydGl0aW9uaW5nIGVhY2ggY3VzdG9t
ZXIgc28gdGhhdCB0aGV5IGNhbid0IE1pdE0gZWFjaCBvdGhlci4KPgo+SXQgaXMgYSBsaXR0bGUg
c3VycHJpc2luZyB0byBtZSB0aGF0IChhdCBsZWFzdCBzbyBmYXIgYXMgSSBrbm93KSBubyBtYW51
ZmFjdHVyZXIgaGFzIGFuIGFycmFuZ2VtZW50IHdpdGggYSBDQSB0byBpc3N1ZSB0aGVtIGxhcmdl
IHZvbHVtZXMgb2YgcGVyLWRldmljZSBjZXJ0aWZpY2F0ZXMgaW4gdGhpcyB3YXkuIEkgZXhwZWN0
IHRoYXQgQ29tb2RvICh0byBuYW1lIG9uZSB3aGljaCBkZWZpbml0ZWx5IGhhcyBidXNpbmVzcyBp
c3N1aW5nIHZlcnkgbGFyZ2Ugdm9sdW1lcykgd291bGQgYmUgYWJsZSB0byBhY2NvbW1vZGF0ZSBh
IGRlYWwgdG8gaXNzdWUgc2F5LCBhIG1pbGxpb24gY2VydGlmaWNhdGVzIHBlciB5ZWFyIHdpdGgg
YW4gYWdyZWVkIHN1ZmZpeCAoc2F5LCAubm93dHYuY2lzY28uY29tKSBmb3IgYSBmaXhlZCBmZWUu
IFRoZSBmaXJzdCB0aW1lIGl0J3MgYXR0ZW1wdGVkIHRoZXJlIHdvdWxkIGJlIHNvbWUgZW5naW5l
ZXJpbmcgd29yayB0byBiZSBkb25lIGluIHByb2R1Y3Rpb24gYW5kIHNvZnR3YXJlIGZvciB0aGUg
c3lzdGVtLCBidXQgbm90aGluZyB0cnVseSBub3ZlbCBhbmQgdGhhdCB3b3JrIGlzIHJlLXVzYWJs
ZSBmb3IgZnV0dXJlIHByb2R1Y3RzLgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPmRldi1zZWN1cml0eS1wb2xpY3kgbWFpbGluZyBsaXN0Cj5kZXYtc2Vj
dXJpdHktcG9saWN5QGxpc3RzLm1vemlsbGEub3JnCj5odHRwczovL2xpc3RzLm1vemlsbGEub3Jn
L2xpc3RpbmZvL2Rldi1zZWN1cml0eS1wb2xpY3kK
0
Robin
6/19/2017 1:02:05 PM
TmljaywKICAgV2UgZG8gZXhhY3RseSB0aGF0IGZvciBzb21lIGRldmljZSBwcm9kdWNlcnMgYWxy
ZWFkeS4KClJvYmluIEFsZGVuLCBDb21vZG8uICAoU2VudCBmcm9tIG15IHBob25lKQoKLS0tLSBO
aWNrIExhbWIgdmlhIGRldi1zZWN1cml0eS1wb2xpY3kJIHdyb3RlIC0tLS0KCj5PbiBNb25kYXks
IDE5IEp1bmUgMjAxNyAwOTozMjoyMCBVVEMrMSwgdHJveS5mLi4uQGNpc2NvLmNvbSAgd3JvdGU6
Cj4+ICAgIFRoZSBjb21wcm9taXNlZCBjZXJ0aWZpY2F0ZSBmb3IgZHJtbG9jYWwuY2lzY28uY29t
IHNlcmlhbCBudW1iZXIgNjE3MENFMkVDOEI3RDg4QjRFMkVCNzMyRTczOEZFM0E2N0NGNjcyIGhh
cyBiZWVuIHJldm9rZWQuICBBIG5ldyBjZXJ0aWZpY2F0ZSBpcyBiZWluZyByZWlzc3VlZCB0byBk
cm1sb2NhbC5jaXNjby5jb20gYW5kIHdlIHdpbGwgd29yayB3aXRoIHRoZSBkZXZlbG9wZXJzIG9m
IHRoZSBZRVMgdmlkZW8gcGxheWVyIHRvIGVuc3VyZSB0aGF0IHRoZSBpc3N1ZSBkb2VzIG5vdCBo
YXBwZW4gYWdhaW4uICAKPgo+VHJveSwgdGhlIG5hbWUgbWFrZXMgbWUgc3VzcGljaW91cywgd2hh
dCAtIG90aGVyIHRoYW4gdGhpcyB0cmljayB3aGljaCBpc24ndCBhIHBlcm1pc3NpYmxlIHVzZSAt
IHdhcyB0aGUgZHJtbG9jYWwuY2lzY28uY29tIG5hbWUgZXZlciBmb3IgaW4gdGhlIGZpcnN0IHBs
YWNlPyBJZiBpdCBkb2Vzbid0IGhhdmUgYW55IGxlZ2l0aW1hdGUgdXNlLCB0aGVyZSB3YXMgbm8g
cHVycG9zZSBpbiBzZWVraW5nIGEgcmUtaXNzdWUgb2YgdGhlIGNlcnRpZmljYXRlLgo+Cj5UaGUg
cmlnaHQgd2F5IHRvIGFwcHJvYWNoIHRoaXMgcHJvYmxlbSB3aWxsIGJlIHRvIGlzc3VlIHVuaXF1
ZSBrZXlzIGFuZCBjZXJ0aWZpY2F0ZXMgdG8gaW5kaXZpZHVhbCBpbnN0YW5jZXMgb2YgdGhlIHN5
c3RlbSwgdGhpcyBib3RoIHNhdGlzZmllcyB0aGUgQlJzIGFuZCAod2hpY2ggaXMgd2h5KSBhY2hp
ZXZlcyB0aGUgYWN0dWFsIHNlY3VyaXR5IGdvYWwgb2YgcGFydGl0aW9uaW5nIGVhY2ggY3VzdG9t
ZXIgc28gdGhhdCB0aGV5IGNhbid0IE1pdE0gZWFjaCBvdGhlci4KPgo+SXQgaXMgYSBsaXR0bGUg
c3VycHJpc2luZyB0byBtZSB0aGF0IChhdCBsZWFzdCBzbyBmYXIgYXMgSSBrbm93KSBubyBtYW51
ZmFjdHVyZXIgaGFzIGFuIGFycmFuZ2VtZW50IHdpdGggYSBDQSB0byBpc3N1ZSB0aGVtIGxhcmdl
IHZvbHVtZXMgb2YgcGVyLWRldmljZSBjZXJ0aWZpY2F0ZXMgaW4gdGhpcyB3YXkuIEkgZXhwZWN0
IHRoYXQgQ29tb2RvICh0byBuYW1lIG9uZSB3aGljaCBkZWZpbml0ZWx5IGhhcyBidXNpbmVzcyBp
c3N1aW5nIHZlcnkgbGFyZ2Ugdm9sdW1lcykgd291bGQgYmUgYWJsZSB0byBhY2NvbW1vZGF0ZSBh
IGRlYWwgdG8gaXNzdWUgc2F5LCBhIG1pbGxpb24gY2VydGlmaWNhdGVzIHBlciB5ZWFyIHdpdGgg
YW4gYWdyZWVkIHN1ZmZpeCAoc2F5LCAubm93dHYuY2lzY28uY29tKSBmb3IgYSBmaXhlZCBmZWUu
IFRoZSBmaXJzdCB0aW1lIGl0J3MgYXR0ZW1wdGVkIHRoZXJlIHdvdWxkIGJlIHNvbWUgZW5naW5l
ZXJpbmcgd29yayB0byBiZSBkb25lIGluIHByb2R1Y3Rpb24gYW5kIHNvZnR3YXJlIGZvciB0aGUg
c3lzdGVtLCBidXQgbm90aGluZyB0cnVseSBub3ZlbCBhbmQgdGhhdCB3b3JrIGlzIHJlLXVzYWJs
ZSBmb3IgZnV0dXJlIHByb2R1Y3RzLgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPmRldi1zZWN1cml0eS1wb2xpY3kgbWFpbGluZyBsaXN0Cj5kZXYtc2Vj
dXJpdHktcG9saWN5QGxpc3RzLm1vemlsbGEub3JnCj5odHRwczovL2xpc3RzLm1vemlsbGEub3Jn
L2xpc3RpbmZvL2Rldi1zZWN1cml0eS1wb2xpY3kK
0
Robin
6/19/2017 1:02:05 PM
There's more than just a clue in the name drmlocal.cisco.com , if one
looks up this address in the DNS it returns the loopback IP 127.0.0.1
.. http://dnstools.ws/tools/lookup.php?host=3Ddrmlocal.cisco.com&type=3DA
This can only mean that this address is fully intended to be referred
to only by one's own machine that the NowTV software is running on.
There's probably an architectural reason why a publicly trusted
certificate is used. But the way it's been implemented clearly does
mean that the private key ends up being shipped, which, even if it
didn't break the Baseline Requirements, it goes against the very
principle of PKI cryptography. Therefore the newly re-issued
certificate *will* end up with it's private key compromised *again*,
no matter how well it may be obfuscated in the application, it is
still against the very principle.
Is a publicly-trusted certificate even needed here? Another this could
have been done is what anti-virus programs often resort to doing:
installing a self-signed root into the OS (and other browser stores)
as part of the client installation process and generating certificates
on-the-fly directly off of it. But then that would mean that if anyone
compromised the key for that, it could potentially put many users whom
use NowTV at risk unless that self-signed root was constrained in some
way. *However* this would mean at least, it no longer breaks the
Baseline Requirements as it would no longer be within it's scope. I'm
no expert here at all, and I do dislike the idea of this kind of
behaviour completely (and I could be completely wrong about why
drmlocal.cisco.com is used). NowTV might want to consider their
options here, but shipping a private key and trusted certificate with
an application, really isn't the way. In summary: I believe a
compromise will happen again as it is clear drmlocal.cisco.com is
deliberately intended to refer to one's own machine.
Sam


On Mon, Jun 19, 2017 at 1:50 PM, Nick Lamb via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com  wrote:
>>    The compromised certificate for drmlocal.cisco.com serial number 6170=
CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked.  A new certificate is=
 being reissued to drmlocal.cisco.com and we will work with the developers =
of the YES video player to ensure that the issue does not happen again.
>
> Troy, the name makes me suspicious, what - other than this trick which is=
n't a permissible use - was the drmlocal.cisco.com name ever for in the fir=
st place? If it doesn't have any legitimate use, there was no purpose in se=
eking a re-issue of the certificate.
>
> The right way to approach this problem will be to issue unique keys and c=
ertificates to individual instances of the system, this both satisfies the =
BRs and (which is why) achieves the actual security goal of partitioning ea=
ch customer so that they can't MitM each other.
>
> It is a little surprising to me that (at least so far as I know) no manuf=
acturer has an arrangement with a CA to issue them large volumes of per-dev=
ice certificates in this way. I expect that Comodo (to name one which defin=
itely has business issuing very large volumes) would be able to accommodate=
 a deal to issue say, a million certificates per year with an agreed suffix=
 (say, .nowtv.cisco.com) for a fixed fee. The first time it's attempted the=
re would be some engineering work to be done in production and software for=
 the system, but nothing truly novel and that work is re-usable for future =
products.
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
0
Samuel
6/19/2017 1:28:12 PM
I wonder if the device intercepts DNS queries within the LAN for that addre=
ss and substitutes in the IP of the appliance instead of 127.0.0.1.  Is it =
often deployed as the customer premise NAT/router in addition to serving vi=
deo purposes?

I'm thinking they probably wanted some other devices or browsers on the loc=
al LAN to access, via https, the appliance on the LAN.  And they wanted it =
to have a trusted cert for that purpose.  They just didn't want to have to =
deal with unique name and cert per device.

Which, as has been pointed out repeatedly is a violation of the CA <-> subs=
criber agreement, because the baselines require that the CA <-> subscriber =
agreement forbid this.

It looks to me like someone wanted to avoid the need to have a unique certi=
ficate issued for each device.

The easy way forward would be for them to create a new domain, run their ow=
n dynamic DNS service for each device on that domain (get said domain on th=
e PSL) and develop software for it to fetch and update valid certificates f=
or these IoT devices.  Presumably they could roll their own DNS infrastruct=
ure and even use something like Let's Encrypt, though I'm not certain wheth=
er Let's Encrypt is on the record as to what they'd think of such a use cas=
e.

In as far as Cisco has requested a new drmlocal.cisco.com certificate.... W=
hy?  They can't use it the new certificate in the same way again (or it wou=
ld just get revoked again) and the real drmlocal.cisco.com record points to=
 127.0.0.1, so it's not like they have a real central drmlocal.cisco.com si=
te that needs a certificate.  I think the "local" part of the name is proba=
bly most telling.  They likely came up with that name because ciscodrm.loca=
l would have been impossible to get a valid cert for.


Matt Hardeman
0
Matthew
6/19/2017 8:49:56 PM
On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-security-policy wrote:
> If you should find such an issue again in a Cisco owned domain, please
> report it to psirt@cisco.com and we will ensure that prompt and proper
> actions are taken.

I don't know, this way seems to have worked Just Fine.

- Matt

0
Matt
6/19/2017 11:36:37 PM
On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> Therefore the newly re-issued
> certificate *will* end up with it's private key compromised *again*,
> no matter how well it may be obfuscated in the application, it is
> still against the very principle.

I'm pretty confused by this as well.

First off, while people have proposed multiple solutions to this
problem, they are not trivially implementable, nor are they
widespread. I think if you shook the tree with some automation, you'd
find on the order of 50 or more publicly trustable private keys
embedded in firmware pretty quickly.

So at what point does the CA become culpable to misissuance in a case
like this? Is it okay that we let them turn a blind eye to issuing or
reissuing certificates where they have a strong reason to believe the
private key will be published in firmware?

Clearly we wouldn't require them to vet every use of every certificate
they issue, but if they revoke a certificate for being used in this
fashion, it seems reasonable for them to ask the customer to at least
give them an explanation of how they've changed things such that a
newly issue certificate for the same domain will not be used in the
exact same way.

Is it reasonable for us to ask a CA to do this (that is, to ask their
customer)? Is it reasonable to require it?

-tom
0
Tom
6/20/2017 4:39:51 AM
On Monday, June 19, 2017 at 11:40:22 PM UTC-5, Tom Ritter wrote:
> So at what point does the CA become culpable to misissuance in a case
> like this? Is it okay that we let them turn a blind eye to issuing or
> reissuing certificates where they have a strong reason to believe the
> private key will be published in firmware?

Pretty much any DV validated certificate could be used the way Cisco's soft=
ware used this one...  Unless we want to create new burdens for every DV va=
lidating CA out there, I don't think it's practical to pre-suppose that a s=
imilar certificate will get similar misuse.

The right balance is probably revoking when misuse is shown.
0
Matthew
6/20/2017 4:49:56 AM
On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman  wrote:
> The right balance is probably revoking when misuse is shown.

Plus education. Robin has stated that there _are_ suitable CA products for =
this use case in existence today, but if I didn't know it stands to reason =
that at least some of the engineers at Cisco didn't know either.

Knowing what the Right Thing is makes it easier to push back when somebody =
proposes (as they clearly did here) the Wrong Thing. If, at the end of the =
day, Cisco management signs off on the additional risk from doing the Wrong=
 Thing because it's cheaper, or faster, or whatever, that's on them. But if=
 nobody in their engineering teams is even aware of the alternative it beco=
mes a certainty.
0
Nick
6/20/2017 9:43:28 AM
On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-security-policy wrote:
> > If you should find such an issue again in a Cisco owned domain, please
> > report it to psirt@cisco.com and we will ensure that prompt and proper
> > actions are taken.
> 
> I don't know, this way seems to have worked Just Fine.
> 
> - Matt

Does no-one else see the lack of responsible disclosure in this thread distressing?

Yes, the cert was revoked, and for all you know during the race that was this public disclosure there could have been compromise. There are APT actors watching this thread right now looking for opportunities.

This could have been reported to the vendor, or if you are not happy with Cisco's security response, to the CA first. 24 hours is not too long to keep this under hat.

Instead -- this was posted to a public forum giving many thousands of people the opportunity to chain a vector attack against Cisco CCO IDs (which in some cases might lead to customer network compromise).

If our community does not work to encourage more responsible disclosures the governments will do it for us, and it won't be nice.

"Remember the Wassenaar"

Matt

Matthew Fisch, CISSP
mfisch@fortmesa.com
0
mfisch
6/20/2017 2:36:14 PM
On 6/20/17, mfisch--- via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
>> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via
>> dev-security-policy wrote:
>> > If you should find such an issue again in a Cisco owned domain, please
>> > report it to psirt@cisco.com and we will ensure that prompt and proper
>> > actions are taken.
>>
>> I don't know, this way seems to have worked Just Fine.
>>
>> - Matt
>
> Does no-one else see the lack of responsible disclosure in this thread
> distressing?

Nope.  The first requirement for "responsible disclosure" is knowing
you're disclosing something.  Take a look at the original msg:
-- I wasn't entirely sure whether this is considered a key compromise. I as=
ked
-- Hanno B=C3=B6ck on Twitter (https://twitter.com/koenrh/status/8738692755=
29957376
-- <https://twitter.com/koenrh/status/873869275529957376>), and he advised =
me to
-- post the matter to this mailing list.
     <.. snip ..>
-- If this is indeed considered a key compromise, where do I go from
here, and what
-- are the recommended steps to take?

If you want to argue that I should have replied with something about
sending the info to psirt@cisco.com instead of just forwarding the 1st
two messages in the thread to them.. yeah, maybe I should have done it
that way.

> Instead -- this was posted to a public forum giving many thousands of peo=
ple
> the opportunity to chain a vector attack against Cisco CCO IDs (which in
> some cases might lead to customer network compromise).

I'm curious - how does one use a cert for drmlocal.cisco.com to chain
a vector attack against Cisco CCO IDs?

Regards,
Lee
0
Lee
6/20/2017 4:51:52 PM
On Tuesday, June 20, 2017 at 12:52:02 PM UTC-4, Lee wrote:
> On 6/20/17, mfisch--- via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
> >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via
> >> dev-security-policy wrote:
> >> > If you should find such an issue again in a Cisco owned domain, plea=
se
> >> > report it to psirt@cisco.com and we will ensure that prompt and prop=
er
> >> > actions are taken.
> >>
> >> I don't know, this way seems to have worked Just Fine.
> >>
> >> - Matt
> >
> > Does no-one else see the lack of responsible disclosure in this thread
> > distressing?
>=20
> Nope.  The first requirement for "responsible disclosure" is knowing
> you're disclosing something.  Take a look at the original msg:
> -- I wasn't entirely sure whether this is considered a key compromise. I =
asked
> -- Hanno B=C3=B6ck on Twitter (https://twitter.com/koenrh/status/87386927=
5529957376
> -- <https://twitter.com/koenrh/status/873869275529957376>), and he advise=
d me to
> -- post the matter to this mailing list.
>      <.. snip ..>
> -- If this is indeed considered a key compromise, where do I go from
> here, and what
> -- are the recommended steps to take?
>=20
> If you want to argue that I should have replied with something about
> sending the info to psirt@cisco.com instead of just forwarding the 1st
> two messages in the thread to them.. yeah, maybe I should have done it
> that way.
>=20
> > Instead -- this was posted to a public forum giving many thousands of p=
eople
> > the opportunity to chain a vector attack against Cisco CCO IDs (which i=
n
> > some cases might lead to customer network compromise).
>=20
> I'm curious - how does one use a cert for drmlocal.cisco.com to chain
> a vector attack against Cisco CCO IDs?
>=20
> Regards,
> Lee

I think his complaint was in the fact that you laid out every single detail=
 while simultaneously asking what you should do. I think you could have don=
e without the vast detail and kept it very generic until you figured out wh=
o to contact, then let the vendors fix it.=20

Moral of the story, if you have to ask if it's a disclosure, you are better=
 safe than sorry and keeping the info under close wraps until you confirm i=
t.
0
reisinger
6/20/2017 5:18:58 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick,

  I misspoke in my reply.  The certificate has been revoked and it has not =
been re-issued.  We have filed a post-stopping defect (Cisco Bug ID CSCve90=
409) against the product to ensure that the issue is not re-introduced.

The certificate in question was never used to transfer customer or service =
provider information over a public network.  The engineering team utilized =
the cert to protect an IPC channel between a users browser and a background=
 process running on the host.

Rest assured that if the Cisco PSIRT or Cisco PKI teams had known that the =
certificate would be exposed in this manner we would have prevented it.  We=
 have folks working with the responsible engineers to insure they understan=
d the implications of their previous design.

Regards,
- -Troy
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAllJYz4ACgkQ1ANYX3sx7SAkVgCeLwuYBx2LceI/SFU+kcSUFtHB
JysAoPm5UtGh+5gzzi/4Gzfdgj2UcGcL
=3DYznP
-----END PGP SIGNATURE-----


On Monday, June 19, 2017 at 8:50:24 AM UTC-4, Nick Lamb wrote:
> On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com  wrote:
> >    The compromised certificate for drmlocal.cisco.com serial number 617=
0CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked.  A new certificate i=
s being reissued to drmlocal.cisco.com and we will work with the developers=
 of the YES video player to ensure that the issue does not happen again. =
=20
>=20
> Troy, the name makes me suspicious, what - other than this trick which is=
n't a permissible use - was the drmlocal.cisco.com name ever for in the fir=
st place? If it doesn't have any legitimate use, there was no purpose in se=
eking a re-issue of the certificate.
>=20
> The right way to approach this problem will be to issue unique keys and c=
ertificates to individual instances of the system, this both satisfies the =
BRs and (which is why) achieves the actual security goal of partitioning ea=
ch customer so that they can't MitM each other.
>=20
> It is a little surprising to me that (at least so far as I know) no manuf=
acturer has an arrangement with a CA to issue them large volumes of per-dev=
ice certificates in this way. I expect that Comodo (to name one which defin=
itely has business issuing very large volumes) would be able to accommodate=
 a deal to issue say, a million certificates per year with an agreed suffix=
 (say, .nowtv.cisco.com) for a fixed fee. The first time it's attempted the=
re would be some engineering work to be done in production and software for=
 the system, but nothing truly novel and that work is re-usable for future =
products.

0
troy
6/20/2017 6:03:19 PM
> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy =
<dev-security-policy@lists.mozilla.org> wrote:
>=20
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
>> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via =
dev-security-policy wrote:
>>> If you should find such an issue again in a Cisco owned domain, =
please
>>> report it to psirt@cisco.com and we will ensure that prompt and =
proper
>>> actions are taken.
>>=20
>> I don't know, this way seems to have worked Just Fine.
>>=20
>> - Matt
>=20
> Does no-one else see the lack of responsible disclosure in this thread =
distressing?
>=20
> Yes, the cert was revoked, and for all you know during the race that =
was this public disclosure there could have been compromise. There are =
APT actors watching this thread right now looking for opportunities.

The disclosure looks responsible to me.

The domain resolves to 127.0.0.1, which means that the private key can =
only be effectively leveraged by a privileged attacker that can forge =
DNS responses. An attacker that can do this can almost certainly also =
block online OCSP/CRL checks, preventing the revocation from being seen =
by clients. In general, revocation will not have any meaningful impact =
against misuse unless the certificate is included in OneCRL/CRLSets (for =
Firefox/Chrome).

Jonathan=
0
Jonathan
6/20/2017 6:05:21 PM
On Tuesday, June 20, 2017 at 2:06:00 PM UTC-4, Jonathan Rudenberg wrote:
> > On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy <dev-secur=
ity-policy@lists.mozilla.org> wrote:
> >=20
> > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
> >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-secu=
rity-policy wrote:
> >>> If you should find such an issue again in a Cisco owned domain, pleas=
e
> >>> report it to psirt@cisco.com and we will ensure that prompt and prope=
r
> >>> actions are taken.
> >>=20
> >> I don't know, this way seems to have worked Just Fine.
> >>=20
> >> - Matt
> >=20
> > Does no-one else see the lack of responsible disclosure in this thread =
distressing?
> >=20
> > Yes, the cert was revoked, and for all you know during the race that wa=
s this public disclosure there could have been compromise. There are APT ac=
tors watching this thread right now looking for opportunities.
>=20
> The disclosure looks responsible to me.
>=20
> The domain resolves to 127.0.0.1, which means that the private key can on=
ly be effectively leveraged by a privileged attacker that can forge DNS res=
ponses. An attacker that can do this can almost certainly also block online=
 OCSP/CRL checks, preventing the revocation from being seen by clients. In =
general, revocation will not have any meaningful impact against misuse unle=
ss the certificate is included in OneCRL/CRLSets (for Firefox/Chrome).
>=20
> Jonathan

Koen,
  Cheers on the find and thanks for your contribution.

Jonathan,

  Is your argument that TLS checking on session key disclosure is not neces=
sary because man in the middle is game over?

  You're right there are only very limited ways this sort of thing can be u=
sed (and maybe it can't be used at all). But it would be difficult to argue=
 effectively that:

a) It can't be used under specific circumstances to weaken security and pos=
sibly combine with other attacks.

b) That someone who recognized this for what it was did not reasonably beli=
eve it _shouldn't_ be public knowledge.

c) I acknowledge your point about the effectiveness of revocation.

My issue is not in fact with the disclosure at all, but the fact that noone=
 else on this thread pointed out that it is not the ideal disclosure method=
ology (at least in order of events). It's now been said.

Both Cisco and the CA maintain infosec incident handling teams that are pai=
d specifically to handle these situations. Yes its true corporate infosec f=
ails a lot too, but a head start is ethical.

The culture of our industry needs to think hard about the power it wields s=
o it is not taken from us and wrapped up in ineffective and burdensome stat=
e oversight.
0
mfisch
6/20/2017 6:27:00 PM
On Tuesday, June 20, 2017 at 2:27:10 PM UTC-4, mfi...@fortmesa.com wrote:
> On Tuesday, June 20, 2017 at 2:06:00 PM UTC-4, Jonathan Rudenberg wrote:
> > > On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy <dev-sec=
urity-policy@lists.mozilla.org> wrote:
> > >=20
> > > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:
> > >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-se=
curity-policy wrote:
> > >>> If you should find such an issue again in a Cisco owned domain, ple=
ase
> > >>> report it to psirt@cisco.com and we will ensure that prompt and pro=
per
> > >>> actions are taken.
> > >>=20
> > >> I don't know, this way seems to have worked Just Fine.
> > >>=20
> > >> - Matt
> > >=20
> > > Does no-one else see the lack of responsible disclosure in this threa=
d distressing?
> > >=20
> > > Yes, the cert was revoked, and for all you know during the race that =
was this public disclosure there could have been compromise. There are APT =
actors watching this thread right now looking for opportunities.
> >=20
> > The disclosure looks responsible to me.
> >=20
> > The domain resolves to 127.0.0.1, which means that the private key can =
only be effectively leveraged by a privileged attacker that can forge DNS r=
esponses. An attacker that can do this can almost certainly also block onli=
ne OCSP/CRL checks, preventing the revocation from being seen by clients. I=
n general, revocation will not have any meaningful impact against misuse un=
less the certificate is included in OneCRL/CRLSets (for Firefox/Chrome).
> >=20
> > Jonathan
>=20
> Koen,
>   Cheers on the find and thanks for your contribution.
>=20
> Jonathan,
>=20
>   Is your argument that TLS checking on session key disclosure is not nec=
essary because man in the middle is game over?
>=20
>   You're right there are only very limited ways this sort of thing can be=
 used (and maybe it can't be used at all). But it would be difficult to arg=
ue effectively that:
>=20
> a) It can't be used under specific circumstances to weaken security and p=
ossibly combine with other attacks.
>=20
> b) That someone who recognized this for what it was did not reasonably be=
lieve it _shouldn't_ be public knowledge.
>=20
> c) I acknowledge your point about the effectiveness of revocation.
>=20
> My issue is not in fact with the disclosure at all, but the fact that noo=
ne else on this thread pointed out that it is not the ideal disclosure meth=
odology (at least in order of events). It's now been said.
>=20
> Both Cisco and the CA maintain infosec incident handling teams that are p=
aid specifically to handle these situations. Yes its true corporate infosec=
 fails a lot too, but a head start is ethical.
>=20
> The culture of our industry needs to think hard about the power it wields=
 so it is not taken from us and wrapped up in ineffective and burdensome st=
ate oversight.

ps, it was noted previously that if other cisco properties are a bit free w=
heeling with their cookie security it would be possible to leak.
0
mfisch
6/20/2017 6:28:22 PM
> Moral of the story, if you have to ask if it's a disclosure, you are bett=
er safe than sorry and keeping the info under close wraps until you confirm=
 it.

I think it's better it was disclosed than had it not been disclosed at all.=
=20

While I agree to an extent that there could have been more optimal ways for=
 the disclosure in this particular case, I think we should not try to disen=
courage disclosure. If someone spots something and and asks a very generic =
question, I'm like 99% sure folks will tell him to be more detailed else th=
ey can't have an opinion. (Which basically is what he did, he asked one per=
son a generic question and that person told him to ask it here, I guess it'=
s reasonable that he was more detailed when doing so.) Now, if we tell peop=
le who spotted something AND did some additional research on it, which is I=
MHO commendable, that they better shouldn't have disclosed anything before =
checking with so-and-so and waited such-and-such an amount of time (which t=
hey might be aware of, or not), the next such person will likely just think=
, oh, sod it, maybe it's not so important anyway. (It's not like this was a=
 complicated 0-day where the itsec engineer who found it would already have=
 known exactly who to contact in advance.) Blaming the person who disclosed=
 it is not helpful I think.=20
0
randomsyseng
6/20/2017 7:51:41 PM
That's a good point.
0
reisinger
6/27/2017 8:03:28 PM
Reply: