How Hackers Hijacked a Bank’s Entire Online Operation
wired.comOh, that's bad. Shows how critical DNS control is. They had control for some time because they used it to generate Let's Encrypt certs well ahead of the switch.
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.
I don't know where they got the information about the certificate being issued 5 months prior to the attack, but that's not what Certificate Transparency shows. Here's the certificate that was issued on the day of the attack[1]. Let's Encrypt hasn't issued any certificates prior to that[2].
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
Based on their description of the bank, it appears to have been Banrisul: https://en.wikipedia.org/wiki/Banrisul
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"
Question: can bank defends themselves when the DNS attacked is client-side?
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...)
HTTPS with HSTS would be a mitigation for the attack you describe. An attacker would not be able to obtain a valid certificate for the bank's domain, and HSTS would block SSL stripping attacks as well as prevent users from bypassing any SSL warning pages.
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).
This is what Public Key Pinning is designed to mitigate: you send hashes of your certificate chain with responses, and the browser will disallow subsequent requests for the same domain if the hashes don't match.
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
HSTS has plenty of issues.
For sure HPKP has plenty of issues, but with HSTS you just need to commit to using HTTPS for the next X days. That seems pretty doable, especially with free automated certificates or CAs with enterprise support.
Care to elaborate?
If there is any issue with the certificate. Your site will be entirely inaccessible:
- 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.
With HKPK (which I think you're talking about here - HSTS just requires that https be used at all) expiration is not an issue as you whitelist the key, not the certificate (and are required to list a backup key, which should ideally be offline). By listing the server's own key, possibly in addition to a trusted CA, you ensure that in the worst case you can renew using the same key.
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...
I am definitely talking HSTS. You only need HTTPS enabled and send the "Strict-Transport-Security" header. It is very easy to setup, it can also backfire pretty bad.
Not HKPK.
I still think you have this wrong:
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...
You don't seem to understand. Read again, I gave many scenarios where a certificate will be invalid, that will block all access to your site if HSTS is enabled.
I read your posts. Your examples apply to HKPK (key pinning), not HSTS (enforcing TLS only).
My examples are for HSTS. I gave examples where a certificates is invalid. TLS fails when the certificate is invalid and HSTS blocks access to your site.
Could certificate pinning have mitigated the damage? Although service would have been denied until the DNS was back under control, that's better than leaking credentials and cards and security questions and account balances.
It can also be used maliciously by the attackers too: they could set HPKP to their own certificates with a 5 year expiry time, then sell them to the bank after DNS is reverted. The bank might pay to have all those chrome/firefox users back.
Presumably there is a manual process to ask browser maintainers to invalidate fraudulent pins. Hell, list maintainers could charge a processing fee to ensure manual review of each case, and frequent update cycles that don't require browser restarts. The spec makes this possible but not necessary or even outlined, which I think is an oversight.
https://tools.ietf.org/html/rfc7469#section-2.1UAs 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 is a truly brilliant use of certificate pinning and strict transport policy.
Real time scanning certificate transparency logs (and DNS changes) would probably be a good idea as well. I don't know how much time they lost figuring out it was actually an attack. Oh, and using a domain registrar that's educated about social engineering...though I don't know that you have much choice in the matter for .com.br.
Yes, this is exactly the thing that HPKP would prevent from happening.
Not supported in IE or Edge though, right? So it would still catch some end users.
Banrisol currently has a message up on their home banking portal that Firefox isn't supported.
That's right, they don't have a pinning mechanism for site operators. They have something called Certificate Reputation[1] which works alongside SmartScreen and should theoretically be of use for attacks like this, but I haven't heard much about it and I don't know if it helped here.
[1]: https://blogs.msdn.microsoft.com/ie/2014/03/10/certificate-r...
My bank returns an icon I chose after I enter my username, I think that would have helped me recognize something was wrong.
Hijacking dns means that when you connected to the bank's website you would connect to their servers first and then they could have just proxied your connection to the real servers, that image->username check wouldn't have saved you from it since the bank's servers still operated normally
Nginx, in proxy mode, even has a nice sub_filter where you can rewrite the response body. Pick a tag that generally occurs once, like </head>, and replace it with arbitary text. Like maybe "</head><script src="whatever"></script>".
That would be perfect...no need to recreate the target site's look and feel. Just whatever js you need to scrape the credentials.
and now the bank just have to block Google's cloud ip range.
The idea is the bank may not notice, since the site would be functional and serving customers.
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.
Although, if the bank realized what was happening, they could shutdown their servers immediately instead of needing to regain control of their DNS.
The bank's servers were unlikely to be involved at all. If the compromise happened at the registrar level - as the article indicates - the attackers could use their own DNS and web servers.
But then the attackers wouldn't know what icon to show each customer (if the bank were using the system described above by emondi).
That's right. Ah, the dangers of replying to new comments without re-reading their parent. :-)
Instead of the cert key pinning as it's easy to obtain an SSL cert (with LE) coudn't we imagine that as banks do own EV certificates that the browser remembers them.
In case the browser sees a new non-EV certificate on a site that was previously EV-certed then it throws an error/warning ?
So to protect against this, don't have all your domains registered at the same place?
Interesting line of thought.
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 :)