
How I Tricked Symantec with a Fake Private Key - hannob
https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html
======
watbe
Symantec is surely testing the patience of Google/Mozilla now. Illegitimate
revocation seems almost on the same level as illegitimate issuance of
certificates. Imagine the impact on an HPKP site.

~~~
SOLAR_FIELDS
I wondered where Apple and Microsoft were in this whole thing and I found this
from one of the Chromium trust discussions:

"Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their changes
in trust prior to enacting them."

Why or why not would you want to withhold this kind of information?

~~~
gsnedders
To some degree, I believe Microsoft and Apple want to avoid any risk of being
seen to collude with other vendors to essentially destroy the business of
another company.

------
Flammy
I agree with the author that one of the most annoying parts of the process is
that Symantec doesn't tell the legitimate owner any details to actually help
them.

If I got that type of error/reissue email, I would assume it was something
fairly normal going on, when in reality I _really, really_ need to know that
the private key had been leaked.

------
ikeboy
[https://support.comodo.com/index.php?/Knowledgebase/Article/...](https://support.comodo.com/index.php?/Knowledgebase/Article/View/684/17/how-
do-i-verify-that-a-private-key-matches-a-certificate-openssl) currently has
instructions for checking consistency. Did they change it after this post was
published?

Edit: Jul 9 snapshot from [https://archive.fo/Zdmck](https://archive.fo/Zdmck)
didn't include those instructions, so they only added that recently.

------
z3t4
I imagine submitting a fake Symatec key and have them revoke their own cert
and the confusion it would create, like a prank. But might actually create
real damage.

~~~
viraptor
That makes me wonder if CAs can be revoked this way. I mean, do browsers even
check for CAs and intermediates in ocsp?

~~~
Piskvorrr
Theoretically not; but as we have seen, there is often a gap between theory
and practice.

------
breakingcups
That's amazing. It's so simple most people wouldn't even think to try it.

In fact, a lot of the really good hacking stories are. The recent .IO takeover
for example.

------
jwilk
> For example a private key contains values p and q that are the prime factors
> of the public modulus N. If you multiply them and compare them to N you can
> be sure that you have a legitimate private key.

But make sure than neither p nor q is 1.

------
walrus01
It is absolutely unacceptable that anyone can revoke any domain's cert by
presenting a fake private key that doesn't cryotographically match to the
cert.

This makes me wonder how easy it would be to social engineer getting Symantec
to revoke a third party's cert, even if you don't have the private key, just
by having a talented person on a phone with faked outgoing caller ID via SIP
trunk. See: Mitnick's Art of Deception book for examples.

~~~
ccrush
Apparently, it's as easy as the blog author presented. It is exactly what they
did: reported a private key leak with a fraudulent private key file (unrelated
and forged cert details).

------
totony
this seems trivial to do, couldn't you extract the public key from the private
key, encrypt something with this extracted key and see if the decrypted
message matches?

~~~
hannob
In the post I recommended to sign a test message with the private key and
check it with the public key - which has the same effect, it's just the other
way round. Whether that's "trivial" is another question, given how arcane the
usage of the tools doing these things is.

There are multiple ways to properly check this. However the point is: Symantec
didn't do it and the vast majority of the guides you find on the Internet
about this are wrong.

------
jwilk
> openssl x509 -in [certificate] -noout -pubkey > /tmp/pubkey.pem

I cry a little every time sometimes uses /tmp this way.

This is insecure.

~~~
scintill76
I cry a little when someone says something is wrong, without explaining how to
do it right. What's insecure with this, and how should it be done instead?

~~~
rrix2
The default umode of /tmp is usually world-writeable, so files created like
this could be manipulated by bad actors on the same system. Not so critical in
this case, but it can be seen as "code smell"

~~~
mioelnir
This of course assumes you are running around an actual multiuser system
without 1777 /tmp and 077 umask like it is 1989.

~~~
jwilk
All the attacker has to do is:

    
    
      touch /tmp/pubkey.pem
      chmod a+w /tmp/pubkey.pem
    

before the victim runs the code.

No sticky bit, no restrictive umask, also no
protected_hardlinks/protected_symlinks is going to save you.

