• Chief Information Officer
• IT Systems Administrator
• Project Manager - Permanent...
• Information Risk Analyst / ...
• Senior Flash Developer / ...

E-commerce in crisis: when SSL isn't safe

Roger A. Grimes, Information Age

13/06/2006 13:23:31

The Great Train Robbery of 1963 netted nearly $90 million in today's dollars. The largest bank heists have scored more than $100m. But "stick-'em-up" bank robberies offer high risks and low rewards: yields average a few thousand and between 50 and 75 per cent of perpetrators get caught.

Robbing a brick-and-mortar bank seems like petty theft compared with a new breed of cybercrime that, according to a growing number of security experts, is siphoning untold millions of dollars from banks and their customers using SSL-evading Trojans and ever more refined phishing techniques.

Every antivirus and anti-malware vendor can report thousands of bank and e-commerce-specific Trojans designed to steal money and identities, often collectively referred to as Bancos/Banker variants.

Yet given the vast investment in quelling consumers' fears about conducting business online, it's no surprise that few sources are anxious to provide information that highlights the severity of the problem.

Although the banking officials and security officers contacted for this article refused to be quoted on the record, all of them agreed that online bank fraud is an increasing problem. One US banking regulatory security auditor said that in some instances, online bank fraud drains as much as 2 to 5 percent from a bank's overall revenue.

Les Howarth, area MD for applications delivery vendor F5 Networks, avers that Australian banks lose much more: "While it's difficult to get hard numbers our evidence would put losses higher.

"F5's client base includes major banks, financial institutions and public sector businesses, and all are so security conscious that they will not agree to be site references, let along divulge the costs of losses through intrusions.

"But we know it's significantly more than 5 per cent through our own experience and by discussing the issue with CSOs at the Jericho Forum and similar gatherings of those concerned with securing their businesses."

Security specialist and assurance services manager for accountants BDO Dr Craig Wright agrees: "There have been some serious attacks in Australia but little is said about them.

"Financial institutions have accepted losses as a cost of doing business, in the same way that some retailers have an allowance built into prices to compensate for bounced cheques. The banks generally take a lot of small hits rather than significant single cyber thefts."

This tallies with Howarth's local experience: "There are not that many really good hackers out there who can go for a big hit, but if they do, the Great Train Robbery will look like pilfered petty cash.

"The people who are making money are doing so in small amounts - they're buying a Ferrari on the proceeds but doing it a wheel nut at a time. It takes longer but they get the Ferrari and the banks can accommodate the costs - but it's still steadily eroding their revenue."

He attributes some of the problem to indifferent software development: "Organisations are getting software written to a price, not a standard. They pay so much for a line of code, insist that it be delivered on time and install it without proper testing.

"The work is often done overseas, but it's not the fault of the contractors that it's below par; the client doesn't go far enough to ensure its integrity and then wonders why an intruder simply walks through it or around it.

"Add the fact that everyone wants Web-based businesses to save on human overheads and the overall problem continues to grow."

Tracking the cost of the problem is also an international business: business analysts McKinsey reported that one US bank saved more than $100m by outsourcing low-value fraud auditing and analysis to India.

Mark Sunner, CTO of e-mail security provider MessageLabs, thinks it will take "a single, high-value tipping-point event" to wake up the general public, which would then pressure public officials. "I think the world's largest bank heist will soon be committed using malware," he says.

Phishing with a hook Phishing remains the weapon of choice for online bank theft -- and the sleight of hand that tricks users into visiting a phishing Web site continues to get more sophisticated. Phishing e-mails now show up with the user's address, area code, or account information already filled in, indicating that professional criminals are using other, previously compromised resources to gain the trust of consumers.

Yet as phishing gets slicker, users are getting smarter. As the average Joe becomes less likely to type in authentication information in response to an e-mail, more and more cybercriminals are turning to SSL-evading Trojans.

These Trojans install themselves on unsuspecting users' PCs and either capture user log-on credentials or manipulate transactions after a successful log-on. In both cases, the SSL connection between PC and bank remains intact. The user may think the confidential online transaction is protected against mischief -- but it is not.

That shift has enormous implications. Ever since Netscape released SSL in 1996, consumers have been told that a confirmed SSL-connection icon indicates that it's safe to conduct online business.

"The problem is," according to one bank regulatory security auditor, "SSL isn't broken. SSL states that the connection between your PC's network card and the bank's network card isn't compromised. This is still true. Nobody is sniffing the transaction off the wire. Instead, this is a 'man-in-the-end-point' attack."

In other words, the Trojan is sniffing or manipulating the transaction before it is ever sent across the Internet to the bank.

According to Mitchell Ashley, CTO of network security provider StillSecure, "Traditional phishing attacks have duped end users into clicking on a link, but in the newest evolution, even the most security-savvy can fall victim to attack. Once you're infected, the game is up."

Although the theft of credentials remains the biggest threat to online e-commerce, SSL-evading Trojans are quickly becoming the criminal hacker's favorite tool, mainly because SSL-evading Trojans can bypass any authentication scheme.

Fighting the last war Most banks and e-commerce sites fall one step behind, responding to Trojans that steal log-on credentials by creating more complex authentication schemes and implementing two-factor authentication solutions. Today, banks frequently require that users click on-screen, randomised keyboards; type in the random letters of a "magic word"; or enter information from a hardware-based cryptographic key fob. None of these solutions works against the new breed of SSL-evading Trojans.

"It's not a problem of authentication but one of transactional authorisation," says Bruce Schneier, leading security expert and CTO of Counterpane Internet Security. "No matter how hard you make the initial authentication for the end user or hacker, the malware can just wait until the authentication is done and then manipulate the transaction."

For example, you think you're checking your bank balance or writing an online cheque to pay a bill, but the Trojan is transferring your bank balance to a bank account in the Cayman Islands.

"The real problem is that we are allowing computers to make transactional decisions for us on our behalf, and the computer really doesn't know what is right or wrong," Schneier explains. "The consumer may not be able to see the real transaction to put a stop to the automated authorisation approval, and the bank really has no way of knowing that a Trojan is making the decision, and not the customer."

Even more disturbing is that most banks and regulatory officials don't understand the new threat, and when presented with it, hesitate to offer anything but the same old advice.

Every bank and regulatory official contacted for this article said they have already recommended banks implement a two-factor or multifactor log-on authentication screen. In general, they expressed frustration at the amount of effort it has taken to get banks to follow that advice. And all complained about the trouble these schemes are causing legitimate customers.

When told how SSL-evading Trojans can bypass any authentication mechanism, most offered up additional ineffective authentication as a solution. When convinced by additional discussion that the problem could be solved only by fixing transactional authorisation, most shrugged their shoulders and said they would remain under pressure to continue implementing authentication-only solutions.

They were also hesitant to broach the subject with senior management. It had taken so long to get banks to agree to two-factor authentication, they said, it would be almost impossible to change recommendations midstream. That puts the banking industry on a collision course with escalating attacks.

Verifying real transactions Workable answers to the SSL-evading Trojan problem aren't necessarily more inconvenient than two-factor authentication solutions. They just have a different focus: transactional authorisation. Solution providers need to realise that any authentication mechanism can be bypassed, and instead focus more on the right long-term answer.

Some banks now send consumers an "out-of-band" authorisation code -- that is, not through the PC, but via voice message or text message through another device -- to type in and confirm a particular transaction. Unfortunately, the bank is confirming the transaction as the bank sees it, whereas an SSL-evading Trojan could be manipulating what the customer thinks the bank is getting ready to do.

The customer may think he or she is making a small transaction, whereas the bank, because of the Trojan, is closing an account out and a transfer of funds to another bank.

In this case, sending an authorisation code to the customer by itself doesn't work because the consumer is confirming a transaction he or she can't really see.

A better solution would be to send the consumer the relevant details -- such as the date, from, to, amount, and so on -- along with the authorisation code, thus allowing the consumer to confirm the transaction. Some banks and e-commerce sites do this already using in-band e-mail confirmations.

Schneier has his doubts about the out-of-band approach. "These types of authorisation schemes would work, but it sounds a little extreme as a solution. Unfortunately, we live in an economic reality where users will not accept extremes. They want convenience."

Bank officials concur. One regulator said: "Most banks, because of their customers, would probably not accept such an extreme form of authentication. How often would the out-of-band device fail or not be available? Requiring users to confirm every banking transaction out-of-band would not be accepted by today's consumers."

The regulator speculated that a better solution might be for the bank to offer out-of-band confirmations as an option and allow the consumer to pick the dollar amount at which the transaction would require additional confirmation measures.

Other bank security officers thought implementing added intelligence on the back end would provide more value. "How about not allowing online transfers to banks and countries with strong ties to crime?" offered one officer. "We could deny any transaction that the bank deemed highly suspicious, like your credit card company does now, and require a second confirmation."

Close observation of consumer behaviour can also help. In one case, nearly 100 customers of one large bank were infected with an SSL-evading Trojan. As usual, the phishing e-mail used mostly legitimate links to the real bank's Web site. After noticing outside requests to links, most of which were normally referenced from other internal links, the bank's IT staff realised a Trojan was to blame.

The solution was to rename one of the requested links. If any user went to the real bank's Web site, the renamed link was now referenced by the legitimate Web site. Only the phishing customers would request the link's old name, enabling the bank to tell how many of its customers were compromised.

Yunus Emre Alpozen, a consultant for one of the world's largest banks, says: "Every customer requesting the old Web page link was redirected to a new page that notified them that they were the victims of a phish attack, and how to proceed. We used the phisher's e-mail against them."

Self-defence for consumers Sadly, infection can't be stopped merely by convincing users not to execute untrusted software. No consumer knowingly installs malicious software, and SSL-evading Trojans can easily go unnoticed by the most careful user.

One of the best defences is simply to convince consumers to check their online balances frequently. Beyond this, consumers need to lobby financial institutions and move their accounts from institutions that keep their head in the sand.

Banks that require stronger authentication and transactional authorisation should be rewarded. Those institutions should also encourage customers to report phishing attacks to the site's security reporting e-mail address so they can take down fake Web sites or otherwise minimise risk.

Currently, log-on-stealing Trojans are still the No. 1 threat to the banking industry, but SSL-evading Trojans that can bypass any authentication scheme are emerging as a particularly frightening challenge. They need to be dealt with now before consumer confidence in e-commerce goes into serious decline.

Peter Davidson contributed to this article.

[sidebar] How SSL-evading Trojans work

SSL-evading Trojans bypass the secure and authenticated tunnel mechanisms that are the safety backbone of today's Internet banking and financial institutions. As with any Trojan, this type can do anything allowed by the user's security permissions.

There are three basic flavours of SSL-evading Trojan: credential-stealing, bogus SSL and transaction-based.

The credential-stealing variety is similar to the conventional password-stealing Trojan but with a twist. Rather than simply capture logon keystrokes and forward them to an attacker, these Trojans can also subvert such authentication methods as on-screen keyboards with random key placement, requests for random letters from a user's "magic word", or reselection of a previously selected graphic.

They do this by taking small snapshots of the screen when the user clicks in previously located authentication areas. The pictures are collected, zipped and then sent back to the malicious hacker.

Bogus SSL Trojans offer up fake local Web pages in place of a bank's real Web site. When the Trojan installs itself, it searches the browser cache for bank and financial Web site pages and generates fake local pages. Then, when the user visits a real bank site, the Trojan intercepts the log-on and redirects it to the locally, bogus copy. The Trojan sends the credentials typed by the user to both the real bank and to the malicious hacker.

Transaction-based SSL-evading Trojans are the most dangerous and sophisticated. They wait until the user has successfully authenticated at the bank's Web site, eliminating the need to bypass or capture authentication information. The Trojan then manipulates the underlying transaction, so that what the user thinks is happening is different from what's actually transpiring on the site's servers.

The Win32.Grams E-gold Trojan, spawned in November 2004, is a prime example of the transaction-based type. When the user successfully authenticates, the Trojan opens a hidden browser window, reads the user's account balance, and creates another hidden window that initiates a secret transfer. The user's account balance, minus a small amount (to bypass any automatic warnings), is then sent to a predefined payee.

Many SSL-evading Trojans are "one-offs", meaning that they are encrypted or packaged so that each Trojan is unique -- defeating signature-style detection by antivirus software.

Ultimately, SSL-evading Trojans can be defeated only when users stop running untrusted code -- or better still, when banks deploy back-end defensive mechanisms that move beyond mere authentication protection.