Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Government The Courts News

Real-Time Keyloggers 205

The NY Times has a story and a blog backgrounder focusing on a weapon now being wielded by bad guys (most likely in Eastern Europe, according to the Times): Trojan horse keyloggers that report back in real-time. The capability came to light in a court filing (PDF) by Project Honey Pot against "John Doe" thieves. The case was filed in order to compel the banks — which are almost as secretive as the cyber-crooks — to reveal information such as IP addresses that could lead back to the miscreants. Or at least allow victims to be notified. Real-time keyloggers were first discovered in the wild last year, but the court filing and the Times article should bring new attention to the threat. The technique menaces the 2-factor authentication that some banks have instituted: "By going real time, hackers now can get around some of the roadblocks that companies have put in their way. Most significantly, they are now undeterred by systems that create temporary passwords, such as RSA's SecurID system, which involves a small gadget that displays a six-digit number that changes every minute based on a complex formula. If [your] computer is infected, the Trojan zaps your temporary password back to the waiting hacker who immediately uses it to log onto your account. Sometimes, the hacker logs on from his own computer, probably using tricks to hide its location. Other times, the Trojan allows the hacker to control your computer, opening a browser session that you can't see."
This discussion has been archived. No new comments can be posted.

Real-Time Keyloggers

Comments Filter:
  • Real Time? (Score:5, Funny)

    by Anonymous Coward on Sunday August 23, 2009 @05:29PM (#29166441)

    My Windoze apps at work don't even respond in real time. Maybe the trojan provides a free performance boost?

  • by upside ( 574799 ) on Sunday August 23, 2009 @05:30PM (#29166469) Journal

    Again, a proper banking system like my bank uses

    - a one time pad for logging on
    - another set of codes, from which one is picked randomly, to confirm transfers

    The one time pad means they can't open a second session. Even if they could hijack the session I've opened they can't transfer money without my explicitly authorizing each transfer by entering the second code.

    • by fbjon ( 692006 )
      Technically, it's possible to modify the browser itself so it inserts unwanted transactions into the list, but hides them from view for the user, and then just waits for them to get confirmed in conjunction with some other transaction made by the user. Don't know if it's worth the trouble though.
      • Re: (Score:3, Insightful)

        A good solution (read as "implementation") would consist of a challenge that the user can verify corresponds to the transaction he wishes to do. Four first digits of the Challenge are the four last digits of the sum. Six last digits of the Challenge are the six first digits of the target bank account. Etc.

        Nobody can expect good security if the user doesn't watch out and double checks what's happening. The attack you're talking of could very well be done to a poor old lady paying her bills for the month i
    • by Jah-Wren Ryel ( 80510 ) on Sunday August 23, 2009 @06:05PM (#29166731)

      The one time pad means they can't open a second session.

      RSA secure-id keys are single-use too. They roll every minute but they also roll on every successful use.

      • by mce ( 509 )

        For starters, I don't think they roll on success (how would the device know, by the way?). -- Disclaimer: I'm holding one in my hand right now, so I'm pretty sure. ;-)

        But even if they would: the legitimate user would not be able to know the difference between a failure due to making a typo and a failure due to some hacker beating him to the line. So he'd assume the former and simply try again, not understanding that someone else is active at the same time. Providing such a false sense of security, doesn't

        • by Jah-Wren Ryel ( 80510 ) on Sunday August 23, 2009 @07:01PM (#29167189)

          For starters, I don't think they roll on success (how would the device know, by the way?).

          The server enforces it. You can't authenticate multiple times with the same token. The server returns an "an already used" code if it was recently used. I know this because I've written software that uses RSA's secure-id toolkit.

          But even if they would: the legitimate user would not be able to know the difference between a failure due to making a typo and a failure due to some hacker beating him to the line.

          Again, see the point out about return values from the server-side. The application may choose to report this information directly to the user or simply flag it for the security team to investigate further. I prefer the later because false positives are going to be pretty rare unless the client software is broken in other ways.

          • by kafka47 ( 801886 ) on Sunday August 23, 2009 @11:32PM (#29168965) Homepage

            I work for RSA and you are absolutely correct. Attempting to authenticate twice with the same tokencode will automatically yield a rejection.

            I believe the idea of this "real-time application" is that they see you typing in your passcode and zap that code into the authentication system before you do. The success of this hack is predicated on the notion that they are watching with baited anticipation, ready to spring into action the exact moment you sign into your online bank.

            The chance of this actually occurring is highly remote, to say the least. The technique of racing ahead of a potential 2-factor authentication is compelling in theory, but of little practical use. If they're going to get into your bank, it has nothing to do with "defeating" Securid (or any other one-time display mechanism).

            Suffice to say, this story is bunk.

            • The success of this hack is predicated on the notion that they are watching with baited anticipation, ready to spring into action the exact moment you sign into your online bank. The chance of this actually occurring is highly remote, to say the least.

              (Emphasis mine).

              Well, if a background process would be waiting with baited anticipation, and would create a valid login and then sit back, the hacker would have 20 minutes (or whatever the server-side determined session timeout) to get to his terminal and use the open, authenticated session.

              Where I think this totally fails, is that my bank uses two-factor authentication for logging in as well as for doing an actual transfer. This is where the hack fails for such systems: it depends on letting the user creat

            • by hab136 ( 30884 )

              The success of this hack is predicated on the notion that they are watching with baited anticipation, ready to spring into action the exact moment you sign into your online bank.

              Or have an automated system waiting to do the same. It's not hard to automate logging in to a website and clicking "transfer funds".

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      An alternative used by at least one bank in Australia is that when you request a transaction they send ans sms to your pre-authenticated mobile number detailing the transaction, i.e who to and how much, and giving an authorisation code that you then enter. That code only authorises that specific transaction.
      No need to carry a one-time pad around or a special code generator

      • by Jah-Wren Ryel ( 80510 ) on Sunday August 23, 2009 @07:06PM (#29167219)

        An alternative used by at least one bank in Australia is that when you request a transaction they send ans sms to your pre-authenticated mobile number detailing the transaction, i.e who to and how much, and giving an authorisation code that you then enter. That code only authorises that specific transaction.

        That's common in Europe too. But the result has been that hacking sms in various [softpedia.com] ways has become of great interest to thieves. If they don't already exist, you can count on seeing java trojans for cells phones that silently forward SMS too.

        • by mjwx ( 966435 )

          If they don't already exist, you can count on seeing java trojans for cells phones that silently forward SMS too.

          Not that easy to do silently as in Australia and Europe SMS's cost the sender not the receiver. At AU$0.25 per SMS this will be noticed easily by even the dumbest of phone users. It will take one case in front of the TIO (Telecommunications Industry Ombudsmen) for Telco's to block SMS forwarding all together, despite the fact the telco will likely win in front of the TIO (virus is on the client

        • by mcrbids ( 148650 )

          A properly designed security system fails gracefully by limiting the knowledge available at *every* step of the game.

          Let's make a few assumptions:

          1) The bank has a password generator. It's a simple key/value randomizer. It's very, very secure.

          2) The end user has a cell phone. It may or may not be hacked.

          3) The end user is attempting to get money or do something with the bank. It might be on a computer, or it might be a credit payment machine at a grocery store. The device can be reliably tracked (EG: IP add

    • by CrashandDie ( 1114135 ) on Sunday August 23, 2009 @06:27PM (#29166931)
      Disclaimer: I work for one of RSA's competitors in this domain.

      The article focuses on RSA's SecurID, but one of the main drawbacks of RSA's SecurID is that it is only time based. Other companies also use event-counters, which means that you can't actually replay the attack.

      The parent is right (and I should now, I deploy these solutions), most serious banks will use OTPs (One Time Passwords) for the initial log-on, but then require Challenge-Responses to sign the transactions (website provides a challenge, which can be a completely random number, or based on a number of variables: amount, target account, etc; this challenge is provided to the token (stupidly named "gadget" in the summary), and it spits out a response.) This can be verified by the server.

      OTPs have always had this flaw, and this really isn't any news. I've heard of attacks were real-time keyloggers would interrupt the network connection (wifi, ethernet, whatever) on a software/OS level temporarily (I assume by refreshing the DHCP bumf) as to allow the attacker to use the OTP.

      However, this can be easily thwarted.

      Any good Authentication Server will provide the option to use seeded authentication, and even though this doesn't apply to OTPs (most OTP algorithms actually include clock counter (and event counter if it is implemented, not RSA's case) related information in the OTP, hence the whole OTP is required for authentication), it does apply to Memorable Data. For example, 2nd and 8th character of your secret passcode. Or for example, even better: multiply the 4th digit of your OTP with the 6th digit of your secret passcode. (OTP still required to be input completely). Yeah sure, given sufficient time, the attacker should be able to know what your passcode is, but heck, that's going to require quite some effort.

      Wikipedia has a bit of a section about the MITM attacks vulnerabilities of OTPs (even though it is right in SecurID's article [wikipedia.org], it doesn't apply to them alone, but to the concept as a whole). The main issue, however, with RSA's implementation isn't necessarily the MITM attack, but quite simply, stealing the token. It doesn't have a PIN code, heck, it even just shows the code the whole time (last one I checked did this), and I could read the number right off my friend's keychain.

      Also, let us not forget that a one-time attack (which again, shouldn't be much of an issue if banks have a good solution that requires CRs for each transaction) on an account really isn't a big deal. It's a One-Time Password. It's only valid once. After he's visited the account, and seen the balance, that's about as far as he's going to go.

      Nothing to see here, please move along. If anything, this is just going to drive our business a bit.
      • The article focuses on RSA's SecurID, but one of the main drawbacks of RSA's SecurID is that it is only time based.

        I can only speak to the RSA authentication I use, but once a 6-digit password has been used, it cannot be used a second time. This feature is enforced server-side and is especially annoying if you need to authenticate multiple times because each remote application (email, timecard, etc.) requires a separate authentication.

        Moreover, at least in this instance, the SecurID password must be combin

        • Re: (Score:2, Insightful)

          Actually, my point was that other vendors provide tokens that require a PIN to be input into the device, rather than to the server. The device can be locked if an incorrect PIN is entered, etc.

          Also, I never intended to say that Authentication Servers implementing SecurID weren't able to counter replay-attacks (this is a base functionality), I was merely stating that it didn't use event-counters to calculate the OTP. Other vendors provide this functionnality, and this enhances security, as instead of havi
    • Re: (Score:3, Funny)

      by bruno.fatia ( 989391 )
      My bank has so much more security that even when I want to I can't transfer anything!
      • My bank has so much more security that even when I want to I can't transfer anything!

        You have to have the money in your account in the first place.... Most banks are pretty good at making sure that requirement is upheld. Sorry if it messes up your plans.

    • by Quothz ( 683368 )

      The one time pad means they can't open a second session.

      No, it means you can't open a second session. You never posted your login, because they control the vertical and the horizontal. Although the transfer confirmation code should stop 'em, one hopes.

    • my bank does something similar - all transfers require inital confirmation via an sms sent to my mobile.
    • Which bank is this, and how do you get your codes?
    • Pff, that's nothing. My bank system is much safer.

      It demands a password.
      It demands the code from a one time pad.
      It demands a confirmation of the full detailed transaction.
      As the transaction surpasses a certain amount it asks you to physically go to the bank.
      You then get to the bank, to assure the bank director you do want to make the payment.

      From that point, the information required depends on your skill convincing the bank director that you actually do want to buy diamonds through "THA INTARWEBS!" and that

    • Did you even read the summary? They are intercepting authentication attempts and using the one time password (not "pad," you ninny).

  • The technique menaces the 2-factor authentication that some banks have instituted:

    Sure, they could intercept my login, but that would get them nothing. A new token is required for each and every transaction once logged in. I suppose they could try to add an emulation layer of sorts for the entire bank site, but that starts to become a lot of work with a lot of opportunity to notice something strange going on.

  • by ledow ( 319597 )

    Does it really matter? If they have access to your PC, why on Earth is this an issue anyway? Two-factor authentication or not, they have *ACCESS* to your Visa numbers, Amazon account, bank details (if you pay some bills online by direct transfer etc.). What the things *do* once they are on your machine is irrelevant. How they got there and finding them is infinitely more important.

  • by mlts ( 1038732 ) * on Sunday August 23, 2009 @05:52PM (#29166639)

    I wonder if the next step will be a dedicated hardware device such as IBM's ZTIC, where one does their transaction confirming on a closed secure device. This way, even though the consumer's PC may be compromised, an attacker trying to run transactions would be stopped when there is no device confirming the transaction.

    Of course, there are always issues like spamming the user with bogus transactions, or compromise the hardware device. However, it is a lot harder to compromise a hardware device than a generic PC which has to parse/execute/render untrusted code from the Internet on a common basis.

    • Exactly right. (Score:3, Insightful)

      by brunes69 ( 86786 )

      How many of these stories do we have to see before people wake up and realize that the login and security method is irrelevant if the OS itself is compromised?

    • by ckedge ( 192996 )

      I already do this basically. I have an encrypted OS on a USB key that I boot from when I want to do online banking, and in that OS image I do ONLY banking, no other websites of any kind. It's linux and it's firewall is on, auto-updates/etc are off. Nothing short of a full BIOS virus running a VM emulator can get at me, that or a hardware key logger. And that's unlikely, because I generally use a dis-used PC at work that has no hdd/os (spare in the corner of the equipment room), or a spare system at home

      • Re: (Score:3, Insightful)

        by mlts ( 1038732 ) *

        Long term, what comes to my mind for secure transactions would be placing a hypervisor at the BIOS level, and having a hardened OS dedicated for banking and other items. Then having an OS in another VM for general stuff (gaming, /., etc.)

        Of course, there are five issues with putting hypervisors in every PC out there:

        1: The hypervisor needs to be hardened. By default, these have a smaller attack surface than an OS, but there are ways to get around its protection. If malware in an untrusted partition is a

  • And browse / log in using the VM. Done.

    • VMs can break into their host machine.

      Read the paper presented at the recent BlackHat Conference.

    • by Eudial ( 590661 )

      What's changed in that? If a Trojan can get into your host machine, it can get into your emulated machine (since it obviously has Internet connectivity), and vice versa. Doesn't really matter if it catches real or emulated key presses.

    • by mjwx ( 966435 )

      And browse / log in using the VM. Done.

      A VM can fall victim to the same vulnerability.

      Virtual Keyboard (preferably a browser based one) is a better defence, still poor compared to stopping malware at the gateway before you infect your machine. If you don't trust\have the virtual keyboard just make one by writing out A-Z, 0-9 and all the special characters into a text editor and copy and paste each one as you need it. Yes this takes time but it is less vulnerable to key loggers.

      Banks implementing two

  • ... that I'm still a Bank of America customer. I've grown to like their 2-factor authentication mechanism. You can set up your account so that whenever you try to log in they send a random 6-digit number to you via a text message to your phone. You then enter that number into the website as you're logging in. Since it's truly a one-time-use number sent out of band from the way you're logging in it's about as secure as you can get.

    • by caluml ( 551744 )
      I remember suggesting this years ago, and the responses I got at the time were "but I/my mother/granddad/aging relative doesn't have a mobile phone", or "I don't want to have to carry around my mobile to use my online banking" - all very strange retorts. Glad to see a bank using its noddle.
  • by Animats ( 122034 ) on Sunday August 23, 2009 @06:39PM (#29167043) Homepage

    Bank of America used to have a good system for authenticating their site. At login, you input your ID, and the B of A site gave you back a photo of your own choosing to tell you that you were on the real Bank of America site. Only then did you input your password.

    Last Friday, B of A broke this feature. I'm now getting a password prompt without seeing the photo I'd chosen. My first thought was that there's was a security problem. I checked the SSL cert info, which looked OK. I reinstalled Firefox. No change. I called Bank of America. They wanted me to remove Flash, which I did. No change. They advised me not to log in. Then they passed me off to tech support, which hasn't called back yet.

    Then I took out a Linux-based Eee PC 2G Surf that had been unused for months, powered it up, plugged in an Ethernet cable, and saw the site doing exactly the same thing. So it's probably not a client side problem.

    What I think happened is that someone at B of A did a partial site redesign and broke something. They introduced some Flash (something called "/sas/sas-docs/html/pmfso.swf") on the password page (a terrible idea, given Flash's history of security vulnerabilities) and along with that, broke some part of the login process.

    If, in fact, they've had a break in on the server side, the main login of Bank of America has been compromised for at least three days now. I'm not seeing any indication of that, though; just general ineptitude.

    (The page HTML is awful. It's clearly been modified over and over for years without a cleanup. It has Flash, Javascript, CSS, single-pixel GIFs for formatting, and comments like "July maintenance OLB timeout inactivity update starts". The "enter password" page has 966 lines of HTML and JavaScript, not including external files. That's too much flaky machinery for such a security-critical function.)

    • FYI, I just looked at the BoA site and I don't see the problem you describe. Maybe it's a regional thing? Also, ING has a similar picture based system.
    • Bank of America used to have a good system for authenticating their site. At login, you input your ID, and the B of A site gave you back a photo of your own choosing to tell you that you were on the real Bank of America site. Only then did you input your password.

      My credit union used this for a while, but stopped recently (or maybe not! *eerie music*). I don't see how it helps me verify that I'm really connecting to their site, though, since a middleman site can just as easily act as a proxy to the real si

    • Re: (Score:3, Insightful)

      by Igmuth ( 146229 )

      How does this provide any security? All the fake site needs to do is get the picture from the BoA site. (Heck a well written script could cause your machine to do it for them.) Once that happens you are no better off than you were before, and likely worse (Since you are training people to assume that "picture means legit", instead of other more secure methods.

  • ...Your router's activity light blinks every time you press a key on the keyboard.

    I assume it's trivial to detect this type of keylogging.

  • When the first part of the authentication is done by a Greasemonkey script, keyloggers don't see that. Or do they?

    This may sound like a joke, but in fact I do have one part of the authentication scripted in Greasemonkey. That gets me directly to the next step with some sort of challenge-response system involving a calculator-like gadget with my bank card inserted in it.

    Of course, if your bank requires nothing else than an account number and a password which you have in a GM script, I would be glad to borrow

  • They use wish-it-was two-factor [thedailywtf.com]

    Two-factor authentication is when authentication requires two different factors of authentication. Some possible factors of authentication are something you know (PIN numbers, passwords, usernames, secret answers to questions arranged in advanced), something you have (smart card, key fob, pass-card, a special piece of hardware, a SSL certificate loaded on a device that you can't read), something you are (biometric identification, facial, voice, fingerprint recognition,

  • Yes this "new" ability! Oh wait, Sub7 has had a real time keylogger on it for almost 10 years. Oh no, that doesn't sound very new at all.
  • Let me guess... (Score:3, Interesting)

    by gillbates ( 106458 ) on Sunday August 23, 2009 @09:53PM (#29168277) Homepage Journal

    "Made possible by Microsoft(TM)"

    Right?

    TFA says nothing about the OS involved, which usually means a Microsoft Windows PC. I suppose the NYT is able to sell more advertising if they keep it ambiguous.

    Now, to be fair, Linux recently patched a root-privilege bug that went unnoticed for EIGHT years. But, to be just as fair, there are several orders of magnitude more compromises available courtesy Redmond, and due largely in part (as Djikstra quipped...) to their poor reinvention of UNIX.

    I have family that use Windows. What am I supposed to do? This is getting ridiculous. Sure, they get the OS they deserve. Sure, my employer gets the security compromises they deserve. But some part of the blame has to be shared by the company which made all of this possible.

    Programmers have always written buggy software. But it took Microsoft to create security flaws *by design* - that is, to deliberately architect software in an insecure an unreliable manner. It took Microsoft to disregard the lessons learned in UNIX, (as Djikstra would say) "To reinvent it poorly."

    I know, I know, ./ers will say, "Don't use Windows". Okay, I don't. But you have to understand that not everyone is a geek. The folks at corporate *BUY* Windows licenses because they don't know any better. My relatives use it because it came with their computer, or, their department at the university uses word, or they want to play games, or they want something familiar.

    What about them?

    Is it really acceptable for us to ignore the needs of the average user? Is it really acceptable to blame the victims?

    Or, should we hold Microsoft accountable to the same standards adhered to by everyone else in the industry?

    • by SL Baur ( 19540 )

      due largely in part (as Djikstra quipped...) to their poor reinvention of UNIX.

      That's a very odd spelling of Henry Spencer.

      Is it really acceptable for us to ignore the needs of the average user? Is it really acceptable to blame the victims?

      In this case, no. Let Microsoft clean up their own mess. The approach that Microsoft took to the internet in their Microsoft Windows 95 ("ActiveX" and auto executing stuff from across a wire or from removable media) had already been discredited for a decade.

      If you really wish to reinvent something, you can at least do a decent job of it.

  • SecurID - Incorrect (Score:4, Interesting)

    by endus ( 698588 ) on Sunday August 23, 2009 @10:32PM (#29168545)
    When you authenticate successfully with a passcode the passcode is immediately invalidated and cannot be used again. You cannot complete a login then use the same passcode again. At my old company we had to request special 30-second fobs for this reason. People would connect to a machine using their passcode and then need to su to root, but had to wait for the code on the token to change before they could authenticate again. If an attacker captures your passcode after you use it to successfully log in it's not going to do them any good at all. I feel like I'm missing something because none of the comments that I read above mention this fact. Pretty basic stuff to anyone who has administrated the system before.
    • Re: (Score:3, Insightful)

      by Qzukk ( 229616 )

      If an attacker captures your passcode after you use it to successfully log in

      That's the point of it being in real-time. The person on the other end of the keylogger has already logged in by the time your mom has gotten her hand back on the mouse, wiggled it around to find where the pointer is on the screen, moved the pointer to the login button and clicked on it. No, not that mouse button, the other mouse button.

      She gets the usual useless error message and decides she must have mistyped something.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...