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 :)
[1]: https://blogs.msdn.microsoft.com/ie/2014/03/10/certificate-r...
Certainly, there's ways to see this is going on, but you could, for example, round robin the DNS and only attack a percentage of traffic.
- Let's say that the certificate expire too soon (every year if you don't pay attention) and you didn't replace on time.
- a domain doesn't match (it's fun with CDN, aliases and international sites with domains by countries)
- a subdomain doesn't match (if you enable strict sub domains)
- you test a new certificate and it's not set up right
- it's broken for all non-public certificates, so never try that on test domains, internal domains or private cert chains.
The issue with HSTS is that if any of this happens. Your site is entirely locked down and gives a very scary error to ALL your users. (There is no "ignore certificate" button, HSTS certs errors have a special page).
It gets worse from there. HSTS is IMPOSSIBLE to disable.
The only way to stop it is to send a "HSTS header: 0 duration" header along the page, that you cannot send because all connections are dropped before they are established. You are fucked! (speaking from experience :D).
Last but not least: The HSTS is cached by browsers in a special way. Asking your customers to clear the cache has no effect.
Obviously when you're first rolling it out you should use a short duration to allow for a quick rollback if something goes wrong.
Of course nothing about this truly prevents someone who didn't take proper precautions when setting it up from screwing it up. Unfortunately it's hard to make a more tolerant system without also making it vulnerable again...
Not HKPK.
HSTS says "This domain uses TLS and ONLY TLS. Ignore insecure connections to this domain. Remember this for x seconds." (should be harmless these days, why should it backfire?)
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security...
HPKP says "This domain uses this certificate. Also, remember this and ignore/complain when different in the future." (which is the problematic part)
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#How_It...