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

Reply via email to