On Wed, Apr 25, 2018 at 1:44 PM, Santhan Raj via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > I did see the (ridiculously silly) self-signed certificate that was used, > but the skeptic in me keeps questioning the timeline of this attack and > recent multiple cert issuances, > - a self-signed cert created on 2018-03-23 and observed by Censys on > 2018-03-29 (https://censys.io/certificates/4f151e2efd755fb1b9a4d50fa6db2a > f0008dff02ffbef8178be54f9db6e86d75) I assume this is the cert used in the > attack from the screenshots > That is what I have understood to be the case. > - the self-signed cert was created exactly a year after the Amazon > certificate was issued > - the self-signed cert was used in an attack the day when/after the Amazon > DV cert expired (April 23rd 2018) > My belief is that that was coincidence, if the date of the attack is significant, it was at or closely before days in which more CAs would begin CT logging of all their certificate issuances. - additionally, and this may have nothing to do with the attack, 3 distinct > EV certs issued to myetherwallet.com by Digicert and Comodo on 2018-03-30 > and 2018-03-31, even though the existing EV cert (issued by Digicert) was > still valid > - https://crt.sh/?id=370369641 > - https://crt.sh/?id=371216075 > - https://crt.sh/?id=378737050 These three are not weird. They were all obviously acquired in near time to each other and there is a rational explanation. If EV certificate is important to you and if you're a professional in these matters, it is not unlikely that you would purchase redundant certificates from two different CAs with entirely different trust hierarchies. This ensures that you already have in-hand a new TLS certificate in case either CA has a loss of trust issue, etc. The two from Digicert reflect two different key lengths. They requested both a 2048-bit version of the certificate as well as a 4096 bit version of the certificate. As EV certificates can take some time to acquire, it is not uncommon for a professional to have multiple simultaneous certificate instances in-hand so that another certificate is already on hand to replace the one that has a problem. (Key compromise of operating certificate, CA distrust, revocation by CA for reasons, etc.) > > > Again, I'm obviously speculating and all this could be coincidence and > business as usual, but if I were writing this crime novel, the plot > wouldn't be "1-2 days of attack to steal $150K" but "a year of silent > attack to steal $17M and get caught due to an expired cert". Why would > anyone with $17M want to go through all this trouble to steal just another > $150K? > There's the question everyone wants answers to. The attacker demonstrated some sophistication. No one has suggested any significant part of that Ethereum came from any prior compromise of MyEtherWallet.com. I myself wonder if the attack on myetherwallet.com was a "bonus" or side-job, designed to be the publicly acknowledged reason for the attack and to stop people digging further. The question which remains is what else might the attackers have done -- and who was or will be impacted -- during the two hour window they opened. It is on that basis I am especially interested to know what DNS validation attempts were attempted across the various CAs during that time period which relied upon responses to queries sent to any destination within the set of impacted prefixes. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
