Bruce Schneier
Schneier on Security
A blog covering security and security technology.
« UK Defense Security Manual Leaked | Main | Don't Let Hacker Inmates Reprogram Prison Computers »
October 6, 2009
Malware that Forges Bank Statements
This is brilliant:
The sophisticated hack uses a Trojan horse program installed on the victim's machine that alters html coding before it's displayed in the user's browser, to either erase evidence of a money transfer transaction entirely from a bank statement, or alter the amount of money transfers and balances.
Another article.
If there's a moral here, it's that banks can't rely on the customer to detect fraud. But we already knew that.
Posted on October 6, 2009 at 6:40 AM • 35 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
AC2 • October 6, 2009 7:35 AM
Hmm suprised you didn't say "and authorise the transaction (....you idiots...)"
vwm • October 6, 2009 8:25 AM
@AC2: German banks (whom the article is about) actually require the user to authorise transactions with unique "Transaction Numbers (TAN)". But that does not stop the trojan from doing its work.
The "Postbank" whose site is shown in the screenshot even offers an optional "Mobile Transaction Numbers (mTAN)": For each transaction you get a short message to your cell phone stating the amount, target account and a random alphanumerical code. The code is needed to authorise the transaction and it will expire if any detail of the transaction gets changed.
Brianary • October 6, 2009 9:30 AM
PDF and AJAX-y online banking systems that send JSON data, rather than HTML, are probably safe from this particular trojan.
AC2 • October 6, 2009 9:33 AM
@vwm... Hmmm interesting.. Then how does the malware deliver the following feature (as listed in the PDF from Finjan)
"Installed on the victims’ machines, it steals money from the compromised accounts"
Also transaction "authorisation" would I believe involve a code that is based on some sort of hash of the amount and bene account id...
Paeniteo • October 6, 2009 9:44 AM
@AC2: "Then how does the malware deliver the following feature (as listed in the PDF from Finjan)"
The unique transaction numbers (TAN/iTAN) are not tied in any way to a particular transaction. A trojan can easily circumvent this measure.
As to the transaction-dependent mobile-TANs sent to one's cellphone... A trojan cannot circumvent these if the user checks the transaction details.
But, with Postbank, they are purely optional (and when I was customer there, they reserved the right to charge you for sending the SMS, although they never actually billed me AFAIR). I dare say that, if you opt-in to mobile-TAN, you are by definition not in the group of the most likely phishing/trojan victims...
Interesting. With the constant push to paperless statements, it could be quite a while before a victim were to discover this.
@Brianary: I don't see how PDF or AJAX-y data transfers would be any more secure. There are freely downloadable libraries to edit .pdf documents. A browser plug-in has access to the data coming back from AJAX calls.
karrde • October 6, 2009 10:17 AM
One online-banking system I've seen has a two-stage login scheme.
Stage 1: enter username
Stage 2: new page loads, showing a user-selected "custom image" with "custom message", and user is allowed to enter password.
It appears to be an attempt to make it harder for black-hats to generate a duplicate of the banking site and trap username/password pairs via phishing.
But this layer of security doesn't protect against on-client trojans like described in the article.
I think side-channel communication, even as slow as a monthly banking statement in the mail, is a must for protecting against this.
However, the Trojan appears to be of the virus/worm variety, for which another kind of general security solution exists.
Bruce, you have argued that the solution to much of the banking authentication woes is the authentication of transactions rather than people. Doesn't this contradict your statement "If there's a moral here, it's that banks can't rely on the customer to detect fraud. But we already knew that"?
Matt from CT • October 6, 2009 10:45 AM
>I think side-channel communication,
>even as slow as a monthly banking
>statement in the mail, is a must for
>protecting against this.
Monthly statements pretty much protect no one, just let you know it was stolen.
The proper fix is an out-of-bandwidth system like some of the posters mentioned above.
You create the transaction, hit send, the bank sends an SMS to your phone with the payee, amount, and authorization code they generated, you enter the authorization code to authenticate the transaction.
AC2 • October 6, 2009 11:06 AM
Though one must ask, should we authenticate EVERY transaction in this less usable manner? Say we do this only when the user sets up a new beneficiary, at which point he also states the expected freq and upper limit on value of payment. Then let transactions that meet this profile thru without much fuss... I'm sure Bruce is going to point to some post where he's discussed this looong back
Mark R • October 6, 2009 11:16 AM
This is definitely impressive, but it really just seems like the next logical step. Today, we have Trojans designed to commit narrow and specific kinds of fraud, but there's a host of other things they could get up to while they've got complete control of your system. For instance, this trojan targeted a particular bank's website, but if it would just passively listen in on all the victim's web traffic for a period of weeks or months, it probably wouldn't be too hard to work out the page layouts, URI strings, and inputs and outputs of whatever banking site the victim uses. They could even take a page from the AV vendors and push out out banking site signature files to leverage the info they've gathered from other machines.
What I find really interesting is that a lot of malware these days is much better written than the commercial software we are paying big money for.
"Bruce, you have argued that the solution to much of the banking authentication woes is the authentication of transactions rather than people. Doesn't this contradict your statement 'If there's a moral here, it's that banks can't rely on the customer to detect fraud. But we already knew that'?"
No. The banks can't rely on the customer to detect fraud, so the banks have to do it themselves -- by authenticating transactions and not people.
gkdada • October 6, 2009 11:27 AM
This is partly mitigated by paper statements mailed each month. However, most banks consider this an avoidable expense and are (VERY) actively trying to push e-statements down the customer's throats.
Also, it involves some amount of diligence and patience on part of customer to try and reconcile paper statements to online statements, faithfully, each month.
Steven Hoober • October 6, 2009 11:57 AM
I think the argument here is missing the point a bit. While malicious, it's not fundamentally different from other vulnerabilities of display not matching actual data. The classic example is the backup system that says "ok" meaning "I ran the script and something finished" but will do that even if nothing was successfully saved to the backup media.
So, the solutions for this are methods to assure that you are viewing correct content. Out-of-channel spot checks seem to be one way, but I suspect there are others. And since it seems to be a structurally good vulnerability for the malicious-minded, it's probably worth finding a structural solution to it.
BankingSecurityGuy • October 6, 2009 12:39 PM
@Mark R: "They could even take a page from the AV vendors and push out out banking site signature files to leverage the info they've gathered from other machines."
They can, they have, and they do.
Mike • October 6, 2009 1:21 PM
And yet there is software out there that can detect this kind of transaction - Entrust's Transaction Guard (full disclosure, I used to work for Entrust, but no longer do), yet they have difficulty selling it and few banks use it.
Its not perfect, by a long shot, but it is more effective than relying on customers.
I guess until banks are made to be responsible for their losses far more than they are now.
Ian Eiloart • October 6, 2009 1:32 PM
Bruce,
how does one authenticate a transaction? You keep telling us that banks should do this, but I still have no clue what it means.
Ian Eiloart • October 6, 2009 1:37 PM
Oh, I see you answered that question a few posts back. It seems a bit vague, though. I've had my bank call me to check on a credit card use, and the first thing they did was ask me my password!
They rang because I'd gone on holiday, so I my location and my spending patterns changed. If I didn't have my mobile phone with me, they'd not have got through. Then what would they do? Block the card, just when I need it most?
Mark R • October 6, 2009 1:48 PM
@BankingSecurityGuy:
Wow... well... I guess my career as the next big malware writer is over before it began.
Shane • October 6, 2009 4:42 PM
Not to be a negative nancy, but I really don't find this very impressive at all. Just a new way to use old methodologies, and certainly only a temporary ruse considering the number of ways of obtaining a bank statement without using your infected Windoze PC.
Shane • October 6, 2009 4:46 PM
@Mark R
"What I find really interesting is that a lot of malware these days is much better written than the commercial software we are paying big money for."
Not very surprising either. Just look at the incentives. People go where the money is.
Shane • October 6, 2009 4:48 PM
Not to mention, just like the big Drug War™: When you try to stifle the supply of illicit goods and services, you simply create more innovation in the supply chain, and more incentive (since the more risky a particular illicit activity is, generally speaking, the more profit there is in it).
vwm • October 6, 2009 5:06 PM
@AC2: as a user of the mobile TAN I must say it is not at all "less usable"; on the contrary I am happy to use it wherever I am, without bothering about carrying around the paper list of transaction numbers.
@Paeniteo: They used to bill me a few cents for that service. But they don't seem to do that any longer. Still I think it's worth the money.
Vincent • October 6, 2009 5:50 PM
Screen scraping and rewriting bank statements? That's a lot of effort for a narrow target. Probably something written to be reprogrammable by non-programmers, or initially written for another purpose.
Vincent • October 6, 2009 5:55 PM
@M
You are correct. JSON is a lot of things, a security measure is not one of them. If the machine is compromised, the whole machine is compromised, PDF ain't going to save U.
Andre D • October 6, 2009 7:35 PM
This reminds me of a trojan I saw several years ago that rewrote Google's search results pages to put spam in the top two positions. The false results looked just like the organic results, and the snippets contained relevant keywords. Clever.
hwKeitel • October 7, 2009 6:51 AM
I like and use the mTAN option. but, I'm still a little worried about the fact, that the phone company (and police etc.) may take a look at my sms and transactions.
Also, I could take advantage using the small local branch of my bank (very unbureaucratic). it's five min. away, and I know the guy since im a kid. the day he retires I bury my money somewhere.
bob • October 7, 2009 6:58 AM
Why shouldn't the receiver be held responsible for validating incoming traffic and comparing it against the original [which they don't have]?
My (ex-)wife always held me responsible for possessing information she didn't actually give me; I was just supposed to "know" it - this seems similar...
Peter E Retep • October 8, 2009 3:34 PM
re: Further Thought on this:
Let me get this right:
There is a bank A.
Money is credited to an account number B within A.
Covert agent C enters A's software,
uses B number to author money a 'transfer' of [cash-equivalent] credits
into another account location D,
allegedly from B,
but then also restores B's numbers
to what they were before D's action.
This being discovered,
the bank A reflexively tries to 'externalize'
the 'cost' to the customer B.
But in fact B suffered no B recognizable loss.
A has suffered no loss.
This e-creation of new value symbols in the e-environment
is actually a new act.
I nominate the term e-feiting, as opposed to counterfeiting.
Is it theft? No.
Is it creating a testably false, yet passable imitation currency?
Apparently not.
It is e-'minting' e-money.
No resources are consumed.
Is this actually a crime, philosophically?
How is it different from a store issuing credit?
If the store issues a credit line credit card?
The problem is one of a complete lack of accountability,
and of consequence, of backing stolen from the shared community,
all impacting a restricted social sharing symbol tool.
A speculation:
It seems the root problem is having all economies denominated in the same cash-equivalence.
If there were cash notes, credits, and trillion-speculative symbological transaction derivative moneys, each in their own economies, with the translations values floated by auction, then if derivatives shunted trillions, it would not effect the cash economy, etc.
What do you think?
Peter E Retep • October 8, 2009 3:37 PM
re: uses B number to author money a 'transfer' of [cash-equivalent] credits
that should read "a money transfer"
rather than "money a transfer"
SnarK • October 12, 2009 1:14 AM
@ Peter E Retep
Your poetic style inhibits my ability to understand you. Could you repost your idea in the form of haiku, instead?
Peter E Retep • October 12, 2009 6:47 PM
Mr SnarK -
Unwritten paper rustlers
Paperless transfers
Money rains from sunny skies
Peter E Retep • October 12, 2009 6:49 PM
SnarK
If you prefer the traditional count:
Unwritten paper
Rustlers paperless transfers
Money rains from skies
Subscribe to comments on this entry
Post a comment
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.
|
| Subscribe |
Subscribe via Kindle |
| Blog Menu |
SearchPowered by DuckDuckGoBlog Home Page
Archives by Date2013 J F M A M
Tags  |
| Latest Book |
more books by Bruce Schneier |
Comments