The attack vector appears to be a faked google analytics plugin that was hosted on the g-analytics.com domain and contained a keylogger.
The domain has since been suspended, but part of why this worked appears to be that Comodo issued a HTTPS certificate - https://crt.sh/?q=g-analytics.com
I know LetsEncrypt has a blacklist of domains that are not allowed. Most are brands and financial institutions. I wanted to open this thread to suggest that popular plugins and their name variants be included as well.
If the only check is that it is from a site that has a valid cert, then does the actual FQDN of where you get the plugin even matter? Did it fool anyone visually? (maybe I need to read the entire story)
…
In the meantime… policing this that way seems like an endless task of blocking name variants.
And this would not stop any names that are not similar to any well known site and yet are malicious.
Even creating a “list” of trusted plugins or their trusted sites, which may be more effective in the long run and even easier to maintain, is still not ideal. I think this sits more in the realm of anti-virus, anti-malware, and such defenses.
The developers of an e-commerce website linked to a plugin hosted on g-analytics.com – probably via an online tutorial – instead of the actual one from google. Because the malware site had a valid HTTPS cert, the plugin worked on their own HTTPS site – exposing all keystrokes (including CCV) to the attackers. The Developers were fooled into linking to a fake CDN, and the certificate allowed the javascript to be loaded into the payment/account pages of users. Without a cert, most browsers would not have executed the mixed/invalid content.
LetsEncrypt currently maintains an internal blacklist/formula for hundreds/thousands of “sensitive” domains like Banking/Credit companies and other software companies. Domains containing terms like “microsoft”, “windows”, “apple”, “google”, etc trigger existing blacklist rules in Boulder – however they are “secret” internal rules, and we only learn of them as people with legitimate claims ask for an exemption. Extending this current anti-malware/phishing strategy to sites that host the most popular javascript plugins (if LetsEncrypt doesn’t do this already - they are aggressive) makes perfect sense to me, as we now know this is an attack/abuse vector.
I agree that any defense is better than none and would not stop anyone from trying.
But, as seen, they didn’t even choose LE for their cert.
Perhaps to be more inline with the intended similar plugin site or maybe LE did deny them a cert?
In any case, even if LE blocks them, they can just go to any other CA.
My point is this attack vector isn’t really something any netizen can expect any CA to defend them from.