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.
Experi-Metal sells metal stampings, trim moldings and specialty items.
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.
An RSA token used for multi-factor authentication
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.
EMI’s complaint is here (.pdf). Comerica’s line-by-line response is available here (.pdf).
Why, after say a minute or so, would the old token still be of use? How could they continue to do transfers hours after the token would have expired?
Once they have used the token and are logged into the bank’s website – as long as they are active and don’t let it time out it will remain in session.
So they were logged in to the account for about 6 hours? Would it make sense to track the average hold time for a customer (how long on average they stay logged in) and to track the normal connect frequency and transfer location and size? If you are, say, 2 standard deviations away or transferring money to a new part of the world for you or an area with a reputation for fraud, would it make sense to verify the transaction or situation with a phone call? Does that scale?
My bank (SEB in Sweden) use a token with a keypad and requires that I use it to log on and to sign every transaction, including the sum to be transfered/payed.
To only have an initial log on and then be free to do any transactions, including external transfers, is stupid.
Clarification: In case I do multiple transfers/payments I sign off the complete batch and the total sum to be transfered. Pretty simple and secure solution.
SEB are using a Sun server but an IIS document system. SEB are otherwise the smartest of the Swedish banks.
My big question with all of this is, if EMI alerted Comerica on the MORNING of the transfers to stop them and not allow any further transfers, where did the 560k go? Don’t these things take days?
Not with Wires. Wires are immediate and there is no way to guarantee a retrieval of the Wire. Once it leaves the sending bank it is basically gone…a reason why Wires are such high risk enterprises for banks. They can request the return of the funds, but the recieving bank is under no requirement to do so.
Wow. Just…wow. I think, in this case, the two-factor authentication simply provided a sense of false security, since it appears (from the complaint) that the system was ignored after the first transfer. Please correct me if my assumption is incorrect.
What is absolutely impossible to believe is that Comerica continued to wire money all over the world for hours AFTER they were told that there was suspected fraud and AFTER the account was drained. There’s gonna be some ‘splainin’ to do.
I agree. Once notified by EMI that the wires where fraud – all activity should have been frozen – even the “in process” wires. Although I find it hard to believe a bank would make a mistep like that. Once fraud is identified, a bank usually takes immediate steps to eliminate any further loss. If this didn’t happen and Comerica truly did drop the ball – they will be liable for all losses after notified I would think.
Brian-
One alternative control that I have seen discussed and pushed by a particular vendor has to do with out-of-band (phone call) notifications and verifications of transaction details. For example, the user logs in with username/password, initiates a wire, and immediately receives a phone call at a number pre-specified asking them “type your 4-digit PIN if you authorized a $20,000 transfer to Nigeria”. Could you comment on whether you see any obvious flaws to this control? This out-of-band verification process seems to be much harder to bypass than anything having to do with pre-shared keys or one-time passwords/tokens.
This works as long as the thieves don’t have control over the out-of-band process. One thing that most people do not grasp at the moment is that at least in the US, almost all mobile providers allow people to check their SMS text messages online. If a user had signed up to manage their account online, and perhaps saved the password to that site (Sprint.com, Verizon.com, etc), thieves who already control the browser could simply rip out that stored password, and check the user’s SMS messages online.
No measure of protection will function in an ecosystem in which malicious intent has control over so many variables. If smart criminals login to your account it would be trivial to update the contact info and then lock the company accountants out entirely – which has probably already happened and is nasty as it puts the responsibility on the consumer to prove identity in a time critical situation..
When the criminals have control over primary authentication (account data), of secondary authentication (fobs/certificates), and of out of band processes (impersonation/SMS/telephone routing) what is left to halt the con?
Banks in the US are really methodical at holding funds transfers into any account for verification of funds. Say for example when buying a house transferring large sums to a common account electronically can be painful as the bank will hold those funds until all the sources are verified; typically 24+ business hours. Of course the con is to send what whatever was gained over the planet to many separate shell accounts.
Why isn’t this same same protocol reciprocated in the foreign countries?
Graft and corruption within the external banking system.
It would be a simple checkbox when managing the account at the domestic bank: [Corp X] automatically refuses all outbound international money transfers on account X(s). And/or unless specified protocol is done [ie during banking business hours, in person, requiring 2 person, notarized signatures authorizing said xfer. A physical white list could be provided for common business partners and suppliers.
Still again cons will get around all these but it makes it difficult and moves the crime to meatspace which pushes it into conspiracy and higher order crimes with tougher penalties than elaborate electronic fraud that a jury must chew on.
Why aren’t accountants who read your column not at the bank in the morning meeting with their bankers arranging for refusal of foreign wire transfers and/or transfers over X values without a protocol? If the bank managers can’t do it for business, those businesses MUST find a sound banker that does provide and guarantee that service.
The out of band challenge doesn’t have to use an SMS message. The transaction can be completed on the voice call and no additional information is sent via the compromised browser.
I think this will be preferable to larger corporations as they become more security savvy and require any out of band authentication to happen via an “office” phone.
Out of Band can be spoofed and a patient con will wait for the right moment.
When the accountant’s computer has been compromised not only can the cons monitor for bank account information but also listen for personal / business traffic signaling an opportune time to strike – such as out of office messages.
At that point it would be easy to wait, then login, change the contact info and re-route to a shell account or shill / mule to impersonate the out of bound authentication then reverse the changes. By the time the accountant returns the account has been cleaned out. Deep log and transaction tracing has to be used to find out what happened. This give even more time to the con to escape.
What is being identified here as a technology problem is actually a fraud problem conducted at the speed of technology. Only good sound business practices can provide the diligence and vigilance against this type of fraud.
Slowing down the process by re-introducing the human presence at a bank counter for authorization is one means at this point to halt such a remote transfer. The better means is to hold to task the Banking Industry for it’s providing poor services.
US business has to also look at the staffing model as well as a vector of attack. Most small businesses are lucky for having as an in house employee, the accountant/CPA. Many businesses contract/outsource to a professional who is juggling multiple accounts – especially at tax time.
Most likely it is an independent consultant or small accounting shop who’s IT is beyond the reach of any one client company to protect – unless the company previously provided a turnkey laptop to them.
In all the scenarios to date, not one mention of a real penetration of a fully managed corporate environment. This leads one to believe its an accountant/CPA working out of small office/home office via DSL or Cablemodem thinking they are “safe.” The worker is likely getting company mail from webapp or remote Exchange and then doing the financial work via webapp.
When they are not actively working the user likely has rights in the OS/Apps to have “liberty” to browse the anywhere on the web, install applications & plugins at will relying on UAC, etc. It could be possible that the co-workers/husband/wife/kids even use the same laptop/pc used for the business on the off hours. Its possible that computer is never shutdown on holidays, weekends, overnight.
If it exists, do you think the local “office” firewall/router has been configured to lock out traffic at such “uncommon” hours? Do you think it is a 2nd internal firewall/router in the facility compartmentalizing the small/home office from the wife/husbands/kid/coworkers’s trojaned PC? Businesses will lock the doors after hours. Businesses should not like to store sensitive files near areas beyond their control.
Again sound business protocols exist already to prevent such fraud. The IT industry has to make it possible for non PhD C.S. candidates to expect them enabled by default, monitor them, and audit them over the lifespan of a product, and trust that when they fail, they fail into a secured mode. If the product doesn’t have such protocols, the business needs to drop it and find a vendor that provides them. This sounds painful, (oh woe is us for Microsoft or App X is everything to us) but this is the business of business.
since i seen your name more and need someone to respond so i know i got out, it would be awesome. i been the target since aug 2008 and havnt got any help yet. i got a hold of someone who claims to be microsoft’s chief engineer, and i showed him and his group the proof and evidence of just some of what i know, and was told to get a hold of ed gibson. i wrote some comments asking for help, andi got a response from him with his hotmail email address. i responded but 5 or 6 days i think, and no response. i was intercepted many ways. my phone affect everyone. i see these hackers through my machines hacking everyone. i still have no control over my machines to this day and know what im doing. right now, i get the impression of the worm rebuilding itself and at the same time, someone yesterday and today removed part of the worm that that was in place to hide anything from reaching your terminal that could help you fight the worm.
whats really going on is sorta scary. all the community sites along others were being hacked years without notice. even microsoft and msft and verison.
the hacker is using a smartphone and a tower to insert radio packets into a chip in the motherboard of every system. he then inserts the well dug in backdoor part of the bot and programmed it to have highest priority.
that backdoor and hacker use both sides of the connetion to go down a list of exploits form any open port(mostly 80). first is adobe popup from hell. no matter what setup you have, he gets in. one system he uses is creating any certificate of choice of any site that would be used to create a cookie. the cookie has an option of blocik/allow/view info. no matter what you choose, the backdoor intercepts all packets and can be ginven commands of any choice.
the backdoor/bot in return uses smft to send email back to thew hacke and using a code in the subject for direction of which computer its form. the code has a dollar sign before and after every word. mine was $chicago$ and $danielle$ one for computer and the other for phone. this is how i got their number which is now disconnected.
another thing a bout the worm that was never mentioned yet is string insertions to any text i type. it starts eating letters and twisting them. since yesterday, that speeded up due to someone removing the layer that hid parts of the worm in kernel.
the lag noticed is linked to a 2nd machine infected being turned on in a local area and is somehow using signals that is used to monitor the hardrives…
im sure there is more to it now, but that was the pattern i seen
anyways, how can i get a return so i know that i successfully sent a message unintercepted
Brian,
Great article; thanks for posting the source materials. I was a little confused by the wording about the certs until I read the documents. I might change “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” to something like “many banks issue digital certificates to their customers. The bank servers are then configured to require customers prove their identity by presenting these certificates (This technique is known as SSL client-authentication)”.
That aside, this is another case of a bank (which is supposed to be in many ways a security company) conflating identity and authorization. And as noted in other comments, some other breaker should have tripped before the problem got this big.
In this part of the security landscape, if you select one-time password tokens, you may avoid some attacks but be vulnerable to MITM attacks. Or you might use software-based X509 certs, and be vulnerable to Trojan attacks or viruses that target your desktop. (Or you might use smartcards and get the best of both worlds, but that’s another story.) Neither identity solution is going to be perfect, and selecting one over the other is a security *and* a business decision. I find it interesting that the bank decided to move away from personal certs, where the burden of security is on the customer’s IT department, to one-time password tokens, where they take on more of the risk.
Given how often banks act like phishers (search that phrase to find some of my old writings) I might tend to side with the customer in this case. The comment that the attack would be visible to “any reasonably alert person who was responsible for safeguarding EMI’s financial records and digital credentials” is almost certainly not defensible if Comerica’s web site, emails, and past practices were like other banks.
Would it be possible for a customer who does not do wire transfers to have their account setup so that wire transfers are no longer available on-line? Or maybe for accounts that have never done them, have some type of opt in process to enable wire transfers. They could send the information on enabling it through snail mail. It sounds to me like something has to change.
My bank does occasionally send me mail, but I never click on any of the links in those e-mails.
A lot of the succes of this particular attack has to do with the implementation of the 2 factor authentication by the bank.
Nothing is fail-safe of course, but in this case had two factor authentication been used more extensively and not just for logging into the account, this type of attack could have been avoided.
An additional layer of authentication might have helped here. The first authentication is needed for logging in to the account (this is the one the thieves took) then another for approving the transactions (or even several when the sum of the transactions is over a certain amount or include international transfers). This one the thieves did not have in this case…. Of course this does not help against a very elaborate MITM attack but it would have at least avoided this one.
So, like Bob Lord, I tend to side with EMI here.
I have written some banking software. For wire transfers an RSA SecurID token was required for every transfer as I recall. If that had been implemented here, the MITM would not have been able to perform even one transfer without continued contact with the “mark.”
Behavioral checks or policy should have alerted the bank to the fact that the wire transfer rate on that day was perhaps 20,000 times higher than the rate established over the previous two years.
Comerica also established a bad pattern by using emails to update the certs for 8 years.
SSL client-auth also only validates sessions, not transactions.
Shame on the client for not catching the phishing attack but the bank is guilty guilty guilty IMO.
Just a note about the ‘random’ token. It’s not random. If it was random, how would the bank know that it was the ‘correct’ token?
It’s really a one-time password (http://en.wikipedia.org/wiki/One-time_password)
Essentially, they work like this (note: This is not how the RSA one works – In fact, none of them should work like this, but this is just for explanation):
At the beginning, a seed and a function are chosen. Your function could be f(x) = x^3 % 23; your seed could be 50.
For f(50) = 50^3 % 23 = 18. Your next calculation would use 51. f(51) = 51^3 % 23 = 10. Your next calculation would use 52. f(52) = 52^3 % 23 = 9.
The server also has the same information as the keypad, and the two devices are time synchronized so that they are always generating the same number at the same time. Then, to log in via two factor authentication, you would use your username and password (factor 1) and you would use the one-time password (factor 2).
At the time of creation, the one-time password generator and a login server are given the same information at the same time. This way the server knows what the device will have generated at all times, and you can log in with it.
There is still this general sense (among business and too many information security professionals) that two-factor authentication will protect against phishing attacks. This is obviously a false assumption, and your post does a good job of driving this fact home. If a user is going to give away their credentials, there are few (if any) technological solutions to prevent unauthorized access to sensitive information.
The question of Comerica’s liability will be left to the courts, but it seems as though EMI has a point (case).
I have received the same types of emails from other banks (not to be named because some of them are now our customers) and have in turn alerted them to the risks. I have never received a response to my warnings.
Quote: “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. ”
This is not a failure of the security token; rather, the employee gave away his security credentials.
Some banks require clients to use their token twice: once to logon to the website, and again to perform the transaction. This helps to less the possibility of the false maintenance screen that pops up.
Banks are easy to blame for a lot of reasons, and certainly are not without fault in this case, but this actual breach was not a failure of security tokens. Sorry, Brian.
No technology is going to prevent someone being scammed out of his/her credentials, and that’s what happened here.
This doesn’t help against zeus or the other rewrite attackers.
My Nordic bank uses a one time password for the initial login plus a password for the login and to confirm transactions. It also sometimes does and sometimes does not require Java, while claiming that it uses Java for security.
If I am foolish enough to use a computer which is compromised, then my bank’s uses of a one time password doesn’t help me, because I’ll log in with the one time password, enter my password, and review stuff, at which point the trojan can do work in a browser frame creature to submit other transactions using the password it got from me in the session I initiated.
Now, you might say “it’s your fault for being foolish (or trusting)”. but perhaps I’m trusting my desktop computer not to be attacked by viruses (including using antivirus and antimalware). It doesn’t have to be an evil computer in an Internet cafe.
Brian’s articles generally show customers using their personal computer (at work), an environment they believe is safe and secure.
I have worked with most of the online treasury management systems (the top 5 vendors have most of the business) and with the bank teams that have to implement them. I don’t know which options Comerica chose to offer but customers are the ones that choose how they will use the system.
Customers can choose to have alerts sent to them for specified transactions like wires. Customers can choose to have limits set for the dollar amount of individual transactions, for the daily amount of transactions, or the number of daily transactions. Customers, with enough users, can also choose to have more than one person involved to finalize high value transactions. In this case the customer could have easily chosen to not accept wire transfer capability. The risk vs. convenience trade off isn’t compelling enough in this case.
So, while banks must continue to add layers of security it still requires customer action to take advantage of what’s on offer. I still see large corporate customers choosing not to take advantage of simple tools available to them. Adding a few minutes to a companies collective day can make it much harder for criminals.
Continuing these stories is one of the best ways to make more people aware of the issue and that will help.
It would be valuable to know the brand of security token used by the victim. Brian puts a pic of the RSA token, but was it really the brand used?
Lots of one time passwords can be used past one minute. If the token was indeed the RSA token, then that means the criminal was able to receive that pin and use it within that minute; statistically 30 seconds depending if the user pays attention to when the code renews. You could wait until the last few seconds of the tokens timer and then login. This could make it very difficult for the criminal to use that RSA pin.
Hendo – the security tokens I have seen give a passcode that can only be used once. So, if the user inputs the passcode, and gets on the bank’s true website — which they can authenticate with a second code from the token that is shown on the actual bank site — the fraudulent man-in-the middle cannot use the passcode.
But if the man-in-the-middle steals the passcode w/keylogging, they immediately put up a maintenance screen (“sorry, online banking is temporarily unavailable, please try again in 15 minutes). Then the M-I-T-M goes to work.
This is where the user needs to contact the bank’s security department, pronto, because they have given someone else their token’s passcode (and their user name, probably due to keylogging software that they allowed on their computer
).
Right, most if not all tokens are one time use. But not all tokens are time sensitive to 30 or 60 seconds. So even if you are keylogging in real time, the criminal is now on a footrace to get that token in place in a very short time.
It truly is time to start authenticating the transaction, something some of us have been asking for for a long time. Only now, in the face of massive fraud, does the idea of bothering the customer again and again for a one time password when they are getting ready to commit their company’s money, make sense.
Sadly, there is no footrace. These attacks are automated with no humans in the loop. When you submit your name/one-time password to the man-in-the-middle (MITM), it can relay that to the bank server in real time. Behind the scenes, there is often a web server on a hijacked machine that sends your login information to a hidden IRC channel that rotates with time. Another bot picks up your credentials on that channel and uses them to login to your bank. If you think you and your bank are sophisticated enough to catch these guys, think again. 🙂
Even worse, asking for credentials with each transaction may not solve the problem. The attacker can ask for your credentials a first time to get logged into the server, and pass back whatever screens he gets that would normally appear to you. It looks like your bank’s web site because it really is (though routed through the MITM)! When you ask to make some minor payment to company X, he does not send your request and credentials to perform that function, but instead asks to wire a large amount of money to an off shore account. There’s nothing to bind the credentials to your transaction request. So the MITM wins again.
There are things to help reduce the risks, like having the bank lock down logins to specific IP addresses. But it’s hard to beat the security you get with client-based certificates, the system they gave up. 🙂
Note that ip address binding doesn’t help much. If your computer is compromised, the attack can take place locally, as Brian has mentioned before the web site content can be rewritten to hide the real transaction that the attacker has decided to use, and those general instructions can merely be downloaded to your computer by that malware.
There are too many ways to lose here. If you’re only concerned about the case where the bank needs to recognize valid origin points for users, then sure, ip address binding is helpful. but if the user suffers from malware then ip address binding is useless.
It’s much more useful to do user behavior binding. If the user doesn’t make wire transfers regularly, then they should be flagged and stopped once they exceed their average usage pattern.
Credit card companies historically afaik did a good job here. Certainly when I would travel, I’d get calls from my credit card company to my phone of record (either with me, or often with my parents, before cell phones), and they would confirm the transaction and location. For multiple transactions outside my usage pattern, I’d inform my credit card company in advance. By phone, using a number on the back of my credit card.
(I also trust my credit card company to log all calls and would expect them to not make it too easy for my phone number to be changed.)
For some reason, I trusted my American credit card vendors to have valid and useful phone numbers on the back of their cards (I also trusted them to provide 24 hour service). It turns out that this trust should not be extended to certain Nordic banking providers.
In theory, DNSSEC will enable people to trust that a given dns entry is really issued by a certain issuer, but what I really want is a way to safely get a phone number for my bank. Using the web to get those numbers is fairly dangerous. I did a survey of banks a while ago and found large portions of them didn’t think it was important to use SSL to serve bank information such as phone numbers and addresses. If a user goes to a fake bank site, they could be given a fake phone number or the address of a fake atm or a fake branch. Now you might claim that a user would never do this. But oddly enough, some people travel (I do it often enough, and certainly visit foreign countries).
I was recently in London and there were banks which had signs indicating that some of the ATMs in the area had been targeted for some sort of attack (I guess skimming/pin stealing). The notice was “interesting” but hardly helpful. Helpful is genuine police officers (how could a foreigner be expected to recognize and establish trustworthiness of a “private security guard”? or see Neil Gaiman’s American Gods for an example of that attack) ensuring that the machines don’t have these things. Telling me “some of these might be dangerous” doesn’t help me at all as a foreigner. It mostly means “oh, you should probably monitor your account for the next 6-12 months”, what can I do with this information? In the US, banks often rely on a system where you use your credit card to enter partway into the bank, a lit area where you can perform your transaction, aware that there should be cameras ensuring that the machines are not tampered. I didn’t see those in London (perhaps space is too much of a premium to justify offering protection to their customers?).
Bob,
I understand the mechanics of the attack. Your description of how the MITM attack is pulled off only accounts for certain website use cases. There are also other controls which probably should be kept private that will thwart the fraud.
One policy banks should require is dual control of commercial transactions. One person can create and stage payments. The second is required to release the money. This would require a more targeted attack by the criminals.
I don’t believe the fraud activities are quite as automated as you state. The initial keylogging is likely quite automated, but the actual fraud appears to be quite human driven, from my observations.
There are many different commercial banking platforms. Some companies outsource, some roll their own. Some have ACH and wire payment white-lists that are not changeable by the user during their login session.
The bottom line is that every control that is reasonable to implement should be considered.
Asking for another token authentication is another layer of security, and a good one. I can say with certainty that some banks have this available to them but will not take this step because of customer complaints.
It’s very easy for us to say that banks need to educate and require their clients to jump through multiple hoops to perform transactions, but the reality is that many of these clients will move their banking relationships if they find the bank’s online banking system to be inconvenient and time-consuming.
Sadly, no one seemed to mention that the phishing attack itself could have been better prevented. It appears that niether comerica.com nor experi-metal.com implement secure email authentication such DKIM or SPF, which might have prevented the spear phishing email from arriving in the experi-Metal controller’s inbox in the first place. Amazingly, the experi-Metal controller Keith Maslowski’s contact info including email address is still proudly displayed on the experi-Metal contact page at http://www.experi-metal.com/contact.html. Does experi-Metal management think that the function of the corporate controller is some mystery to cyber criminals? That contact page says *I MANAGE LOTS OF MONEY AND I AM VERY IMPORTANT SO PLEASE SEND ME A MALICIOUS EMAIL SO THAT YOU CAN TAKE ALL OF THE COMPANY MONEY*
N3kt0n your comment is spot on. Particularly the part about these victim corporations having their CFOs and controllers’ contact info on their sites. In fact, I’ve noticed a pretty consistent pattern amongst almost all of the victim corporations I’ve interviewed: Nearly all had the contact info — including sometimes a picture and personal details — for the person in charge of their finances prominently displayed on their Web site.
Then maybe this article should be titled “Comerica Phish Tricked Corporate Employee” because that’s the real story.
If you think that a bank’s authentication system is designed to ensure that only the employee can use it, I think you are mistaken. The authentication system only ensures that the user is receiving the passcode from a token. The bank can’t control what the employee does with the token or who the employee gives the code to.
An argument could be made (and is, obviously) that the bank had contributory negligence, but the bottom line is the authorized user gave their passcode to someone else, and that’s not a failure of the passcode device.
The bank is clearly at fault here, since this is completely within the bank’s control. The bank has chosen to take custody of their customer’s money, so they alone are responsible for ensuring it is properly protected against any/all threats. If the bank is going to provide computer-based access to the money they are protecting, then the bank must have enough layers of security in place (at least equivalent to their physical environment) to protect that money.
From the information provided, the bank “dropped the ball” on several levels, by not providing proper authentication, not limiting/delaying fund transfers, not detecting the obvious volume/velocity changes, etc.
Quote: “The bank has chosen to take custody of their customer’s money, so they alone are responsible for ensuring it is properly protected against any/all threats.”
This is your opinion, but not a standard that a court or regulatory authority has ever set.
Rather, the regs require a “commercially reasonable method,” which while open to interpretation, is nowhere near as absolute as you suggest.
What about having the user enter a one-time passcode instead of clicking “save” for each transaction. Then if the user is only posting one transaction, the MITM can only do one transaction. If the MITM displays a site-under-maintenance page, it then can’t intercept a second passcode to save its own entry.
i dont blame the guy for falling for the trick. i been fighting the botnet since its creation in aug 2008. to this day i have no control over my systems. if he was to lose the lawsuit, i would then sue microsoft and verison for giving everyone false sense of security. their certs were the mostly used ones. the hacker also used support.microsoft.com to email whomever he wanted for whatever hacks.
the main worm still isnt being addressed. it uses injected radio packets into the hardware. if i was to suggest anything, i would have the server used to starte the trick, and look at their graphics/audio/lan drivers. this is 1 of 2 ways that i know that successfully detects the worm. if you cant update those drivers, then your infected. also logonsessions.exe f rom sysinternals.net aka anonyous logon aka from worm aka backdoor.
The best out-of-band activity I have seen for wire transfers exists where the requester on the sending end must be physically present at the bank with a valid government issued ID card. Although this doesn’t make it a simple process for the account owner, it does provide a great detail of security, especially if you have a good working relationship with the bank and they know who you are.
The biggest problem I see is a social culture shift where convenience has become such a misunderstood necessity that security goes by the wayside.
No doubt there are still banks that require the sender of a wire to authorize it in person.
But if you are a corporate controller, is this the bank you would choose to do business with?
Right or wrong, people choose/change their banks for a variety of reasons, and security is not even on the radar for most people.
(Note: unfortunately, the readers of this blog are not representative of typical bank depositors…)
Brian
You have been highlighting these cases quite frequently over the last few months…but we don’t get any follow-up as to how they conclude.
Are you aware of how these lawsuits are resolved? I suspect that most, if not all, are quietly settled out of court..but it would be interesting to know if any have proceeded all the way to trial and a verdict.
For example, you featured the lawsuit launched by Patco Construction launched against Ocean Bank back in Sept last year. Is this still ongoing as far as you know?
With online banking fraud being a booming business right now, I suspect there are a large number of parties anxious to have some case law established to see where the fault lies. Clearly each case will be unique…but if banks start losing these cases on a regular basis, they (perhaps prompted by their nervous shareholders) will start to make radical improvements to the security of their online banking services.
cheers
Nick
Incredible that a bank would, as noted in the suit, train customers to update (in)security technology on-line ; a more obvious opportunity for spoofers is hard to imagine ! My Swedish bank, Nordea, after earlier encountering problems with an insecure system, adopted its current one some years ago and it seems to be rather secure. I am provided with a tocken and a credit/ATM card. To use the token the credit card must be inserted ; this allows me to click the «log-in» button, after which I can visit the bank’s site on line, click to log in, where I am required to identify myself with my personal number (which is public information). I am provided with a six-digit control code, which I enter into my token ; if this code is correct I am then requested to enter my credit card’s PIN, after which I receive a second nine-digit code which, when entered into the on-line log-in form gives me access to my account. Admittedly a somewhat cumbersome process, but reasonably secure in the event the black hats don’t have access to a token (easily done, of course, as these are not individualised), my credit card (which carries a unique chip), and my PIN. A keylogger wouldn’t be of much help, as my PIN is only entered into my token, rather than on the bank’s web site. Moreover, after ordering a transaction to take place, I have to go through a «sign-in» process similar to the above but now using the token’s «sign-in button» rather than the «log-in» button, in order to confirm the transaction. I’d be interested in hearing any comments from professional banking security people regarding the above system ; the only weak point I can see is the possibility for someone other than myself to come into physical possession of my credit card and gain knowledge of my PIN, but it’s hard to see that this could be done on-line….
Henri
I’m not sure I’m clear on the steps you’re describing, but the question is whether any authentication must be entered after the initial log in? A man-in-the-middle attack simply waits for you to do all the logging in, then once you have done it shows you a screen that says the site is temporarily unavailable while it accesses your account.
i seen signs now for the first time that the main part of the botbnet worm is being addressed. this global hijack allows the hacker to gain access to any server with highest authority and probably dont really need a connection from what i experienced. in my situation, they first get in the board of devices such as computers using radio packet injections. all security i attacked it with failed. i thank a lot of the security teams for listening to me and be aware of whats going on. there is still a lot of work to be done, but i seen yesterday for the first time parts of the main worm being stripped allowing me to see what he had hidden. a lot of hardware was seen that i couldnt see before allowing me to gain for info on the technical info.
Thanks for replying, AlphaCentauri ! After first logging in, I can order a transaction without any further authentication, but in order to carry it out, I have to sign in – a process similar to but distinct from – the initial authentication. I’m not certain whether a man-in-the-middle attack would be able to intercept and modify both the initial order and the confirmation necessary to complete it….
Henri
If I read the complaint right Comerica sent almost 2 million in wires – EMI is claiming a loss of about 560k.
My best guess is Comerica contacted EMI when their account balance hit zero – someone dropped the ball at Comerica and didn’t halt the additional wires. Those wires fall on Comerica; after being able to recall a few of them I bet Comerica took about a million dollar loss.
Shame on the bank for not recognizing the highly unusual transactions earlier, shame on the EMI employee for being so trusting and shame on the EMI Controller/CFO for accepting the risk on on-line wires when the apparently had no need for them.
there is no excuse for falling for a phishing scam, or getting infected with malware. i am 25, work in infosec field, do programming, have never once been infected (or godforbid fall for phishing).
i think people should be fined for falling for phishing– a “phishing phee”.
i think people should be fined for being infected with malware
use a secure OS, use common sense, dont be an idiot. idiots should be forced to pay
don’t use insecure software like adobe
patch stuff if needed
conclusion:
pay a phee for phalling for phishing
don’t be an idiot
i’ve never had a problem, no one else should either
kthx
We’ll check back with you in about 10 years, and then see how smart you feel then 😉
I have to concur with the last comment. Suppose banks issued a fairly user friendly, bootable , password protected, Open BSD keychain stick to their assigned customer’s representative that was unwrite-able, and linked to a static secure sockets IP? AKA a hardware key for the money, in addition passphrase and whatever human based verification routines they might care to invoke? Couldn’t spoof the website that way, and might autoverify all the connections. Only question is, would people use it?
Oughtta have the same thing for votin’ , durn gummuh and big bidner anyway.