more literal evidence of ... well, everything really:
Targeting over 400 banks (including my own :( ! ) and having the ability to circumvent two-factor authentication are just two of the features that push Trojan.Silentbanker into the limelight. The scale and sophistication of this emerging banking Trojan is worrying, even for someone who sees banking Trojans on a daily basis.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.
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....
(spotted by JPM) MITB, MITM, two-factor as silver bullets for online banks, the node is insecure, etc etc.
About the only thing that is a bit of a surprise is the speed of this attack. We first reported the MITB here around 2 years back, and we are still only seeing reports like the above. Although I said earlier that a big problem with the banking world was that the attacker can spin inside your OODA loop, it would appear that he does not take on every attack.
See above for some limits: the attacker is finding and pursuing the attacks that are easiest, first. Is this finally the evidence that cryptographers cannot ignore? Crypto alone has proven to not work. It may be theoretically strong, but it is practically brittle, and easily bypassed. A more balanced, risk-based approach is needed. An approach that uses a lot less crypto, and a lot more engineering and user understanding, would be far more efficacious to deliver what users need.
Posted by iang at March 13, 2008 07:18 AM | TrackBacksome of this dates back to EU finread terminal standard in the 90s ... which identified personal computer end-points as particularly vulnerability ... misc. past posts
http://www.garlic.com/~lynn/subintegrity.html#finread
this was before some disastrous deployment attempts brought personal computer addons into such disrepute (one of the things that USB was designed to handle) ... a few old references:
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO
as implied, the mechanics of how the operations are performed can contribute significantly to the vulnerabilities ... discussed in the old "naked transaction" metaphor blog entries, threads, and posts:
http://www.garlic.com/~lynn/subintegrity.html#payments
and for a little more topic drift ... when there are security solutions that tend to be simple point solutions ... and not provide end-to-end coverage ... leaves enormous infrastructure vulnerability leakage:
Data Protection is Impossible
http://www.cioupdate.com/article.php/3733716
one of the x9.59 financial transaction standards characteristics
http://www.garlic.com/~lynn/x959.html
was not to try and eliminate all the places that information could leak ... but change the paradigm so that such information leakage didn't represent a threat or vulnerability.
Posted by: Lynn Wheeler at March 13, 2008 10:18 AMre:
http://www.garlic.com/~lynn/aadsm28.htm#41
the issue of encrypted/armored sessions somewhat assumes that the vulnerability are (session) evesdropping attacks. purely session-based protection mechanisms are significantly more vulnerable to end-point compromises
article on this trojan from jan08:
New Trojan intercepts online banking information
http://www.networkworld.com/news/2008/011408-silentbanker-trojan.html
similar trojan from dec07
New Trojan Attacks Clients At Four Worldwide Banks
http://www.crn.com/security/204803106
Sophisticated Trojan loots business bank accounts
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053018
article from may06 mentioning similar trojan from nov04:
How SSL-evading Trojans work
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature
both SSL and VPN showed up in IETF about the same time. The problems with home personal computers as end-point of VPN into corporate networks was well recognized in the 90s ... the issue was also part of what led to EU FINREAD standard ... much of the design predicated as countermeasure to personal computer vulnerabilities.
somebody that we had worked with on & off over 10-15 yrs had developed encrypted sessions for his own use from home and then introduced it as VPN in gateway committee at '94 IETF meeting in san jose.
about the same time, we were brought in to consult with small client/server startup that wanted to do payments on their server. two people responsible for something they called a "commerce server" ... when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
and cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa
they had been at a large rdbms vendor ... old meeting
http://www.garlic.com/~lynn/95.html#13
the client/server startup had this technology they called SSL that they wanted to use with what has since come to be called electronic commerce ... and various aspects of electronic commerce (primarily targeted at hiding credit card numbers) is probably the majority use on the internet today.
we were then brought in to x9a10 financial working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... which resulted in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
part of the work was detailed end-to-end threats & vulnerability analysis ... which identified a whole slew of things other than session evesdropping attacks (some also identified in the EU FINREAD standards work).
the resulting x9.59 financial standard ... armored the transaction ... previously discussed in the various naked transaction metaphor threads
http://www.garlic.com/~lynn/subintegrity.html#payments
which eliminated evesdropping as a threat ... and also eliminated the requirement for encrypted sessions as a countermeasure to fraudulent transactions. the spate of online banking trojans are various work arounds to encrypted sessions ... x9.59 armored transactions eliminates the need to have encrypted sessions ... and therefor the perception that online banking is secure based on encrypted sessions.
Armored transactions are still subject to the integrity of the originating endpoint ... something that the EU FINREAD work attempted to address as compensating process.
Posted by: Lynn Wheeler at March 13, 2008 02:08 PM