Nice pitch for Google's cloud service in there though:
"the attackers were able to change the registration simultaneously for all of the bank’s domains, redirecting them to servers the attackers had set up on Google’s Cloud Platform"
They knew switching all the bank's DNS records would bring an unpredictable load, so they went cloud for their phishing sites. Heh.
Another fun fact: It took them about a month to revoke the certificate in question. They didn't even bother revoking a second certificate[3] (valid for a subdomain). Heh, at least this will make a good example when discussion the pros of short-lived certificates.
[1]: https://crt.sh/?id=47675898
[2]: https://crt.sh/?Identity=%25.banrisul.com.br&iCAID=16418
It checks all these marks:
"the firm says it’s a major Brazilian financial company with hundreds of branches, operations in the US and the Cayman Islands, 5 million customers, and more than $27 billion in assets"
I am from Brazil, and many, MANY, MAAAANY times I saw my bank webpage be slightly off, and I noticed it was fake, every single time after tracking down the problem was some DNS interception, for example once was a virus on my PC, another time was a virus on my router, another time someone used a bug on my modem to change its DNS configuration without knowing the password, another time the local ISP got hacked and their DNS servers polluted with fake IPs for all major banks.
So, can the bank somehow defend itself from that? (not that they care... from what I've seen so far banks just tell the costumer that he lost the money due to his own fault...)
To prevent it on the server-side (i.e. hijacked DNS or web servers) and/or to prevent rogue CAs from issuing certificates for their domain, they would need to use key pinning (for example via HPKP).
Banks should probably be using this. Though none of my 3 banks do, or even use HSTS.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
UAs MAY choose to implement additional sources of pinning
information, such as through built-in lists of pinning information.
Such UAs should allow users to override such additional sources,
including disabling them from consideration.
The effective policy for a Known Pinned Host that has both built-in
Pins and Pins from previously observed PKP header response fields is
implementation-defined.
That would be perfect...no need to recreate the target site's look and feel. Just whatever js you need to scrape the credentials.
In case the browser sees a new non-EV certificate on a site that was previously EV-certed then it throws an error/warning ?
I suppose in theory for the sacrifice of some latency and processing overhead you could treat SSL/X.509 as busted, explicitly include multiple domains in a given page, cryptographically validate a signature supplied by each to the other (potentially both server side and in javascript), and thereby replace the SSL/X.509 assumptions of trust within the browser.
All this would do is raise the bar for the attacker so they had to hijack all domains at once. By varying them dynamically you could further frustrate.
You could potentially SaaS this (eg. expose an SCP/SFTP endpoint, from which you automatically deploy across disparate domain infrastructure including signatures) and/or provide a passive content-based pinning mechanism as standard, wherein the included JS or HTML raises hell if the version of a site you've received does not match that observed elsewhere. Inefficient as all hell, already attempted at different layers of the stack, but perhaps an idea whose time has come.
If you do this and make lots of money buy me a beer :)