On 01/03/2009 07:31 AM, Ben Bucksch:
On 03.01.2009 04:59, Eddy Nigg wrote:
The report is available from here: https://blog.startcom.org/?p=161
That's surely interesting, but the report does not contain any details
of interest.
It only says
"The attack ... involved proxying ,intercepting all communication from
and to the browser and eventually modification of the browser response
to the server. A tool like
http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project was used
for the attack."
That's all it says about the problem. Which tells me nothing, other than
that the *user*s browser might have been involved in some critical
verification steps.
Other info;
"Only low-assurance Class 1 certificates were involved."
He passed all your tests and you only noticed, because he tried to get a
cert for verisign/paypal.com, which are on your blacklist. While that's
a good idea, it obviously wouldn't have prevented registration of other
targets.
So, what really happened and why? How is the browser any relevant in the
verification steps?
I can give some more information on this. This attack is perhaps trivial
for a hacker, it's maybe not overly obvious. In this respect, we
actually have more protections in place and attacks are anticipated to
DNS and mail servers, but also otherwise to the web interfaces. That's
because as I also said previously, bugs do happen as many developers
here can confirm. The attack was foiled by the assumption that it must
have some value for the attacker and that attackers usually make at some
point a mistake. This is not the first time attempts to circumvent our
various procedures happened, it's however the first time somebody
actually succeeded to some degree.
Another word before disclosing some more. You and also Mike Zusman asked
in his article what would have happened to smaller targets. Rightly,
unknown sites are not equally protected as high-profile targets.
However, StartCom has a responsible policy in place which disallows wild
cards and multiple domains in the Class 1 settings, prevents other
possible misleading issuance such as paypa1.com or micr0soft.com just to
mention a few, financial institutions must provide identity documents
and most important, certificates are valid for one year only - no matter
which validation level the subscriber enjoys. Manual verifications are
also performed on an ongoing basis. With this we try to counter some
misuse as well.
The attack was performed by using said tool above or by using a modified
version of the browser. By hooking this tool between the server and
browser, the tool allows to change the values coming to and from the
browser. With it, he was able to change some values send during the post
response to that of his liking. The validations wizard allows for a
selection of a few possible email addresses considered for
administrative purpose or as listed in the whois records of the domain
name. The flaw was, that insufficient verification of the response at
the server side was performed, allowing him to validate the domain by
using a different email address than the validations wizard actually
provided. The value of the selection was changed during transit after
performing the selection at the browser. Hope that clarifies the details
which aren't outlined in the report.
Additionally all steps of the subscribers are always logged (yes, every
click of it) and we have records about every validation and about which
email address was used for it, failed attempts etc. With those records
could we re-validate all certificates very quickly. The only ones which
failed were those of domains which retired. Expired certificates were
not tested.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
