Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Hackers Hijacked a Bank’s Entire Online Operation

wired.com

Post reply on HN
Print view View original

31–39 of 39 posts

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

#31

Post by DennisP »

pfg wrote: post #27
bhtp wrote: post #26

Earlier quoted context omitted.

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

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

#32

Post by pfg »

DennisP wrote: post #31
pfg wrote: post #27

Earlier quoted context omitted.

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

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

#33

Post by tyingq »

gcb0 wrote: post #29
tyingq wrote: post #7

Earlier quoted context omitted.

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.

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.

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

#34

Post by contingencies »

chiph wrote: post #8

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

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

#35

Post by 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 ?

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

#36

Post by okket »

user5994461 wrote: post #28
bdonlan wrote: post #24

Earlier quoted context omitted.

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.

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

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

#37

Post by user5994461 »

okket wrote: post #36
user5994461 wrote: post #28

Earlier quoted context omitted.

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

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.

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

#38

Post by okket »

user5994461 wrote: post #37
okket wrote: post #36

Earlier quoted context omitted.

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

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

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

#39

Post by user5994461 »

okket wrote: post #38
user5994461 wrote: post #37

Earlier quoted context omitted.

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.
Post reply on HN