The hijack was so complete that the bank wasn’t even able to send email
April 8, 2017 10:49 PM   Subscribe

Researchers at the security firm Kaspersky on Tuesday described an unprecedented case of wholesale bank fraud, one that essentially hijacked a bank’s entire internet footprint.
posted by Chrysostom (23 comments total) 24 users marked this as a favorite
 
It's worth reading for how insane the whole thing was. As I'm reading down the article I keep getting to points where I think "well that obviously won't work, because X", and then they explain how they had X covered - like of course they had valid SSL certificates for the hijacked domains .

I would definitely watch the heist movie.
posted by Dr Dracator at 11:26 PM on April 8, 2017 [2 favorites]


And those sites even had valid HTTPS certificates issued in the name of the bank, so that visitors’ browsers would show a green lock and the bank’s name, just as they would with the real sites. Kaspersky found that the certificates had been issued six months earlier by Let’s Encrypt, the non-profit certificate authority that’s made obtaining an HTTPS certificate easier in the hopes of increasing HTTPS adoption.
So herein lies the problem. Let's Encrypt can only issue domain-validated certificates. This is not the same as "in the name of the bank" (EV). Essentially if the attacker can pwn the domain (by compromising the account at the NIC), they can create their own valid DV cert, and this is how the system is designed to operate.

The problems is that the user isn't likely to notice the change of certs, even if theres's a change from EV/OV to DV. And this is why I think it's absolutely essential to have pubkey pinning supported. Standard key-pinning could have helped, but for now I use this annoying client-side addon, Cert Patrol, which nagges me whenever a cert changes. You get a nice diff and summary of the changes, and this works no matter the server supports pinning or not.
posted by runcifex at 11:30 PM on April 8, 2017 [18 favorites]


I'm assuming my Dutch bank account would be impervious to this because in order to move money out of the account online (even after I've logged into the bank's website and even when shopping online) I have to put my card in a card reader and do a challenge and response sequence with my pin and generated codes, secureID-style. I wish my US bank did a similar thing.
posted by antinomia at 11:41 PM on April 8, 2017 [2 favorites]


Why has the bank not disclosed this? I assume they informed their customers; if not, I think the moral thing to do is disclose the name of the bank.
posted by maxwelton at 12:43 AM on April 9, 2017


Why has the bank not disclosed this?

https://en.wikipedia.org/wiki/Banrisul#Security links to an October 2016 article that has a statement from the bank.
posted by effbot at 12:58 AM on April 9, 2017 [1 favorite]


Okay that's terrifying. Guess I need to open an account in my mattress after all.
posted by Mchelly at 4:26 AM on April 9, 2017 [3 favorites]


This is awkward...
posted by certs at 6:27 AM on April 9, 2017 [9 favorites]


None of this is a surprise, it's a pretty straightforward attack. The role of Let's Encrypt is a bit worrying coming on the back of other reports of Let's Encrypt being used in fraud. Those other reports are mostly about certs for crummy fishing domains like customers.brazilbank.br.dontlookhere.com; if you're paying attention you can spot the fraud. This report looks like they got certs for customers.brazilbank.br itself. As Let's Encrypt points out their system is working as designed, but it sure does confuse users. It's no longer enough to verify a site has a valid SSL certificate with the expected URL, you now need it to be an EV cert.

All this is a consequence of SSL's security model being crappy. On one hand it's the only way on the Web to provide low level cryptography, some basic privacy and MITM protection. Let's Encrypt does this. On the other hand it's also used to establish identity, but really only expensive EV certs do that. They don't do it particularly well either; there's several reports a year now of bad certs being issued. Symantec's entire right to create EV certificates is about to be taken away, for instance, because they kept issuing fraudulent certs.
posted by Nelson at 6:45 AM on April 9, 2017 [3 favorites]


The guys on the Risky Business podcast discussed this a week ago. They came down somewhere between guffaws and shocked silence.

But yeah, the whole certificate infrastructure that enables modern web commerce is at the root of this whole caper.
posted by wenestvedt at 6:46 AM on April 9, 2017 [2 favorites]


This was the first thing I looked at after finishing the recent New Yorker article about the obsession with immortality in Silicon Valley, which contains this chestnut from Ray Kurzweil:

When we cross Bridge Four, those same nanobots will connect our brains to a neocortical annex in the cloud, and our intelligence will quickly expand a billionfold. Once that transformation happens, in 2045, the Singularity occurs and we become like gods. “For a time, we’ll be a hybrid of biological and nonbiological thinking, but, as the cloud keeps doubling, the nonbiological intelligence will predominate,” Kurzweil said. “And it will be anachronistic, then, to have one body.” He raised his arms slightly and squinted at them, a carpenter troubled by a burl in the wood.

So, if I eat well and keep running, I just may live long enough to see Russian mafia hackers pwn Peter Thiel's actual brain! This truly is an age of wonders.
posted by ryanshepard at 7:18 AM on April 9, 2017 [33 favorites]


I just may live long enough to see Russian mafia hackers pwn Peter Thiel's actual brain!
How do we know this hasn't already happened? It would explain a lot.
posted by oneswellfoop at 8:36 AM on April 9, 2017 [5 favorites]


Before we go off down the route of keeping money in our mattress, please remember that the money that is getting stolen is not your money.

Up until the point the bank goes bust,at least.
posted by fistynuts at 8:54 AM on April 9, 2017


This was the first thing I looked at after finishing the recent New Yorker article about the obsession with immortality in Silicon Valley, which contains this chestnut from Ray Kurzweil:

I have to finish that. My impression so far is: these are not the people who I want to have an extended life span.
posted by thelonius at 8:55 AM on April 9, 2017 [7 favorites]


None of this is a surprise, it's a pretty straightforward attack. The role of Let's Encrypt is a bit worrying coming on the back of other reports of Let's Encrypt being used in fraud.

Traditional issuers are not immune to this kind of thing, either. COMODO in particular has been involved in shenanigans, I believe. I don't remember the details (IIRC, it was something about issuing intermediate CA certs to malicious parties), but it was bad enough that I removed them from my trusted keystores on all my devices.

Anyway, Let's Encrypt is really just revealing a long-standing issue with SSL. As Taylor Swift likes to say, trust is not transitive.

Or, to put it another way: a successful SSL handshake only proves that one of the CAs or their authorised agents believes that the certificate holder has the right to use a domain. It doesn't prove that they do, and it doesn't prove that they are who they claim to be.
posted by tobascodagama at 10:56 AM on April 9, 2017


DNS hijacking is so lucrative to scammers that if you're big enough, you can't trust a 'normal' registrar that lets you just login to some web portal to change settings - you need a registrar that makes it stupidly hard - there's a very short list of people who can even change it in the first place, and they need to do it in-person and with government issued ID. Assume scammers have already spearphished their way into your accounting department and have stolen all the billing details the registrar has on file.

The real problem here is Let's Encrypt and their response. Their goal of SSL-for-all is laudable, but they have to add some sort of friction to make this harder to pull off. Even something simple like a mandatory 24-hour waiting period for new domains. The worst isn't that Let's Encrypt took shocking long to revoke the 'bad' cert (months), (or the known issues with cert revocation lists,) but that they're acting like there's nothing for them to do.

In terms of banks getting hacked, you'd hope SWIFT as a whole were better secured, but as was publicized last year, apparently not. Kaspersky Lab has a fascinating, if terrifying, article about some the details about attacks against EU banks by the same group as the Bangladesh heist (though no relation to the linked Brazilian bank heist).
posted by fragmede at 11:47 AM on April 9, 2017 [2 favorites]


Or, to put it another way: a successful SSL handshake only proves that one of the CAs or their authorised agents believes that the certificate holder has the right to use a domain. It doesn't prove that they do, and it doesn't prove that they are who they claim to be.

I never quite figured out why my shitty little Lightsail instance has host key fingerprinting enabled by default but the web doesn't.
posted by Talez at 6:18 PM on April 9, 2017


I'm not an expert on the inner workings of the Internet, so what I am going to suggest here may well be hopelessly naive, or otherwise wrong, but...

No one is REQUIRED to use the DNS system to connect to a web URL. DNS' job is to translate web addresses in familiar text format ("metafilter.com", for example) into a server's "real" numeric IP address in dotted-quad format (54.186.13.33, in the case of metafilter.com), but there's nothing stopping you from entering the numeric address into your browser's address bar and bypassing the DNS lookup entirely.

So if you're concerned about DNS hijacking happening at your bank's online presence, why not jot down their numeric address and manually enter it every time you need to do online banking? Assuming that you get the correct IP address BEFORE a bad guy has hijacked their domain name, it should take you to the bank's real pages instead of the bogus ones even after DNS lookups are compromised.

You can find the dotted-quad associated with a website address by running 'ping' on the address in a terminal window (or DOS prompt in a Windows system). For that matter, if pinging a URL suddenly starts turning up a different numeric address than before, then that might be a clue that there are some shenanigans afoot.

I realize that this strategy depends on the premise that the dotted-quad returned by DNS for a given site is static, which is not guaranteed to be true, and that's probably the fault in my logic here. However, I suspect that in the absence of major overhauls of a site that involve switching servers, numeric addresses would tend to remain relatively static. This is purely a guess on my part though, I'm sure there are folks here that are more knowledgeable who can chime in.

So, any real experts wanna say why this is a stupid idea, please clue me in -- thanks!
posted by TwoToneRow at 6:42 PM on April 9, 2017


For that matter, if pinging a URL suddenly starts turning up a different numeric address than before, then that might be a clue that there are some shenanigans afoot.

Load balancing and multiple IP ranges throw that out the window. Like for instance an Australian bank might have one group of addresses 58.6.* and another that are 203.178.*. You don't know which are valid. This is a trust issue that needs better solutions to fix and it'll probably have to start with a hardware security module establishing a bank's identity.
posted by Talez at 6:55 PM on April 9, 2017 [2 favorites]


why not jot down their numeric address and manually enter it every time you need to do online banking?

Among other reasons, it won't work because the modern web requires hostnames in the URL. To take a specific example, MeFi's IP address at the moment seems to be 54.186.13.33. http://54.186.13.33 actually works but just redirects to http://www.metafilter.com. Which is more generous than most sites, but still if that DNS entry were hijacked I'd be caught. https://54.186.13.33 doesn't work at all, I get an SSL error. If I ignore that error I'm redirected back to the (non-SSL) http://www.metafilter.com.

More generally lots of Web infrastructure assumes IP addresses can change frequently, maybe even every single page load. Like Talez says load balancing does this frequently. So does modern cloud server deployment, like Amazon's EC2 cloud servers. www.google.com's IP address could be any of (guessing) 1000 things and still work.

On top of that you'd still need to validate that 54.186.13.33 was actually in control of who you expect to be running Metafilter and not, say, hijacked via BGP. I'm not sure you can even issue an SSL certificate to an IP address. Even if you could you'd still have problems like what caused this attack.
posted by Nelson at 7:39 PM on April 9, 2017 [2 favorites]


So... how can I confirm that I'm reading the legit MeFi and not the alterweb version engineered by the Cabal?
posted by cosmologinaut at 10:26 PM on April 9, 2017 [2 favorites]


there is no cabal
posted by mephron at 10:39 PM on April 9, 2017 [3 favorites]


I have to finish that. My impression so far is: these are not the people who I want to have an extended life span.

I might be missing something, but having spent the past ~5 years paying close attention to the computer security lit for work, w/a focus on IoT security, the belief in an internet-enabled immortality (obvious philosophical problems aside) is quite literally some of the dumbest shit I have ever heard.

I mean, we can't even secure a smart thermostat with any degree of reliability. Or, rather (and I think this is real crux) we won't.
posted by ryanshepard at 9:21 AM on April 10, 2017 [4 favorites]


Ok, I kinda figured that was a naive idea, based on my simplistic understanding of how DNS works -- a good example of how a little knowledge can be a dangerous thing. Thanks for the explanation, y'all.
posted by TwoToneRow at 9:39 AM on April 10, 2017 [1 favorite]


« Older Poor little sister, I hope you understand   |   Who else could substitute for Chris Squire? Newer »


This thread has been archived and is closed to new comments