jgombos

[Log in to get rid of this advertisement]

US-CERT, for one, detects attacks that are far stealthier than the sloppy low-tech approach of disclosing screen shots on a distributed scale. And at the corporate level, snort would catch it. And even the non-technical home user knows to question the sudden extra hard drive activity that would occur with every click.
It's not the fact that data moves that's suspicious, but /how/ it moves. Intrusion detection tools develop a statistical awareness of the types of data moving, and the direction it moves in, including a number of characteristics of the data. It also keeps general statistics on overall egress network bandwidth consumption. General sensors would trip even if the attacker were to attempt to spoof the payload inspection.
The malware itself is not inherently more or less detectable than the same malware that simply logs keystrokes. But it's the astronomical size of the captured information being disclosed that makes the idea foolish and unworkable. The tedious labor intensive process of extracting the sensitive bits in a usable form is show stopper alone, considering the alternative can be automated.
This is like saying the guy who grabs a $100k in chips from a casino table is in the clear if he can make it to the getaway car. Nevermind all the cameras and facial recognition data the prosecution has. And the fact that you still need to cash the chips in before you become a suspect. Collecting the information is the easy part. It's the not getting caught part that matters.
This is my point. The idea is to have better security than the masses. But capturing screens would be a low-tech step back, because it lacks the stealth of todays attacks - and in fact attacks a decade ago were stealthier.
The bank cannot use this as an excuse for their lack of due diligence in securing their systems. Banks that simply take a conventional and traditional username and password cannot claim diligence, so their lack of control over the customers computer isn't even worthy of mention. If the bank is wholly diligent, and can establish in court that they bent over backwards to secure logins with at least something you have and something you know, only then is it relevant to question the account holder. You can't fault the masses, when the bank knows full well what kind of security most end users tend to have. The bank is reckless if they don't design their security system with this in mind - and it's unreasonable to expect the average Joe to have as much as a CISSP understanding of security, or even know the meaning of the word malware.
Of course it is. Competent security professionals do risk assessments. It comes down to the bottom line. It's very unlikely that someone would attempt the attack you're talking about on a distributed basis. The cost of altering the security policy and forging tools to counter it quickly exceeds the money they would pay in damages (probability of the attack multiplied by the potential loss). It doesn't make sense to spend money on every obscure or unlikely corner case scenario, because the cost of security begins to erode the business case.
Agreed. That counters all kinds of threats and reduces vulnerability significantly. But it's not the screen cap threat that prompts it - it would be an absurd expense if that were the only threat being countered. One time passwords protect from the very real threat of keyloggers.

mihalisla

So, after all this discussion I feel that a live cd would be the solution but....
1. the live cd should be in position to interact with the bank's site without any changes in the programs installed by default
2. the live cd should not allow any changes to the system (not even RAM after boot) ,not even an installation of a cookie

I don't know if my suggestions are applicable to a system but I like the idea.


P.S World's changes come from small ideas

Jim Bengtson

I wonder if anyone's put together a live CD with a version of Linux that is pared down to the bare bones necessary to support a browser (TCP/IP, Firefox, javascript, and Java(?)), and is hardened. It's purpose would be a bootable, secure browser and nothing else, so you could use it for banking, secure transactions, and for venturing where the malware is thick.

Being Linux, most malware won't work anyways. Being a live CD, any virus infections disappear when you reboot, so it wouldn't matter.

The logo would be Tux in an enviro-suit.

win32sux

It would be neat for the CD to put you in a VM by default too, in order to make it more difficult for an attack to propagate onto your hard disk. That is, assuming that unplugging the hard drive every time would be too inconvenient.

Jim Bengtson

I suppose you could build the custom Linux kernel for the live Cd so that it didn't know anything about hard drives...

win32sux

Yeah, and without any module loading capability. Plus all browsers run in a VM, and everything restricted by SELinux. There should also be a memory overwrite script on shutdown, to prevent cold boot attacks*.

Some nice paranoia-themed music would be nice too.


*At least some of them.

Jim Bengtson

Band: Bugs In the Dark
Song: Paranoia
http://www.vimeo.com/2375755

mihalisla

I Have a crazy idea :
To establish an encrypted relationship between the RAM and the system . . .
It gets even better now....... :
The type of the encryption could be the "one time password "(in every boot one random password from the user) that is mathematically uncrackable
So no matter how many times the cracker (even with quantum processor) tries to crack the system it would be impossible

PS. And moreover as win32sux said