The screenshot didn't get thru the first time. Hope it get thru this time !! - D -----Original Message----- From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Debasis Mohanty Sent: Saturday, December 03, 2005 1:23 AM To: sjohnston@xxxxxxxxxxxxxx; '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@xxxxxxxxxxxxxxxxx [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] 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/
Attachment:
citibank-vkl.zip
Description: Zip compressed data
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/