A metals supply company in Michigan is suing its bank for poor security practices after a successful phishing attack against an employee allowed thieves to steal more than half a million dollars last year.
The lawsuit, filed by Experi-Metal Inc. (EMI), in Sterling Heights, Mich., charges that Dallas-based Comerica Bank effectively groomed its customers to become phishing victims by routinely sending them e-mail messages that asked recipients to click a link to update the bank’s security technology. The company also alleges that Comerica’s security protections for customers are not commercially reasonable, because the phishing scam routed around the bank’s 2-factor authentication system.
According to a complaint EMI filed in December with a Michigan circuit court, for many years Comerica used “digital certificates” for authenticating online banking customers. Digital certificates are the browser-based counterparts to ATM cards, and many banks require customers to include the bank’s cryptographically signed digital certificate in their browser before the bank’s online system will allow users access.
Once a year from 2000 to 2008, Comerica sent emails to EMI and other customers directing them to click on a link in the email, and then log in at the resulting Web site in order to renew the digital certificate that Comerica required.
The trouble with relying on digital certs, of course, is that phishers have been using the e-mail ruse of “Hey, this is your bank, please update your digital certificate” for several years now in a bid to fool people into giving away their credentials or installing malicious software. Also, several families of malware will steal digital certs from victim PCs.
Perhaps in response to these fraud trends, Comerica in 2008 began urging customers to adopt a different security solution that supplemented user names and passwords with a security token. These small devices periodically generate a new, random numeric code, which must be entered along with the customer’s user name and password in order to access online banking at many commercial banks.
On Jan. 22, 2009, an EMI employee fell for a phishing e-mail that spoofed Comerica, and claimed the bank needed to carry out scheduled maintenance on its banking software. The e-mail instructed the EMI employee to log in at a linked Web site that mimicked Comerica’s online banking site. The EMI employee provided the site with the company’s online banking credentials, as well as the the code generated by the security token.
Thieves almost immediately began wiring money out of EMI’s account. Between 7:30 a.m. and 10:50 a.m., the attackers initiated 47 wire transfers — to China, Estonia, Finland, Russia and Scotland.
EMI claims Comerica inquired about the transfers at 10:50 a.m., and that EMI asked the banks not to honor any requested wire transfers until future notice. But over the next three hours, thieves would initiate another 38 wires from EMI’s account. EMI also noted that, prior to this burst of fraudulent wires, the company had requested a total of two wire transfers in as many years. EMI says it lost more than $560,000 from the fraud.
In an answer to EMI’s complaint, Comerica denied that the bogus Web sites that lured the EMI employee would appear to be Comerica’s real Web site “to any reasonably alert person who was responsible for safeguarding EMI’s financial records and digital credentials.” The bank also argued that its banking security technologies were commercially reasonable “because they were in general use by other similarly situated customers of other banks.”
As I noted in a first-of-its-kind story back in 2006 about a phishing scam that attacked Citibank business customers, the use of security tokens adds very little — if any — additional protection. For one thing, as in the Citi example and now this case, we can see that tokens work great provided the phishers don’t also ask for the token code as well as the visitor’s banking credentials.
Also, thieves are routinely defeating security tokens through the use of malicious software like the ZeuS Trojan, which can re-write the bank’s actual Web site as displayed in the victim’s browser, so as to inject code asking the victim’s user name, password and security token number. The victim is usually then redirected to a fake maintenance page telling them to try again in a few minutes, while the thieves are submitting that intercepted information on behalf of the victim, and then initiating unauthorized money transfers.