Real-Time Keyloggers

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."

Comments

Real Time?

[Anonymous Coward]

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

Re:Real Time?

[Inner_Child]

I understand, it's embarrassing to admit to watching professional wrestling...

Thwarted by properly designed online banking

[upside]

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.

Re:Thwarted by properly designed online banking

[CrashandDie]

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, 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.

Re:Thwarted by properly designed online banking

[Jah-Wren Ryel]

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.

Re:Thwarted by properly designed online banking

[kafka47]

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.

Re:OTP !!

[shird]

That doesn't stop them from blocking your login such that they are the only ones using the password/id. They log the keystrokes prior to it being sent over the wire to the bank, block the post to login.cgi, and login for themselves.

Execute them? No. Catch them.

[John Hasler]

No need to execute them. No need to punish them severely at all. We just need to catch them. Given a 50% risk of being caught a one year prison sentence would provide more than adequate deterrence. Given the present one in 100 million risk of being caught an 18th century hanging would offer no significant deterrence.

This applies to crime in general as well.

Re:Biometrics

[John Hasler]

Anything to avoid a secure OS eh?

Re:OTP !!

[Jah-Wren Ryel]

They log the keystrokes prior to it being sent over the wire to the bank, block the post to login.cgi, and login for themselves.

If they are smart they can even provide a fake error page once they've acquired the credentials that tells the user that the site is "experiencing technical difficulties" and that they should please try again in 15 minutes. 99.99% of users won't think a thing of it.

The problem is service provider sloppyness

[Animats]

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.)