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
