

Comodo attack appears to have originated from Iran - trotsky
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

======
ChuckMcM
It has always been "believed" that nation states are using MITM attacks based
on "legit" certificates and a single pipeline. This however provides stronger
evidence that that belief is well founded. (versus just being paranoid).

Combined with the Ars article [1] on those certificates that come bundled with
the browser and the circumstantial evidence begins to pile up.

Presumably one can delete various CA's they don't trust from their cache, but
that just makes the browser complain that mail.google.com is using a
certificate that isn't trusted, it doesn't let you connect to a server from
Google that is using a certificate you trust.

[1] [http://arstechnica.com/security/news/2010/03/govts-
certifica...](http://arstechnica.com/security/news/2010/03/govts-certificate-
authorities-conspire-to-spy-on-ssl-users.ars)

------
trotsky
Also, ioerror has posted an update in response to Comodo's disclosure:

[https://blog.torproject.org/blog/detecting-certificate-
autho...](https://blog.torproject.org/blog/detecting-certificate-authority-
compromises-and-web-browser-collusion#Update)

Bottom line is certificate revocation lists and OCSP don't mean anything to an
attacker like Iran who is MITM'ing the relevant traffic.

~~~
yuhong
Yea, did the OCSP designers even thinking about the possiblity of MITMing the
OCSP itself?

------
nikcub
This is a bit of a mess. I wouldn't trust the revocation to work, since that
involves a request over a network that has already been compromised.

Interesting to find what the Chrome team did to fix this:

[http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x50...](http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate.cc?r1=76824&r2=78478&pathrev=78478)

Good reason to upgrade!

(Edit: this happen a few weeks ago, it has apparently taken the browser makers
8 days to issue an update while in the interim there were rogue signed certs
out in the wild)

------
nikcub
I just got sent this screenshot from an Indian tech co who say they were
hacked only a few hours ago, from an Iranian IP address:

<http://imgur.com/qj1Ak>

Turns out the IP address is being misreported as from Iran, so i'm wondering
if the same thing happen in this case to point the finger at them

------
Getahobby
Does anybody find it ironic that this guy from the TOR project (great work by
this guy) uncovers this and we take it at face value that the IP address that
this attack _appeared_ to be coming from is the actual attacker? The attacker
couldn't possibly have been using a proxy, could he have? </sarcasm>.

------
biafra
Did anyone ask the ISP (Pishgaman TOSE Ertebatat Tehran Network) to
investigate which subscriber was using the IP address at the time of the
attack?

~~~
trotsky
I think when there is presumably a state actor involved, the issue comes up of
how you could possibly trust any answer you got. If the iranians told you oh
we traced it back to joe in columbus or victor in st. petersburg would you say
"oh, thanks" and go knock on their doors? Pretty sure no one has been
bothering to ask the CIA who they think made Stuxnet either.

------
randomstring
This is proof that nations are hacking and spoofing SSL keys in order to spy
on its citizens.

~~~
gloob
No it's not. Even if "most of the IPs involved in the attack came from Iran"
constituted proof that the attacker was Iranian, it would not be proof that
(1) the attacker was the Iranian government, or that (2) they intended to use
the stolen SSL keys to spy on the citizenry of Iran.

It is, at best, _evidence_ , not _proof_. Reasonably strong evidence, mind
you.

~~~
biafra
Not that strong if you consider this:

"The attacker was well prepared and knew in advance what he was to try to
achieve. He seemed to have a list of targets that he knew he wanted to obtain
certificates for, was able quickly to generate the CSRs for these certificates
and submit the orders to our system so that the certificates would be produced
and made available to him."

This makes me think that this could've been prepared anywhere in the world and
was made from an Iranian IP address to make it look like it originated in
Iran.

If they were that prepared why not use a host in a different country?

~~~
trotsky
It is the classic "China IP" issue, in that China has become such a famous
source for penetrations that other actors appear to prefer Chinese IPs as
effective cutouts. But the other side of the coin is that a substantial number
of attacks from china IPs do actually get tracked back to individuals or
organizations inside China. That would lead one to conclude that if it quacks
like a duck, it is, often, a duck.

------
pasbesoin
Goes to show that you need to know/trust your certificate chain, and not some
"padlock" piece of browser chrome. Continuing my irritation with the way
browser presentations de-emphasize the actual chain and certificates involved.

Even if the certificate labeling is copied, the actual cryptographic values
will change. (If they were readily reproducible, the cryptography itself would
be useless.)

So... notify the user when those values change from previous sessions, or at
least when the fingerprint changes. This still assumes the ability to
establish the legitimate values during those previous sessions or via other
means. And it appears that trusting the original browser installation is not
adequate. (E.g. dozens of "built-in" certs, some from who knows where. Or now,
apparently, attempted forgery of Mozilla certificates.)

Of course, I guess most users will refuse to deal with such details, anyway.
Until it hurts enough...

