Date: Fri Dec  2 21:24:11 2005
From: gboyce at badbelly.com (gboyce)
Subject: Most common keystroke loggers?

Shannon,

A compromised system and a social engineering attack to get important 
credential information are two very distinct problems, and will be solved 
in very different ways.

For the social engineering attack, some of the methods I've seen so far in 
this thread (One Time Pads, two factor auth, etc) can be very useful.  I'm 
sure they all have their limitations, but I'm hardly an expert, so I'll 
let the experts hash this one out.

With the compromised system on the other hand, its pretty much game over. 
No matter what method you try to use to obscure the data, the person who 
compromised the system can get at it.  The only way you're even remotely 
safe is if you use a completely obscure system, and you're a small enough 
target that no one puts the effort into working around your "security". 
Hardly something you can count on though.

Perhaps it would be a better method to try to instead verify if a system 
has been compromised, and disallow the system to use your application if 
the system is known to be compromised.

I'm not sure if anyone has spent any time researching the feasibility of 
third party verification of client systems.  Some form of required 
virus/spyware scanning before allowing a client to use a service.  Of 
course, this may severely limit what operating systems are able to connect 
to the service.

On Fri, 2 Dec 2005, Shannon Johnston wrote:

> 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/
>

Powered by blists - more mailing lists