Live data from Hacker News

How Hackers Hijacked a Bank’s Entire Online Operation

wired.com

21–30 of 39 posts

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#21
post #17

Earlier quoted context omitted.

HSTS has plenty of issues.

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.

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#22
post #11

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.

   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

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#23
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...)

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#24
post #17

Earlier quoted context omitted.

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 u…

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

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#25
post #23

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…

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

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#26
post #5

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

Although, if the bank realized what was happening, they could shutdown their servers immediately instead of needing to regain control of their DNS.

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#27
post #26

Earlier quoted context omitted.

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

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.

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#28
post #24

Earlier quoted context omitted.

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 u…

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…

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.

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#29
post #7

Earlier quoted context omitted.

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 , and replace it with arbitary text. Like maybe " ". 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.

Re: How Hackers Hijacked a Bank’s Entire Online Operation

#30
post #23

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…

[deleted]
Post reply on HN