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

[Jakob Bohm via dev-security-policy]

On 25/07/2017 14:58, simon.wat...@surevine.com wrote:

On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb  wrote:

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 becomes a certainty.


I'm aware of another instance of this pattern in widely deployed software, 
discovered through security testing 3rd party applications (Thanks to Hanno 
discussing related issue on twitter).

The pattern "Using a certificate with DNS resolving to 127.0.0.1 to allow a browser 
page to communicate with a local web server".

Although it was done in an insecure fashion (not yet fully resolved, so 
disclosure would be unhelpful), I don't see a good alternative model for this 
vendor's use case.

I also looked when I first found the encrypted P12 file (and password hardcoded 
into the application), and found nothing useful online discussing this pattern, 
or alternatives.

I only found that you could no longer register certificates for 127.0.0.1 (the 
world only needs one such).

The mass issuance of certificates described above doesn't seem any better, 
since there still needs to be a trust relationship with an unprotected 
appliance or application. Or is there some aspect of the certificates issuance 
that bind them to a particular implementation (I thought all such binding were 
basically broken in most TLS implementations).

What is the recommended practice here?



In general: Do not conflate an outside address (such as the domain of
the vendors online service) with anything local (like 127.0.0.1 or the
actual IP of some local IoT device).  That is a gross violation of one
of the most fundamental security barriers (mine vs. yours).

The fundamental question is: What do they want to access locally, and
why should a remote web domain get any access to it?

From there logic solutions can be built that don't compromise the
browser security model and don't involve sharing secret keys with
strangers.

One common solution discussed by others in this thread is to serve
everything within the trust barrier from a localhost http server and
relying on browsers trusting explicit localhost http connections more
than remote http connections.

Another similar solution is to use a self-signed random per installation
localhost certificate generated on first run, then server everything
from a local https server.

For some cases, even simpler solutions such as using file:// URLs or
file upload form fields is appropriate.

Whatever is done, within the browser any data sharing between local and
remote needs to be treated as cross-site data sharing with all
associated security restrictions and concerns.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[simon.waters--- via dev-security-policy]

On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb  wrote:
> 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 becomes 
> a certainty.

I'm aware of another instance of this pattern in widely deployed software, 
discovered through security testing 3rd party applications (Thanks to Hanno 
discussing related issue on twitter).

The pattern "Using a certificate with DNS resolving to 127.0.0.1 to allow a 
browser page to communicate with a local web server".

Although it was done in an insecure fashion (not yet fully resolved, so 
disclosure would be unhelpful), I don't see a good alternative model for this 
vendor's use case.

I also looked when I first found the encrypted P12 file (and password hardcoded 
into the application), and found nothing useful online discussing this pattern, 
or alternatives. 

I only found that you could no longer register certificates for 127.0.0.1 (the 
world only needs one such).

The mass issuance of certificates described above doesn't seem any better, 
since there still needs to be a trust relationship with an unprotected 
appliance or application. Or is there some aspect of the certificates issuance 
that bind them to a particular implementation (I thought all such binding were 
basically broken in most TLS implementations).

What is the recommended practice here?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[reisinger.nate--- via dev-security-policy]

That's a good point.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[randomsyseng--- via dev-security-policy]

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

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

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 disencourage 
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 they can't have 
an opinion. (Which basically is what he did, he asked one person 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 people who spotted 
something AND did some additional research on it, which is IMHO 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 they 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. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[reisinger.nate--- via dev-security-policy]

On Tuesday, June 20, 2017 at 12:52:02 PM UTC-4, Lee wrote:
> On 6/20/17, mfisch--- via dev-security-policy
>  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 ps...@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 asked
> -- Hanno Böck on Twitter (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 ps...@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 people
> > 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

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 done 
without the vast detail and kept it very generic until you figured out who to 
contact, then let the vendors fix it. 

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

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

[mfisch--- via dev-security-policy]

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 
> > >  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 ps...@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.
> > 
> > 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
> 
> Koen,
>   Cheers on the find and thanks for your contribution.
> 
> Jonathan,
> 
>   Is your argument that TLS checking on session key disclosure is not 
> necessary because man in the middle is game over?
> 
>   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 argue 
> effectively that:
> 
> a) It can't be used under specific circumstances to weaken security and 
> possibly combine with other attacks.
> 
> b) That someone who recognized this for what it was did not reasonably 
> believe 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 
> methodology (at least in order of events). It's now been said.
> 
> Both Cisco and the CA maintain infosec incident handling teams that are paid 
> specifically to handle these situations. Yes its true corporate infosec fails 
> a lot too, but a head start is ethical.
> 
> 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 state 
> oversight.

ps, it was noted previously that if other cisco properties are a bit free 
wheeling with their cookie security it would be possible to leak.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[mfisch--- via dev-security-policy]

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 
> >  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 ps...@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.
> 
> 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

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

Jonathan,

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

  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 argue 
effectively that:

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

b) That someone who recognized this for what it was did not reasonably believe 
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 methodology 
(at least in order of events). It's now been said.

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

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

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

[Jonathan Rudenberg via dev-security-policy]

> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy 
>  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 ps...@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.

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

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

[troy.fridley--- via dev-security-policy]

-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 CSCve90409) 
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 understand the 
implications of their previous design.

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

iEYEARECAAYFAllJYz4ACgkQ1ANYX3sx7SAkVgCeLwuYBx2LceI/SFU+kcSUFtHB
JysAoPm5UtGh+5gzzi/4Gzfdgj2UcGcL
=YznP
-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 
> > 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 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 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 seeking 
> a re-issue of the certificate.
> 
> The right way to approach this problem will be to issue unique keys and 
> certificates to individual instances of the system, this both satisfies the 
> BRs 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 
> manufacturer has an arrangement with a CA to issue them large volumes of 
> per-device certificates in this way. I expect that Comodo (to name one which 
> definitely 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 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

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

[Lee via dev-security-policy]

On 6/20/17, mfisch--- via dev-security-policy
 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 ps...@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 asked
-- Hanno Böck on Twitter (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 ps...@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 people
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[mfisch--- via dev-security-policy]

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

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

[Nick Lamb via dev-security-policy]

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

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

[Matthew Hardeman via dev-security-policy]

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 software 
used this one...  Unless we want to create new burdens for every DV validating 
CA out there, I don't think it's practical to pre-suppose that a similar 
certificate will get similar misuse.

The right balance is probably revoking when misuse is shown.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tom Ritter via dev-security-policy]

On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy
 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matt Palmer via dev-security-policy]

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 ps...@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

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

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

[Matthew Hardeman via dev-security-policy]

I wonder if the device intercepts DNS queries within the LAN for that address 
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 video 
purposes?

I'm thinking they probably wanted some other devices or browsers on the local 
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 <-> 
subscriber 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 
certificate issued for each device.

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

In as far as Cisco has requested a new drmlocal.cisco.com certificate Why?  
They can't use it the new certificate in the same way again (or it would 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 site that needs a 
certificate.  I think the "local" part of the name is probably most telling.  
They likely came up with that name because ciscodrm.local would have been 
impossible to get a valid cert for.


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

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

[Samuel Pinder via dev-security-policy]

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=drmlocal.cisco.com&type=A
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
 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 
>> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 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 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 seeking 
> a re-issue of the certificate.
>
> The right way to approach this problem will be to issue unique keys and 
> certificates to individual instances of the system, this both satisfies the 
> BRs 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 
> manufacturer has an arrangement with a CA to issue them large volumes of 
> per-device certificates in this way. I expect that Comodo (to name one which 
> definitely 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 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Robin Alden via dev-security-policy]

Nick,
   We do exactly that for some device producers already.

Robin Alden, Comodo.  (Sent from my phone)

 Nick Lamb via dev-security-policy   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 
>> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 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 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 seeking a 
>re-issue of the certificate.
>
>The right way to approach this problem will be to issue unique keys and 
>certificates to individual instances of the system, this both satisfies the 
>BRs 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 
>manufacturer has an arrangement with a CA to issue them large volumes of 
>per-device certificates in this way. I expect that Comodo (to name one which 
>definitely 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 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Nick Lamb via dev-security-policy]

On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com  wrote:
>The compromised certificate for drmlocal.cisco.com serial number 
> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 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 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 seeking a 
re-issue of the certificate.

The right way to approach this problem will be to issue unique keys and 
certificates to individual instances of the system, this both satisfies the BRs 
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 
manufacturer has an arrangement with a CA to issue them large volumes of 
per-device certificates in this way. I expect that Comodo (to name one which 
definitely 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 
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

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

[Ryan Sleevi via dev-security-policy]

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​ 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
> 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
> > >
> > ___
> > 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

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

[troy.fridley--- via dev-security-policy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Koen,

   The compromised certificate for drmlocal.cisco.com serial number 
6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 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.  

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

Regards,
- -Troy

- -- 
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
=ayil
-END PGP SIGNATURE-





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

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

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

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

[qwerty123456--- via dev-security-policy]

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​ 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.
> 
> Yes, the subscriber intentionally compromised this key when they implemented 
> 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 
> cryptography, the purpose of certificates in the Web PKI) should have 
> understood 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 
through, like many other software defects. Bottom line - could happen 
unintentionally.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Nick Lamb via dev-security-policy]

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

Yes, the subscriber intentionally compromised this key when they implemented 
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 
cryptography, the purpose of certificates in the Web PKI) should have 
understood they were intentionally compromising their key.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Stephen Davidson via dev-security-policy]

Hello:

Thank you for alerting us.  The issuer HydrantID has communicated with the 
certificate holder Cisco, and the certificate has been revoked.

Kind regards, Stephen Davidson
QuoVadis



From: dev-security-policy 
[dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozilla.org] 
on behalf of Koen Rouwhorst via dev-security-policy 
[dev-security-policy@lists.mozilla.org]
Sent: Sunday, June 18, 2017 6:18 AM
To: Nick Lamb via dev-security-policy
Subject: 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öck 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-certificates-pem
 
<https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-certificates-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-message-txt
 
<https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-message-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


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

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

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

[Eric Mill via dev-security-policy]

One question though, is whether the key was compromised at the time of
intentionally shipping​ 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 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
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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

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

[Daniel Cater via dev-security-policy]

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

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

[Koen Rouwhorst via dev-security-policy]

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  sub domain (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öck on Twitter (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 
 (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 
Issued by: HydrantID SSL ICA G2

Leaf certificate + HydrantID intermediate:
https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-certificates-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-message-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


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