Tuesday, January 15, 2008

Targeted Bank Malware

There have been a lot of interesting things going on with malware these days, but this is on the top of the list (for the next few hours anyway ;). Symantec has a blog write-up on a specific trojan that targets over 400 of the most popular banks in the U.S. and abroad. From the post:
This Trojan downloads a configuration file that contains the domain names of over 400 banks. Not only are the usual large American banks targeted but banks in many other countries are also targeted, including France, Spain, Ireland, the UK, Finland, Turkey—the list goes on.
Targeted malware has some interesting economic ramifications. With signature based anti-malware, the defenses only work if a signature exists (duh!). But the problem is this: will your very large (think yellow) anti-malware vendor really publish a signature to catch malware targeted at only your organization, especially considering that each signature has the possibility of falsely identifying some other binary executable and causing a problem for another of their customers? No doubt anti-malware vendors have seen targeted malware and then specifically not published a signature for all of their customers. They may have released a specific signature for an individual organization, but the support risks are significant. It's better for everyone to NOT publish a signature unless it's widespread. Signatures add overhead, even if it's minimal. It's at least one more signature to search through when comparing each signature. At best, that's logarithmic complexity, and even that minimal complexity across a half-million signatures is expensive.

But that's not all that is interesting about "Trojan.Silentbanker" ...
Targeting over 400 banks ... and having the ability to circumvent two-factor authentication are just two of the features that push Trojan.Silentbanker into the limelight...

The ability of this Trojan to perform man-in-the-middle attacks on valid transactions is what is most worrying. The Trojan can intercept transactions that require two-factor authentication. It can then silently change the user-entered destination bank account details to the attacker's account details instead. Of course the Trojan ensures that the user does not notice this change by presenting the user with the details they expect to see, while all the time sending the bank the attacker's details instead. Since the user doesn’t notice anything wrong with the transaction, they will enter the second authentication password, in effect handing over their money to the attackers. The Trojan intercepts all of this traffic before it is encrypted, so even if the transaction takes place over SSL the attack is still valid. Unfortunately, we were unable to reproduce exactly such a transaction in the lab. However, through analysis of the Trojan's code it can be seen that this feature is available to the attackers.

The Trojan does not use this attack vector for all banks, however. It only uses this route when an easier route is not available. If a transaction can occur at the targeted bank using just a username and password then the Trojan will take that information, if a certificate is also required the Trojan can steal that too, if cookies are required the Trojan will steal those. In fact, even if the attacker is missing a piece of information to conduct a transaction, extra HTML can be added to the page to ask the user for that extra information.
If you understand how Two Factor Authentication really works (at least how banks are implementing it) then you already understand that it cannot stop fraud by an adversary in the middle (a less chauvinistic way to say "man in the middle"). Bruce Schneier has been preaching "the failures of two factor authentication" for a long time. What's monumental about this piece of malware is that it is the first to do well that which pundits have been saying for a long time. Two factor authentication, including PayPal's Security Key (courtesy of Verisign, a company not on my good list), is broken. SiteKey is broken (for the same reasons). What Schneier said in 2005 took until 2008 to materialize (at least publicly). This will not go down in history as an anomaly; this will go down as the first run at creating a sophisticated "engine" to handle MITM on any web application that has financial transactions.

Here's the real question to answer: How many fund transfer transactions must be hijacked to bank accounts in foreign nations that don't extradite their criminals to the U.S. before we finally realize just how bad malware in the "Web 2.0" world (sorry that's O'Reilly's name, I really mean "XMLHTTPRequest" world) can get?

It's about the transactions, folks. It's time to authenticate the transactions, not the users. (Schneier's been saying that, too.) Bank of America is closer-- yet farther away at the same time-- to getting this multi-factor authentication problem solved by implementing out-of-band multi-factor authentication in their "SafePass" service ... BUT, it's still completely vulnerable to this malware (I cannot state that this specimen does in fact implement a MITM on this BoA service since I have not reversed a sample, but if not in version 1.0, it will eventually). I wanted to write a rebuttal to the entry on Professor Mich Kabay's column on Network World, but the authors of this trojan did a better job!

The downfalls of SafePass, which uses SMS text messages to send one-time-use 6 digit passcodes (think RSA SecurID tokens without the hardware) to a customer's mobile phone. It's nice to see authentication out-of-band (not in the same communication channel as the HTTPS session), however, once the session is authenticated, the trojan can still create fraudulent transactions. SafePass could be improved by: 1) not using a non-confidential communication channel (SMS text messages are sent through the service provider's network in plaintext) and 2) requiring the customer to input the authentication code to validate transaction details that are sent with the out-of-band authentication token. Obviously you don't want to skip on #1 or else you'll have a privacy issue when the details of the transaction are broadcast through the provider's network and over the air.

Suppose Eve can modify Alice's payment to Bob the merchant (the transaction's destination) via a MITM trojan like this one. Eve modifies the payment to go to Charlie (an account in the Cayman Islands). Suppose Alice is presented with a "Please validate the transaction details we have sent to your mobile phone and enter the validation code below" message. Alice receives the message and notices the payment is to be sent to Charlie. Since she doesn't intend to pay Charlie, she calls her bank to report the fraud (as directed in the transaction validation method). Of course, that pipe dream would only work if SMS was a confidential channel [and if we could deliver a trustworthy confidential channel to a mobile phone, we will ALREADY solved the trustworthy transaction problem-- they're the same problem] AND if we could find a way to make customers actually PAY ATTENTION to the validation message details.

And of course, incoming SMS messages in the U.S. are charged to the recipient (what a stupid idea-- what happens when people start spamming over SMS like they do over SMTP?).


...

[Side commentary] Oh. And then there's the problem of telling your family members not to click on any random e-cards (or anything else that your family members were not expecting) because it just got a little scarier out there. Imagine your retired parent just clicked on some pretty animated something-or-other that launched some client-side script, installed the Trojan.Silentbanker (or similar) and then the next time they went to check their retirement savings, their life's solvency was sent to a Cayman Islands' account and liquidated faster than you can say "fraud". Does dear old Grandma or Grandpa have to go back to work? They just might, or become a liability on their children and grandchildren. If that won't scare the older generation away from the unsafe web, what will?

19 comments:

MarkM said...

I've been disappointed with Schneier's argument, and don't agree with the way you've stated it here either. While there's no doubt that SilentBanker is a nasty piece of work, it's not an MITM attack in the classic sense of the term.

A malicious website that uses social engineering to get you to access its URL instead of your bank's, then establishes separate TLS connections between itself and your machine, and itself and your bank, so it can forward your password to the bank, and otherwise alter the traffic passing through its proxy, is an MITM attack. These exist, and are defeated when you carefully review the server certificate and discover that it's an on-the-fly forgery. That's how server-authenticated TLS is supposed to work.

SilentBanker isn't in the middle, it's in your host machine. No protocol is invulnerable to corruption of a trusted host. No doubt using SMS as a second channel can make it possible to detect that you have a compromised host, since that channel can't be compromised by the same trojan, but as you point out, such a protocol differs only in complexity and not in kind. You also say:

"Of course, that pipe dream would only work if SMS was a confidential channel [and if we could deliver a trustworthy confidential channel to a mobile phone, we will ALREADY solved the trustworthy transaction problem-- they're the same problem]..."

But not really; the communication channel between your bank and your phone isn't the only problem, any more than the communication channel between your bank and your computer. As cell phones become more capable (i.e. morph into general purpose computing devices) they become susceptible to malicious code just as conventional computers are. This happens already on a small scale, so it's only a matter of time before the truly scary developers who create exploits like SilentBanker can also target your PDA/cellphone with a trojan that defeats this method of authenticating the transaction. Your suggestion to have the user transfer an authentication code from SMS message to browser in order to close the transaction loop makes things a lot more difficult for the attacker, but not impossibly so.

Without trustworthy computing platforms on both ends of the transaction, it's impossible to guarantee its integrity. Giving the client two platforms instead of one only makes life more complicated for an attacker.

securology said...

Hi MarkM,

Thanks for commenting.

I don't disagree with you entirely, but I do want to point out that the more academic definition of MITM is "an attack in which an attacker is able to read, insert and modify at will messages between two parties without either party knowing that the link between them has been compromised" (that quote is from Wikipedia, however that is a generally accepted definition of MITM overall). Therefore, my usage of MITM to describe the SilentBanker Trojan is correct.

If you wish to be more specific to say MITB (B="Browser"), then perhaps we can agree on terms more succinctly. But for the record, one of the problems the field of security experts has is that we are constantly creating new names for existing threats warmed over.

I stand by what I said: "if we could deliver a trustworthy confidential channel to a mobile phone, we will [have] ALREADY solved the trustworthy transaction problem-- they're the same problem" because a "trustworthy channel" IMPLIES trust at the foundational levels, from hardware through OS, through application layers, to the (weakest link) human at the other end. If we can solve the trustworthy transaction problem on ANY platform (because it has of yet to be done effectively) then we will have succeeded. But I do agree with you that mobile phones are becoming more complicated and we all know that complexity erodes trustworthiness-- phones are starting to look just like the PCs that are home to so many malware installs.

Anonymous said...

Just my 2 cents. May be wrong!

Each online banking website have their own unique identifiers for user ID, password, transaction amount, etc. No matter how generalise a trojan can be, an MITM attack to an online banking website still has to be very specific for it to work. This means that when the trojan intercepts a customer's fund transfer request, it searches and replaces fields from specific identifiers. If the trojan uses a brute force method to modify transaction or create fictitious transaction, its like playing 4D! There are just too many combinations and conditions for a generalised attack to work.

Hypothetical, a MITM trojan could work this way. It monitors for keystrokes to detect specific URLs. If it detects a login to BANK A, it uses a specific way to attack. If it detects a login to BANK B, it uses another specifically crafted attack. Is this how silentbanker works? If possible, it will be great if you can pass me a sample of the binary. Thanks.

My email - silverfish74@gmail.com

securology said...

Silverfish,

Thanks for dropping by.

Yes, Trojan.Silentbanker is actually downloading a config file to attack specific rules about specific banks that it "knows". This snippet was taken from Symantec's Blog post:

...

jhw21]
pok=insert
qas=someBankSite.com/xpage/loginxxxxxxxxxs.htm
njd=name="oppasswd;
dfr=14
xzn=/>n
xzq=2
rek=<div class="clear sep4"></div>
<label for="clave">Clave de firma: </label>
<input name="ESpass" type="password" size="8" maxlength="8"
class="input01 aleft w180"/>’
req=166

...

You can see that the trojan is looking for specific form fields in specific URLs and has a sort of find and replace mechanism. In this case, it's adding form fields to a bank's web page to collect a user's "clave de firma" (Spanish for 'strong encryption key'). Here are BEFORE
and AFTER screenshots.


Apparently the options in its config file are:

Token - Purpose
pok - Action to take
qas - URL to take action on
njd - String to search for
xzn - End string to search for
rek - HTML to insert

And if you want a copy of the virus (for research purposes, I'm sure) then you'll need to take that up with an AV vendor with whom you have a relationship.

Mike said...

Look up www.OHVASecurity.com and then click on SoundPass. SoundPass uses a virtual token that is designed to be returned to the PC that sent it to the server. If any attempt is made to steal or re-route the virtual token, the patent design will keep the online account locked down for protection and no one can enter it. There are also built-in monitors tracking the virtual token. The verification process includes the user, the virtual token, and the server. Short of a hacker pointing a gun at your head, I don't know how else a hacker can break into your online account. ABECU has been operating under SoundPass for almost a year across the nation and this is their comment:

"OHVA's SoundPass™ is a cutting edge solution. We feel it offers our members the highest level of security available."
- David Gray, Manager, Electronic Services, Anheuser-Busch Employees' Credit Union and Division

securology said...

Mike, Mike, Mike, Mike!

First of all, thanks for taking the time to read and post.

Second, though, is please note that no form of second factor authentication (patented or not), regardless of how it interfaces with the endpoint computer (using USB, human entry, or by generating modulated analog signals over the microphone jack to pass an ID and session key), will prevent this type of MITM (Man/Attacker In The Middle) scenario.

[And by the way to everyone-- any kind of "patented" security technology should scare the pants off of you. Security designs should be transparent for all to inspect. They're hard to create. They're even more difficult to formally validate. Don't trust that patent lawyers have taken care of that for all of us.]

This particular type of malware is DESIGNED (this is one of the features it contains) to steal 2 factor creds. Two factor auth just won't ever stop a MITM. Because it's always possible to do a real-time MITM using a valid session, which is what this specimen of malware does. Those attackers could re-tool their wares to steal creds from your Anheuser Busch credit union customers (employees) also. Just because it has not happened yet does not mean it cannot or will not.

Schneier says the same thing, in case you (or others) would rather hear it from somebody with a pony-tail.

And just to echo one more time so everybody else can know: "It's never the crypto that's the problem, it's ALWAYS the endpoints."

For the visual learners, here is the Trusted Path from customer to bank:

HUMAN --> Keyboard/Mouse --> OS (Keyboard/Mouse I/O) --> BROWSER --> Java Applet/JVM --> OS (Mic Input) --> SoundPass token --> OS (Mic Input) --> Java/JVM --> BROWSER --> OS (Network stack) --> ISP/Internet (DNS in all of its lackluster is in this step) --> Bank website --> Bank

Because this malware resides in the "Browser", you cannot authenticate anything to the left of that step, because the browser can take your valid credentials and do something horribly wrong that the human didn't want it to do, then present back to the human what s/he expects to see (that's what's so horrible about this malware, we've been saying it was possible for years, but we finally now have in-the-wild proof that this happens). And if you STILL believe that this sort of token will help, notice that all of the steps taken by the Java based SoundPass soft token is book-ended by the browser. If an attacker owns your browser, you cannot trust anything in those steps (in italics). And, if malware lived in the OS (as is much more common with things like rootkits and keyloggers), it would be even more damaging-- just look at all of the steps that the OS can book-end. A malicious or overtaken OS can subvert ANYTHING in those steps. Each of those steps is a "chain link" in a greater "chain of trust". All it takes is one link to break and the integrity of the whole chain is compromised.

What banks like yours want (and with good reason) is "remote attestation", which just isn't possible, yet. General purpose computers and browsers are simply too complex to validate how they'll behave today, which is why we'll all have to push for more simplicity before it gets better. If you cannot remotely trust the software (OS, Browser) that runs on a remote computer, there is no way to trust the output of software that you provide to that remote machine (soft token).

Mike, again, thanks for reading and commenting. I encourage you to comment back if you disagree with me. I'll have you know, though, you're turning me into the Ralph Nader of Security Products, like this is some kind of Consumer Report or something. If you bought that product for your customers thinking you were going to reduce risk, I feel for you. I don't like "researchers" whose purpose it to go around breaking everything to prove the emperor had no clothes in the first part, but the description of the product assures me I could break it (and if more people line up to buy it beyond Anheuser Busch, I won't have to, some other "insecurity researcher" will at the next Black Hat or DEFCON).

Caveat Emptor!

Mike said...

Securology,

It has been 3 years almost to the day since I suggested SoundPass as strong MFA security and it still has never been breached. I can not think of any other authentication solution that after 4 years since it was first installed (at ABECU) can say their solution has never been breached. It is true that even though I have a dead bolt on my front door, someone could drive a tank through it and gain access into my house. My point was and still is that SoundPass provides very strong MFA security. There are always ways to improve anything
but starting from such a strong base of security provides a much better foundation to build on than anything else I am aware of out there.

Best,
Mike

securology said...

Mike,

Just because it hasn't been broken doesn't mean anything. The laws of economics are at play here! That solution is not widely deployed, and even if it was, there are plenty of banks out there that are wide-open for the taking by malware. Even if your solution were to be deployed widely, it could and would be broken by malware authors because there would be economic incentives for them to do so, and the "laws of physics" when it comes to information security demonstrates they do have the ability to tamper with anything operating on the remote (client) machine.

Thanks for the comment, though!

Mike said...

It has now been 5 years!
I agree that there are no "Silver Bullets" but at some point in time give SoundPass some credit, as Cyber crime capabilities have continued to grow and get stronger plus SoundPass has had its share of attack attempts. How many millions of stolen dollars could have been protected under SoundPass? I don't see much else helping online banking out there and certainly not with the convenience and affordability of SoundPass! When you remove the human from the equation, authentication accessing security becomes a lot more effective.
Best,
Mike

securology said...

Mike A.,

Love your persistent enthusiasm.

Your website (http://virtualsoundpass.com/) has virtually no information about what SoundPass actually does, so it's hard to make a fair comment in response.

Post up a whitepaper description, or even some sales slides or something to your website, then reply back here and I'll take a serious look, and then give your product its own dedicated blog post.

If you can't/won't share, I wonder if Kerckhoff's Principle is something to which SoundPass adheres, in which case I'm already extremely skeptical of its efficacy.

Mike A said...

Okay, go back and review our website: http://virtualsoundpass.com/

I added our SoundPass WhitePaper plus its Key Features.

It would be a shame to see SoundPass become the best kept MFA accessing security secret.

Best Regards,
Mike

Mike Angelinovich said...

Nearly 9 years and SoundPass was never broken. If you read the White Paper I added for you in our Web-Site you would have seen that the SoundPass credential is dynamic and generated in the client's Java Applet from a previously sent virtual token by the Authentication Server and is encrypted prior to the Applet automatically sending it to the Authentication Server for validation along with the user's entered credentials. It is monitored at both the client and server ends plus is under a time constraint. Before the server will allow access into the online account the new virtual token must be received by the original sending source and it automatically stored in the user's client C-Drive or can be stored in the user's memory stick. I agree that there is no "Silver Bullet" in the security world but SoundPass is closer still today than anything else I've seen especially when it comes to the user's convenience and the cost of protecting a mass amount of users.
If 76% of Network intrusions are stolen credentials, then SoundPass would have prevented 76% of those intrusions and saved billions of dollars!

securology said...

@Mike,

I appreciate the enthusiasm, but I guarantee SoundPass hasn't been broken/bypassed because of economics/scale, not due to technical prowess. If malware is on the remote host, all bets are off. Sell your product to a very large high value target bank, and watch how quickly your statement will erode. When the incentive is there, people will spend their time breaking it.

Mike Angelinovich said...

How much faith do you place on a Smartcard Authentication solution, which uses a smart dynamic encrypted credential? SoundPass was designed from and operates like a Smartcard solution? SoundPass also has an additional optional security layer that provides a screen key pad that the user enters their PIN code. If a Hacker can take over the user's client and has the user's PIN code then SoundPass will be broken and so will every other solution that takes over the user's client. MITM nor MITB will not break SoundPass. A real-time Keylogger or any attempt at Phishing will not work because the SoundPass dynamic generated, encrypted and automatically sent to the authentication server is not known to the user nor entered by the user, so there is nothing for a Keylogger to steal and a user can not give away something they don't know. Two-Factor solutions that are hacked are really not Two-Factor solutions. For example, receiving a OTP from a Token or Phone is something you have but as soon as the user enters the OTP it becomes something the user knows and is no different than another Password or Single Factor Authentication. Using an IP Address and/or a Cookie for the second factor is also useless because all Trojan exploits can move an IP Address and will eliminate all Cookies. These are the types of so called Two Factor solutions that are being broken by Malware carrying a Trojan exploit.

securology said...

@Mike:

Still 2 things:

1) Show me a high value target client of yours.

2) I don't assess these things for free. Hire a very reputable pentest firm to publicly vouch for your system.

Mike Angelinovich said...

Interesting that you didn't post my last comment. Tells me that no matter what I try to explain that you must always be right. Unfortunately that type of attitude prevents you from further learning new ideas. I wish you all the best!

securology said...

@Mike,

Not sure what comments didn't get published? Moderating blog comments is not exactly our favorite use of time here. All conspiratorial misconceptions aside...

Mike Angelinovich said...

This is what I wrote in response to your reply on Nov. 16:

I'm not asking you to assess SoundPass. However, my issue is that you have been assessing SoundPass publicly on your Blog for years and you haven't had a clue of how it even works. PM Systems tested SoundPass before it was ever released and it was implemented by NCR for ABECU's use nation wide in 2007. It operated at ABECU until last month when ABECU switched their online banking system to Digital Insight and over that entire period of time SoundPass was never breached.

You have and continue to put down Two-Factor Authentication but the Two-Factor solutions that have failed have really not been based on something the user has that eliminates the human element and therefore they are NOT Two-Factor solutions. A smartcard is a Two-Factor Solution and so is SoundPass.

securology said...

@Mike,

The problems I have with *ANY* multi-factor authentication system that relies upon data stored on disk is that malware can read anything on disk. If your threat model includes avoiding key loggers, then you're already assuming malware on the client machine. The only thing stopping malware from grabbing encryption keys, jar files, DLLs, or anything else on disk is strictly just the malware author's imagination.

Like I said before, the reason you were not breached is much more likely because of economics than technology. If a bank or other target was of sufficiently high value, then malware would have been created to either mimic or bypass the functionality of your solution.

I don't do assessments for free. I recommend you get any of the following companies to do a full on review of your application and then publish their report (in no particular order):

- NCC Group
- Optiv
- Praetorian
- Atredis Partners
- Cigital
- Rapid7