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

2017-03-31 Thread 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

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

2017-03-31 Thread 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

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

2017-03-31 Thread 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

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

2017-03-23 Thread via dev-security-policy
On Thursday, March 23, 2017 at 12:09:23 PM UTC-4, Ryan Sleevi wrote:
> (Posting in a Google Capacity)
> I just wanted to notify the members of this Forum that we have started an 
> Intent to Deprecate and Remove, consistent with our Blink process, related to 
> certain certificates issued by Symantec Corporation.
> This is a proposed plan, not a final commitment, and we welcome all feedback 
> from members of this Forum to understand the risks and challenges. To 
> understand the goals of this process, you can find more details at 
> You can participate in this discussion at 

What will be the process for critical infrastructure such as medical devices 
and payment systems when they're affected by this? 
dev-security-policy mailing list