Attacks/Breaches
7/5/2012
02:16 PM
Connect Directly
RSS
E-Mail
50%
50%

Court Slams Bank For Ignoring Zeus Attack

Federal appeals court panel reverses previous ruling that construction company could not sue bank to recover $345,000 stolen by malware attackers.

Score one for common-sense rulings: A three-person federal appeals court Tuesday slammed a bank for failing to spot fraudulent transactions, despite the bank's security systems having flagged six related transactions as "high risk" and very likely fraudulent.

The court's decision reverses a lower-court ruling that found that Ocean Bank wasn't responsible for the fraudulent transactions initiated by attackers, who withdrew $589,000 from the account of Patco Construction, a family-owned construction firm in southern Maine. While the bank recovered almost half of those funds, the previous ruling had meant that Patco wouldn't recover the rest.

But in the new federal appeals court ruling, the judges decided to "leave open the question of what, if any, obligations or responsibilities" Maine's Uniform Commercial Code (UCC) imposed on Ocean Bank, which has since been acquired by People's United Bank, and said they were allowing the suit to proceed. But in their ruling, the judges pointedly asked whether both parties might not "be wiser to invest their resources in resolving this matter by agreement."

[ Three Baltic men face jail time for thwarted money laundering scheme. Read about it at British Police Bust Baltic Financial Malware Trio. ]

Here's how the attack unfolded: Over seven days in May 2009, attackers used the construction firm's banking details and security-challenge questions--captured using Zeus malware--to authorize the money transfers. "The perpetrators supplied the proper credentials of one of Patco's employees, including her ID, password, and answers to her challenge questions," court documents read. "The payment on this withdrawal was directed to go to the accounts of numerous individuals, none of whom had previously been sent money by Patco. The perpetrators logged in from a device unrecognized by Ocean Bank's system and from an IP address that Patco had never before used."

While the bank recovered about $243,400 of Patco's missing money, the construction firm was left with $345,440 out of pocket. Accordingly, in 2010, Patco sued the bank to recover the rest, alleging per Maine's UCC that the bank hadn't used a "commercially reasonable" security system.

But last year, U.S. District Court magistrate D. Brock Hornby in Maine disagreed after finding that the bank had complied with Federal Financial Institutions Examinations Council (FFIEC) security guidelines. Those rules, set in 2005, required banks to use a second factor to secure online transactions. Hornby recommended that the case be dismissed.

His ruling drew widespread criticism, however, for putting the bank account information security onus on small and midsize businesses rather than on banks. According to many security experts, since the rise of financial malware and more advanced attacks, the minimum security safeguards required by the FFIEC no longer offer a reasonable level of protection. Furthermore, while banks have been beefing up security for consumer customers, many have left small and midsize business customers more exposed, according to security experts. Accordingly, criminals have been harvesting business account credentials and targeting them with increasing prevalence.

The three-judge federal appeals court seemed to agree, noting in their ruling Tuesday that as far back as 2005, security firm RSA was warning that challenge questions were "quicker and simpler to adopt but were less secure," and should be used only "in the short term, as the first phase of a full project," and then triggered only in response to suspicious activity.

But beginning in 2008, Ocean Bank began using challenge questions for any transaction over $1. Furthermore, the judges said that the problem of keyloggers targeting financial accounts was widely known then, and that a "common-sense" security response from the bank would have addressed that fact since there was no way a bank customer would have been able to spot when an attacker had obtained and used their security-challenge questions. In fact, the bank spotted the fraudulent transactions only after some transfers were rejected by the receiving banks because the transfers referenced invalid account numbers.

Ocean Bank already had software in place to detect fraudulent transactions, which it ignored. Notably, the bank's risk-scoring engine generated a score of 790 for the first fraudulent transfer from the Patco account. That score was a significant departure from Patco's usual risk scores, which ranged from 10 to 214. "Despite this high risk score, Patco was not notified. Moreover, it appears no one at the bank monitored these high-risk transactions," read the ruling. Some of the subsequent fraudulent transactions, which involved sums that were orders of magnitude larger than any transfers Patco had ever made to third parties, scored 720, 563, and 785.

"Although the bank's security system flagged each of these transactions as unusually high-risk because they were inconsistent with the timing, value, and geographic location of Patco's regular payment orders, the bank's security system did not notify its commercial customers of this information and allowed the payments to go through," said the ruling.

"Because it had the capacity to do all of those things yet failed to do so, we cannot conclude that its security system was commercially reasonable," wrote the judges. "We emphasize that it was these collective failures taken as a whole, rather than any single failure, which rendered Ocean Bank's security system commercially unreasonable."

But the ruling noted that in the wake of the Patco attack, the bank did implement several improvements. "Since then, the bank has instituted a policy of calling the customer in the case of uncharacteristic transactions to inquire if the customer did indeed initiate the transaction," the judges wrote.

Security information and event monitoring technology has been available for years, but the information can be hard to mine. In our SIEM Success report, we provide a step-by-step guide to make the most of your SIEM system. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Andrew Hornback
50%
50%
Andrew Hornback,
User Rank: Apprentice
7/7/2012 | 2:30:07 AM
re: Court Slams Bank For Ignoring Zeus Attack
"Ocean Bank already had software in place to detect fraudulent transactions, which it ignored."

There's your smoking gun, at least in this case. When you have a system in place that could prevent this kind of problem and you ignore it - that transfers the responsibility for the legality of the transaction.

At least that's how things operate in my world...

Andrew Hornback
InformationWeek Contributor
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7392
Published: 2014-07-22
Gitlist allows remote attackers to execute arbitrary commands via shell metacharacters in a file name to Source/.

CVE-2014-2385
Published: 2014-07-22
Multiple cross-site scripting (XSS) vulnerabilities in the web UI in Sophos Anti-Virus for Linux before 9.6.1 allow local users to inject arbitrary web script or HTML via the (1) newListList:ExcludeFileOnExpression, (2) newListList:ExcludeFilesystems, or (3) newListList:ExcludeMountPaths parameter t...

CVE-2014-3518
Published: 2014-07-22
jmx-remoting.sar in JBoss Remoting, as used in Red Hat JBoss Enterprise Application Platform (JEAP) 5.2.0, Red Hat JBoss BRMS 5.3.1, Red Hat JBoss Portal Platform 5.2.2, and Red Hat JBoss SOA Platform 5.3.1, does not properly implement the JSR 160 specification, which allows remote attackers to exec...

CVE-2014-3530
Published: 2014-07-22
The org.picketlink.common.util.DocumentUtil.getDocumentBuilderFactory method in PicketLink, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 5.2.0 and 6.2.4, expands entity references, which allows remote attackers to read arbitrary code and possibly have other unspecified impact via...

CVE-2014-4326
Published: 2014-07-22
Elasticsearch Logstash 1.0.14 through 1.4.x before 1.4.2 allows remote attackers to execute arbitrary commands via a crafted event in (1) zabbix.rb or (2) nagios_nsca.rb in outputs/.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.