Financial Trojans: Following the Money

Wednesday, March 16, 2011

Simon Heron


Recently, I wrote an article for (In)Secure Magazine focusing on two financial Trojans: namely Zeus and URLZone. 

In the article I go into some depth looking at the configuration files and the command and control options that the malware writer has provided in the toolkit. 

I think what is of concern is that it is increasingly easy for someone to use these toolkits which means that there will be more attempts at setting up botnets than we have previously seen. 

Also, they will be running malware that uses increasingly sophisticated methods to dupe the victim.  I think URLZone is particularly grim as it seems to show the direction in which hackers will go which seems to be the implementation of man-in-the-browser attacks. 

These attacks allow the malware to circumvent the security put in place by most sites and even two factor authentication is ineffective in protecting customers.

The future is malware that effectively hides itself in the operating system of choice which means that anti-virus software will either fail to detect or will require days to detect it. 

During that period of grace, the malware will be able to wait until the victim has successfully logged on  to their bank (for instance but certainly not limited to this alone) before inserting itself between the browser and the bank’s website and then automatically and invisibly transfer money to the destination of choice: usually some individual who believes they are working for a legitimate company. 

The victim will be totally unaware that this money has been transferred until they receive their paper statement.  So, until this has been resolved, do not let your bank persuade you to stop those statements. The result is that Internet users have to be increasingly careful. 

The best solution seems to be to reuse an old desktop or laptop that has been retired and reformat that system and install a free operating system like Linux. Then only use that system for financial transactions.  It must not be used to surf the web or to download email.  This way the threat is greatly diminished. 

Without emails to deliver infected attachments or URLs  and no casual surfing to contaminated websites, the chance of a Linux operating system becoming a home to malware is massively reduced.

This may seem like overkill but given the increasing importance of information that is being stored on websites and the cunning of the malware writers, it seems like a good use of old hardware to me.

Cross-posted from RedScan

Possibly Related Articles:
Viruses & Malware
Trojans malware Botnets Web Application Security Financial
Post Rating I Like this!
Christoffer Undisclosed The above scenario should be mitigated by any reasonably "secure" bank. It easy easily mitigated by requiring the user to sign each transfer, unless it's to an account owned by the user itself.

I would argue that these trojans only exist due to "faltering" security engineering practices within the respective bank susceptible to such an obvious attack.

If identification and authentication is done through multiple factors and the hardware token used to "sign" critical functions such as transfering money to external bank accounts... these attacks wouldn't be possible.
Simon Heron It would be good if the current implementations were enhanced. The trouble is that the trojan is logically between the browser and the encryption layer so even signing a transaction would enable the trojan to pass on that signature.

As a quick fix,I would suggest that some form of out of band confirmation (via SMS for instance) would greatly help reduce the damage that these trojans can do.

A longer term fix needs to ensure that the trojan cannot insert itself between the user and whatever encryption is deployed.
Jimi Thompson Unfortunately, if you only steal $1 from a million people, you've still stolen $1,000,000. I agree with the out of band confirmation, however, if it's via SMS - so many people bank from their mobile phones these days, it wouldn't be hard to put something in a "banking app" that would reply to the SMS appropriately :/
Christoffer Undisclosed Simon, Jimi: I disagree. There seem to be some sort of misunderstanding here as to how transaction signatures could be implemented.

One way of doing this is through a mutual key shared between the hardware token and bank. The hardware token is prepared by the bank and also provided to the user through one of the banks offices, obviously first ensuring proper authentication of the user by means appropriate. The fact that the bank prepares the hardware token is obviously key (no phun intended) to the solution.

Now assume the user has authenticated and logged into his bank and wants to perform a transaction.

The user will select the receiving bank account and the amount to transfer. The bank will now issue a challenge for the user to enter into the hardware token. The response is a combination of the challenge and key stored in the token and with the bank (to enable the bank to actually check the response of the challenge).

Now let's ponder the threat you present, a trojan changing data to transfer into another account or whatever. This is rendered "impossible" due to the signature. If the trojan changes the receiving bank account the signature will clearly not match since part of the input to the challenge generation algorithm has changed, rendering the attack useless.
Simon Heron Hi Christoffer, I guess the first thing to say is that many banks are still not deploying two factor authentication which is a great concern and I am in agreement that this needs to be addressed.

However, even with the more sophisticated two factor authentication that your refer to (which sounds like the Nationwide token system, am I right?) there is still a problem. So, for instance, the customer enters amount 'a' and bank account 'c', the trojan intercepts and submits amount 'x' and account 'y'. The bank returns the challenge 'z' which the user enters into token and then submits the response which is correct for what the trojan asked for (not for what the customer asked for and the customer is unaware of this), the trojan just passes this through and the bank transfers the money.

Christoffer Undisclosed Let me also clarify that I'm assuming that the receiving bank account have been previously authenticated (by YOU as a customer of the bank) and will hence already be authorized for use in the transaction.

In a bank transaction there are two critical pieces of information that you as a user want to ensure are correct; bank account number and amount to transfer both having been "verified" by the challenge-response.

Man-in-the-browser will have no effect on the transaction assuming the physical token is not compromised, but that I feel is outside the scope of this discussion.
Christoffer Undisclosed Simon: No, that's not how this works. Let me try and make this as clear as I possibly could. (1) It's not a nation wide token system and (2) the scenario you describe is flawed on many levels. Allow me to elaborate.

Assumption 1:
Let's assume that the user is authenticated to use functions provided by the bank "application", such as transfer money between accounts etc.

Assumption 2:
The user has been provided with a hardware token by the bank. The hardware token is unlocked with a PIN chosen by the user. This PIN will unlock the actual device and allow the user to enter numbers, challenges etc. I'm assuming this device to be secure and hence have not been tampered with.

Scenario - User transfer money to external bank account.

(1) User will first enter the bank account to which she wishes to transfer money. The challenge will be the bank account, since that is what she wishes to authenticate. She will input all, or part of the account number into her device and be presented with a response. This is transfered to the bank, along with the bank account number.
(a) The trojan intercepts and changes the bank account number. This will fail since the response number will not match the account number. And since the user key (stored in the device) is part of the algorithm to present a response code this will ultimately fail.

The account number have now been verified and authenticated and may now be used by the user for transactions.

(2) The user selects the already authenticated receiving bank account number and the amount to transfer. The user will user the amount of money to transfer as the challenge and get a corresponding response code entered into the browser and sent to the bank. bank will verify the amount by using the same algorithm and key as the user (remember that the key stored on the hardware token is one that the bank also has access to, there are two copies of this key)

(b) Threat: Trojan attempts to change the amount of money transfered. This will fail in precisely the same way as the bank account number.
(c) Threat: Trojan will attempt to change the whole transaction, also failing as should be obvious by the above explanation.

Does that clarify the issue?
Simon Heron Hi Christoffer, I think we are talking at cross purposes! The "Nationwide" is a building Society/Bank in the UK which deploys a system similar to this (well a little!). Also which banks are deploying the system you describe? Thanks, Simon
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.