Message-ID: <43918DF9.9012.31AE0659@gmail.com>
Date: Fri Dec  2 23:22:30 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Most common keystroke loggers?

Jan Nielsen to me to Jan:

> >Obviously, then, your book does not include the phrase "Halting 
> >Problem"...
> 
> Sorry, I don't follow you there, you mean that the scan would halt the
> system ? fair enough, I don't think any method of scanning a target is
> fool-proof, no matter how its done.

Ahh, no...

   http://en.wikipedia.org/wiki/Halting_problem

Basically (and simplifying a lot), the Halting Problem means that you 
cannot write a computer program to determine if some other program 
exhibits "function X", _in finite time_.  Thus, you cannot write a 
program to detect all viruses, you cannot write a program to detect key 
loggers, you cannot write a prorgram to detect all spyware, etc, etc.

In short, the Halting Problem means that your suggestion to "beat" the 
problem of having to run on a compromised system by detecting if the 
system is compromised is just as impossible as is finding a solution 
more in line with the OP's suggested (but it turns out, unclearly so) 
aims.

> > ... that would be in the end-users
> > best interest I think (and of course report your findings to the users
> > mailbox or something, don't tell the hacker that you detected his
> > keylogger :-) 
> 
> >And what machines do you think users are most likely to check their 
> >mail from?
> 
> Thanks for pointing that out, but you would wan't to somehow relay to
> the person not gaining access, why they are not getting in though, ...

It would be _nice_ to do that, but it is an equally fraught problem.  
After all, even if you could entirely reliably programmatically 
determine that the users's system was compromised, you cannot trust any 
response from the system, or that any message you try to send to them 
to alert them to this will not be intercepted by some warez put on the 
system as a result of the compromise...

> ... a
> textmessage/SMS might be wiser.

And, as I already pointed out and you seem to have missed (or forgotten 
already), regardless of whether you try to do such "warning" out-of-
band (a good idea on its face) or not, that raises the issue of how do 
you _reliably_ know who to send the message to that the system has been 
compromised.  You cannot trust that anything returned from the 
compromised machine will be reliable, and you can't allow the user to 
perform any kind of "sensitive" authentication (as gaining that 
information is presumably the aim of the compromiser andd _preventing 
that_ was the aim of this suggested solution...

"Rock?"

"Hard place?"

"Meet Jan Nielsen..."

> >And, of course, your suggestion raises a primacy issue -- if you 
> >actually did detect the user's machine was compromised before they 
> >logged in and thus prevented allowing the login by not allowing the 
> >login dialog to be displayed or somesuch (thereby saving the user 
> >compromising yet more of their data), how in the heck do you know where
> 
> >to send the warning mail?
> 
> >Hmmmmm...  Methinks you should think more before responding.
> 
> Again, somehow they need to know, i don't have any ideas that can't be
> intercepted on a compromised system, other than SMS/textmessage or
> something.

Yes, and while doing the signalling that you have detected their system 
is compromised out-of-band of the compromise is a genuinely desirable 
thing, you still have not provided a way to strongly authenticate _who_ 
to send that message to, regardless of the actual form of OOB 
signalling used.

While you're working that problem you may also want to think about the 
"chicken and the egg" problem as they are closely related.

We look forward to your solutions...


Regards,

Nick FitzGerald

Powered by blists - more mailing lists