Message-ID: <20051202195835.AB94EBED@lists.grok.org.uk>
Date: Fri Dec  2 19:58:42 2005
From: mail at hackingspirits.com (Debasis Mohanty)
Subject: Most common keystroke loggers?

Typo <everyone seems to have out here is>  -> <everyone seems to have missed
out here is>

-D

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Debasis
Mohanty
Sent: Saturday, December 03, 2005 1:23 AM
To: sjohnston@...ionplus.com; 'Full-Disclosure'
Subject: RE: [Full-disclosure] Most common keystroke loggers?

The point that everyone seems to have out here is, all these User IDs / PINs
etc are all stored in clear text in the web 'form fields'. These days
attacks are much more sophisticated and stealth. The idea of X-x-X screen
capture is bit outdated and can easily be fooled. Ex: If an user has to type
a PIN as 2031156, then just to fool those screen capture progms; the user
can first <click 111> <Backspace> <type 5> <use home key> <type 20> <click
3> <end key> <type 6>. Although, the screen capture program will capture
each one of those mouse clicks but will miss those keystrokes and the
sequence might get disturbed. It will be a pain in the ass for attacker to
analyse the scrambled logs and get the correct PIN. 

As all those user credentials are stored in clear text in the web forms, a
program can use COM (in case of IE) to retrieve those data directly from the
form elements. Here the user can't so easily fool the program by using the
above technique as the data will be directly captured for the web form
elements once the user try to submit the form. I have attached a screenshot
of a demo program which uses this technique. 

- D 

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Shannon
Johnston
Sent: Friday, December 02, 2005 10:40 PM
To: Full-Disclosure
Subject: Re: [Full-disclosure] Most common keystroke loggers?

This is fantastic! I like all the feed back that has been coming through. I
think that it would be helpful to explain a bit more.

The original question about keystroke loggers was an effort to find some
loggers that were in use (with screen capture capability) so they could be
used in our testing.

The actual problem stems from our efforts of trying to secure an application
keeping in mind that a user's system may be compromised, and/or the user has
been socially engineered into giving out important credential information.

We've been playing with 2-factor authentication, randomized graphical
"keyboards", S/Key, one time passwords (sent via email/SMS), even getting to
the point where the system will call a user on the phone and ask for a
verification word when authentication is attempted.
I know that education of the end user is the best defense, but there will
always be people who just don't get it. With that logic I almost have to
consider the user an untrusted source.

The goal of the project is to see if we can design a system that prevents an
uneducated user from shooting themselves in the in the foot.

Shannon



On Fri, 2005-12-02 at 12:01 +1300, Nick FitzGerald wrote:
> deepquest wrote:
> 
> > To me the only thing that can defeat keystroke is what a software
or  
> > trojan can not do: See (OCR is just a partial application of guess 
> > but not applicable in that case)
> 
> Then you are so far inside the box you cannot see the walls...
> 
> The OP said "keystroke logger" BUT he also said "compromised".  If
the 
> machine is compromised you cannot limit yourself to "keylogging" as a 
> compromised machine may be running _anything_ (including something
not 
> yet written, as we are talking about a hypothetical future situation, 
> so the OP limiting the original question to "the most common
keylogger" 
> is further evidence that the OP does not understand the actual
problem 
> set he has been posed).
> 
> > Imagine a web page with a virtual keyboard page (clickable). In
order  
> > to prevent the localisation on the keys mapping based on position
of  
> > the mouse, display the keyboard on random location of the
screen.  ...
> 
> Trivially, and already long ago, overcome by screen-shot keyloggers.
> 
> > ...  Add
> > a random password and challenge authentication process.
> 
> Why?
> 
> This adds nothing but annoyance to the user, thus reducing
usability.  
> If you're going to move to OTP, why _also_ move to an onscreen 
> keyboard?  It's almost like you believe that taking two unrelated 
> approaches that indivdually make no improvement whatsoever will 
> suddenly make some real improvement when combined.  A hint -- zero
plus 
> zero equals ??????
> 
> As already explained ad nauseum to the other na?ve "use OTP", if you
do 
> not do something "out of band" _relative to any and all possible "bad 
> code" that could be running on a compromised machine_, you have
lost.  
> To achieve that requires a second, "secure" piece of _hardware_ that 
> simply uses the network connection through the compromised machine to 
> communicate in a crptographically secure way with the server.  The OP 
> made no mention of designing hardware
> 
> > my 2 cents,
> 
> If that's really what the above "advice" is worth, inflation must be 
> _really bad_ where you are!
> 
> 
> Regards,
> 
> Nick FitzGerald
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists