Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[urijah--- via dev-security-policy]

I think page 8 of their manual at least partially explains how and what 
"QuickInvite" is. The whole document is rather interesting...

https://www.geotrust.com/geocenter/resources/partnercenter-user-guide.pdf

On Saturday, April 1, 2017 at 6:01:23 AM UTC-4, Nick Lamb wrote:
> On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com  wrote:
> > I'm Tarah. I am the Principal Security Advocate and Senior Director of 
> > Engineering at Symantec Website Security (the certificate authority.
> 
> Hello Tarah,
> 
> Regular readers of m.d.s.policy will not be surprised that the news media 
> doesn't do a great job of explaining problems with the Web PKI.
> 
> As so often I have questions, none of which involve kittens or Ferris Bueller 
> but instead today focus on QuickInvite URLs.
> 
> 1. Symantec's own web site describes "Quick Invite" in several places, I 
> presume this is the same QuickInvite system you're talking about. It explains 
> that "The Quick Invite Duration default expiration time is 30 days, but can 
> be set during the sending of the invite" with a maximum of one year. 
> Presumably this is simply obsolete documentation, or else it refers to some 
> other feature under a similar name? If the former, I am happy to provide the 
> URLs where I found this, are you able to ensure they get updated or removed ?
> 
> 2. What was the designed purpose of the QuickInvite URL / the QuickInvite 
> system itself ? I appreciate that for you its purpose is very obvious as 
> you've spent time up to your neck in it, but to me it's still rather opaque. 
> Let me set out some possible actors in our play, and hopefully you can tell 
> me which actors arrange for the URL to be sent out, which actors receive it, 
> and what they can do with it. That last is quite important. If the list I 
> provide is inadequate feel free to invent more people, just explain what they 
> do.
> 
> Exam PLE is a small business with a web site, www.example.com
> Andrea is the sysadmin at Exam PLE
> Betty is Alice's boss, her details are listed in WHOIS for example.com
> Catherine is an employee at the CA, Symantec
> Jo is an SSL reseller, she offers cheap Symantec certs
> Valorie is a seemingly helpful person who answers Andrea's queries on Q 
> sites
> Wendy runs a web hosting business, she runs the servers www.example.com uses

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Nick Lamb via dev-security-policy]

On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com  wrote:
> I'm Tarah. I am the Principal Security Advocate and Senior Director of 
> Engineering at Symantec Website Security (the certificate authority.

Hello Tarah,

Regular readers of m.d.s.policy will not be surprised that the news media 
doesn't do a great job of explaining problems with the Web PKI.

As so often I have questions, none of which involve kittens or Ferris Bueller 
but instead today focus on QuickInvite URLs.

1. Symantec's own web site describes "Quick Invite" in several places, I 
presume this is the same QuickInvite system you're talking about. It explains 
that "The Quick Invite Duration default expiration time is 30 days, but can be 
set during the sending of the invite" with a maximum of one year. Presumably 
this is simply obsolete documentation, or else it refers to some other feature 
under a similar name? If the former, I am happy to provide the URLs where I 
found this, are you able to ensure they get updated or removed ?

2. What was the designed purpose of the QuickInvite URL / the QuickInvite 
system itself ? I appreciate that for you its purpose is very obvious as you've 
spent time up to your neck in it, but to me it's still rather opaque. Let me 
set out some possible actors in our play, and hopefully you can tell me which 
actors arrange for the URL to be sent out, which actors receive it, and what 
they can do with it. That last is quite important. If the list I provide is 
inadequate feel free to invent more people, just explain what they do.

Exam PLE is a small business with a web site, www.example.com
Andrea is the sysadmin at Exam PLE
Betty is Alice's boss, her details are listed in WHOIS for example.com
Catherine is an employee at the CA, Symantec
Jo is an SSL reseller, she offers cheap Symantec certs
Valorie is a seemingly helpful person who answers Andrea's queries on Q sites
Wendy runs a web hosting business, she runs the servers www.example.com uses
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Gervase Markham via dev-security-policy]

Hi Daniel,

We appreciate your additional input into determining the exact scope of
this problem.

On 31/03/17 19:37, Daniel Baxter (Aractus) wrote:
> With all due respect this reply is the most ridiculous load of
> nonsense I've ever read.

However, please keep the tone civil. If it's nonsense, demonstrate why
that's so rather than asserting it.

> Yeah OK, I got a few things wrong on my blog post, I can fix that
> shortly. 

We would appreciate it if you would let us know what the updates are.

> Firstly you claim email accounts should be secure - um since WHEN?

Regardless of the wisdom of this assertion, it is true that many CAs
rely on the (relative) security of email when doing domain validation.
Symantec is not alone in this respect. It's probably not productive to
have an argument at this point over whether email-based domain
validation is a good idea or not.

> Next, you say that URLs in emails should be treated like a password.
> Um - SINCE WHEN? And furthermore, if it should be treated as a
> password, if that's your claim, WHY ARE THEY BEING SENT IN PLAINTEXT
> IN THE EMAIL? You can't have it both ways - if you want customers to
> treat that as they do a password, you need to treat it with the same
> care, and put it behind an authentication.

This leads to a chicken-and-egg problem. To use email for domain
validation, you need to send something in the email which the domain
owner does not already know, and then use that to validate that the
person wanting the certificate is able to receive the email. It doesn't
matter whether it's a token or the username and password to a web interface.

> Again, stop passing the buck. You need to assume that not every email
> account in the world is secure! Also, it's a breach of s.6.1.2:
> 
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
>
>  No party other than subscriber shall archive the private key. I.e.
> it should be impossible to retrieve from an email in the first
> place.

Do you have evidence that private keys were retrievable? Can you provide
steps to reproduce?

> How does that matter? Chris was able to do it, and if he was able to
> then your investigation should have uncovered the vulnerability. The

It would be great if Chris were available to drop in and corroborate
this. I may reach out to him.

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Peter Bowen via dev-security-policy]

> On Mar 31, 2017, at 6:01 PM, Daniel Baxter via dev-security-policy 
>  wrote:
> 
> On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote:
>> Oh, come on, if that's her job title, that's her job title, and at any
>> CA, that is actually an important job that /someone/ should have.
> 
> I meant the content of her reply, not her job title.

Hi there,

I’m Peter.  I am a Principal Security Engineer at Amazon and Vice President of 
Amazon Trust Services (the certification authority).  I’ve been participating 
in this group for several years, mostly in an individual capacity. One of the 
part of the Mozilla CA program I value the most is open and transparent 
communication.  To that end, I appreciate the direct and clear email from Tarah 
to the group.

As the mozilla.dev.security.policy name indicates, this is a netnews (i.e. 
Usenet) group which is gatewayed to an email list and Google Group.  It is part 
of the Mozilla Forums, which are primarily a place for technical discussions.  
I would hope that anyone looking for a formal statement from any organization 
whose employees participate in this group would reach out to the appropriate PR 
team.

I'm glad to see posts that help keep a high signal-to-noise ratio in this 
fourm, as long as they fall within the etiquette rules 
(https://www.mozilla.org/en-US/about/forums/etiquette/).

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[aractuspuphlicus--- via dev-security-policy]

On Saturday, April 1, 2017 at 6:51:30 AM UTC+11, Vincent Lynch wrote:
>
> It is simply a bug, related to an OID included in the certificate. This has
> been documented by Chrome
> .

OK, I'll update that, thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Daniel Baxter via dev-security-policy]

On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote:
> Oh, come on, if that's her job title, that's her job title, and at any
> CA, that is actually an important job that /someone/ should have.

I meant the content of her reply, not her job title.

> Unfortunately, when initially establishing encryption certificates, one
> generally has to start from some kind of unencrypted connection, such
> as an unencrypted phone call or an unencrypted e-mail, or an
> unencrypted paper mail.

Not the private key though. And besides, it doesn't matter if your CSR and 
Certificate are duplicated, they're not a secret only the private key is.

> But a password or random secret string in a URL /is/ authentication.
> And in an e-mail, it is behind whatever authentication you (not
> Symantec) have set up for that e-mail (and Symantec obviously didn't
> know about the Yahoo undisclosed breach at the time).

I don't know how to say this any other way - but that's unbelievably sloppy. 
That's like saying you'll let your customers email their credit card numbers to 
you. You don't put anything that sensitive into an email address, ever. Any 
time I get a password emailed to me I change it immediately.

Besides this is passing the blame to the customers. And there is a big 
difference of how informed each party was. Symantec knew about this exploit, 
customers didn't. They knew to take extra precautions, customers didn't have 
that knowledge.

> They need to only assume that whatever e-mail account people provide
> for signup is secure enough for the people choosing what e-mail to
> provide /and only on the day or week where they provide that e-mail
> address/.

So since December 2016 they banned all Yahoo! emails, right?

> But was he, or did you simply exaggerate something in your blog?

He says it on his facebook post: "for some third party vendors, depending on 
the type of certificate, and how the certificate was issued, you could also 
retrieve private keys."

> The Google issue is *microscopic* except Google is using it as a lame
> excuse to threaten Symantec big time.

I believe the 30,000 number they talked about relates to the same security 
issue that Chris Byrne identified. If it didn't then here's my question: how 
many certificates were affected by the Chris Byrne issue?

On Saturday, April 1, 2017 at 9:11:00 AM UTC+11, tarah.s...@gmail.com wrote:
> 
> So sorry, but I don't know what you're referring to. Did you tweet me a link 
> to a blog post? Blame Jack if so; all of us are dealing with hugely 
> problematic threading today due to the Twitter @ changes. If you reply here 
> with what you are talking about, I can take a look, though unfortunately I 
> might not be able to get to it today. I always like hearing opposing 
> viewpoints.

Sure, it's no secret: https://blog.aractus.com/the-symantec-ssl-shitstorm/

That page I'm pretty sure wasn't even indexed in google when I posted. Even it 
it was, my viewership is only small. I was here reading these threads, and 
gathering more information so that I can fix up all the errors I've made - 
that's how we all learn, by making mistakes and fixing them. Anyway, I only 
used primary sourced material (ie, the google groups discussions, Chris's 
facebook post, and the Symantec website), I haven't read anything on Twitter.

Again, I obviously can't speak for others, but any confusion over the facts 
here could have been easily avoided had Symantec made a full public statement 
about the Chris Byrne vulnerability the moment that it no longer posed a threat 
to customers.

Where I will agree with you is that from the description, it would have 
involved a fairly sophisticated attack to steal private keys from the 
"incompetent resellers", and that they were equally culpable.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[mono.riot--- via dev-security-policy]

Maybe I'm alone in this but, while entertaining, I'm taken aback a bit if this 
is official Symantec communication in a forum like m.d.s.p. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[tarah.symantec--- via dev-security-policy]

> 
> Yeah OK, I got a few things wrong on my blog post, I can fix that shortly. 
> It's no big deal. At least I'm informing people about security - claiming 
> that we're just "looking for hits" is ridiculous. Most people pay no 
> attention to security, I can't speak for others but I'm trying to inform.
> 

So sorry, but I don't know what you're referring to. Did you tweet me a link to 
a blog post? Blame Jack if so; all of us are dealing with hugely problematic 
threading today due to the Twitter @ changes. If you reply here with what you 
are talking about, I can take a look, though unfortunately I might not be able 
to get to it today. I always like hearing opposing viewpoints.

I feel like Jakob basically covered every other point.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Vincent Lynch via dev-security-policy]

>
> Finally, what have you actually done to address EV revocation? You clearly
> didn't bother to tell Commonwealth Bank:
>
> https://www.commbank.com.au/
>
> One of the largest banks in Australia that their EV status would evaporate
> in Chrome. So what did you do to inform your customers about this?



As Jacob Bohm has said in his reply, Google's proposal to remove EV status
for Symantec certificates has *nothing* to do with this report.

Furthermore, the issue you have brought up with Commonwealth Bank has
*nothing* to do with *either* of the two separate issues Symantec is
currently dealing with. It also has nothing to do with Commbank.com.au
being "hacked," as you have written on your website
.

It is simply a bug, related to an OID included in the certificate. This has
been documented by Chrome
.

You can test this by visiting https://www.commbank.com.au/ in Chrome
Canary, which has fixed the bug, and returned the green address bar to the
site.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[tarah.symantec--- via dev-security-policy]

> Yep, but there must have been an API (at some level) for generating or
> processing the QuickInvite URL.  That was what I was suggesting might
> have been the issue.

So, it's hard for me to answer this question because I didn't see any POC, but 
1) it's not physically possible for private keys to be revealed in the 
interface as described to me and in which I've spent the last few days 
completely submerged, and 2) there's still the validation process which isn't 
simply bypassed with this URL.

I have to be cautious here in a couple of my answers, and I hope you appreciate 
why: as soon as I found out Symantec wasn't affected any more by this reseller, 
I found out who was. I have to responsibly disclose that information first and 
get a confirmation from them. I've already notified everyone I had contact info 
for there, and I'll stay on them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Jakob Bohm via dev-security-policy]

On 31/03/2017 19:31, tarah.syman...@gmail.com wrote:

On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote:

Dear Tarah,

Below some friendly speculation as to what the parts that some bloggers
claimed was included (if those claims were somehow true) might have
been (i.e. where *you* might look for it in internal Symantec
systems/records).




Thank you.






Could this be about some other URLs in the (now hopefully closed) RA
interface?  Such as an interface for requesting the QuickInvite URL for
later forwarding to the subscriber?

Perhaps an interface that takes only "known/guessable" parameters, such
as subscriber e-mail or order number?  This would explain the claim
that an URL sent to one subscriber by an incompetent RA could be
edited to retrieve the data for another subscriber.



Nope. That QuickInvite URL was/is hashed and salted. I have personally seen the 
code for generating it. Just editing stuff in that URL without being able to 
crack it wouldn't give any useful information or lead anywhere. Although now 
I'm kinda wanting to create a specific error page for people who try. Nah. It'd 
be funny to me and anyone trying to hack those but the customers wouldn't get 
my jokes, likely. Brute forcing the URL would take too long, which is why I 
agree with the original decision to decrease the URL validity timespan. It 
helps prevent brute force attacks too.



Yep, but there must have been an API (at some level) for generating or
processing the QuickInvite URL.  That was what I was suggesting might
have been the issue.


Also, just was chatting with Chris. I just found out that the reseller in 
question was dropped from our Symantec a while back. Details to follow, but 
suffice to say that they are no longer a problem for us.



Great!

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: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[tarah.symantec--- via dev-security-policy]

On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote:
> Dear Tarah,
> 
> Below some friendly speculation as to what the parts that some bloggers
> claimed was included (if those claims were somehow true) might have
> been (i.e. where *you* might look for it in internal Symantec
> systems/records).
> >

Thank you. 

> 
> Did Symantec ever offer Symantec-generated private keys (e.g. PKCS#12
> files) via that or a similar mechanism?  That would explain the
> "private key" claim without an additional PoC.

That was available for 1 or 2 customers, but it was not via the QuickInvite 
interface . It took a downloaded Java app (dear lord) to make that happen, and 
my belief is that this practice ended around the same time as this initial 
report but was not related to this issue. I don't think anyone can do this 
anymore, and I'll follow up on that too, but even in that case, we would never 
have seen their private keys. Resellers should never have had the ability to 
generate key pairs and CSRs and if they said they did to Chris, I'm furious.


> Could this be about some other URLs in the (now hopefully closed) RA
> interface?  Such as an interface for requesting the QuickInvite URL for
> later forwarding to the subscriber?
> 
> Perhaps an interface that takes only "known/guessable" parameters, such
> as subscriber e-mail or order number?  This would explain the claim
> that an URL sent to one subscriber by an incompetent RA could be
> edited to retrieve the data for another subscriber.
> 

Nope. That QuickInvite URL was/is hashed and salted. I have personally seen the 
code for generating it. Just editing stuff in that URL without being able to 
crack it wouldn't give any useful information or lead anywhere. Although now 
I'm kinda wanting to create a specific error page for people who try. Nah. It'd 
be funny to me and anyone trying to hack those but the customers wouldn't get 
my jokes, likely. Brute forcing the URL would take too long, which is why I 
agree with the original decision to decrease the URL validity timespan. It 
helps prevent brute force attacks too. 

Also, just was chatting with Chris. I just found out that the reseller in 
question was dropped from our Symantec a while back. Details to follow, but 
suffice to say that they are no longer a problem for us.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[okaphone.elektronika--- via dev-security-policy]

Right. It is then.

It says private keys can only be stored with permission of the subscriber and 
encryption must always be used to transfer them. And of course the certificate 
must be revoked if/when it becomes known that a private key has gotten to the 
wrong person.

Well... NOT my private keys. I'll create the CSR myself, thank you. ;-)

Anyway, would be nice if there was some evidence in this thread.

CU Hans

On Thursday, 30 March 2017 00:31:50 UTC+2, Ryan Sleevi  wrote:
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
> 
> Section 6.1.2
> 
> On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via
> dev-security-policy  wrote:
> 
> > Weird.
> >
> > I expect there are no requirements for a CA to keep other people's private
> > keys safe. After all handling those is definitely not part of being a CA.
> > ;-)
> >
> > CU Hans
> > ___
> > 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: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Ryan Sleevi via dev-security-policy]

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf

Section 6.1.2

On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via
dev-security-policy  wrote:

> Weird.
>
> I expect there are no requirements for a CA to keep other people's private
> keys safe. After all handling those is definitely not part of being a CA.
> ;-)
>
> CU Hans
> ___
> 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: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Florian Weimer via dev-security-policy]

* Nick Lamb via dev-security-policy:

> In order for Symantec to reveal anybody's private keys they'd first
> need to have those keys, which is already, IIRC forbidden in the
> BRs.

I think this requirement was dropped because it makes it unnecessarily
difficult to report key compromises.  There used to be a time when CAs
demanded zero-knowledge proofs of key compromise (which can be
surprisingly hard to do with existing tools).  Fortunately, these
times are over, and CAs no longer categorically reject the submission
of compromised subscriber keys (although my sample is really small due
to my limited factorization capabilities).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[okaphone.elektronika--- via dev-security-policy]

Weird.

I expect there are no requirements for a CA to keep other people's private keys 
safe. After all handling those is definitely not part of being a CA. ;-)

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Peter Gutmann via dev-security-policy]

Nick Lamb via dev-security-policy  
writes:

>In order for Symantec to reveal anybody's private keys they'd first need to
>have those keys

That's standard practice for many CAs, they generate the key and certificate
for you and email it to you as a PKCS #12.  It seems to be more common among
lesser-known CAs though, particularly ones with government-mandated monopolies
for some reason, so I'm not sure if Symantec does it.

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[ian--- via dev-security-policy]

On Tuesday, March 28, 2017 at 3:46:05 PM UTC-4, Nick Lamb wrote:
> In order for Symantec to reveal anybody's private keys they'd first need to 
> have those keys, which is already, IIRC forbidden in the BRs. So even proof 
> that Symantec routinely had these keys is a big deal.

>From what I can tell, this may be correct in the context of retainment. Many 
>CAs have provisions to generate the key on the behalf of the subscriber, 
>though. The wording of the section you're probably thinking of (6.1.2) is 
>tricky:

> Parties   other than the Subscriber SHALL NOT archive the Subscriber 
> Private Key without authorization by the Subscriber.

So I guess you would need to see if the subscribers here authorized it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Vincent Lynch via dev-security-policy]

On Tuesday, March 28, 2017 at 11:08:08 PM UTC-4, uri...@gmail.com wrote:
> For what it's worth, this is the latest post on facebook from the researcher.
> https://www.facebook.com/cbyrneiv/posts/10155129935452436
> 
> The private key storage issue sounds like a reseller tool, like
> https://www.thesslstore.com/ssltools/csr-generator.php
> and he found the private key was stored with the reseller,  when he accessed 
> the account.
> 

I work for The SSL Store and just wanted to quickly clarify that Urijah is 
using our site as an example of the *type* of tool that the private key issue 
was related to.

But our specific tool does not store the user's private key in any way. Nor is 
there any scenario in which we store the user's private key or make it 
accessible to them through their account.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[urijah--- via dev-security-policy]

For what it's worth, this is the latest post on facebook from the researcher.
https://www.facebook.com/cbyrneiv/posts/10155129935452436

The private key storage issue sounds like a reseller tool, like
https://www.thesslstore.com/ssltools/csr-generator.php
and he found the private key was stored with the reseller,  when he accessed 
the account.

Chris Byrne
March 24 at 8:02pm · 

UPDATED Tuesday March 28th, to clarify some language, and provide additional 
detail...
..
Looks like I don't have to stay quiet about this one anymore... 
I found out about this problem... and others related to it... back in early 
2015. I warned Symantec about it, and worked through some of the issues with 
them. 
At the end of it, they asked for a chance to verify how extensive the issue 
was, and to fix it. We both agreed it would take up to two years to fix, 
without creating more chaos and causing more damage... and I said yes.
I agreed to limited non-disclosure of the issue, unless I felt it was 
critically necessary, or it would be unethical or irresponsible for me not to 
disclose (for example, if there were a threat to national security, or I 
discovered a compromise of a client, or any actual criminal compromise arising 
from it, etc... etc...). 
That said, I informed Krebs and a few others about what I had found... and also 
that I agreed to let them fix it, because it would be less damaging to the 
world, than exposure would be. 
It was one of those issues where there's no GOOD choice... but I looked at the 
damage immediate exposure would cause, vs. a slowly rolling fix over two 
years... 
I talked to some of my friends on the grey and black sides of things, and did 
my own checking, to see if there was any chatter about this anywhere, and I 
couldn't find any... and I concluded that more harm would be done if I 
disclosed.
Fellow security professional Bobby Kuzma helped me investigate and validate 
these issues, and he can verify what I state here. 
I checked a few months later, and they HAD fixed several of the core 
problems... though not all of them... So I waited, and so did those who I had 
informed about the problem, and had verified it for themselves... 
Unfortunately, late in 2015, my cancer recurred, and spread to my lymph 
nodes... and I've been fighting it ever since, so I haven't kept up with the 
issue. 

So... Here's what the post doesn't mention...
If you purchased a Symantec certificate (or a cert from any of their associated 
subsidiaries and partners) through a third party, from at least as far back as 
early 2013 until recently; their third party certificate generation, 
management, and retrieval API allowed those certificates... including in some 
cases private keys generated by third parties... to be retrieved without proper 
authentication, or in some cases any authentication at all.
Unless the third party added proper security around it, all you had to do was 
click a link sent in email, and you could retrieve a cert, revoke a cert, and 
re-issue a cert... and for some third party vendors, depending on the type of 
certificate, and how the certificate was issued, you could also retrieve 
private keys.
Note, this was not just for server certificates for SSL, it also included other 
certificates, such as personal certificates used for email and other personal 
encryption. These certs could be requested entirely through the web interface 
without a separate server issued certificate request, generating both private 
and public keys, which would then only be protected by a passphrase. 

Further, even with first party purchase, for some time in some web interfaces, 
it was possible for properly authenticated users to edit a URL, and at least 
retrieve information about first party certificates and their owners, and 
possibly the certs of others. 
This is because third party data retrieval was not limited to certificates 
issued by that third party. It was available to anyone by entering the UID of 
any other user. 
To clarify... at no time were we able to retrieve private keys directly from 
Symantec, only from third parties that issued certificates from a web interface 
without requiring a server generated certificate request.
We were able to confirm that these third party weaknesses extended to 
retreiving, revoking, and reissuing certificates, in some cases without 
notification to the legitimate certificate holder.
In one case, we were also able to reissue a certificate without first 
explicitly revoking it, and the original certificate continued working for at 
least 48 hours... We did not test further to see how long it would take for the 
certificate revocation list to propagate, and we're not pale to prove one way 
or the other if the organ certificate was revoked or not. 

It is possible that the certificate was never revoked at all, and another 
certificate was simply issued, leaving two valid certificates one controlled by 
the original requestor, and one controlled by the 

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Nick Lamb via dev-security-policy]

In order for Symantec to reveal anybody's private keys they'd first need to 
have those keys, which is already, IIRC forbidden in the BRs. So even proof 
that Symantec routinely had these keys is a big deal. The whole reason things 
like CSR signing exist is that public CAs have no reason to know anybody's 
private key, the clue is in the name.

Beyond that I'll note that anybody reading Raymond Chen for a few weeks will 
learn that not every researcher who thinks they just found a smoking gun turns 
out to know what a gun actually is, nor sometimes what constitutes smoke. So, 
evidence is what we need. Neither holes in Symantec security nor overclaims 
from a person who misunderstood what they were seeing are unlikely.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[urijah--- via dev-security-policy]

https://www.bleepingcomputer.com/news/security/researcher-says-api-flaw-exposed-symantec-certificates-including-private-keys/

Does anyone have further information about this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy