How to prevent spying keyboard input
 

Hi,
I just made a script to read out /dev/input/event3 into a file (My keyboard is identified here [ Machine is a laptop which runs on slax-atma distro ]).
Then used a hexdump to convert the binary into hex.
After that used a gwak script to print out the keys corresponding to each keyboard input.
So now when I put this in my rc.local , It is taking down all the keys I press. Including login passwords (In short, each and every keys I press).
Isn't this a big security risk, because intruder who has a physical access to my machine or has root password can put this file in rc.local and run a script to mail him all the details like my passwords, account and PIN numbers.
How can I prevent anyone from doing that?
Thanking you in advance.
Joe

Most interesting, I didn't know this was possible, but it seems like it is possible.

Well, to prevent this you have to prevent anyone else from gaining root access, because you need root access to be able to do this. Once someone has rooted your system, you're pretty much screwed anyway. So, use a strong root password, disable remote login if possible, use a firewall, run chrootkit and rkhunter regularly, etc.

Is locking up the only solution?
 

Hi,
Thanks a lot for the tips.
So does it mean that only our locked up computer which we are sure that nobody other than us have access is secure for banking and other purposes?
Because otherwise anybody can boot any machine with a live linux cd, and put this keyboard spy script as root in my rc.local. Then the intruder will get everything including my root password...
Any way to prevent such root access by booting from live cds?
I mean some way of encrypting the linux OS files in my hardisk so that they cannot change anything?
Thanking you,
-Joe

It is alarming!! Attention!!
 

Hey, I think Indiajoe has a a point. It is not personal laptop (as in case) that we use. In many public places we have to login perhaps to check e-mail or any such. If it is so easy to squeeze out private information when I type my pin or account number on the grocery store computer, it is alarming me! That is a major security threat than perhaps the virus or spams in Windows machines! The Gurus must certainly look into it and suggest an OS level fix for it.

Yet another example of how it is game over when a knowledgable user has physical access.

How about an encrypted hard drive and a BIOS password?

A sturdy lockable computer case wouldn't hurt either.

1. if someone has physical access, only strong encryption can save you (assuming you DON'T save the key on there).
2. for internet banking, try booting off a LiveCD/usb-drive, that you keep under lock+key

Never do anything confidential on a public system, or anyone else's imho.

BIOS passwords and disk encryption will not stop a determined attacker.
http://theinvisiblethings.blogspot.c...truecrypt.html

Even this is dubious. Physical access generally moots any logical security.

http://www.schneier.com/blog/archive...aid_attac.html

EDIT: How did I miss allend's post?

I remember reading about this kind of attack almost five years ago:Still, the additional insight provided by Bruce Schneier and Joanna Rutkowska was quite refreshing. It was weird to see Ms. Rutkowska doing the kind of stuff that us ordinary people do. Weird in a good way, though. :)

I saw a suggestion about a way to prevent this. You type in some random characters, highlight them, overtype with more random characters, highlight them, overtype with more random characters + the first letter of your password, highlight everything except this first character, overtype randomly + the second character and continue doing this until you have built up the whole password. Because you don't delete anything, the keylogger will end up with a very long random character string. Obviously, if you do this regularly, a determined cracker will be able to figure out your password from the repeated entries. As well, the practicality of doing this is somewhat questionable.

How are they going to copy the hard drive when they can't access anything on the case but USB, firewire, Ethernet?

I suppose if they hacked the BIOS they could boot a USB stick image then DD the hard drive.

All the attacks mentioned require running an image not on the hard drive and getting unbridled access to the hard drive.

Selecting password problem
 

The method XaviourP suggested works wonderfully well when I use it in Firefox and other internet browsers.
So I think it is an excellent way to prevent spying while using internet on others machine.
But selection and over typing is not working when I try it on my password to login as user in my machine and other instances where we give root password to run some applications as root. The password simply won't get replaced when we type. I am using KDE . I guess it is a security measure to prevent people spying on the buffer which stores selection.
-Cheers
indiajoe

By removing the hard drive and connecting it to another computer.

That's a possibility, yes.

Yes, the type of physical access which is given to maids/janitors across the world every single day.

Simple solution: don't leave your laptop unattended.

Mouse Highlighting not effective
 

I do not think that the suggestion to highlight using the mouse and retype is an effective solution. With a bit of homework, the mouse movement can be tracked just like the keyboard inputs and be automated to filter out what all has been highlighted and removed to get the secreat word!

As it was pointed out, the encryption method also can be hacked in the same way.

The only method to prevent it is to secure the keyboard entry using some secure hardcoded key unique(?) to each system. It is important that such coding does not produce the same code when the inputs are similar. Otherwise standard attacks in cryptography could again pause a threat.

Ing Direct (a bank) has a very simple login that counters keylogger attacks. They use an onscreen keyboard, each key displaying a random unique character next to it. You can click out your password, or you can use keyboard, but instead of typing your password you enter the randomly mapped characters instead.

Of course only your Ing password is safe. But I believe tinfoilhat linux has a similar feature for all password entry.

[QUOTE=scourge99;3737280]How are they going to copy the hard drive when they can't access anything on the case but USB, firewire, Ethernet?

seriously? ... thats like saying how can they turn the computer on when they only have access to the power button. lol

Then perhaps you can explain it if its so obvious?

Malware could make a screenshot everytime you click.

But then that's not a keylogger attack either. Ing protects against the keylogger, not every possible attack. Shoulder surfing, for example, requires more countermeasures.

Moreover, screen captures on clicks would not be effective if a user hits backspace and clicks elsewhere a couple times, or if they use the keyboard to do the entry.

Sure it's not a keylogger if you look at it like hat,
but you can rest assures that there is malware out there, at
least on windows, designed to steal user passwords by making screenshots, capturing keys and reading the clipboard.

So thinking that a screen keyboard can protect you against password stealing is a false sense of security imho.

Well, to test this theory out, I made a keylogger (using borrowed code) to do exactly what the OP says. I noticed that if you do this you can find it by simply running:

as root, X and hald-addo will be each using the /dev/input/event# (I assume that if X is not being used, then only hal will be using the events), and if there's a keylogger at work, the keyboard event (event#) will be open one more time by a different program, whatever the keylogger is named.

For example:

no keylogger working:
keylogger (called keys by me) is working:

Now, probably with more sophisticated keyloggers they may have a way around this ?

Often one would combine a keylogger with a rootkit.
The rootkit would replace the lsof binary in a way that it doesn't display the keylogger anymore.

Ah, well in that case, use chrootkit and rkhunter ...

You're looking for a one size fits all countermeasure. Countermeasures are tailored for specific attacks. It would be unreasonable to expect an anti-spyware tool to protect you from a DoS attack, for example.

Ing's approach effectively counters the keylogger - and more login screens should be following their lead. The screenshot attack you mention requires considerably more sophistication from the attacker, and it only works in the case of basic mouse entry, which is easily countered on the server side by simply making the onscreen keys mouse-insensitive.

Sure, but I don't believe that the casual user at the end of the day cares if his banking account has been hacked with a keylogger,
or a keylogger with screenshot abilitys. All he cares about is that
his money is now gone and he wants protection from that.

I don't think a screenshot program is more complicated to program
then a keylogger. It might even be the other way round,
I do not know of a way to prevent a normal user to make screenshots
of all windows at the moment. So it might be harder to create a keylogger that can log keys of all windows.

What do you mean making certain keys mouse insensitive?
The user intentionally clicks on keys that have no function?

A way better counter measure against password spying malware
are one-time-passwords imho.
Because even if the program spys the password it would be useless if the user could still login, so you need a way of preventing the login from happening and that will be suspicious at least.

Bingo. http://www.rsa.com/node.aspx?id=1156

Problem is that getting one to every single user doesn't seem practical. Especially with our less than tech-savvy population.

From reading this thread, I get the impression that the only solution will be to encrypt the connection between the keyboard and the application (that is, encrypt the connection between the web browser (or logon screen or spreadsheet or ...) and the keyboard such neither Linux nor any other application or process running on Linux will be able to decrypt the characters being typed).

I wonder how much work it would take to do that?:scratch:

Something like a smartcard reader with a keypad should be able to do that.
The smartcard would then take your PIN to encrypt / authenticate.
But that requires support on the other side as the USB key from RSA does.

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.

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.

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

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.

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.

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