LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Closed Thread
  Search this Thread
Old 10-30-2009, 07:23 AM   #16
SajeethPhilip
LQ Newbie
 
Registered: Oct 2009
Posts: 2

Rep: Reputation: 0
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.
 
Old 11-01-2009, 01:22 AM   #17
jgombos
Member
 
Registered: Jul 2003
Posts: 256

Rep: Reputation: 32
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.
 
Old 11-01-2009, 03:06 PM   #18
deepsix
Member
 
Registered: Apr 2003
Distribution: ANY
Posts: 339

Rep: Reputation: 32
[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
 
Old 11-02-2009, 10:39 AM   #19
scourge99
LQ Newbie
 
Registered: Jun 2009
Posts: 24

Rep: Reputation: 16
Quote:
Originally Posted by deepsix View Post
Quote:
Originally Posted by scourge99 View Post
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?

Last edited by scourge99; 11-02-2009 at 10:40 AM.
 
Old 11-02-2009, 12:02 PM   #20
mase
LQ Newbie
 
Registered: Jul 2008
Posts: 22

Rep: Reputation: 15
Quote:
Originally Posted by jgombos View Post
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.
Malware could make a screenshot everytime you click.
 
Old 11-03-2009, 08:26 AM   #21
jgombos
Member
 
Registered: Jul 2003
Posts: 256

Rep: Reputation: 32
Quote:
Originally Posted by mase View Post
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.
 
Old 11-03-2009, 12:18 PM   #22
mase
LQ Newbie
 
Registered: Jul 2008
Posts: 22

Rep: Reputation: 15
Quote:
Originally Posted by jgombos View Post
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.
 
Old 11-03-2009, 01:36 PM   #23
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291
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:

Code:
lsof | grep input
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:
Code:
bash-3.1# lsof | grep input
hald-addo  3028        root  txt       REG                8,1    25880      27673 /usr/libexec/hald-addon-input
hald-addo  3028        root    4r      CHR              13,74                7308 /dev/input/event10
hald-addo  3028        root    5w      CHR              13,73                7343 /dev/input/event9
hald-addo  3028        root    6r      CHR              13,65                6381 /dev/input/event1
hald-addo  3028        root    7r      CHR              13,64                6358 /dev/input/event0
hald-addo  3028        root    8r      CHR              13,72                7147 /dev/input/event8
X          3198        root  mem       REG                8,1    35872     336589 /usr/lib64/xorg/modules/input/evdev_drv.so
X          3198        root   24u      CHR              13,75                7374 /dev/input/event11
X          3198        root   25u      CHR              13,74                7308 /dev/input/event10
X          3198        root   26u      CHR              13,73                7343 /dev/input/event9
keylogger (called keys by me) is working:

Code:
bash-3.1# lsof | grep input
hald-addo  3028        root  txt       REG                8,1    25880      27673 /usr/libexec/hald-addon-input
hald-addo  3028        root    4r      CHR              13,74                7308 /dev/input/event10
hald-addo  3028        root    5w      CHR              13,73                7343 /dev/input/event9
hald-addo  3028        root    6r      CHR              13,65                6381 /dev/input/event1
hald-addo  3028        root    7r      CHR              13,64                6358 /dev/input/event0
hald-addo  3028        root    8r      CHR              13,72                7147 /dev/input/event8
X          3198        root  mem       REG                8,1    35872     336589 /usr/lib64/xorg/modules/input/evdev_drv.so
X          3198        root   24u      CHR              13,75                7374 /dev/input/event11
X          3198        root   25u      CHR              13,74                7308 /dev/input/event10
X          3198        root   26u      CHR              13,73                7343 /dev/input/event9
keys      20666        root    4r      CHR              13,73                7343 /dev/input/event9
Now, probably with more sophisticated keyloggers they may have a way around this ?
 
Old 11-03-2009, 01:43 PM   #24
mase
LQ Newbie
 
Registered: Jul 2008
Posts: 22

Rep: Reputation: 15
Quote:
Originally Posted by H_TeXMeX_H View Post
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:

Code:
lsof | grep input
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:
Code:
bash-3.1# lsof | grep input
hald-addo  3028        root  txt       REG                8,1    25880      27673 /usr/libexec/hald-addon-input
hald-addo  3028        root    4r      CHR              13,74                7308 /dev/input/event10
hald-addo  3028        root    5w      CHR              13,73                7343 /dev/input/event9
hald-addo  3028        root    6r      CHR              13,65                6381 /dev/input/event1
hald-addo  3028        root    7r      CHR              13,64                6358 /dev/input/event0
hald-addo  3028        root    8r      CHR              13,72                7147 /dev/input/event8
X          3198        root  mem       REG                8,1    35872     336589 /usr/lib64/xorg/modules/input/evdev_drv.so
X          3198        root   24u      CHR              13,75                7374 /dev/input/event11
X          3198        root   25u      CHR              13,74                7308 /dev/input/event10
X          3198        root   26u      CHR              13,73                7343 /dev/input/event9
keylogger (called keys by me) is working:

Code:
bash-3.1# lsof | grep input
hald-addo  3028        root  txt       REG                8,1    25880      27673 /usr/libexec/hald-addon-input
hald-addo  3028        root    4r      CHR              13,74                7308 /dev/input/event10
hald-addo  3028        root    5w      CHR              13,73                7343 /dev/input/event9
hald-addo  3028        root    6r      CHR              13,65                6381 /dev/input/event1
hald-addo  3028        root    7r      CHR              13,64                6358 /dev/input/event0
hald-addo  3028        root    8r      CHR              13,72                7147 /dev/input/event8
X          3198        root  mem       REG                8,1    35872     336589 /usr/lib64/xorg/modules/input/evdev_drv.so
X          3198        root   24u      CHR              13,75                7374 /dev/input/event11
X          3198        root   25u      CHR              13,74                7308 /dev/input/event10
X          3198        root   26u      CHR              13,73                7343 /dev/input/event9
keys      20666        root    4r      CHR              13,73                7343 /dev/input/event9
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.
 
Old 11-03-2009, 02:12 PM   #25
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291Reputation: 1291
Ah, well in that case, use chrootkit and rkhunter ...
 
Old 11-04-2009, 12:21 AM   #26
jgombos
Member
 
Registered: Jul 2003
Posts: 256

Rep: Reputation: 32
Quote:
Originally Posted by mase View Post
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.
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.
 
Old 11-04-2009, 02:03 AM   #27
mase
LQ Newbie
 
Registered: Jul 2008
Posts: 22

Rep: Reputation: 15
Quote:
Originally Posted by jgombos View Post
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.
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.

Quote:
Originally Posted by jgombos View Post
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.
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.
 
Old 11-04-2009, 11:28 AM   #28
scourge99
LQ Newbie
 
Registered: Jun 2009
Posts: 24

Rep: Reputation: 16
Quote:
Originally Posted by mase View Post
A way better counter measure against password spying malware
are one-time-passwords imho.
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.

Last edited by scourge99; 11-04-2009 at 12:37 PM. Reason: spelling
 
Old 11-04-2009, 11:37 AM   #29
Jim Bengtson
Member
 
Registered: Feb 2009
Location: Iowa
Distribution: Ubuntu 9.10
Posts: 164

Rep: Reputation: 38
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?
 
Old 11-04-2009, 01:15 PM   #30
mase
LQ Newbie
 
Registered: Jul 2008
Posts: 22

Rep: Reputation: 15
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.
 
  


Closed Thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Prevent un-blanking due to input events RuchiS Linux - Software 1 09-26-2009 09:07 PM
Repeated "input: AT Translated Set 2 keyboard as /class/input/input" messages AcerKev Mandriva 2 09-16-2007 08:35 AM
No keyboard input under gnome. gatdrydock Linux - Software 1 07-10-2005 03:15 PM
my mouse input is takes as keyboard input in BASH e1000 Slackware 5 12-08-2003 03:00 PM
No keyboard input seen neo77777 Linux - General 5 07-12-2002 09:32 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 07:22 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration