
How Hackers Hijacked a Bank’s Entire Online Operation - bjxrn
https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/
======
tyingq
Oh, 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.

~~~
pfg
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](https://crt.sh/?id=47675898)

[2]:
[https://crt.sh/?Identity=%25.banrisul.com.br&iCAID=16418](https://crt.sh/?Identity=%25.banrisul.com.br&iCAID=16418)

[3]: [https://crt.sh/?id=47630635](https://crt.sh/?id=47630635)

------
tyingq
Based on their description of the bank, it appears to have been Banrisul:
[https://en.wikipedia.org/wiki/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"_

------
speeder
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...)

~~~
pfg
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).

------
bckygldstn
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_Public_Key_Pinning)

[https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

~~~
user5994461
HSTS has plenty of issues.

~~~
daveguy
Care to elaborate?

~~~
user5994461
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.

~~~
bdonlan
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...

~~~
user5994461
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.

~~~
okket
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...](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#HSTS_mechanism_overview)

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...](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#How_It_Works)

~~~
user5994461
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.

~~~
okket
I read your posts. Your examples apply to HKPK (key pinning), not HSTS
(enforcing TLS only).

~~~
user5994461
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.

------
based2
[https://www.theregister.co.uk/2017/04/05/hackers_take_over_b...](https://www.theregister.co.uk/2017/04/05/hackers_take_over_banks_dns_system/)

[https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)

------
btown
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.

~~~
bckygldstn
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.

~~~
btown
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.

    
    
       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.
    

[https://tools.ietf.org/html/rfc7469#section-2.1](https://tools.ietf.org/html/rfc7469#section-2.1)

------
emondi
My bank returns an icon I chose after I enter my username, I think that would
have helped me recognize something was wrong.

~~~
elsombrero
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

~~~
tyingq
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.

~~~
gcb0
and now the bank just have to block Google's cloud ip range.

~~~
tyingq
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.

------
mirages
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 ?

------
chiph
So to protect against this, don't have all your domains registered at the same
place?

~~~
contingencies
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 :)

