oh come on, all you need to do is run rkhunter or chkrootkit regularly (which you should do anyway), and maybe check the 'lsof' list once in a while for suspicious activity. I think clamav may also come in handy.

No scanning program will ever detect everything and can potentially be bypassed.

Don't you know what is going on in the Windows world?
So many new viruses everyday that the antivirus firms have a
hard time coping with the masses.

Window$ is not Linux. I can imagine that there are ways to bypass it, but if you know of all the ways and cover them, then you'll be reasonably safe.

Trust me, you will NEVER be 100% secure and safe from malware, unless you don't use the internet, but even then, a simple USB stick could carry it. On Window$, malware is absolutely impossible to control. I have tried many times and failed every time. On Linux, it's much better.

Isn't that closing the barn door after the cows have left? By the time you discover the keylogger is there, it could have sent the logon IDs and passwords of your admins (and god knows what else) to the hackers.

To expand on what I said, the only solution that will prevent the data loss from a keylogger is to encrypt the data flowing from the keyboard to the application. And it has to be application-specific, so that only the application you're using (be it a web browser or logon screen) can decrypt the characters you're sending from your keyboard to the application. It would do no good if the operating system or another application could decrypt the data, because that would potentially allow the keylogger to get the data.

Yes. If the Ing direct onscreen keyboard were insensitive (buttons unclickable), then users would have no choice but to use the keyboard to enter the randomly mapped keys for their password. In that case, the attacker would have to be both logging keys, and capturing the screen as well.

That's a countermeasure that requires every provider to make an expensive change. An RSA key is useless to a user when the provider doesn't support it. It may be more effective, but not *better*, because of the practicality. To be a better option, it has to be cheap, and not require millions of systems to make a change. OTOH, a tool that functions like the Ing tool could be implemented on the client side (I believe tinfoil hat linux does something like this). And ideally, it would incorporate Jim's suggestion and use crypto in cases where the application were wired for it.

It's not hard to combine a keylogger with screenshot making abilitys.

Well if a banking account is not valuable than I don't know anymore.
I've heard of people who have lost 100.000K $ through keyloggers.

If you really want to believe that the onscreen keyboard is secure you can do so, just a matter of time before the bad side will adjust.

You seem to be thinking of a targeted threat. For the much less common case of a sophisticated and determined attacker targeting a specific individual, sure the countermeasures to mitigate that sort of attack would have to be substantial. The more common threat is distributed and untargeted, where malware would attempt to harvest passwords from a large number of machines, in which case grabbing screenshots is just not practical. An attacker could not stay under the radar with the kind of volume of data that would be involved. It just doesn't make any sense to get screenshots, when an attacker can easily go for the low hanging fruit and grab keystrokes. There are quite enough users who are not protected from keyloggers for attackers to not have to consider dealing with screenshots, which requires a good deal of manual effort. AFAIK, there are no tools that can sort through thousands of images and pick out the interesting ones.
The OPs inquiry is not restricted to banks. I only brought up Ing because they have an effective means to counter the keylogger.

Moreover, when a bank account is attacked, the victim is the bank. Damage to the end user is incidental, and is more a matter of time and effort than lost assets. And sure, it's worth it to banks to spend money on security, even to the extent of issuing tokens/rsa keys and the like. It's common for European banks to do so. I'm not sure why it's not common in the US. But in any case that's the banks choice to make, not the consumers. At best, as consumers, we can only choose between banks, we can't walk up to our existing bank and expect to not get laughed at when we ask for special treatment - to have better security implemented on our account.
There are no absolutes. Being secure is largely a matter of being more secure than the masses.

IMHO, if you have $100,000 in the bank, you should have a computer dedicated for only banking. A contractor had an account at a bank that used the RSA devices. He had malware on his computer that didn't log his password at all, it just waited for him to authenticate normally and open an https session. The malware then transferred $400,000 from his account.

You don't need to target a specific individual, just for example all people who use a certain service. As soon as the programm is opened, or the website, you start making screenshots every click for a few minutes or so. Even if you use a keylogger alone you still have to go through all the data to find the passwords, I don't know of a automated way to do so.

Also you will be under the radar, because the user entered his password without knowing that he had malware running.

Security is only as good as the weakest link in the chain, so if the
users computer is infected with malware then the security is mostly gone. And I don't see how it is the banks fault if the users computer gets infected.

It is just that banks normally give you your money back.

I'm pretty sure banks can't just do whatever they want, there are regulations / laws. Also you are paying them, so I don't see how you don't have any saying.


[QUOTE=jgombos;]
IMHO, if you have $100,000 in the bank, you should have a computer dedicated for only banking. A contractor had an account at a bank that used the RSA devices. He had malware on his computer that didn't log his password at all, it just waited for him to authenticate normally and open an https session. The malware then transferred $400,000 from his account.
/QUOTE]

A live cd should be enough to prevent most attacks from happening.

The problem of session hijacking is one where I don't know how to prevent it. One could for example install a vnc server, and then, as soon as the person is logged in and has typed his password, grab the window onto your own pc and transfer the money.

There's an easier and cheaper solution...

[QUOTE=mase;3745524]You don't need to target a specific individual, just for example all people who use a certain service. As soon as the programm is opened, or the website, you start making screenshots every click for a few minutes or so.
...
Also you will be under the radar, because the user entered his password without knowing that he had malware running.
[/quotes]
That's not under the radar in the slightest. The kind of payloads you're talking about are several orders of magnitude more than any sort of stealthy exploit. It's just too much data to move around the net and expect no one to notice. Malware authors go to extremes build stealthy malware, to the extent of writing assembly code. What you're proposing is to raise absurdly overt flags to collect data that can be collected in a much more concealable fashion. It makes no sense at all to attack with such visibility when you can harvest passwords with footprint that's 1/1000th the size.
It doesn't take much sophistication to only record words that fall in the range of the size of a password, or to activate the logger after reading the string "username" or "password". But even you're sloppy and record all keystrokes for post-delivery analysis, we're still talking very small amounts of data - small enough to harvest from tens of thousands of machines.
My point exactly. If your neighbors links are considerably weaker than yours, you have less to worry about. Most black hats are opportunists, like the car thief that simply checks for unlocked doors rather than bothering to deal with locks and alarms.
It's not a matter of fault. It's law, and liability. And liability is correctly placed on banks, because banks are better equipped to secure accounts, and they're (rightly) expected to be more knowledgeable and diligent about security than laypeople. They're also better equipped legally to prosecute an attacker (lawyers on retainer), and they're financially better equipped to take a loss. It's an incompetent bank that allows their clients accounts to be vulnerable to keyloggers.

From the point of view of a bank customer, the deal is that you give them money and they store it until you want it back (to yourself, pay bills or something else that requires transferring the money off). The point of storing is to keep the money available so you can today access it in a variety of places, for example using a credit card, and to take care of it -- no customer would give their money to a bank that states that they couldn't care less if somebody stole the money. Typically customers also pay some (smallish) amount of money for the banking service, and for that money I personally would expect, at the very least, that they make sure the money is not stolen and if it is, it's not me who pays it (because my only way of making sure it's not stolen from the bank is not to have the money in that bank at all). For this reason banks have insurances and so on.

The banks here use typically a two-stage login procedure to prevent password stealing. First there's the normal id-and-password combination over a https connection, which grants one to enter the "private" part of the site. Then, to view account details or take any actions like transfer money, one is presented with a key, and to continue one must search for a pair for that key from a list of one-time keys (i.e. one keypair is used only once). The session ends if too much time passes without any actions (quite a short time really) or if the page is closed. The customer keys are sent as a paper copy, a couple dozen keys at a time, and when there are only a few left, new list is ordered. The old list is used until the new one arrives, and switching the list then requires a key (if I remember it right, one needs a key from the old list to log in, and a key from the new list to activate it, so both lists are needed at the same time). This makes the life of keyloggers difficult, because in addition to watching the keys they would need to see the (paper) keylist to know what the next key would be. In the past the keys were sorted on the list, but at some point they moved on to random keys, meaning that it's unpredictable which keypair is asked before it is asked.

One bank went even further and spent quite a honorable sum of money to develop a piece of software (in Java) that the client must install in order to authenticate. The point of the software was to collect information from the client computer (it wasn't specified what information, though) and form a sort of fingerprint of it that told the bank the connection was coming from the same computer as before, and not from a neighbour who loaned the keys. I sort of never catched what this was for, because the installation of the software was said to be not as easy as it should, and because people didn't like the bank collecting information about their computer that way. Plus they of course were tied to using that one computer; I guess modifying the computer could also result in the app rejecting the connection, if those parts were modified that the program collected information from. I don't even think it's too effective, because one would still need the keypairs, and if they can be obtained, I don't think a physical access to the machine is so far away anymore.

All in all, I know of and have heard of a horde of ways to prevent stealing passwords, mostly so that the victim didn't know about it before it was too late (stealing the paper containing keys, for example, would trigger the victim to inform the bank of it, which would cause the keys to be changed). Still none of them is good when you start thinking about it, and most of them cause extra work for the end user. It's good security tech evolves, but so does the opposite, and in the end the only one still winning is a company who provides insurances -- everybody pays for them, but most don't get hit and thus insurance gets more than has to pay. Nice.

[QUOTE=jgombos;3745718]And what will be the radar you are talking about? iptables?
How do you configure iptables to differentiate between good and bad
traffic? And since when is it suspicious to move data around on the internet?

The size of the malware itself won't be bigger and it only really matters if you write a trojan, because a text editor that is 10 MB in size is suspicious. And then again you only need a little piece of software that is able to download the actual malware of the net which is what is happening a lot in the windows world.
Once you are in though you can practically do whatever you want.

Just as it doesn't take much sophistication to do the same with a screenshot program. Even if the amount of data in terms of MB is higher,
the actual manual analysis of the data by the attacker will take about as long if you don't record everything.

Malware is getting better and better using even more advanced techniques, and they have to keep producing new malware because otherwise antivirus companys would catchup soon.

The law might protect them which is good, but it likely still was their fault. The bank has no control whatsoever about their customers computers.

I don't think it's a competent bank if it lets its customers vulnerable to the screenshot programs I mentioned. If a bank didn't use one-time password, ideally in combination with some hardware device, I wouldn't trust it for a second. The use of one-time passwords has long been standard in the banking sector at least in germany.

FYI my bank requires three pieces of information to log on, one of which is a 6-digit number which has to be entered via a drop down list for each digit.

Apparently that is not enough because around a year ago they issued an electronic device which requires 3 inputs: a "smart" bank card, a 4-digit PIN and a transaction amount; given these it generates a ?-digit code which must be entered on the site to validate the transaction.

It is an ordinary "high street" bank.

That sounds like a good idea actually, make the transaction key
depend on details of the transaction.

Ideally in a way that it could only be used for this exact transaction.