"Financial Service Technology America, today's latest financial news now..."
New Account

The Magazine

Issue 4

This is a short description of the magazine.

E-magazine
  • Previous Issues

Blog

Where our team of editors discuss what they think about the current FST US Issues.

Huw Thomas
Editor

From the archive: FST US 9 podcast

We take a look back to our last issue to see what was on the industry's mind in Autumn 2008.
03 Feb 2009

Latest threat: ‘man-in-the-middle’ attacks

Tricipher, Inc | www.tricipher.com

Comments (1) | Read All

By John De Santis, CEO, TriCipher, Inc.

Throughout 2006, a series of high-profile incidents occurred that very painfully and very publicly highlighted how flimsy usernames and passwords are in protecting a person’s online identity. Phishing and various other forms of online fraud sent the e-business community – particularly in financial services, which bore the brunt of these attacks – into a tailspin. In a bold move, one of the world’s largest banks aggressively promoted its deployment of multi-factor authentication as a free, required service to all of its online banking customers.

Subsequently, many banks have followed suit, adopting technology designed to verify that the bank’s website was really the bank’s website, and that users were who they said they were. Generally, the enrollment process required people choose an image to use as a unique identifier, write a brief phrase, and select three challenge questions. The website then dropped a cookie on the user’s machine that gets passed back and forth between the user’s computer and the bank to confirm each other's identities. This process made customers feel safer, and demonstrated that banks were stepping up to the plate to protect their customers online. But where the cyber-rubber hits the road, they’re relying on HTTP cookies for authentication – a method which is at best weak, and at worst, completely useless.

As a quick refresher, the term "HTTP cookie" derives from "magic cookie", defined in Wikipedia as a packet of data a program receives but only uses for sending it again, unchanged. Already used in computing, magic cookies were “webified” by Netscape programmers while developing an e-commerce solution for one of Netscape’s customers to implement a virtual shopping cart.

From their inception, cookies have been fraught with both security and privacy issues. Cookies are easily hacked, often deleted by users (requiring frequent answering of security questions to view their accounts), and useless against Man-in-the-Middle (MITB) and Man-in-the-Browser (MITB) phishing attacks, which are occurring with increasing frequency.

To be fair, cookies, passwords, and images are more secure than passwords, but not by much. In a nutshell, they raise the bar from nothing to…almost nothing. As a consumer of online services, I can appreciate the initiative to ensure my safety without any major inconvenience -- but if it’s not buying me a safer experience, then what’s the point? When the cookies crumbles, then what?

The justification for using cookies for consumer authentication is that it’s a step up from what’s currently being used (usernames and passwords) and doesn’t interfere with the online experience. It all boils down to the classic battle between security and convenience – more security means more complexity, and if it becomes too much of a hassle to bank online no one’s going to do it. So the big nut the banks, the FFIEC, the auditors, security vendors, analysts, and market researchers are all trying to crack is what is “good enough” security – meaning, secure enough to actually protect people, without making the user experience so complicated that it drives them offline.

It’s not an easy question to answer. That said, any organization that knowingly rolls out insecure security technology to quickly appease customers and/or meet compliance deadlines is not only wasting time and money, but also flagrantly deceiving its customers.

One of the early and vocal critics of a cookie-based approach to authentication was David Cowan, general partner at Bessemer Ventures and co-founder of VeriSign. In a July 2005 blog post, Cowan wrote that this particular approach to web-based authentication “…promises to confuse and inconvenience customers, instilling a false sense of security that will, when it quickly fails, further impede online banking.”

The analysts were kinder -- at least at first. Gartner, Inc. named the bank’s technology provider as one of its “Cool Vendors in Security and Privacy” in 2006, citing that its “coolness” was, in great part, due to the fact it was the first to successfully introduce some form of multi-factor authentication to thirteen million consumers.

Less than six months later, Gartner analyst Avivah Litan wrote a report highlighting the security flaws of the same technology, stating that the bank’s solution “… fosters consumer confidence but cannot be wholly relied on to effectively reduce fraud.” She went on to say, “Online consumer service providers need a bifurcated strategy… one piece to build consumer confidence and another piece to keep the crooks out.”

Unfortunately, the Gartner report came out after many banks had already followed suit in order to meet the tight window imposed by the December 2006 FFIEC deadline.

The irony of the FFIEC guidance is that, while it intends to ensure that banks do the right thing to protect online customers, it leaves more than enough rope for banks to hang themselves on security. Given the short timeframe banks had to comply and the wide variety of choices they had to sift through, it’s conceivable that banks would lean towards cookie-based technologies. They’re an improvement over what they had and cookies provide them with an FFIEC checkmark. So in the short-term, consumers will feel safer, and the banks will get to breathe a deep sigh of relief once they pass the audit. But they better breathe deep -- things are going to get ugly once the next high profile attack demonstrates how ineffective cookies really are.

At the risk of raising the already nauseating level of fear-mongering that’s par for the course in the security industry, I encourage you not to throw the baby out with the bathwater. Last year MITM attacks were widely perceived as a strictly theoretical threat. In 2006, these “theoretical threats” crippled a bank in Europe and compromised a major U.S. bank (despite its use of tokens) along with several brokerages in Canada. In November 2006, hackers using Trojans successfully executed an online “pump and dump” scheme against the customers of two leading U.S. brokerages to the tune of $22 million dollars. Think the folks impacted by that attack are still comfortable leveraging online services? Cookies, and even tokens, would have been utterly useless in stopping these attacks.

Man in the Middle Phishing

In 2004, the first wave of “Phishing 1.0” attacks tricked unsuspecting consumers into clicking on links to fake bank websites and giving up their usernames, passwords, and other personal information leading to financial fraud and identity theft. Phishing 2.0 has evolved to combine traditional Phishing ‘hooks’ with a Man-in-the-Middle attack (in the Citibank case involving a botnet), and URL spoofing. A Phishing 2.0 attack tricks the user into clicking on a link to login to their bank through the Man-in-the-Middle Phishing proxy site. It is actually easier to launch than traditional Phishing 1.0 scams because the attacker does not need to create and maintain a copy of a fake site. The phisher merely passes through the actual pages from the real web site, then steals data or makes changes to transactions automatically using easy-to-write scripts.

"This is a common and predictable attack. As an industry, we need to accept that solutions not incorporating strong client and server authentication cannot survive the Internet. Ten years ago, this was evident with the advent of key SSL mechanisms. It's time to put them to work,"

Eric Greenberg
Chief Master Architect for security firm KSR
Former leader of Netscape's security group, which originally created SSL

Security Measure How it Works Vulnerability to Phishing 2.0
One Time Password Tokens
(Including Hardware, Software, and Scratch Cards)
Users receive a hardware device, paper scratch card or grid card that changes their passcode for every login (in some cases every 30-60 seconds) The one time password is passed through by the attacker and used to login within milliseconds, making even the 30-60 second time period for time synchronous tokens irrelevant
IP Geolocation The website associates the user’s account with the geographic location of the IP address The Man-in-the-Middle proxy server is routed to a local botnet computer located in the same geographic region or ISP as the user’s computer.
Device Fingerprinting The website attempts to create a profile of the device based on information provided by the web browser The browser information is passed through unchanged from the original user’s computer. This can also be easily spoofed by the phisher
Browser Cookie The website places a browser cookie on the user’s computer after answering secret questions Due to frequent roaming and cookie deletion, users get accustomed to answering secret questions. The Man in the Middle can trick the user into answering the secret questions at the phisher site and then use those questions to log into the real bank.
Picture or Text on Website
(such as Bank of America’s SiteKey™)
The user select a personal picture or text phrase that always appears on the login website to assure the customer that they aren’t being phished After stealing the secret questions and resetting the cookie as described above, the attacker now also has the picture and text that is unique to the user.
Virtual Keyboard The user inputs their passcode through a web-based graphical keyboard The user’s passcode is stolen after it is entered through the web-based virtual keyboard.
Phone or Email Out-of-Band Authentication The user enters a code sent to them over the phone or through email Because the user is online performing transactions, when the phone rings with the passcode, the user answers and enters the code into the website. The attacker’s proxy site passes the code through, and a script changes the transaction that the code is verifying without the user knowing.
Knowledge-Based Authentication The user answers a series of personal questions The attacker’s man in the middle proxy automatically passes the questions to the user and returns the user’s answers to the web site (after stealing the answers).

Why Are These Security Measures Vulnerable?

These measures are vulnerable to Phishing 2.0 attacks for some combination of the following reasons:

  • They rely on weak, easily spoofable information such as http header information or IP geolocation
  • They rely on ‘shared secrets’ that must be sent over the Internet where an attacker can get them
  • They use only one-way SSL security (only the website has an SSL certificate) instead of two-way, which is the way SSL was designed to be used

Of course, consumers want convenience – it’s one of the fundamental drivers for any online service offering. On the other hand, they certainly don’t want to get their money or their identities stolen. It’s one thing to acknowledge that despite the vigilance and good intentions of service providers, bad things happen in Cyberspace. It’s a completely different issue if my bank goes out of its way to let me know all the things its doing to protect me, only to learn it knew beforehand that the measures it had taken were ineffective against anything but a small set of already obsolete phishing attacks. That would cause me to stop doing business with them forever.

Evidently, it appears I’m not the only one who feels that way. An August 2006 Gartner survey revealed that almost nine million US adults have stopped using online banking, while another estimated 23.7 million won't even start because of fears over security. How many more users would defect if they knew they were being scammed by the very people promising to protect them? It certainly blurs the line between the good guys and the bad guys, doesn’t it?

When the cookie crumbles, everyone loses. So why let it happen?


More like this...

Disclaimer: All comments posted in a personal capacity
POST A COMMENT
In order to post a comment you need to be regsitered and signed in.
Register | Sign in
Read All Comments Comments (Total 1 Comments)
Marco Morana
Posted: 29 March 2009 @ 02:16       |       Updated: 29 March 2009 @ 02:51

I believe phishing 2.0 threats requires banks to adopt new countermeasures. One of the reasons is, as you rightly pointed out in the article, that previous countermeasures were designed to fight phishing 1.0 and were adopted at least by US banks to mostly buy a checkmark from FFIEC auditors. By the end of 2006, most of banks in the USA adopted RSA MFA technologies such as SiteKey and Cyota that are now ill designed to fight phishing 2.0 since are based on IP geolocation and device fingerprinting that can be spoofed via web proxies, and MiTMable challenge answer questions and same channel delivery of OTPs.

The question is than how to fight this new threat? In general I think there is a need of application security awareness on new phishing 2.0 threats, MiTM attacks as well as understanding of the sophistication of the attacking tools being used (e.g. RBN crimeware tools such as rockphish, storm, asprox).

For a change, I think current phishing 1.0 technologies need to be criticized at CIO level also in terms of total cost of ownership vs. benefit to mitigate fraud. The current industry trend as I see it, is to mitigate phishing 2.0 with a defense in depth approach (client and application) that practically means 1) EVs certificates and promoting AV, AS for clients, 2) adding new MFA controls and 3) updated fraud networks.

The problem in my opinion is that the security industry lack honest validation in the claimed effectiveness of new countermeasures for phishing 2.0 with real objective data. Ideally financial regulatory bodies (e.g. FFIEC, OCC) also need to come with a new requirements. MFA vendors need to make both the security and the cost vs benefit cases for phishing 2.0. The most known solutions such as PKI (e.g. TriCipher), chip ID fingerprinting (e.g. Broadcom USH/Verdasys Sitetrust), client sandboxing (e.g. Trusteer) lack these data. You have a good mitigation case for mitigations but what about cost vs benefit?

Disclaimer: All comments posted in a personal capacity