Welcome Guest. | Log In| Register | Membership Benefits
  • Email this page E-mail this page
  • |  Print Print this page
  • |   Bookmark and Share

New Bank Practices Make Hacking Easier

New multifactor logon procedures actually improve attacker's chances of breaking in, expert says at DefCon

Aug 08, 2007 | 08:46 AM

By Tim Wilson
DarkReading

Many of the new practices that banks are using to verify users' identities are actually making their customers easier targets, according to a security researcher.

In a study presented this past weekend at DefCon in Las Vegas, independent researcher Brendan O'Connor outlined a variety of methods that attackers could use to turn banks' latest security measures to their own advantage.

Many of the new authentication methods are a response to federal banking requirements, which state that banks should not rely on a single password system. Under guidelines and deadlines set by the Federal Financial Institutions Examination Council (FFIEC), most banks are now asking customers to answer a challenge or identify a "personalized" image before they can log into their accounts.

But O'Connor says that in their rush to meet the FFIEC requirements, many banks have overlooked some serious vulnerabilities in their schemes, many of which fall short of true two-factor authentication but are sometimes called "greater than one."

"When I started looking at how these banks were deploying this 'greater than one' technology, I couldn't believe my eyes," O'Connor says.

For example, many of the "challenges" that banks use alongside passwords require the user to give away additional personal information, which phishers can steal and use to improve their chances of breaking into an account. Other banks ask users to choose from a series of images, which actually makes it easier for attackers to guess their way into an account, O'Connor says.

To prove his point, O'Connor signed up for a number of online banking services, then installed an inline proxy so that he could monitor the exchange between his computer and the bank's. "I just watched the HTTP requests and responses for these sessions, and immediately knew how to break them," he says.

"The methods [banks] are using for device 'fingerprinting' are effectively Javascript and, in some cases, a flash object," O'Connor explains. "If you think about it logically, they are sending code to my computer, and asking it to be honest about its characteristics. Because I can see the code they are using, I can see exactly what questions they are asking my computer, and what a proper response needs to look like.

"I'd hate to call this a 'hack,' because they did the hacking for me," O'Connor says.

The banks believe that by adding a second question or image -- or by requiring the user to send an email -- they are increasing the odds against an attacker guessing his way into a user's account, O'Connor says. But most savvy phishers and thieves don't break in by guessing, but by stealing information through different means, such as keyloggers or social engineering, O'Connor observes.

The banks' new "second" factors of authentication actually improve the attackers' chances of a break-in by making the penetration path more clear, he explains.

"Effectively, I just downloaded the authentication scripts from the target Website -- it happens before you are authenticated, so you just go to the login page and copy and paste," O'Connor says. In his DefCon presentation, O'Connor demonstrated an exploit against one of his own accounts, "to show the audience how ridiculously easy this stuff is to bypass or impersonate," he says.

"At the end of it, I delivered my security image and phrase via my 'phishing' Website to show how an attacker can impersonate the real bank," O'Connor says. "I also did a standard man-in-the-middle attack for challenge questions, to illustrate that [one-time passwords] and challenge questions are just as easy to get past."

O'Connor believes that the efforts of banks and the FFIEC to add additional factors of authentication are a misuse of resources.

"I don't think authentication is where we need to be spending our time and money," he states. "Was authentication ever the real problem? You had three chances to enter your password, then your account was locked out. The bad guys aren't getting in by guessing passwords. They're getting in by tricking customers into giving them the information, or they are stealing it off their computers through worms, bots, and other malcode. That is the crux of the problem."

The real problem, O'Connor says, is that banks follow what he calls the "Inheritance Trust Model," in which a user who is authenticated automatically has access to all of the functions inside the account.

"In the physical world, stores don't put a bunch of security guards just at the front door -- they put them in the store. And they have cameras in the store, especially in high-risk areas like cash registers. They watch what is taking place inside the store, not just who comes in. In the real world, that's common sense. But when it comes to online banking, the industry just doesn't think that way for some reason."

— Tim Wilson, Site Editor, Dark Reading


Subscribe to RSS










Bugs
ENTERPRISE VULNERABILITIES
Vulnerability:suse linux
Published:2010-01-22
Severity:High
Description:SUSE Linux Enterprise 10 SP3 (SLE10-SP3) configures postfix to listen on all network interfaces, which might allow remote attackers to bypass intended access restrictions.
Vulnerability:ie
Published:2010-01-22
Severity:High
Description:The URL validation functionality in Microsoft Internet Explorer 7 and 8 does not properly process input parameters, which allows remote attackers to execute arbitrary local programs via a crafted URL, aka "URL Validation Vulnerability."
Vulnerability:bind
Published:2010-01-22
Severity:Medium
Description:ISC BIND 9.0.x through 9.3.x, 9.4 before 9.4.3-P5, 9.5 before 9.5.2-P2, 9.6 before 9.6.1-P3, and 9.7.0 beta does not properly validate DNSSEC (1) NSEC and (2) NSEC3 records, which allows remote attackers to add the Authenticated Data (AD) flag to a forged NXDOMAIN response for an existing domain.
Vulnerability:ie
Published:2010-01-22
Severity:High
Description:Microsoft Internet Explorer 6, 6 SP1, 7, and 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, aka "Uninitialized Memory Corruption Vulnerability," a different vulnerability than CVE-2009-2530 and CVE-2009-2531.
Vulnerability:ie
Published:2010-01-22
Severity:High
Description:Microsoft Internet Explorer 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, aka "Uninitialized Memory Corruption Vulnerability," a different vulnerability than CVE-2009-3671, CVE-2009-3674, and CVE-2010-0246.


Briefing Centers
POWERFUL INFORMATION
AT YOUR FINGERTIPS
(SPONSORED LINKS)