On Tue, Apr 24, 2018 at 7:11 PM, Wayne Thayer <[email protected]> wrote:
> Thanks Matthew, I appreciate you bringing this to everyone's attention. > > Unless I'm misunderstanding the scope of the attack, it would have been > trivial for them to get a trusted cert from most any CA. However, according > to the following article, "Victims had to click through a HTTPS error > message, as the fake MyEtherWallet.com was using an untrusted TLS/SSL > certificate.", yet the attackers still managed to steal millions of dollars > in alt-coins. > This is mostly in line with what happened. It is presently believed only approximately $150K in value of Ethereum was stolen in this event. The thieves hold an account which has amassed over $17 million in value. It likely would have been trivial for them to get a certificate from many CAs during the attack period. I'm curious as to whether they tried or succeeded and then didn't use it. Or if they tried and failed because a CA was smart or well positioned. Of relevance for this community, as you point out, the fake site which users were referred to did not present a valid TLS certificate at all. It was a self-signed. Despite that, users clicked through and got taken for $150k. That, in itself, is a problem for the community. Broadly, I understand this is one that HSTS seeks to resolve. Given the sophistication of the attack and how long the attackers held the space, it does surprise me that they didn't achieve a certificate for their target... Or did they? That's among the questions I would like to raise. Perhaps this is a bit of spy-novel flight of fancy, but perhaps there are plausible attack scenarios to be explored here: We are days away from virtually ubiquitous CT logging of new certificate issuances. Some CAs are not yet logging their certificates unless customers have requested it. I think some start tomorrow, most will likely start by the end of the week. What if there were non-obvious goals of the attackers? What if myetherwallet.com was only a convenient distraction from an as-yet unknown real target? This is perhaps the more significant security question. It's possible that the goal was to secure a certificate for another entity just in time to avoid this quiet issuance from getting CT logged. It's plausible that this would have been requested from a commercial CA with a longer validity period, to be held and used in a future attack. The only way we can know is if CAs are willing to go back to their validation logs and explore the question. Any validations which relied upon DNS query responses from authoritative DNS servers inside 205.251.192.0/24, 205.251.193.0/24, 205.251.195.0/24, 205.251.197.0/24, or 205.251.199.0/24 between approximately 11:05 UTC through 13:03 UTC on April 24, 2018, were potentially improperly manipulated. Depending on what view of the internet a given CA's validation infrastructure has, a given CAs infrastructure may or may not have been referencing the wrong DNS servers during that period. Questions that I'd love to see answered: Did anyone get a validation request for myetherwallet.com during the attack period? If so, what was the final status of that validation request? If denied, on what basis was it denied? If validated, did a certificate issue? Did anyone receive validation requests during the attack period for any domain for which the validation infrastructure, in turn, relied upon answers from the above mentioned IP space? If so, did any of those validations succeed? If so, did any certificates issue upon that reliance? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
