Hackers Hit 100 Banks

[x9200]

Hackers Hit 100 Banks in 'Unprecedented' $1 Billion Cyber Heist: Kaspersky Lab.

http://www.securityweek.com/hackers-hit ... persky-lab

According to the report, the spear phishing emails contained attachments with weaponized Microsoft Word 97 – 2003 (.doc) and Control Panel Applet (.CPL) files. The malicious files exploit Microsoft Office (CVE- 2012-0158 and CVE-2013-3906) and Microsoft Word (CVE- 2014-1761) to execute shellcode, which decrypts and executes the Carbanak backdoor

I just don't get how something like this is possible. The banking staff just can open some attachments on their PCs that are connected to internal, supposedly secured network, nobody verifies on system level the attachments or what?

[zzm9980]

I just don't get how something like this is possible. The banking staff just can open some attachments on their PCs that are connected to internal, supposedly secured network, nobody verifies on system level the attachments or what?

It only takes one employee f-ing up and opening them to breach the network. 100% security is impossible. It's like ants in your condo/hdb. You can keep cleaning and spraying, patching holes, etc, but given time they'll find another way in.

[x9200]

Yep, no doubts but this is the whole point – such obvious human errors should be addressed. Why do they need to open (Internet) emails on the machines within the secure internal network? I am not a banking IT security specialist but it seems to me like some serious security architecture flaw.
1. The only direct Internet access to the intranet should be low privilege, individual client based
2. Any machines on the intranet (including inter-division secure vpn and alike) should not be able to receive external emails or, less secure, all the emails originated from outside the bank networks and containing attachments should be rejected.

[zzm9980]

Yep, no doubts but this is the whole point – such obvious human errors should be addressed. Why do they need to open (Internet) emails on the machines within the secure internal network? I am not a banking IT security specialist but it seems to me like some serious security architecture flaw.
1. The only direct Internet access to the intranet should be low privilege, individual client based
2. Any machines on the intranet (including inter-division secure vpn and alike) should not be able to receive external emails or, less secure, all the emails originated from outside the bank networks and containing attachments should be rejected.

So do you propose air-gapped networks? Two (or more) computers on everyone's desk that have no ability to communicate with each other? What if you need to email some figures or a screen shot from a "secure" system to someone else? How do you get the data over? Security is a balance with usability. You can't make something so secure that it isn't usable, because then your "security" ends up costing your business more money than any potential breach.



Generally you have a bunch of connected networks (VLANs) with access controls (ACLs on your routers/switchs, or better firewalls) restricting traffic that passes between them. The problem is, there has to be some kind of way in for people to manage the system on the other side.

What happens in cases like this usually is someone opens an attachment, allowing their laptop to get compromised. The hacker/whatever has a beachhead on the desktop network. They compromise more systems on the same network (generally most desktop systems) until they find one with useful internal credentials or that belongs to an IT admin. This is easy because most of the systems will have the same configuration and patch (or lack of) level. Find a flaw in one system, own them all. Or, there are local "it admin" accounts for support that they crack the password for and find the same password gives them local admin on every other desktop device.

If they compromise the device for a sys admin, they just use whatever access he normally has to manage systems to compromise further. Or (and often easier) they can just find internal-only web applications that have significant vulnerabilities and compromise those directly from the desktop. They are often not patched because the IT Support team will say "It's inside the firewall!" and shitty companies like Oracle don't like to even release patches. These are the systems with all of the juicy data anyway.

[rajagainstthemachine]

The other day i went to some citibank office in Holland village , they are still using windows XP
like wtf! even MS said that the OS is vulnerable, maybe its not just the network security alone, it could also mean using older/unsupported software that compounds it.

[x9200]

So do you propose air-gapped networks? Two (or more) computers on everyone's desk that have no ability to communicate with each other?

We are talking about the human error so probably even a VM based solution on a single physical machine would be much safer than co-sharing mail clients. It is clearly about lots of $$$$ so even air-gapped networks could IMHO be a possibility.
Anyway, in the discussed case it was enough to reject e-mails not originated from the bank's networks and containing attachment or even to scan such attachments not allowing any executable parts. This could be done for peanuts.

What if you need to email some figures or a screen shot from a "secure" system to someone else? How do you get the data over?

One way only access (de facto or even true)? You can send but not receive. Still much safer to what apparently is today and causing minor inconveniences only.

Security is a balance with usability. You can't make something so secure that it isn't usable, because then your "security" ends up costing your business more money than any potential breach.

I am aware of this but it looks like it was as much secure as an average office around and clearly it cost the banks lot of money. IMHO if you have this sort of facility security should come slightly before the usability.

Somebody wanted to have it cheap and with the full usability and now they pay and will pay the price. No wonder no bank officially admits to what happened.

[zzm9980]

So do you propose air-gapped networks? Two (or more) computers on everyone's desk that have no ability to communicate with each other?

We are talking about the human error so probably even a VM based solution on a single physical machine would be much safer than co-sharing mail clients. It is clearly about lots of $$$$ so even air-gapped networks could IMHO be a possibility.
Anyway, in the discussed case it was enough to reject e-mails not originated from the bank's networks and containing attachment or even to scan such attachments not allowing any executable parts. This could be done for peanuts.

See, you're trying to solve human error in opening an attachment they shouldn't by instituting a complex (for most average bank employees at least) solution involving VMs?

You can't reject external emails as banks deal with businesses, customers, and partners, and guess what - they email each other. And sometimes, details of those emails (statements, applications, orders, etc) will need to be entered into a transactional system to update account details and such. You can't tell people to manually transcribe those details over between VMs/air-gapped systems/whatever.

What if you need to email some figures or a screen shot from a "secure" system to someone else? How do you get the data over?

One way only access (de facto or even true)? You can send but not receive. Still much safer to what apparently is today and causing minor inconveniences only.

This is done now normally with network services that pull into more sensitive zones (as oppose to allowing data to be pushed), firewall policies, etc., but isn't a real solution. It's just a minor mitigation.

Security is a balance with usability. You can't make something so secure that it isn't usable, because then your "security" ends up costing your business more money than any potential breach.

I am aware of this but it looks like it was as much secure as an average office around and clearly it cost the banks lot of money. IMHO if you have this sort of facility security should come slightly before the usability.

Somebody wanted to have it cheap and with the full usability and now they pay and will pay the price. No wonder no bank officially admits to what happened.

Yes they will, and it will be expensive for the bank (or their insurance) that it happened to. But the thousands of banks that aren't affected? They'll continue to skate by and not pay for the upgrades.

You have to realize, that security is also implemented by humans and the industry has a huge talent shortage. Even if you have the money to build a more secure environment and associated processes, the hard part is finding someone competent to hire to help your and your (likely also incompetent) IT team to implement it. You can't just buy something and forget it either. Opportunity cost for an attacker is a multiple orders of magnitude cheaper than the cost to defend against the possible one day attack. Semi-organized gangs in third-world countries can earn millions on these attacks for almost no cost, where as the banks/whomever has to invest tens of millions annually to try to ward them off.

[maneo]

We are talking about the human error so probably even a VM based solution on a single physical machine would be much safer than co-sharing mail clients. It is clearly about lots of $$$$ so even air-gapped networks could IMHO be a possibility.
Anyway, in the discussed case it was enough to reject e-mails not originated from the bank's networks and containing attachment or even to scan such attachments not allowing any executable parts. This could be done for peanuts.

See, you're trying to solve human error in opening an attachment they shouldn't by instituting a complex (for most average bank employees at least) solution involving VMs?

You can't reject external emails as banks deal with businesses, customers, and partners, and guess what - they email each other. And sometimes, details of those emails (statements, applications, orders, etc) will need to be entered into a transactional system to update account details and such. You can't tell people to manually transcribe those details over between VMs/air-gapped systems/whatever.

A competent IT group should be able to quarantine attachments and release them to the addressee when requested (and after scanning). As in this case, banks must follow this kind of discipline.

[x9200]

I think zzm plays a bit the devil's advocate. He is perfectly aware that all these (VM or other solution) can be easily implemented to be completely transparent with the same or lower complexity to what is probably in the banks today.

[zzm9980]

A competent IT group should be able to quarantine attachments and release them to the addressee when requested (and after scanning). As in this case, banks must follow this kind of discipline.

Correction, A competent IT group could be able to install a solution which markets itself as able to quarantine attachments, but they seldom function as advertised. The IT Security industry is loaded with more snakeoil than most other tech areas. These solution generally don't work as advertised, and you're lucky when they catch known trojans or viruses. They're almost always useless for any new unknown (zero-day) threat. And these are quite common now, especially when a lot of money is the potential prize.

I think zzm plays a bit the devil's advocate. He is perfectly aware that all these (VM or other solution) can be easily implemented to be completely transparent with the same or lower complexity to what is probably in the banks today.

No offense, but you speak as either an academic or "CSO Magazine"-reading white-shirt that has no practical experience engineering or deploying the solutions you're espousing. Solutions like this are *hard* to do right, and never full-proof. None of us have anyway of knowing if these banks actually did have a product in place (FireEye, PAN, etc) which does claim to do this and it was just missed.

And I'm not saying the banks SHOULDN'T be doing these things, just that everyone has to be realistic that the problem is much harder to solve than just setup a few gee-whiz solutions.

It is orders of magnitude easier and cheaper to attack than it is to defend.

[ecureilx]

,

Correction, A competent IT group could be able to install a solution which markets itself as able to quarantine attachments, but they seldom function as advertised. The IT Security industry is loaded with more snakeoil than most other tech areas. These solution generally don't work as advertised, and you're lucky when they catch known trojans or viruses. They're almost always useless for any new unknown (zero-day) threat. And these are quite common now, especially when a lot of money is the potential prize.
.

Reminds me of the time I was doing pre-sales for an EAL4 firewall

[x9200]

No offense taken zzm. I am not even in the IT industry, but I have some good idea what is the process alike on industrial basis. I worked as a product developer, full path from proving the concept all the way to mass production counted in millions where one day of the line-down translates to 5-6 digit loses. For every product development there are some common stages so I believe even without formal IT education I can speculate a bit on the subject.

No doubts, you are right if we see this VM (or anything) as a solution to what just and already happened but this is not what I actually meant. This system was implemented some time ago and had to undergo the release process. It probably took more than 2 years to have it developed and tested. It is beyond me that during this whole product development process nobody addressed such issues and relied on the solution prone so much to human errors. This is what I see as a fundamental flaw in the security architecture. If the solution (whatever it would be) was a part of the basic product development it would have cost peanuts and be a part of all the testing scrutiny and foolproof making along with all the other components of the system, or not?

[maneo]

A competent IT group should be able to quarantine attachments and release them to the addressee when requested (and after scanning). As in this case, banks must follow this kind of discipline.

Correction, A competent IT group could be able to install a solution which markets itself as able to quarantine attachments, but they seldom function as advertised. The IT Security industry is loaded with more snakeoil than most other tech areas. These solution generally don't work as advertised, and you're lucky when they catch known trojans or viruses. They're almost always useless for any new unknown (zero-day) threat. And these are quite common now, especially when a lot of money is the potential prize.

My reply was not based on a hypothetical situation, but rather actual practice of high-tech companies that did this.

From what I could tell, they did not rely only on attachment scanning, but seemed to err on the side of stopping almost all attachments and forcing recipients to request specific attachments when needed.
It was a tough protocol, but the alternative of letting viruses through was unacceptable.
Would think that banks should have this same kind of mindset.

[zzm9980]

This is what I see as a fundamental flaw in the security architecture. If the solution (whatever it would be) was a part of the basic product development it would have cost peanuts and be a part of all the testing scrutiny and foolproof making along with all the other components of the system, or not?

Yes, you're right on this. Unfortunately this doesn't happen in reality.

[zzm9980]

My reply was not based on a hypothetical situation, but rather actual practice of high-tech companies that did this.

From what I could tell, they did not rely only on attachment scanning, but seemed to err on the side of stopping almost all attachments and forcing recipients to request specific attachments when needed.
It was a tough protocol, but the alternative of letting viruses through was unacceptable.
Would think that banks should have this same kind of mindset.

All of my replies are based on my career and work experience, being focused on exactly this subject matter.

The system you describe above will break down for two reasons:
1) It is impossible to scan and detect all (or even most) hostile attachments. Current technology sucks at this, it is much easier to evade than detect.

2) All this does is add an extra step between opening and email and opening the attachment. When you do this to every attachment, you train the user to just click through and download whatever looks interesting. Targeted attacks like this are generally using "interesting" looking attachments to some target user-audience, so they *will* click through to download. Hide your attack as a resume and send it to recruiters, invoice and send it to AP, etc. Now you have an expensive system that is an additional layer of complexity to maintain, and you're adding friction to your user's lives for nearly zero gain.