StartCom (false) vulnerability report

[s...@gmx.ch]

JFYI:
https://oalmanna.blogspot.com/2016/03/startssl-domain-validation.html
https://startssl.com/NewsDetails?date=20160322
https://startssl.com/NewsDetails?date=20160323

Regards,
Jonas

[Peter Gutmann]

s...@gmx.ch <s...@gmx.ch> writes:

>https://oalmanna.blogspot.com/2016/03/startssl-domain-validation.html
>https://startssl.com/NewsDetails?date=20160322
>https://startssl.com/NewsDetails?date=20160323

So who are we supposed to believe here, the original reporter showing that he
did it or the CA claiming that he didn't?

Peter.

[Peter Bowen]

The original reporter showed that he could choose which of the valid
email addresses to use for validation at a later stage than the UI
suggested. He did not try to ask Startcom to use an email address not
associated with the domain. Therefore it is unknown whether there was
an issue or not.

Thanks,
Peter

[Peter Kurrasch]

A more cynical response might be to say that StartCom is just as bad as everyone else. To wit:

1) The website has a vulnerability. The blog post shows the user providing a value which appears to be invalid for that page. StartCom very well could have a check in a backend system that checks the email address against the WHOIS info so no actual harm took place. But, as Peter B points out, we won't really know for sure. Bottom line is that there was a web site vulnerability, but most web sites do which is why there's the OWASP Top 10 list.

2) The automated system used in this case relies on email addresses ("postmaster", et al.) that do not sufficiently prove that the applicant is an authorized user/owner of the domain. I've raised this point before so I won't belabor it here. Bottom line: everyone seems to rely on potentially unreliable data to establish domain control and authorization.

3) The claim that CT leads to better security is partially specious. My argument here is also one I've made before wherein having an audit trail such as CT typically only helps after the fact--only after a problem is discovered. We've even had posts in this forum of the variety of "I just noticed in the CT logs that such-and-such has done whatever". Clearly, the use of CT did not detect such problems so there is a period of time where users were less safe. This isn't to say that CT is of no value, rather that it's limited.



  Original Message  
From: Peter Bowen
Sent: Wednesday, March 23, 2016 7:27 PM
To: Peter Gutmann
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: StartCom (false) vulnerability report

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Eric Mill]

A less cynical response is that the researcher failed to show what they
said they showed. So the situation is basically just the same as it was
before the researcher made their post, except that StartCom has made an
improvement that adds a server-side check to make sure the email address is
what was presented.

Not that StartCom looks awesome in this situation, it's a dangerous area
for bugs to be present and could/should mean that they and others apply
some more scrutiny to their interface -- but I don't think there's any
reason to assume bad faith in StartCom's response.

-- Eric

--
konklone.com | @konklone <https://twitter.com/konklone>

[Paul Wouters]

On Thu, 24 Mar 2016, Peter Kurrasch wrote:

> 3) The claim that CT leads to better security is partially specious. My argument here is also one I've made before wherein having an audit trail such as CT typically only helps after the fact--only after a problem is discovered. We've even had posts in this forum of the variety of "I just noticed in the CT logs that such-and-such has done whatever". Clearly, the use of CT did not detect such problems so there is a period of time where users were less safe. This isn't to say that CT is of no value, rather that it's limited.

Note: I'm the IETF co-chair for the CT group (called "trans")

CT is in the early stages. We have logging now and we need to develop
more monitoring and auditing on top of that. The IETF is working on
a few items in this area, such as the gossip protocol:

https://tools.ietf.org/html/draft-ietf-trans-gossip-02

While CT is not meant to guarantee preventing attacks, it should in the
near future be able to shorten the useful lifespan of bogus certificates,
and perhaps more importantly guarantee anyone using bogus certificates
will be caught by the public. So a targetted attack has a hefty price.

Paul

[Jakob Bohm]

On 24/03/2016 16:11, Eric Mill wrote:
> A less cynical response is that the researcher failed to show what they
> said they showed. So the situation is basically just the same as it was
> before the researcher made their post, except that StartCom has made an
> improvement that adds a server-side check to make sure the email address is
> what was presented.
>

Correction: StartSSL claims the check was always in place, and the
input was allowed because it was *intentionally* allowed to provide
that value, even if the user interface suggested it should have been
typed at an earlier HTML page in the sequence.

> Not that StartCom looks awesome in this situation, it's a dangerous area
> for bugs to be present and could/should mean that they and others apply
> some more scrutiny to their interface -- but I don't think there's any
> reason to assume bad faith in StartCom's response.

As their answer stands, the only issue may be that the user interface
doesn't allow the requester to type in that more secure e-mail address
directly.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded