A lawsuit headed to court this week over the 2009 cyber theft of more than a half-million dollars from a small metals shop in Michigan could help draw brighter lines on how far banks need to go to protect their business customers from account takeovers and fraud.
The case is being closely watched by a number of small to mid-sized organizations that have lost millions to cyber thieves and have been waiting for some sign that courts might be willing to force banks to assume at least some of those losses.
Nearly two years ago, cyber crooks stole more than $560,000 from Sterling Heights, Mich. based Experi-Metal Inc. (EMI), sending the money to co-conspirators in a half-dozen countries.
On Jan. 22, 2009, EMI controller Keith Maslowski responded to an e-mail that appeared to be from its bank, Comerica. The message claimed the bank needed to carry out scheduled maintenance on its banking software, and instructed the EMI employee to log in at a Web site that looked like Comerica’s online banking site. Maslowski says the email resembled the annual e-mails Comerica used to send, prompting customers to renew EMI’s digital certificates. Trouble was, the year before, Comerica had switched from using digital certificates to requiring commercial customers to enter the one-time passcode from a security token. The site linked to in the e-mail asked for that code, and Maslowski complied.
Almost immediately, the crooks who stole those credentials began wiring money out of EMI’s account. Between 7:30 a.m. and 10:50 a.m. that day, the attackers initiated 47 wire transfers — to China, Estonia, Finland, Russia and Scotland.
Both EMI and Comerica agree on the above version of events, but have very different versions of what happened before and directly after the theft. The two parties met on Tuesday for a pretrial conference, and presented their respective briefs to the court. Comerica’s is here (PDF), and Experi-Metal’s is available at this link (PDF).
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.
For its part, Comerica said Experi-Metal is not entitled to relief because it cannot prove that Comerica’s actions caused its claimed damages. “The unfortunate events of January 22, 2009 happened because Mr. Maslowski failed to safeguard Experi-Metal’s security information, in breach of Experi-Metal’s contract with Comerica,” Comerica said in its pre-trial brief. “And those losses would not have occurred had Experi-Metal accepted Comerica’s recommendation that Experi-Metal require a different user to approve all wires after one user initiated them.”
Many of the facts to be litigated center around whether Maslowski was authorized to initiate electronic transfers, and did Comerica employees fail to take action with respect to the suspected fraud on a timely basis under industry and commercial standards? Also in question is what portion of Experi-Metal’s claimed losses occurred before Comerica knew of and had a reasonable amount of time to react to the fraudulent wires?
Businesses do not enjoy the same legal protections afforded to consumer banking customers hit by cyber thieves, and most organizations will be held responsible for any losses due to phishing or account takeovers. But a rash of these attacks that has netted thieves more than $70 million over the last few years has caused some victim businesses and their lawyers to look for ways to hold banks more accountable, by pointing out ways in which the banks may not be living up to the somewhat nebulous state legal standards that govern commercial banking activities.
The few cases brought so far challenge whether banks are meeting their obligations under the Uniform Commercial Code. Michigan’s adoption of the UCC holds that a payment order received by the [bank] is “effective as the order of the customer, whether or not authorized, if the security procedure is a commercially reasonable method [emphasis mine] of providing security against unauthorized payment orders, and the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer.”
David Navetta, founding partner of the Information Law Group and co-chair of the American Bar Association’s Information Security Committee, said the court in this case punted on any discussion of whether Comerica’s security procedures were commercially reasonable. Instead, Navetta said, the court focused on the contracting process between the parties. It declared as a matter of law that Comerica’s security was reasonable because EMI had agreed that it was reasonable in a contract.
“The EMI Court also focused on process in another way that ultimately hurt the bank, and provide the main basis of the dispute for this trial,” Navetta wrote in an e-mail to KrebsOnSecurity. “The court focused on the question of whether Comerica acted in ‘good faith’ in accepting the payment orders from the phishers. This essentially shifts the analysis to the activities of Comerica in reacting to the security breach and refraining from processing the fraudulent wire transfers and sending money out. The question becomes where do the bank’s responsibilities end and the customer’s begin, and to what degree must banks anticipate their customer’s mistakes and develop security to mitigate the risk of a security breach. Reading the trial papers it is obvious that the big fight in front of the jury is whether and to what degree EMI brought this upon itself.”
Navetta believes this case is likely to make banks look very carefully at their security policies and make sure they are in line with federal guidance from federal regulators. “They also may beef up their educational processes around phishing attacks,” Navetta said. “They will also likely offer very robust security in some cases that their clients may ultimately turn down.”
For the moment, though, relatively few banks — particularly smaller to mid-sized institutions — are offering commercial customers that robust security that goes beyond mere customer authentication, said Charisse Castagnoli, an independent security consultant and adjunct professor at the John Marshall Law School.
Castagnoli said more banks could and should offer the kind of technology employed by the major credit card networks, which try to build profiles of customer activity and then alert the customer or the issuing bank of any suspicious or unusual activity. But she said a large percentage of banks outsource the day-to-day customer transactions to third-party service providers, most of whom do not currently offer services that would conduct that transaction analysis.
“If you look at economic theory, the organization that is best positioned to mitigate the risk is really the bank, because with extremely simple technologies deployed they could reduce risk of current threat or losses from 90 to 95 percent of the time,” Castagnoli said.
“This is a classic case where anomaly detection is ideally suited, because if you look at the circumstances in these thefts and how the transfers occurred, it slaps you in the face because most of this activity looks so odd and would stand out to anyone who took a moment to look,” she said. “But the service providers don’t offer this detection, because of the cost to implement and deploy it, and the question of whether they can push those costs onto their customers. On top of that, there is no incentive or disincentive for that provider to make these investments, because it increases complexity and cost, and nobody is mandating that they do it.”
That may change soon. Garnter fraud analyst Avivah Litan wrote last week that businesses can soon expect new IT security guidance from the the Federal Financial Institutions Examination Council (FFIEC), the regulatory body that issued the last round of guidance on secure electronic banking Authentication in an Internet Banking Environment (PDF) in 2005. From Litan’s blog:
“Nonetheless, not all financial institutions have kept up with the spirit of the 2005 guidance. The threats and associated risk levels have clearly moved ahead of the safeguards many banks and credit unions, and their service providers have in place today.
“Typically, the larger banks and credit unions have remained proactive, for reasons ranging from reducing fraud costs, maintaining reputations, and improving organizational efficiency.
“But most of the smaller financial institutions have relied on their online banking service providers to mitigate fraud risk with appropriate services, but the service providers have not introduced risk appropriate fraud mitigation services across their various platform versions and implementations, leaving thousands of U.S. financial institutions — and their customers — unnecessarily exposed.
“I don’t envy the regulators’ job of striking the right balance between too much and too little prescriptive guidance. But based on what happened with the last round, it appears that many executives at financial institutions need more regulatory prodding and detailed guidance in order to allocate budgetary resources to their online and mobile (and other channels’) banking security programs.
“The fate of a customer’s bank account safety should not be determined by the U.S. courts. It should be proactively guided by well-informed and balanced regulators, and conscientious security staff at our nation’s banks.”
I will continue to closely follow this case and others like it. Stay tuned for more updates, including news of additional lawsuits from commercial banking customers seeking to recover six-figure losses from cyber fraud.”
“The question becomes where do the bank’s responsibilities end and the customer’s begin, and to what degree must banks anticipate their customer’s mistakes and develop security to mitigate the risk of a security breach.”
That statement sums it up quite succinctly. In reality though, I just don’t know how you can ever anticipate and fully mitigate such extremely poor judgment as displayed by Mr. Maslowski in this case. The easiest solution is prevention, which in my mind rests with the weakest link, the end point.
I’ve never understood the extreme risks many of these businesses seem to take with their financial assets. You’d think they would take better precautions to protect themselves considering what is at stake.
Regardless, I really hope a balance is struck here. The last thing we need is heavy handed legislation shifting most of the responsibility onto the banks, because they’ll just defer the additional costs to the customer anyway.
I fail to see why you were modded into oblivion when your points make sense. While the banks do have a responsibility to create reasonable security mechanisms the end user has one too.
In the story detailed, both parties failed to take reasonable precautions to prevent further fraud from occurring. Small businesses absolutely need to be held to a common level of computer competency, or they shouldn’t be banking online. It is extremely well known by now that the internet can be a dangerous place… A business doesn’t try and go after an automobile manufacturer when they leave their car unlocked and they keys in the ignition. It would be absurd to say that the manufacturer was responsible for the theft because it didn’t catch the unusual 3:00 AM entry, start, theft…. (Enough bad analogy)
I’m not saying the banks aren’t responsible as well, but the banks are not the sole party with blame here. Both acted foolishly and both need to adjust accordingly.
So, a customer walked into a bank and demanded that the bank offer online banking. That’s how online banking happened? Right? The design, sales pressure, and assurances that moved businesses into online banking all came from the demand side, as it always does–right?
So because the bank provides online banking, they are 100% responsible for every interaction that occurs on it?
I continue to not understand why when these stories come up, everyone focuses on the failure of the financial institution. There is a substantial failure of the end user to take any reasonable precautions. I’ve spoken with a lot of small business owners who even refuse to secure an unsecured wireless network connection, because they don’t think security is an issue.
You can’t fix a people problem with technology, and customers getting their machines compromised or tricked via phish is generally a people problem. The bank in this case definitely has a lot to learn as well, but it isn’t entirely their fault either. These stories should be an indication that both end users and banks need to step up their practices. From my personal experience small business owners do almost nothing to protect themselves online
Also I can tell you with certainty that it is customer demand driving the up and coming mobile banking offerings. However these products come about, both the part that uses them and the party providing them has a responsibility to practice good security.
In the near future, you will see a lot more effort on the banks’ side to mitigate this risk. Even small to medium-sized banks are looking at solutions to help prevent Account Takeover. The first and most important step is educating the customer. More and more banks are holding seminars or posting lots of information on how to protect customers’ online IDs. It begins to come down to how much the customer listens.
At the FI where I work, we have held a seminar for customers and provided educational materials for all customers with payment solutions on their online banking on how to improve their security. This education is important because it accomplishes several goals. Fromt he customer perspective, it offers them a chance to leanr better practices and to build a partnership with their FI to help protect their account. The more open the relationship, the better their protection.
One problem we commonly run into, however, is resistance from the customer. Many aren’t interested in educating themselves about the risks, and many of our solutions seem to fall on deaf or uninterested ears. From the overpriced solution of having a “dedicated pc” to the simple yet effective (so far) solution of “buy a mac”, any solution which will cost small businesses more than a few dollars is typically dismissed as inconvenient and expensive. When we offer solutions such as using a “Live CD”, we often get the feedback that “it’s too cumbersome” or “too technical.”
To be fair, we stop short of handing out free Live CD’s because of the perception of liability if someone’s computer crashes after using one. (It doesn’t matter if it caused the problem. If they THINK it caused the problem, it becomes a problem for us.)
Eventually it comes down to this: It has to be a shared responsibility, and the actual losses should be felt by the customer in the event they do not protect themselves, and by the bank when they fail to protect their customer. However, in most cases of this type of fraud I have seen clearly show that the customer was the negligent party. Many customers believe their security responsibility starts and ends with owning anti-virus software and possibly anti-spyware software and having it run once per month.
@Yar – Great comment. I’m sure that many small business owners are frugal by nature, especially in today’s economy. Many are also probably working long hours.
Have you considered customers running a “light” Linux distro Live CD (e.g, Xubuntu, TinyMe) on an unused (or underused) older PC that they may have at work or home? Or, perhaps, a relative’s or friend’s old, unused PC. This would essentially operate as a disk-less PC and require only some desk space. Well, maybe an Ethernet cable.
And one can suspend a PC running a LiveCD to avoid periodic reboots as well as conserve energy.
Helly you have actually put your finger on the issue very well the institutions are in a superior position of knowledge and small business is always time & resource poor. Consequently the institution if they are customer and service focussed will understand this and will design their systems accordingly. Contrary to your belief it is possible to improve the position with technology and that is the exciting thing because technology is simply automation of processes designed by humans. So if you believe you can fix it using human processes then those can be coded the key is are the processes up to scratch.
Once upon a time in America (and other places), in the days of clerks, ledgers, and banking without online access, this problem of online funds theft of individual DIDN’T EXIST. Banking was VERY SAFE. Then came online banking. And major risk for certain customers. If the banks introduced it and sell customers on using it, then they bloody well are obligated to make it as safe as possible for their customers.
@Rabid Howler Monkey –
We are working on a big educational push in which we will try and educate as many of our vulnerable customers (read: all of them) on how to create and use a Live CD. Unfortunately, we can’t really create and hand out the CD’s, or we would. The issue which comes up is one of perception. If we create live CD’s with Xubuntu, tinyme, or puppy linux, for example, we are, in essence, telling the customer that we recommend that particular OS for online banking. If they use this and are compromised (or even if they use it and their PC coincidentally crashes 4 or 5 days later), a customer may perceive that it is our fault, and, therefore, our responsibility to cover their losses.
We see it when we troubleshoot customers who have problems logging in. We might walk them through a setting or two in their browser to ensure they allow cookies from our site, etc. And then, if their computer crashes within the next week, they call and say we caused it. It stems from them not understanding what the settings we had them change do. This will also happen when they use a strange operating system. If they use something unfamiliar on their computer, and then their computer has an unrelated problem later, their perception will be that the occurrences are related, even if they are not.
Some changes happen due to government mandates.
I visited my bank to question some charges on my account, showing the clerk my bank statement.
She said “most customers don’t get copies of their checks any more, do you want me to stop us sending to you?”
I said “heck no, the more info I have, the easier to find glitches in my account.”
I am sure banks stopped sending stuff to customers, to save on cost of the paper it printed on.
Hi helly! I wanted to agree with you, but found I could not:
“Small businesses absolutely need to be held to a common level of computer competency, or they shouldn’t be banking online.”
OK, “held to a common level…of computer competency” by whom? Perhaps the bank, which is hardly a disinterested party?
And how is that to be determined, by course, test, degree, license or professional membership? In particular, how does a customer *prove* having a given level of “competence,” and so force the bank to cover a major loss?
And what do we expect “competence” to accomplish, given that a single online mistake can install a hidden bot infection which remains until the operating system is re-installed? Can “competence” really prevent human error?
I would argue that the issue here is not “computer competency” at all, but instead “online risk management,” the very existence of which both banks and computer manufacturers downplay.
“A business doesn’t try and go after an automobile manufacturer when they leave their car unlocked and they keys in the ignition.”
I suppose the analogy would be clearer if the ignition would accept any key at all. That product would not have reasonable security in the expected operating environment.
Similarly, computers promoted for Internet use are too easily infected by transient human error, thus causing massive loss. This might be a very good reason to start looking at hardware and software manufacturers. We know there can be safer computer system designs, because Linux LiveCD systems do exist which make malware unlikely and infection difficult or impossible.
If banks can identify most bad transactions, they should do so. But the remaining bad transactions still go through. Fairness and justice demands that we address those as well.
You definitely make good points (my analogy was strained).
I guess my only point with regard to end user competency is that they need to be financially accountable for a portion of their actions online. In this particular case, they got phished and responded to the phish. Overall banks can spend (and do spend) millions on sophisticated detection systems such as transaction monitoring software. But there is only so much they can do to secure the end user against their will, as is often the case. In the situation here, I think it would be reasonable to split the losses. The bank definitely should have stopped the wires once the customer identified the fraud for example…
Another analogy attempt:
In the case of Title companies who can initiate hundreds of wire transfers a day. If an end user at one of those companies falls for a pish or gets infected there is nothing I can see to stop the fraud from occurring. Especially if geographically local money mules are used. My point being there is only so much that can be done to help an end user be secure, at some point they have to take that liability on themselves.
Banks definitely have a role here as well, and hopefully the perpetually upcoming FFIEC guidance will continue to push things in the right direction. But there also needs to be some force to push end users in the right direction as well, because my experience is that they are far from close to secure… I won’t provide more of my personal horror stories, but there are too many users who would happily sue that don’t invest anything towards security.
So what else could the customer have done when, as clearly stated in the article, the bank failed them miserably:
… 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.
Perhaps they took ‘until further notice’ to mean prevent further wire transfers, but only after the account is empty?
Granted, customers need to take security seriously, but if the bank systems can’t or don’t work in a secure manner, how is it the customer’s fault?
Is the bank’s system not capable of blocking transfers?
If not, why not. This part of the problem is the bank’s responsibility, not the customer’s; at this stage they have done all they can and it is up to the bank to stop any further fraud.
Any why rely on tokens for security when they are extremely vulnerable to man in the middle attacks. Again, this choice is made by the Bank, the customer had no say in the matter.
Perhaps the bank should learn how to authorize the transaction with the token, not just the connection!
Classic security failure that desperately needs fixing.
Is it practical for there to be a tracer on Internet Web site images, looking for any which look like some bank’s internet banking site, but are not registered as belonging to that bank?
Find phishing sites that way.
I don’t think we have enough information to decide who has the most blame for the first 47 wire transfers — how well crafted was this phishing attack, how well did the bank inform its customers of the change in procedures, etc. It’s likely a matter of opinion whether the bank’s security was “reasonable” even though it’s years behind the methods used by credit card companies.
I find it completely unconscionable that the additional 38 wire transfers after both parties were aware of the problem could have any chance of going through. If that’s really what happened, I would be very interested in the bank’s explanation. “Please allow 6-8 weeks?”
The banks hold out that they have secure systems to attract customer deposits away from their competitors consequently people trust that the banks will protect their assets. It is not good enough for them to place that onus back on the customer irrespective of whether they are a personal or business customer with cleverly worded legal agreements. A simpler solution is to fix the authentication so the customer is not held at risk trying to decipher what is and is not a legitimate banking communication or system. As an example a bank is downloading updates for its online banking software when customers go to the bank website. Now is this legitimate or not. If the customer downloads the update and it is not legitimate because it is a spoofed site that the customer has gone to because of misspelling then they are caught. If it is legitimate and the customer fails to download it they are exposed because their system has not been patched which in turn may leave the customer open to attack or denial of liability. It’s just not as simple for the customers as some people are making out (granted this case Krebs is reporting on does raise questions of contributory negligence). There seems to be this elitist view that non-technically minded people should be able to understand what are often bewildering and complex processes to many. Systems need to be designed to accommodate the wide spectrum of knowledge skills and aptitude of customers.
Although this sounds a bit old fashioned, having a bank employee in the middle between the wire request and the actual wire has made it so the bank where I work hasn’t lost a single penny of a commercial customer money from ZeuS-related fraud.
As simplistic and perhaps stupid as my post may be, it seems as though what is being spent litigating would be better spent by Comerica employing a live person in central operations monitoring wire transfer requests and making a simple phone call to customers verifying the transfer. This is especially true in the case of EMI who doesn’t have a track record sending wires. I’m positively baffled some red flag wasn’t raised when wire transfers were going hither and yon from a company who barely uses wire transfers to begin with. A simple phone call could have stopped this immediately.
And yes, I know phone numbers can be compromised too. :=)
There are a number of issues with that principally without a voice register or you knowing a persons voice personally that system can easily be circumvented. Even in small banks with changes of staff etc it is difficult to maintain direct personally relationships particularly given people are more and more dealing with banking in a non personal manner reducing the opportunities for banking staff to maintain the personal relationships. With the advent of mobile and VOIP it is going to be more difficult to determine the correct number to dial and of course calls can be redirected and numbers can be changed etc before the scam is executed. It may work for you because not many use it anymore or the limits have been raised to keep costs down. Costs is the big issue if you employ that technique it would be much more costs effective to rewrite the code on the authentication so the attackers can’t use simplistic methods to breach it and you will ultimately have a more secure solution. Here I am referring to the attacks to get credentials eg phishing, vishing, smishing, spearphishing, malware & traitorware on the client device not attacks on the network directly via hacking code or installing backdoors etc.
My understanding is that ZeuS comes preloaded with the templates it needs to spoof a large variety of banks’ online banking user interfaces. If your bank hasn’t lost any money to ZeuS, it may not be one of the banks included in ZeuS’s software.
And if you’ve got an employee intervening in the wire tranfer process, it may never be included.
I couldn’t agree more w/ Louis Leahy’s comment.
That being said, I agree w/ one very important point of Comerica’s case, backed up by E-M’s own statement. If E-M only wired money once per year, it was stupid NOT to have a second layer of authentication, especially if it was offered/recommended.
Afterthought: given this negligence by E-M, is this even a good test case? Have many of the Zeus victims made similar or worse errors of judgement?
There’s no mention that the “offer” or “reccomendation” didn’t come with an additional (LARGE) fee attached. For an organization that only uses the wire feature once or twice a year, the idea of getting hit with a fee annually (or monthly) for a service they barely used?
The company probably saw it as a risk from an employee breach and thought they were safe from that because it was the owner who held the purse strings.
But we all know the right things to do, the problem is making them so that they are habit. Eat your fruits and vegetables, get exercise, drink water, take care of your teeth, avoid bad foods/drinks. How many of us actually live up to all of those?
Now think about how many people aren’t familiar with computers beyond “I do this and that makes it work. Why and how it works is beyond me.” The company SHOULD have avoided visiting unsafe sites or opening strange e-mails. The company SHOULD have had a pc set aside just for banking, and/or the LiveCD. But nobody wants to waste a company asset like letting a machine sit unused.
My take? The company’s argument is based on when they began to respond to the incident. They’re arguing that if the bank didn’t heed their requests to hold things up, that the bank was liable to let all the fraud wires go through. So they’ll aim for most/all and settle for the some. The bank will argue that it did everything according to its procedures, which means they’re resting their case on whether or not the company crossed their “t”s and dotted their “i”s in filing a hold request.
If a customer is only wiring once or twice per year, they should not have access to that transaction type online. The bank should have explained to them that the risk of doing so far outweighs the reward, which is the convenience of not having to contact your bank personally.
For high-volume customers, I understand that the balance is reversed in a lot of ways, but for a low-volume customer who only sends once or twice per year (and most likely not on a regular schedule), this service should require human intervention on the bank’s side.
Some (read: all smart) banks do a risk assessment before allowing this type of service online. It takes into consideration the amount of cash they keep on hand, the number of expected transactions, the timing of the transactions, and whatever other information might be deemed relevant to the customer’s riskiness. If they don’t meet a certain level, they aren’t allowed the online service.
In this particular case, there are a lot of things both parties did wrong. To think that the bank held up their end of the deal would be irresponsible, but to think the customer shouldn’t have to face the consequences of their own mistakes would also be equally irresponsible. The fact is both parties in this case share the blame, but if the customer can show evidential proof that the bank allowed several transactions after being notified of the problem, the bank should be held responsible for their inaction at that point.
If a customer contacts us with even a slight suspicion that someone is sending out fraudulent transactions, you can bet we would be acting immediately, not waiting for something in writing. It’s better to freeze all transactions in the account until you can sort it out than to risk losing this much money for your customer.
Regardless of the outcome of this case, the bank is in a lot of hot water. If I were a business customer of this bank, my accounts would have been moved months ago.
I’m in agreement with you that the risk/reward should have resulted in their online wireless transfer ability being left inactive.
I also agree that the customer shouldn’t be able to skip off on the tab. The customer is liable for the transfers that went out before they notified the bank and that could not be recovered. I also believe that the bank should be liable for those transfers that did go out after the notification, and possibly for those transfers that should have been recoverable (IE; they take a few hours to clear, at which point the 2nd bank should have been notified to hold them, etc).
Yar, your post suggests you may be one of those working in the financial industry. If so, I’m glad to hear that there’s someone who can approach these things fairly. If the customer’s been warned and chooses to take the risk, then the rewards and penalties are theirs.
I do work in the financial industry, but I keep up with both sides. Even though I am partial to my industry (of course), I have to look at the issue from the perspective a judge would take. Whose fault is this compromise? Who should be held responsible? Honestly, from what I have read here, I believe the liability should be split.
Experi-Metal should have done more to protect their PC, but Comerica should have done more to help them do this. Banks have been too complacent with helping their customers protect themselves.
I firmly believe the best thing that can come out of this case is that educating and assisting business customers will cease to be seen as an unnecessary expense and will be seen as a competitive advantage. Having the tools and learning materials available for our customers will make them feel safer, and will make them safer. And isn’t that what banking should be about?
“But nobody wants to waste a company asset like letting a machine sit unused.”
A new PC – box, monitor, etc., can be bought for less than 1000 US dollars. If the business can justify paying a manager (or the owner can justify paying hisself) 60,000 a year, what’s a mere 1000 dollars for a dedicated machine ? That’s less than 2% of hisroyalhighness’ compensation.
Some “businessmen” have bizarre (to me) notions of where money is to be spent. They seem to think their own inflated salaries are more important than simple (to us) security measures.
$1000? Heck, you can buy a decent netbook for $350. That’ll actually fit in your drawer, and should hold a charge for quite a while.
The simple answer is… 10% business, 90% banking industry.
Banks require business customers to move to tokens because they were instructed to enable 2 factor authentication as a means to ensure reasonable security on banking accounts from the FFIEC.
Which was a valid configuration for about 3-4 years from when it was required (2005).
Then, the game changed. And no one forced the banks to change. They knew that 2 factor authentication was no longer reasonable protection and rather than “recommending” that wires be protected by authorization from two individuals, they should have required it.
Imagine you are business customer XYZ. You walk into a bank. They tell you that you are required to have a token for security purposes and to prevent fraud. They then suggest that you go with 2 individuals for authorization of wire transfers. The financial background individual who is non-security and non-technical goes, “but that’s what you gave me this token thingy for, right? Forget it.”
So yes, while companies that have their accounts drained should’ve paid more attention to their security practices, until they operate out of MA and have a state data breach law that requires more reasonable security to be implemented, it should be the banks that are held responsible, because they were already expected to offer strong security for the accounts. That is what 2FA was supposed to do in the first place.
On the other hand, most medium and small banks count on their core processor to provide their online banking. It is the core processor that should’ve stepped up and enabled stronger security measures and therefore they should be held responsible when the bank is not in direct control of their online presence.
Finally, the FFIEC should be held responsible for being as slow as a tortoise in regards to improving online banking security. Businesses have required tokens for Internet VPN access for well over a decade. Why did banking not begin requiring it until so much later? And then, why didn’t the FFIEC go to the full measure to require banks to take further steps, because we all know how well capitalism works in adding cost on a business for something that they aren’t required to do when they are trying to stay competitive. Not to mention how much customers love to be limited and held up over security measures and would just go to a less secure bank to get more ‘hassle free’ service.
Here we are 2 years from when this major theft and fraud occurred and FFIEC still remains silent on how to better protect accounts and no extra security has been added to 90% of online banking offerings.
Case in point:
Taken From(http://www.schneier.com/blog/archives/2005/10/us_regulators_r.html)
Two-factor authentication is coming to U.S. banks:
Federal regulators will require banks to strengthen security for Internet customers through authentication that goes beyond mere user names and passwords, which have become too easy for criminals to exploit.
Bank Web sites are expected to adopt some form of “two-factor” authentication by the end of 2006, regulators with the Federal Financial Institutions Examination Council said in a letter to banks last week.
Here’s more details.
This won’t help. It’ll change the tactics of the criminals, but won’t make them go away. I’ve written about that already (the short version is that two-factor authentication won’t mitigate identity theft, because it’s not an authentication problem — it’s a problem with fraudulent transactions), and also about what will solve the problem.
–Bruce Schneier
The reason your technology is not being widely adopted is probably because the bank IT committees are smart enough to know that it is only a matter of time before what some specialists as the one you have quoted out of context are suggesting will prove true and that is your system only serves to confirm the device is authorized to transact not the person controlling the device. This may also be the reason the prudential authorities have not acted. Also your solution only addresses transactions there are a myriad of other interactions that need to be protected that are subject to the same weaknesses to which your technology doesn’t apply. The other big issue with your technology are costs and complexity the more involved the technology the more that can go wrong from a customer perspective and that pushes up help desk costs and looses business. That why simple solutions are preferable and fixing the authentication so credentials can’t be stolen, copied or changed is I believe the better starting point. You have a good technology but even yours is subject to this weakness although not directly as was discussed on Krebs forum previously. Every time I speak with senior management in companies one of the most prominent questions quite rightly is what do the users think. Thus the solutions have to be simple so as to not alienate the customer but at the same time protect them and this is the frustrating dichotomy that bankers in charge of online banking & other online businesses continuously have to deal with. To date institutions have been working on the basis of tolerating a certain amount of loss however with the knowledge of how to secure access becoming more widespread, the media scrutiny and statutory requirements to keep user data private, mandatory reporting requirements, audit requirements and simply the costs and time lost to attending to breaches are now resulting in a real need to adopt a more sophisticated approach.
Leah you missed my point, i’m not advocating for 2FA or security tokens as a solution to all of this.
1, 2fa is already a requirement. Go read the FFEIC guidelines. Most banks have gotten away with substituting a ‘cookie’ that is placed on your computer and you validate the website via an image that is associated with your account.
2, it obviously isn’t enough because even in cases where a token is used, such as this one, it wasn’t enough to protect against stopping the transaction…
which leads to 3… my quote of Bruce Schneier who stated “This won’t help. It’ll change the tactics of the criminals…” which is 100% true to what we’re seeing today.
So no, my quote isn’t out of context. And 2 i don’t have to guess about bank’s IT Committees because I work as a security consultant with a heavy concentration of medium sized banking clients, and know that their focus is primarily on what they are mandated to do by FFEIC and FDIC and how to improve their score for their next audit.
If the FFIEC or FDIC does not require banks to improve the security of online banking, it will not be done.
Yes my apologies I did miss your point I thought you were advocating those systems in particular single transaction authentication. However I still think you may be under estimating the prudential authorities reluctance but perhaps you are better placed to judge. I do know it is difficult to communicate with them and if they are not listening then they are not learning about new concepts and of course the politics of it all is ridiculous technical merit seems to bake a back seat but maybe that is just my jaundiced view.
“simple solutions are preferable…”
That is breathtakingly true. Experience tells us that there can be no complex system which is also secure.
“…and fixing the authentication so credentials can’t be stolen, copied or changed is I believe the better starting point.”
I believe that seriously misunderstands the variety of threats available to a Zombie botnet client. Any authentication that can be communicated is, in fact, “copied” for transit, and so can be relayed and used by the bot. As one possibility, the bot can pass through all authentication and then as soon as an account is open the bot can issue orders (from the correct user IP address) while confusing and delaying the authorized user.
The problem is not authentication, so improved authentication will not solve it. The problem is the bot. The bot places the attacker inside the user machine in real time, making it almost or completely impossible to distinguish attacker from authorized user. And, not only does the bot get bank account credentials, it also gets all email and everything on the hard drive including legal documents, which it could decide to change.
The solution is to not have a bot. In practice, that means we first have to detect it (for which there is no trustworthy tool), and then, sadly, we generally have no secure alternative to a full hard-drive reinstall of (at least) the operating system. As bad as that is, trying to enforce security on systems which may have running bots is just nuts.
It is the hard drive storage of the operating system (and other) boot data which supports bot infection. Our current systems cannot protect that data. In contrast, systems which boot from a DVD can be very strong, and difficult or impossible to infect. This is because it is vastly more difficult to write to a DVD than a hard-drive (or USB flash drive), and if the DVD has been removed, writing to it is actually impossible.
Yes Terry I understand where you are coming from but the way to defend against that is to have properly written code on the network server to do the authentication and not rely on the client device. Once the Authentication is done then what you say holds true but that is where the authentication by transaction would then kick in. The issue is with the current authentication topology even when you get to this point the attacker can see the authentication and copy it because the authentication is designed so poorly. In our design they can’t unless they are on the network of course and that is a completely separate issue and not part of the scope of what we are doing one would expect a higher level of security would prevail on the network server than on the client device. DVD’s are fine but mobile phones don’t have them nor do many of the new fangle tablets and notebooks and I would suggest that a DVD is not a defence against the vishing attacks and perhaps some of the others that deploy social engineering in their cons.
This is very interesting and looking forward to read updates on the case. Reading through the 2 court briefs I noticed they contradict each other in 3 important aspects: The E-M claims to have revoked Mr. Keith Maslowski ability to initiate wire transfers on 1st November 2007 AND TO HAVE received confirmation in writing from the bank over the issue. Comerica claims not to have received such request. The second aspect is related to when the order came to stop processing any wires once it was suspected fraudulent wires were being sent. E-M claims to have requested to stop processing any transaction at 10:50 when first became aware of it while Comerica claims not to have recived such request (“in writing” is added at one point in their court brief, which seems ridiculous in such situation). I would have expected if indeed swift action was taken within 3.2 hours since the fraudulent wires began (7:30 a.m) to recover most of it, especially since it looks the first wires were not sent to local money mules but to foreign banks. Fraud victims in other cases only became aware after 24-48 hours and still were able to recover sizable amounts. Finally, the third aspect where the briefs contradict each other is whether or not there was an agreement to permit overdrafts. For all of the above, the truth should be easy to establish using written documents, voice recordings of telephone conversations (I don’t know if banks record all telephone calls when calling their customers about suspected fraud, but they should) employee testimonials and alike. Other aspects might fall a bit into a gray area (such if it was reasonable for the bank to believe fraud was committed judging from the sudden influx of wire orders). Unfortunately, chances are big this two will settle out of court after their lawyers cross (s)words a few times. And we the settlement will never be made public.
This is probably a stupid question. I see the assertion that requiring two people in order to complete the wire transfer would’ve stopped this. I don’t understand how?
The EMI employee thought this was a legitimate site. Wouldn’t a coworker have done the same thing? Then the bad guys would be logged into both accounts, initiating and approving the transfers. Maybe if the bank’s online interface had a mandatory timeout even without “inactivity,” and even then you’re just crossing your fingers and hoping the two coworkers don’t enter their information within 5 minutes of each other when they check their emails first thing in the morning. I probably missed something.
Jane, you are completely right. Assertion that 2 different people required to initiate and approve the wires would have stopped this is too bold. In one case reported by Brian, the owner of a company which have fallen victim to this had in place exactly this safety mechanism. But the owner (which have authority to approve) received a mail purportedly from UPS loaded with Zeus. She tried to open it, which resulted in some kind of (apparent) error and nothing displayed on the screen. She then forwarded the email to her secretary (which had authority to initiate wires), probably assuming her secretary will be more successful in opening the “UPS” mail. Both computers got infested by Zeus and the company lost a few hundred thousand dollars. This also does not help if the same computer is used by both the initiator and approver, especially if both have user accounts with Administrator privileges or, worse, share the user account also. Finally if both are spearphished and gullible enough to fall for it. On the other hand, if a phish has 10% chance to be successful with a certain individual, infecting both employees has a 1% probability to happen and since no protection is 100% effective, every measure you can take will help. Just to be clear, I’m totally for requiring 2 separate people to complete the wire transfer (this also provide protection in case of employee fraud), but I’m against presenting it as a panacea, but as a measure that can significantly reduce risks in many situations associated with Internet banking.
probabilities and statistics.
if there’s a 1 in 4 chance of an event occuring, then what do we know about two events occuring?
probability math as a multiplicable operation only applies for independent events.
consider instead:
you walk down the street and see a coin. what is the probability that HEADs is up?
(1/2)
a person behind you sees a coin, what is the probability that HEADs is up?
(1/2)
what is the probability that both of you see HEADs up?
well, it could be 1/2 * 1/2, but it really isn’t. that only applies if there’s a 100% chance that the coin will be tossed between you seeing it and the person behind you seeing it. As that’s almost entirely 100% unlikely, it’s really 1/2 * (1 – (possibility that you decide to flip the coin)) with that possibility being very close to 0.
Statistics.
imagine there’s a 1 in 10 chance of knocking on the front door of a house in a certain community and encountering a lefty.
you knock on the door of one house and encounter a lefty.
if you knock on the same door to the same house, do you really have a 1 in 10 chance of finding another lefty? the answer is probably “no”, as being a lefty is probably genetic.
if there’s only one person in thouse, you have a 100% chance of encountering a lefty.
if there are two people, the odds are >50% (you could encounter the first person again).
if there are three people, there’s some reasonable chance (marriage isn’t required, although adoption messes w/ things but it’s relatively rare, and i’m selecting community to the exclusion of college campuses/dorms) that one of the three is offspring of the other two, which gives a probability of a gentic predisposition either child implying parent or parent influencing offspring.
the same applies to most other groups. i’m not trying to single out lefties.
once you’ve selected for any character trait, it’s you no longer have randomness and thus you shouldn’t assume you can say 1/10 * 1/10 = 1/100.
if you receive an email instructing you to do something and you believe it, you might tell or order your colleague to believe it.
your two factor authentication is at best 1 and 1/10th which is perhaps 80% worse than your goal even w/o an attacker with a vested interest in improving *his* odds.
What if the second method of authentication is a phone call from the bank, to the company that is purported making the wire transfer? “Mr./Mrs. CIO, do you authorize this $37,000 transfer to Estonia?”
That could stop a lot of this nonsense. Though as others mention, phone numbers can be changed/redirected/etc. But I still think this kind of secondary authorization would reduce a large portion of this type of fraud. That, and automated detection systems that “flag” strange transactions, and put a hold on them until they are verified to be legitimate.
@Yar:
“we stop short of handing out free Live CD’s because of the perception of liability if someone’s computer crashes after using one.”
All LiveCD’s are not the same. You need one which does not routinely access the Windows hard drive. Then the system boots from the DVD, makes no changes on the hard drive, and so causes no new problems. It is easy to return to the unchanged original system simply by not booting from the LiveDVD.
Currently, I recommend Lucid Puppy Linux 5.1.1. But it is free software, the result of hobby-like development, and does have rough edges compared to commercial packages.
“in most cases of this type of fraud I have seen clearly show that the customer was the negligent party. Many customers believe their security responsibility starts and ends with owning anti-virus software and possibly anti-spyware software and having it run once per month.”
What is reasonable to expect from a customer? The typical bot (i.e., Zombie botnet client) infects immediately after a single user error. Can we seriously expect any form of “security responsibility” to prevent all human error?
An infected computer will remain infected, often with no clear indication at all, until the operating system is reinstalled. There exists no tool or set of tools guaranteed to find a computer infection. Without a clear indication, how can a customer possibly be considered “negligent” just because they do not know something is wrong? We might just as well say the bank was negligent for not providing an infection-finding tool and then standing behind the results.
Antivirus software is one of the most common security recommendations even though we know that it cannot be trusted to maintain a clean system. Apparently, being sufficiently “responsible” to *try* to follow computer security recommendations is *still* not enough to escape a charge of “neglegence.” Exactly what *would* constitute sufficient proof of customer “responsibility” for a bank employee to decide their bank was liable for a substantial loss, and how could the customer provide such proof?
@Terry,
I understand the security merits of the LiveCD approach however all businesses I know run accounting software which would be a big problem with LiveCD. Also most business invoices go through email and so would require a working email client along with a slew of other business specific software which could not run from a LiveCD. Most of these need regular online updating and attaching any writeable media defeats the purpose of using a LiveCD. In fact I recently read of a trojan hiding in a usb connected printer so you would need to disconnect that too. I know even my own personal banking doesn’t exist in a vacuum and I require all sorts of second hand transaction specific information when I do my online banking which I wouldn’t be prepared to manually enter from another terminal.
Desktop Linux, whether bare-metal, virtualized or a LiveCD, is not quite there yet. Intuit’s QuickBooks Online service currently supports only Windows and Mac OS X.
Linux enthusiasts have gotten it to work, however. One has to download, install and configure the Firefox user agent switcher add-on to fake Intuit’s QuickBooks Online web site into believing the user is on a Windows client. In addition, Adobe’s Reader is required to view documents created by QuickBooks and, while available for Linux, is not the default PDF reader for any Linux distro that I am aware of. The deal breaker for small businesses, though, is the lack of Linux support from Intuit.
More pressure needs to be applied to Intuit to support Linux clients with the QuickBooks Online service. Might financial institutions have any stroke with Intuit on this? In addition, financial institutions and/or Intuit may want to consider pooling their resources to create a LiveCD that includes all of the necessary components to successfully use the service if, and when, it supports Linux clients. And, likewise, leaves all of the unnecessary applications off (e.g., IM client, email client, media player).
Hi Matthew!
We have a bad malware situation, and there are remarkably few “degrees of freedom” available to solve it. At this point I think we have to view every claim of a software solution extremely critically.
That leaves the bank, which we now know cannot detect, let alone repair, a Zombie bot infection. Hopefully banks will start to analyze and detect unusual transfers, but that will always have limitations.
Since we find ourselves in a bad situation, the issue is not just how bad a LiveDVD is, but also how bad the alternative is. If the fallback position is to continue use Microsoft Windows online, without any loss insurance or guarantee, that is a terrible risk. A lower-risk alternative for any small business which banks online is to immediately consider banking at the “drive thru.”
“all businesses I know run accounting software which would be a big problem with LiveCD.”
Yes, I understand. I only deliver the news and it happens to be bad. The Lucid Puppy Linux DVD is the best I can do so far.
“most business invoices go through email”
I personally use Gmail from the Firefox browser, running under Lucid Puppy booting from DVD, on a machine without a hard drive. For those who prefer a local email client, I think that is possible under Gmail as well. As far as I know, Gmail is still the only online email service which supports complete session encryption via SSL (https://).
For invoices on a hard drive, it is still possible to access a Windows drive, if one exists, from Puppy Linux.
The problem is the “slew of other business specific software which could not run from a LiveCD.” I have no answer. But living in a house without a backyard does not make it OK for the kids to go play on the freeway. Sometimes the answer is not great, just better.
The fundamental problem is a hardware security flaw inherent in our decades-old concept of booting from a drive. We now know that software simply cannot protect the operating system (and other boot data) as stored on a drive. Malware changes that data to get restarted, and that change is the bot infection that kills us.
What we need is some form of independent hardware control to prevent malware from changing the boot data. Current operating systems would have to change, somewhat, to support the new security structure, so we cannot simply sell new hardware and solve the problem.
“Most of these need regular online updating and attaching any writeable media defeats the purpose of using a LiveCD.”
The system I am using right now has no hard drive at all. Nevertheless, I still have to update Firefox (and the Firefox security add-ons) every couple of weeks or so. Puppy Linux supports the idea of writing data changes to a new session on the DVD+RW, then recovering the newest files on the next boot. New data files can be saved similarly.
Unfortunately, I have found optical media to be less reliable than one might hope. My personal work-around is to attach new files onto emails to myself, which is at least secure in transit to and from Google. I also save locally on a USB flash drive.
“In fact I recently read of a trojan hiding in a usb connected printer so you would need to disconnect that too.”
Ultimately, everything will need better security. However, for now, the vast, vast majority of malware cannot run under Linux. So even if there is an infection in a USB device, it probably cannot run.
Normally, the problem with an infected USB device is that Microsoft Windows executes data from the device while connecting. My recollection is that Windows patches over the last 2 years or so have stopped that, at least to some extent, but modern systems should be set up to disallow “autorun” upon simple CD or USB insertion.
There do exist various “cross-platform” malware approaches (like Java), but mainly to select a variety of infection to drop. Although these might become a danger, for now very little of this actually appears in Linux systems, especially if they do not have Java installed.
“I know even my own personal banking doesn’t exist in a vacuum and I require all sorts of second hand transaction specific information when I do my online banking which I wouldn’t be prepared to manually enter from another terminal.”
On machines with a Windows drive, you can access that drive from Puppy Linux. You can at least collect information by cut/paste, edit it, and save it. None of this is going to be as convenient as a specific Windows application. But we cannot trust our usual equipment and software.
Overall, we have a bad situation. In my view, no add-on software or software patch is going to solve it. Nor is there any indication that the computer manufacturers have any understanding of the problem. I do encourage the FCC to type-accept computer system performance, and require new computing designs to be “difficult or impossible” to infect. But we will be living with what we have for years, at the very least.
Small businesses currently doing online banking from Microsoft Windows should immediately consider using another operating system, or, better, a “LiveCD.” Perhaps an easier alternative is “drive thru” banking, and that is not going to be convenient either.
Hi Terry 🙂
I completely agree with you on the scepticism regarding a software solution, I think that time and billions of dollars have proven that there will always be a new security hole in software which only grows ever more complex.
I also agree the unusual detection or heuristic approach will have limited results, while many of these are obvious to us, a bank manager is probably more concerned with overall customer satisfaction and doesn’t want irate customers with stopped payments to their suppliers who are increasingly international. That said many of these transfers should have been picked up by some sort of heuristic approach even if just to catch the over the top ones. The bad guys will of course just analyze the heuristic levels of any software and modify their transfers to match as many of them already do.
I was with you about an instant-on read only system from a ROM in the hardware which I thought was a pretty neat plan as it solves the long time delay between switching booting out and in which bothered me for casual use until I heard a motherboard manufacturer implemented this a few years ago with an onboard internet browser I believe. The result was they discontinued it due to the need for constant updating in the face of new bugs turning up every time someone fuzzes anything. So I cant see a manufacturer revisiting this theoretically more convenient “livecd” style concept any time soon especially when so many of my applications seem to be updating against new threats more and more regularly.
I agree Linux is superior in general software security terms to Windows however many non IT people aren’t prepared to make the jump. My case in point was several years ago when all the cheap netbooks came out cheaper with ubuntu installed, for awhile there it seemed like linux was going mainstream. Unfortunately the mainstream public didn’t take it up and opted to pay more for the convenience of something they were familiar with even though Vista at that time wasn’t all that familiar. Most of the mainstream netbook makers have now dropped the ubuntu option and its win7 across the board. Quite a few IT guys I know run and love linux but out in the non IT world it’s generally a completely alien os. Perhaps MS will stumble with a future version of Windows and Linux can have a second try at the mass market but for the moment Linux is a hard sell on non IT users. I wont mention driver issues etc etc as weve rehashed all that many times here.
For what its worth even I would recommend the linux LiveCD approach for very specific positions in very specific companies, primarily businesses which need to do a low amount of high value transactions online on a isolated machine dedicated to doing online banking transactions with all the ports glued up and a dedicated IT guy on the staff to set it up properly. I actually wanted to use this setup myself but my bank in Singapore offers data download directly into various accounting packages and the convenience won out, also the vast majority of low end laptops now don’t come with cd drives anymore including the ones I use.
I cant help but mention my passwindow method as being the best solution to this problem, the passive mutual authentication afforded by it is the only method I know of which couldn’t be bypassed by an infection of any sort anywhere on the machine or network even with the social engineering style MITB attacks which are now overcoming the electronic tokens including the transaction signing tokens which utilize active mutual authentication. No OS issues or driver problems and a lower learning curve than most mainstream captchas. The delivery cost is the lowest with the price of a regular envelope and the cards themselves cost virtually nothing being only a regular piece of transparent plastic. I wont do the entire pitch but needless to say unless the laws of physics change or people suddenly become psychic it’s the least likely method to be broken in the future, nobody is fuzzing or hacking out of the screen into a plain plastic card no matter how smart they are. This brings us back to the essential problem of any complex software or electronics invariably being more vulnerable to possible attacks now and in the future. I deliberately chose the simplest most primitive solution I could think of because I was sick of the endless battle with new software bugs turning up constantly. If anyone here has any better ideas to solve the problem the floor is all yours, no need to downvote anyone.
I have done up a comparative against other authentication methods here http://www.passwindow.com/security.html
I hope I don’t sound too harsh Terry, as a long time commenter I do have respect for your staunch LiveCD support over the years and I readily admit it does have many security merits.
@Terry and Matthew,
Respectfully, all this talk about LiveCD’s, no hard drive systems or writable media, non-Windows operating systems, or different authentication systems fails to get to the heart of the matter:
Technology is not a panacea, no matter how sophisticated the hardware and software become, they will never replace common sense and sound security policies and practices (ex. Defense in Depth).
As proof, I have NEVER had a malware infection in the 14+ years of using Microsoft Windows (with Internet Explorer as my main and only browser)! Subsequently, I have never had any online account (financial or otherwise) compromised.
The heart of the matter, in this particular case, is spear phishing. A good link for avoiding spear phishing scams (7 steps) is here:
“How to Prevent Spear Phishing Scams
http://www.ehow.com/how_4893140_prevent-spear-phishing-scams.html
This article, as you would point out, is operating system agnostic. And familiarization with anti-spear phishing tactics adds to one’s security policies and practices.
The discussion of LiveCDs and non-Windows operating systems, which I also got sucked into, was in response to @Yar’s very good post above. Windows-based malware is also a significant vector responsible for bank fraud. Just not in this particular case.
As you point out, applying defense-in-depth to one’s Windows-based PC is indeed another option available to small business owners. Is is especially applicable to those unable or unwilling to go the dedicated computer route. I would (honestly) like to see a high-level summary of the defense-in-depth you use.
“I would (honestly) like to see a high-level summary of the defense-in-depth you use.”
Ok, this may be a little more than high level 🙂 :
1. Use a non-admin (limited user) account for daily use (* see below)
2. Use a firewall (preferably a hardware firewall at the perimeter and a software firewall on each computer)
3. Use a blocking HOSTS file (ex. http://www.mvps.org/winhelp2002/hosts.htm)
4. Install ONLY required software using the latest versions, uninstall old or unused software (reduces system attack surface and minimizes patching)
5. Avoid Adobe Reader (ex. Foxit instead), Java, Quicktime, and Real Player
6. Avoid peer-to-peer file sharing software (extremely risky to obtain malware)
7. Keep the system fully patched (includes ALL software)
8. Use Antivirus (Anti-malware) software configured to update itself DAILY
9. Practice safe computing
a. Use caution with downloaded files and e-mail attachments
b. DO NOT OPEN E-MAIL ATTACHMENTS FROM UNKNOWN SOURCES
c. Be very cautious of attachments from trusted sources, if unsure, contact sender to confirm, otherwise, be safe, don’t open it, delete it
d. Be extremely cautious of links in e-mail (may be phishing attempt or malicious web site)
e. Browse wisely, hover mouse over links to see where they go before clicking
10. Routinely (at least monthly) backup your data to external media (CD/DVD, hard drive, network attached storage, etc.)
11. Use a UPS (Backup power supply and surge protector) to protect equipment from damage and minimize loss of data
12. Optional (but highly recommended):
a. Enable Windows Automatic Updates (Auto download and install)
b. Avoid webmail, instead use an e-mail client (ex. Outlook) and configure it to “Read all e-mail in plain text” and use secure (SSL) POP3 or IMAP
* A non-admin (limited user) account provides a greater level of protection should malware make it past your primary defenses to the desktop. Most malware is designed with the assumption the user is an administrator. Without “administrator” access, the malware is not able to run as designed and fails to compromise the entire system, worst case it is limited to affecting only the currently logged in user.
A few more points:
1. Disable unneeded Windows services (ex. WebClient)
2. Disable unneeded network controls (ex. File and Printer Sharing)
3. Use cookie ad blocking (ex. built into IE, Tools, Internet Options, Privacy, Sites, Block
4. If using a wireless network, configure it for WPA2 and a complex shared key
5. Never use your wireless network to access anything of sensitive nature (ex. online banking). Instead use a hardwire connection (minimizes network mischief, wireless can be sniffed over the air)
6. Before accessing any website of sensitive nature, close all programs, clear browser cache (temporary internet files, cookies, etc.). Use a stored bookmark to go directly to secured (SSL) login page. Do NOT browse to any other website (minimize cross site scripting issues). When done, use sites log out option, close browser and clear cache again.
@xAdmin – This is a very extensive list and all excellent recommendations. However, please have a look at this Symantec write-up for Trojan.Zbot, a banking trojan:
http://www.symantec.com/security_response/writeup.jsp?docid=2010-011016-3514-99&tabid=2
Note that under “3.2 System modifications”, Trojan.Zbot is fully functional in a limited or standard user account. The executables associated with this malware, including ntos.exe, oembios.exe, twext.exe, sdra64.exe and pdfupd.exe, run inside of the user folder, %UserProfile%\Application Data. Also, the following registry entry is made in a limited or standard user account:
HKEY_CURRENT_USER\ SOFTWARE \Microsoft\Windows\CurrentVersion\Run\”userinit” = “%UserProfile%\Application Data\sdra64.exe”
Lastly, it injects itself into both the explorer.exe and svchost.exe services in a limited or standard user account. And these two services are critical to the operating system and cannot be disabled.
Least privilege, while necessary, is no longer sufficient. Execution control via Software Restriction Policy whitelisting using either gpedit.msc or Parental Controls (or TrustNoExe for Windows XP Home) is also needed to prevent the executables associated with Trojan.Zbot from running.
Here’s the test that I use. If one can download and install the Google Chrome browser as a limited or standard user in Windows, the executables associated with Trojan.Zbot can also run and do their dirty work.
Finally, there is a substantial difference in running Internet Explorer on Windows Vista/7 vs. XP. Internet Explorer running at low integrity level on Vista/7 may be enough to thwart an attack, depending on whether there are any prompts provided to the user and how the user responds to the prompts (rolling the dice?). It’s much better to use Software Restriction Policy whitelisting to apply default deny to executables attempting to run outside of folders C:\Windows and C:\Program Files. With SRP whitelisting, the user will not be presented with a prompt and the executables will not run. This is much safer.
Please also note that Intuit’s QuickBooks, accounting software that is very popular with small business, currently requires use of Adobe Reader as it is hard-coded into their software.
The bottom line is that your excellent and extensive list, with or without my execution control recommendation, is a very big job for most Windows users. And disabling Windows services (which I have also done on my systems), even if using the BlackViper site as a guide, can create usage problems that can be difficult to diagnose.
For those Windows users conducting online banking on the same PC that they use for everything else and choose not to use a dedicated Windows PC, Mac OS X computer or even a discarded PC running a Linux LiveCD, you would do well to consider the above-listed defense-in-depth recommendations.
Very good comment, @Terry. Unfortunately, there is no airtight security fix for this on the customer’s side. The goal ceases to be making your system invulnerable because it’s simply not possible. The goal is to make it hard enough to compromise your computer that the hackers move on. Simply utilizing Linux is a step in the right direction here, because you step out of the direct line of fire. Unfortunately, that means there’s no way to correct for the “Accounting software.”
Unofficially, if I were to recommend to my father, who is a small business owner, how to handle his online banking, I would recommend he use his usual software for his payroll and accounting, and load the LiveCD any time he needs to get on his online banking. This can be done from the same machine with a simple reboot. If he needs to upload an ACH file for payroll, log into online banking after booting from CD, THEN plug the USB drive with the file on it, upload it, remove the drive, log off, and reboot back into Windows to get on with your day.
Even if the USB drive has some ultra-rare malware written to attack Linux systems, it would be ineffective if it is loaded after the login process takes place.
However, this still doesn’t eliminate all risks, and it’s very cumbersome if you’re in a hurry (and what small business owner isn’t?). It’s all up to the business owner’s tolerance for inconvenience and risk.
Of course, this is the same conversation that’s been held in the comments section a hundred times. It’s all relative to what the computer owner is willing to do, and banks must account for that in their practices.
I think in the near future (especially now that this case is going to trial), you’ll see an increasing number of banks taking more serious looks at educating customers and using risk analytics to tighten up transaction handling on the back end.
And why not? We’ve used risk analytics for debit cards for a long time, and most multi-factor authentication questions use them for determining who should be prompted for security questions. Why not have a system which monitors typical transaction activity for an account and flag for an out-of-band callback any out-of-character activity?
“Mr. Krebs, we noticed today that you are sending an ACH batch to 23 individuals in 15 states, all for under $10,000. This activity does not match your typical use pattern. Did you authorize the transaction?”
It wouldn’t just apply to transactions. You could also watch for unusual activity such as adding users, changing email addresses, or altering user permissions or limits online.
Of course, the only reason this hasn’t been done is cost, but if this case results in a significant loss for the bank, you’ll see the landscape change pretty quickly.
@Yar,
Presumably, the financial institution (FI) where you work has periodic turnover of PCs when they are refreshed with new PCs. Why not grab a used laptop PC at the next refresh, remove the hard drive and give your father the laptop PC along with a Linux LiveCD?
And instead of rebooting his PC to run a Linux LiveCD, all he would need to do is raise the lid on the laptop PC which will cause it to wake from suspension and transfer the ACH file from his PC to the laptop for upload to his FI? (A similar thing could be done with a used desktop PC by purchasing a KVM switch for approx. $30, allowing him to share his monitor, keyboard and mouse between the two PCs.)
Heck, when the laptop is in suspension somewhere on his desk, he can use it as a tray for a coffee (or tea) and scone.
@Rabid Howler Monkey:
1. The laptop should have a DVD writer to support updating the browser and add-ons, even if done only rarely.
2. Keeping a computer suspended (instead of turning it off) runs the risk of malware continuing to operate on subsequent sessions. The blinding advantage of the DVD boot is to guarantee a clean start, and continuing from a previous session cannot do that.
3. The computer should be restarted immediately before banking online or doing an update. While booting from DVD does take some time when coming up, a computer with no hard drive can simply be turned off after a session with no delay at all.
@Yar:
“Unfortunately, there is no airtight security fix for this on the customer’s side. The goal ceases to be making your system invulnerable because it’s simply not possible. The goal is to make it hard enough to compromise your computer that the hackers move on.”
There can be no perfect security in any reasonably-complex field. But there are different types and amounts of risk:
User education is useful, in that much or most malware is ultimately “invited in.” Unfortunately for the user, the information needed to make a correct choice may not be clearly available when needed. Sometimes there is no correct choice, or the time to make it has unknowingly passed. And even when a choice is known to be wrong, time or financial pressure may cause the wrong choice to be taken anyway. Alas, once done, that may be impossible to take back, but is easily ignored when nothing seems to have changed and there is no idea what to do about it anyway. Certainly, antivirus scanners cannot be trusted to find, let alone recover from infections. Thus, even trained users can collect malware infections. And no amount of education can eliminate simple human error.
If the error leads the user to a familiar-looking but still strange site, the user might be tricked into making further errors, such as giving up personal information. That could be costly. But at least that sort of attack ends when the session ends. It is, in that sense, less dangerous than the alternative:
If the error leads to the installation of a Zombie botnet client on the boot drive, no further user error is required, and the danger will not end after that session. The danger will, in fact, remain and even increase on subsequent sessions. Damage will occur at the whim of the attacker. In a real sense, the danger from an existing bot is hundreds of times greater than the risk of acquiring a bot on any one session. A bot is also the major threat to online banking.
Although any sort of attack might possibly lead to disaster, the vastly greater power of a resident bot is a major risk that continues on and on. While that might be acceptable if we had a tool which would guarantee to find any hiding bot (since we could use it before banking online), there is no such tool. As a result, in conventional computers, the probability of having a hidden bot continues to increase with each online session.
The inability to prevent malware infection is a security design flaw present in almost all personal computers. This is a technical flaw which thus can have a technical solution. That solution is either to (a) prevent damage to the OS and boot data on the boot drive, or (b) to boot the computer from an unchangeable source, like a DVD.
The DVD is a true solution to bot infection, and not a mere complication to the attacker. In contrast, Linux *is* a mere complication, and Linux malware, though in practice very rare for ordinary users, does exist. While “front end” defenses (e.g., the firewall and browser) may not prevent new malware from getting in, and perhaps running, a mere DVD reboot does start a new, clean session every time. That is a simple, easy-to-use yet massive security advantage.
@Terry Ritter
Flip a coin. ‘Heads’, one gets pwned through Mozilla:
“Mozilla Pulls Firefox Add-on for Stealing Passwords
2010-07-14
http://www.eweek.com/c/a/Security/Mozilla-Firefox-Addon-Pulled-for-Stealing-Passwords-399326/
“Compromised file in Vietnamese Language Pack for Firefox 2
2008-05-07
http://blog.mozilla.com/security/2008/05/07/compromised-file-in-vietnamese-language-pack-for-firefox-2/
‘Tails’, one gets pwned through a financial institution:
“Bank of India Hack
2007-09-10
http://www.bankinfosecurity.com/articles.php?art_id=560
Heck, one does not even need to engage in online banking to have one’s account compromised:
“Banks Warn Customers of Data Breach
2011-01-18
http://ezinearticles.com/?Banks-Warn-Customers-of-Data-Breach&id=5712107
As long as desktop Linux and Mac OS X remain in Window’s long shadow, the arguments about how best to run a Linux LiveCD is really a distraction. First, small business owners have to make the switch to a LiveCD. (Or, alternatively, a dedicated computer running an installed Mac OS X, desktop Linux, PC-BSD or Windows operating system.) Why not provide the small business owner (and consumer) with convenient options for running a LiveCD?
In my mind, the solution to the Linux LiveCD for online banking dilemma is to have some group or organization, having a vested interest in safe online banking, take either Debian or Ubuntu and use something like remastersys to strip the distro down to essential applications for online banking and add some hardening. Who needs an IM client? A torrent client? Two media players? An IRC client? Wget or wput? Nope. Firefox? Yup. We know that whitelisting online banking-related sites for the Firefox browser has value, so throw in the Procon Latte add-on and add a small help file to guide small business owners (and consumers) in its use. We also know that Intuit Quickbooks Online requires Adobe’s Reader, so throw that in.
Hardening? A non-root default account. An enabled iptables-based firewall set to default deny for incoming connections. A tight AppArmor profile for Firefox. Not a single service enabled by default. A Grsecurity patch applied to the Linux kernel and configured with a high security setting.
And why not follow Microsoft’s lead with Patch Tuesday? Have a patch Monday, the first Monday of the month, where an updated LiveCD iso is made available for download and burning to a CD. (Just remember to recycle your used media.)
And, PLEASE, Intuit, make your QuickBooks Online (and mint.com site for personal finance) service compatible with both desktop Linux AND LiveCDs.
Could someone explain how the attackers could use one value from the token to make so many transfers? Why did not each wire transfer require separate authentication? This could have prevented 84 fraudulent transfers. I am not saying it’s a panacea, but it would have either significantly limited losses or it would have forced attackers to initiate a wire transfer of such high value that it would have hopefully triggered a bank alarm. What am I missing?
There are different ways to implement 2FA (two factor authentication).
The problem is that it’s designed to solve a log in problem, not a transaction problem.
I bank in Finland. I have a password and a plastic card with a limited number of random one time use keys (sometimes called challenge-response codes).
Because I have say 50 of these one time use keys, and because replacing my set of keys is expensive (both time and resourcewise) for both me and my bank, we collectively agree that it would be bad to make me use the keys to approve each transaction. (more on this below)
I’m not sure how many checks people write these days, but let’s imagine a world where you didn’t have credit/debit cards and could only use “checks”, would you go through 100 checks in a month? In two months? I’m pretty sure I’d go through that in two months, possibly in one. now assume that instead of “checks” you used your bank to send “echecks” (Finland doesn’t use checks at all and hasn’t for years). If it took say 10 business days for you to get a new card with 50 one time use keys, and you needed to use one key per transaction, you could easily end up unable to pay your heating bill. This would be bad (ask your friends up north in Canada, it’s cold in the north, people die when it’s cold).
Instead, to Authenticate to the bank, I run a stupid java applet (embedded in page, mandatory, ….), enter my password, enter my one time challenge response, and the bank says “hello timeless”.
Actually, the bank doesn’t know me as timeless, only JPMorgan Chase is stupid enough to call me timeless (because one of its corporate customers couldn’t spell his/her email address correctly and JPMorgan Chase couldn’t be bothered to validate the email address before permanently accepting and using it for correspondence). – Brian, please feel free to contact me about this, I’ve been calling Chase for about 4 years on this (international from Finland..). I even visited them in person last week. But I don’t believe they’ve fixed their system and they haven’t promised to improve.
Anyway. Once I’ve authenticated, the bank lets me queue up 1 or more transactions. At any time, I can approve 1 or more pending transactions (or just my current transaction). This is done by the Java applet as an “e signature”, it’s about as secure as the “e signature” on your 1040 irs form (roughly a random number you select to claim you’re you). The signature here is my “password”.
Again, we can’t use the one time challenge answers because they’re scarce and refilling them is expensive (oh, and they can’t be refilled to an international postal address) (add one week and one friend for insecure international delivery, I’ve made the mistake of being a middle man once for this, I do not want to ever ask anyone else to do this on my behalf, being MITM sucks unless you’re well paid).
Let’s look at this another way.
20 years ago, you ordered checks, a checkbook had say 50 checks, a box of checkbooks has say 10 books. The checks were “secure” (see also Catch Me If You Can) and somewhat “scarce” but “refillable” on roughly the same schedule as my one time challenge response keys. However, you got 10 books, I get one card. Your 10 books should have cost your bank much more than it costs my bank to make 10 cards, but my bank is cheap. Oh, my bank literally prints money (for Northern Ireland, http://en.wikipedia.org/wiki/Northern_Bank).
You might ask why my bank won’t give me 10 challenge cards. I think there’s a risk involved w/ them lying around, it’s like what happens when principals write their passwords and leave them in their desks at school (see various movies, even WarGames).
In the old days, a burglar could break into your house and steal your spare check books. You might remember to cancel your checks. You’re unlikely to remember to cancel your one time challenge response cards (or even notice they’re missing).
In some ways the cards replace checks (which were a form of two factor auth: something you have, the other factor was your signature: something you know). But as we all know, signatures and pins (you are reading Brian’s articles on atm’s, right? Or even articles like this about zeus) are capturable. A thief could trivially snapshot a challenge key card and install a hardware keylogger leaving no trace of a break in (and effectively defeating your secure read only DVD – or he could replace that too, physical access once gained is…). Thus allowing extra cards to exist outside an account holders physical space is a bad idea (and wallets can’t hold 10).
Security is hard. Recognizing aberrant behavior is easier. Sadly we don’t like 1984’s Big Brother (I don’t like
)
html filter, oops. that last part should read:
I don’t like
http://en.wikipedia.org/wiki/Big_Brother_(Finland_TV_series)
How the token functions is dependent on the type of token, who supplies it, and when the users are challenged. For instance, my FI uses tokens which change every 60 seconds, but the user can only successfully enter the code once. Once that code has been entered successfully, it is useless, and the custoemr must wait 60 seconds for a new code.
This can occur at login, but it can also be set up to challenge users when they submit a transaction. This is useful if the intruder is trying to send out an ACH or wire transaction without the customer’s knowledge.
So, let’s picture a scenario:
The customer attampts to log in and the fraudster nabs his code. The fraudster gets in and starts his transaction. 60 seconds later (at most), the user gets in when the code updates. The fraudster goes to submit his transaction, and the system requests another code, which the fraudster does not have, because the customer is not currently typing codes into the system.
Of course, the fraudster could fake an error message requesting the confirmation of the 6 digit code, or could log the user out and make them login again (resulting in the submission of another code), but at this point, the hairs on the back of the user’s neck should be standing on end, and they should be calling us.
Besides, the point is not to make your customers’ accounts completely impregnable (it’s impossible to protect from every threat and still bank online). The point is to make it so difficult to get your customer’s money that it’s not worth the hacker’s time and effort to try. If there are better profits hacking the guy at the bank down the street who isn’t doing all of this, that’s where they’ll go.
@Yar:
“The customer attampts to log in and the fraudster nabs his code.” “The fraudster goes to submit his transaction, and the system requests another code, which the fraudster does not have,” “Of course, the fraudster could fake an error message”
But the strength of the approach depends on the strength of the next assumption: “at this point, the hairs on the back of the user’s neck should be standing on end, and they should be calling us.”
So, if the bank never had on-line interface issues of any sort, then maybe the assumption would be justified. But that seems unlikely. And success also depends upon the customer having a phone at that time, and being able to get through to the bank at that time, and so on, which are even more things the bot has a chance to influence.
“The point is to make it so difficult to get your customer’s money that it’s not worth the hacker’s time and effort to try.”
Once again, a questionable assumption: The attacker might just sense success and keep working until that is achieved. Normally, bots get in where they can; locating a bot-infected user at a particular easier bank may be more than it is worth.
“Besides, the point is not to make your customers’ accounts completely impregnable”
Actually, that is exactly the point. Failure means somebody pays. Everybody volunteering to pay, raise your hands!
“(it’s impossible to protect from every threat and still bank online).”
Either do it, or prepare to pay.
Which is not a solution, of course, since the bank customer ends up paying for bank errors, even if that customer uses the “drive-thru.”
There can be no absolute security anywhere. But security failure has consequences.
@Rabid Howler Monkey – Great info all around. While I agree software restriction policies can be another layer of defense, I choose to rely on two other defenses: blocking hosts file and my own behavior. That’s not to say that at some point I won’t implement SRP, but at this point, time has proven my existing layered defense has been and continues to be effective. The blocking hosts file blocks known malicious websites, which I strongly believe has kept malware from ever getting to my systems to begin with while browsing the dark corners of the Internet. 😉 I’m also highly cynical by nature and not easily fooled by spam or Tomfoolery in general. It should be noted I rarely get any spam e-mail anyway even though I have the spam blocker turned off in Gmail. Yes, there is a method to stay off spam lists! But, that’s a whole other subject. 🙂
Also, not that I rely very heavily on Antivirus, but I confirm it updates daily and should something get onto my system, it should provide some type of detection/protection against known threats. I’m also hyper aware of exactly what is on my systems and the number of processes that should be running at any given time. And finally, another method to test a system for malware is to boot to a Recovery CD and scan the hard drive. But, that’s all after the fact. My mindset is prevention, to NEVER allow unauthorized code on my system to begin with. In following that faithfully over the years, I am confident that’s been the case. I have no proof otherwise! 🙂 Sure, it takes discipline and eternal vigilence, but the peace of mind is priceless.
From the Symantec write up on ZBot:
Infection methods:
Spam emails
The attackers behind Trojan.Zbot have made a concerted effort to spread their threat using spam campaigns. The subject material varies from one campaign to the next, but often focuses on current events or attempt to trick the user with emails purported to come from well-known institutions such as FDIC, IRS, MySpace, Facebook, or Microsoft.
Drive-by downloads
The authors behind Trojan.Zbot have also been witnessed using exploit packs to spread the threat via drive-by download attacks. When an unsuspecting user visits one of these Web sites, a vulnerable computer will become infected with the threat.
The particular exploits used to spread the threat vary, largely depending on the proliferation and ease-of-use of exploits available in the wild at the time the Trojan is distributed.
Prevention and Avoidance:
Trojan.Zbot relies heavily on social engineering in order to infect computers. The spam email campaigns used by attackers attempt to trick the user by referencing the latest news stories, playing upon fears their sensitive information has been stolen, suggesting that compromising photos have been taken of them, or any number of other ruses.
Users should use caution when clicking links in such emails. Basic checks such as hovering with the mouse pointer over each link will normally show where the link leads to.
Patch operating system and software
The attackers behind this threat have been known to utilize exploit packs in order to craft Web pages to exploit vulnerable computers and infect them with Trojan.Zbot.
@xAdmin – We agree on some very important items including least privilege, the use of both hardware and software firewalls, regularly patching software and making periodic backups. These items happen to be operating system independent. I am ambivalent regarding blacklisting technologies such as host files and anti-malware software, but I’ve never recommended against anyone using these technologies. And, to be honest, I have not used blacklisting technologies for around 3 years.
Humans are imperfect and our judgment is not always as good as we would like. And even though many believe themselves to be skilled at multitasking, the reality does not match the belief. Thus, the continual updating of software to fix bugs (both design and coding), some with significant security vulnerabilities. And, thus, the fact that many individuals fall victim to social engineering ploys. Last year, almost to the day, Aurora was the rage and even a Google employee fell victim to social engineering. Google is an internet company, not a small business, and one would think that its employees would have above-average skills when faced with social engineering ploys. And that their systems would be immune to it when they do.
My discussion of the Trojan.Zbot was to make it clear that Windows malware authors are beginning to target least privilege accounts. This is what Charlie Miller does to Mac OS X each year at pwn2own. He doesn’t get root privileges, but instead owns the user account where documents reside and online banking is conducted. And while Trojan.Zbot is well known to the anti-malware community today, there will be new exploits (0-days) in the future where the malware is either unknown or poorly known (think of the hand full of exploits targeted by Stuxnet).
With Software Restriction Policy whitelisting, I use default deny to provide a safety factor against software vulnerabilities (actually, exploits based on some subset of them) generated by developers as well as many users tendencies to fall for social engineering ploys. Better to just deny an arbitrary executable from running than to have a prompt coming out of nowhere asking the user if they want to run it. Or, even worse, silently running the arbitrary executable. Think of Brian’s very recent posts on the Christmas card social engineering ploy and the Java applet exploit, both which launched arbitrary executables on users PCs. And some of us do use Java.
“I’m also hyper aware of exactly what is on my systems and the number of processes that should be running at any given time.
This is an unreasonably high standard for most small businesses. It’s better to know what specific software employees need to perform their jobs and use some form of whitelisting to ensure that the software they need does run, while arbitrary executables associated with email scams and web site drive-by’s are stopped in their tracks without the need for (or risk of) any user intervention. And stopping p2p among users is easy with whitelisting.
I agree whitelisting is another very effective layer, one I will study further and consider whether it’s appropriate for my personal setup. But whether whitelisting, blacklisting, greylisting, or any of the other defensive layers, the main goal is to prevent malware from ever getting to your system to begin with. Because that is the very first step the bad guys need before they can proceed any further. So if you can stop that, you’ve won. So far my existing layered defense has done just that. 🙂 I would say the blocking hosts file which is a blacklist is the primary means that has kept malware at bay, followed by my systems reduced attack surface via limiting what software is installed, turning off unneeded services that can be attacked, keeping all software patched to minimize vulnerabilities, and my own behavior in using smart computing practices.
Now whitelisting applications, meaning only allowing approved programs to run on a computer is of value, but it’s quite another to attempt to whitelist the Internet (the opposite of the blocking hosts file that blacklists known bad sites). That would be an administrative nightmare as every single resource you want to access on the Internet would have to be approved (whitelisted). Anyway, good stuff. Off to get some sleep.
@xAdmin – You are correct that whitelisting the internet for general use would be a nightmare. However, here’s a scenario where whitelisting an individual user account is both easy and compelling:
Online banking using a using a Windows PC (whether dedicated to online banking use or not)
Create a limited or standard user account expressly for online banking and select an account name, perhaps using your own nickname or a much loved current or former pet. And password protect this user account. Next, log into this account and start Internet Explorer (IE).
Then, open up IEs “Internet Options” and create a bogus proxy server with a URL of ‘127.0.0.1’ and port number of ‘0’. Finally, under exceptions, enter only the URLs and/or IP addresses needed for this account such as financial institution (FI) URLs (there can be more than one FI), Intuit’s Quicken Online service URL and your email service provider’s IP addresses for both sending and receiving email.
Aside from the bogus proxy server address, how many addresses need to be whitelisted via the excpetions list? One, if all you need is access to online banking from a single FI. If you have three FIs, then there are three addresses. If you use Intuit’s QuickBooks online service (or mint.com for personal finance), add one address for that. And if you need email access to send out invoices and purchase orders from QuickBooks, add two URLs, one each for your email provider’s POP3 and SMTP services. So, anywhere from one, to three to six internet addresses are required for whitelisting. Very manageable (and much safer).
Detailed instructions for IE running on Windows Vista here:
http://windows.microsoft.com/en-US/windows-vista/Change-proxy-settings-in-Internet-Explorer
And Firefox has a great add-on, ProCon Latte Firefox, available here:
https://addons.mozilla.org/en-US/firefox/addon/procon-latte/
that one can use to whitelist URLs for the Firefox browser.
One correction to my above post. The following:
“add two URLs, one each for your email provider’s POP3 and SMTP services.
should be changed to:
“add your https-based webmail URL.
Alternatively, one could use Microsoft Outlook for email in this user account and the software and/or hardware firewall settings would apply, as the whitelist is specific to the Internet Explorer browser. However, assuming that Internet Explorer is the account’s default web browser, clicking on any links embedded within an email (not advised, but some users still do this) will only work if they are whitelisted URLs. Thus, this setup would provide protection against spear phishing emails that would try to take the user to a site that a miscreant controls, a non-whitelisted site.
You know, it could be even simpler without implementing application whitelisting. Granted it’s not as good, but it’s another method to protect against Zeus that may have infected the regular daily use limited user account.
Of course, this is assuming the system is already hardened and locked down greatly minimizing the risk of malware infecting anything other than that existing limited user account.
Create another limited user account and log into it ONLY for online banking. Then use a bookmark to go directly to the SSL online banking login. When done, use the sites log out option and clear the browser cache, log off this user and log back in as the regular limited user.
To be clear, when I say log off, I don’t mean switch user which would leave any existing apps still running from the other user. Logging off ensures any user processes are ended. You could also change the desktop background and window coloring to differentiate from any other login and emphasize to be used ONLY for banking.
This would be much more convenient versus rebooting into a LiveCD as you’re simply logging in and out of user accounts. Again, it all hinges on the system being hardened and locked down to begin with. Also, just as you have to remember to reboot into a LiveCD, the user would have to remember to log off and login to the appropriate account.
Here’s another example why URL whitelisting, described in detail above, provides additional protection:
“Bank of India site hacked, serves up 22 exploits
http://www.computerworld.com/s/article/9033999/Bank_of_India_site_hacked_serves_up_22_exploits
The bank’s web site was hacked and customers were redirected to a malicious server controlled by the hackers.
As the malicious server’s URL is not in the whitelist, the redirection will fail.
It would seem that among commenters, and especially raters, the readers of KoS favor the banks’ side of this dispute. Is this because people w/ a good grasp of technology have a tendency to disdain for those who don’t? Do they identify w/ authority in the hopes that one day they’ll have authority of their own to wield?
They have zero empathy for people trying to run small to middling businesses who’ve been sold online banking without having its risks fully explained. May they be treated just as pitilessly some day.
I work for a community-based bank and strongly believe that Comerica erred big time in this case.
The security debate is an excellent one and I have enjoyed reading it. There is much food for thought.
I believe that Comerica could have nipped this scenario in the bud quickly by contacting EMI immediately. Again, a gigantic red flag should have been raised when they began seeing money fly out of an account that only occasionally uses wire transfers. To me common sense should have prevailed on the bank side but didn’t.
EMI could’ve nipped this in the bud by not falling for a phishing attack and getting their account credentials compromised! To me common sense should have prevailed on the business side but didn’t.
/Devil’s Advocate 😉
I agree that if the controller had not fallen for the phishing, this disaster would never had happened.
In many phishing incidents, it seems MANY company employees can fall for these things, so the company firewall should perhaps be doing something about it.
For example … register the legitimate addresses of all the places the company does business with, including the bank site, then block access to others.
Might not want to block ordinary browsing, just block transmission of data away from the company, except to the registered sites.
Just as we have anti-virus to try to protect from incoming data which is badware, in theory we should also have similar protections to try to protect against outgoing data which is inappropriate.
Kathy
I am sure your bank and Comerica are good guys in the current financial crisis. Hopefully I am not too off-topic here.
I am currently reading the US government report on how come our financial earthquake, economic melt down, great recession (whatever you want to call it) happened, and I find it interesting that Michigan was one of the states that could have stopped it for Michigan residents, but for US Supreme Court ruling (against Michigan) that federal laws trump state laws, when it comes to banks registered with feds not with states, and states cannot do a damn thing about organized financial crime syndicates operating inside their borders, when the criminals are protected because they are under federal regulators who are sitting on their hands and are clueless.
Details here http://fcic.law.stanford.edu/
So one lesson is to only do business with banks that are under state jurisdiction, and thus federal laws don’t trump state laws, and clueless federal regulators do not enter into the picture.
I wonder if it’s possible that this column just has a high percentage of readers in the banking industry 🙂
Although I quite openly agree that people need to be more savvy when connecting to online banking, the banks just don’t seem to make this easy. Consider:
Use of a token to authenticate logins.
Security Guru Bruce Schneier commented on this in April 2005:
‘Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had 10 years ago, not the security problems we have today.’
Yet the banks still seem keen on implementing it and claim that it’s a great way to secure online banking. The customer has no other choice, the bank has decided.
Schneier also predicted this:
‘… it won’t work for remote authentication over the Internet. I predict that banks and other financial institutions will spend millions of dollars outfitting their users with two-factor authentication tokens.’
Criminals still able to make many wire transfers several hours after the fraud was noted and they were asked to prevent all wire transfers.
Surely this should just be a one click operation! Did the bank staff not know how to do it, or was the system not capable of doing it?
Doesn’t sound very reassuring to me.
Did the customer have the option of limiting the number of wire transfers per day because they rarely use it?
Were they given the option of setting up destination accounts that can be identified by name to restrict where the money can flow in a wire transfer?
These, and many other questions, have to be considered. I expect the bank just didn’t see this as important.
If the customer had all these options and ignored them, perhaps the banks have a point. If the banks didn’t offer them at all because it would be inconvenient to have to set this up on their system then they aren’t giving the customer a chance to protect their money.
And of course, customers don’t really log in from insecure machines, do they. Surely any competent security engineer would start off with the assumption that the customer’s machine is already owned and try and build the security to take this into account, e.g. an external device to authorize transactions (not logins).
The banks seem to make all these decisions, the customers never have any say. Not sure why so many people seem to favour the bank …
You need to be more specific when talking about tokens as they are not all the same. I believe Bruce was referring to your standard OTP style tokens which are vulnerable to the modern trojan which hijacks the machine or even as Bruce pointed out common phishing scams. I agree with Bruce these are a gigantic waste of money and im not quite sure what threat they exactly protect the modern user against. The only thing I can think of is an attacker uses a trojan to get into your machine but instead of installing the latest MITM attack program decides to install an oldschool keylogger instead, but that makes no sense at all.
The next security step up are tokens which are capable of what the industry calls “transaction signing” or mutual authentication devices. If you google around you can identify these as quite large calculator sized devices with a numeric keypad. In short these work by performing a back n forth authentication from digits given from the server and then entered into the device then basically hashed with a secret key and the user re enters the output. The key to this method was it enabled specific transaction information to be entered by the user into the device on each transaction thereby preventing any trojans on the machine or network or even phishing type attacks. It appeared to be an almost perfect security solution for a long time however the drawbacks on cost, size and usability (can take up to 5 mins for a user to go through a process of entering long randomish looking strings of numbers without making any mistakes .. 40+ digits in many cases) meant that it is rarely used outside of some Scandinavian banks.
Then several months ago a new effective attack against the transaction signing devices came out in a Belgium law court where essentially the Trojan took advantage of the nature of electronic devices in general and sent garbage information to the user and when their devices came up with an error message told them that the device was “out of synchronization” and needed to be resynchronized by following the prescribed procedure which was of course authenticating the criminals transaction out to a mule account. http://slashdot.org/story/10/07/25/1954216/Online-Banking-Trojan-Stole-Money-From-Belgians Enough people followed the Trojan directions for the whole thing to go to court and be exposed and the entire 2nd factor industry is now stumped as to what to do. Mobiles are increasingly vulnerable and it appears all electronic tokens are vulnerable to a similar style attack too.
This is where passwindow comes in as the only online security method I know of which is not vulnerable from any of the online or Trojan attacks including this one, its much easier to use as its mutual authentication is passive (you can see a demo at the top of the security page http://www.passwindow.com/security.html ) meaning the user only needs to visually check the transaction information and manually enter in the associated OTP. This means the user only needs to enter say 4 or 6 digit code instead of 40+ with the electronic devices and errors by the user can be easily identified by the server without fully rejecting the transaction. The cost to implement and deliver is virtually nothing, much less than any other 2nd factor as it is essentially just a printed barcode key pattern on a regular id card which fits easily in any wallet without concern about breakage. No need to worry about drivers or devices as its simply an animated gif so it will work on anything from laptops to mobiles without concern for OS etc. Most importantly from a security point of view I cant convince you your printed pattern is broken in any way or ask you to divulge it over the phone so its not vulnerable to the same attacks which bypass the electronic tokens.
In short is assumes the customers machine, network and any other electronic device ie mobile are already owned and provides a simple solution at a low cost and I cant see any of those things changing in the future. If anyone here has a better solution please let me know.
@Matthew
A better solution? Stop authenticating just the login.
Seem to recall a similar attack from a trojan a while back. System gets infected, monitors network access to bank URL and once authenticated login is achieved queried the bank itself for a balance and drained the account with many transactions.
This login was not compromised by MIM, the connection was to the real bank site, but the transactions came from malware.
What has this in common? No authentication was made on the transactions, only the login.
If the customer has a standalone calculator style device with a shared key issued by the bank, get it to sign the transaction details: amount, date/time and account number.
This token will only match that transaction; try changing the amount or account number and the transaction fails.
And one other thing, since most of these attacks arise from e-mails, why don’t the banks send out PGP signed mail? Anyone know of any bank currently doing this?
Admittedly mail client writers are failing people badly here as despite being a well established standard, you don’t see many (any?) mail clients with out of the box signature checking instead of having to track down and install plugins.
Not an ideal solution, as it depends on how securely the certificate store is, but it is another layer of security, requiring the attacker to compromise the machine as well as send the mail and surely better than receiving unsigned mail.
Of course, a more old-tech solution would be to use snail mail, you can’t hyperlink on paper; or try using text only mail … html is for websites, not mail.
@Not Impressed, I dont think you read through my post, passwindow’s advantage is it does authenticate the specific transactions mutually from server to the user and user to the server. By doing it passively without requesting long transaction information from the user it prevents the coaching attack I described against the electronic tokens. I provided a demo link above which uses the destination account number. There are many different ways I could include transaction information but for banking the destination account is the key aspect from an attackers point of view.
I believe banks dont use email for a variety of reasons. First would be the prevalence of phishing scams so it seems best to have blanket ban. Secondly they are not in the software support business calling up grandmas to explain how to setup and configure their pgp clients, even I myself decided the drama of configuring up gpg wasnt worth the security benefits because at the end of the day if everyone starts using it the malware will start looking for the local keyring files and they will keylog your passphrase. The reason I went with the passwindow approach which is completely outside the electronic loop is adherence to Brians philosophy that “Any solution that does not assume the customer’s machine *is already compromised by malware* stands zero chance of beating the bad guys at their own game.” To assume anything else is just wishful thinking especially if you’ve spent time at a blackhat conference.
@Matthew
My fault, I did skim that a bit quickly.
My main point being, of course, that the bank in question didn’t authenticate the transactions at all, yet claim to have done everything to prevent this.
The company only made about one wire transaction a year, the criminals made 85 in one day. Any transaction authentication at all would stop this fraud completely, as the customer only logged in leaving the criminals to provide the token, which they can’t.
Are banks now considering passwindow or some other transaction authentication, or just continuing to not authenticate anything past the login.
‘… but for banking the destination account is the key aspect from an attackers point of view.’
If the customer can arrange setup of wire transfer destinations with the bank (not through the online system 🙂 then transfers could only be made to those select accounts by name. Might not work for all cases, but I suspect a number of smaller businesses only need transfer to a small number of suppliers.
I agree that banks don’t need to send e-mails at all.
Some time ago I needed a paypal account; they said that they never send e-mail for security reasons. Then I started getting e-mails from them: You haven’t used our account in a while, why not give us your bank details to make payment easier …
@Terry
‘That means a bot can deny banking services at will.’
Which is inconvenient, but will alert the customer that something’s wrong with his machine and he’ll still have the half a million dollars in his account.
‘At that instant, the bot would able to send banking orders to the account, unless every single bank command required tedious authorization’
Let the customer decide the limits of what becomes tedious, not the bank.
The attackers in this case made 85 transfers in a day; if the customer knows he will never makes more than a couple of wire transfers in a day then let them cap it.
In this case they only made about 1 a year, which is hardly ‘tedious’ 🙂
If the customer pays many small bills (< $500) then let them set the limit for authenticated transfers (e.g. $500 or more). This forces the attackers to make a much larger number of transfers and makes the fraud more obvious to even an automated fraud detection system which can then step in and ask for authentication. If it doesn’t get it, it can stop the transfers automatically.
Seems to me that the bank just sell an online package that allows unlimited wire transfers without giving the customer any say in the matter.
I don’t expect banks to be faultless, but it’s the customer’s money so why not give them some say in how to protect it.
@Not Impressed,
“My fault, I did skim that a bit quickly.”
No problem, passwindow is so outside of the box that it is easy to make assumptions at first glance, it takes quite some time of thinking about the security implications to realise the benefits over other methods.
“Any transaction authentication at all would stop this fraud completely” “Are banks now considering passwindow or some other transaction authentication”
Yes weve got a lot of banks implementing passwindow at the moment and I might be able to give an inside on what is going on from the banks point of view. First of all the people in charge of making these decisions do not have the same mindset as our community here at Krebs. While we discuss the finer points of new IT security attacks and how to prevent them, their minds (the majority ive engaged with) are primarily focused on running a business. This means the people in charge of the decision are focused on How much will this cost to buy/setup/deliver/maintain? The Public Relations and Legal people are often given as loud a voice as the actual IT Security Officer. Not all organizations are like this but I do think its easy in the Security industry to be a little myopic and realize much of the rest of the world mostly sees us as the guys who make their day to day life difficult for reasons they don’t fully understand.
About your idea, actually I personally recommend the same kind of theory to the banks, rather than being focused so much on the login with modern online banking it would seem the key authentication focus should be on the creation of new outgoing accounts.
“Surely this should just be a one click operation! Did the bank staff not know how to do it, or was the system not capable of doing it?”
Most likely a case of the left hand not knowing that the right hand was on fire. The wires department is most likely completely separated from the Online Banking Department, and they probably did not communicate that the access needed to be turned off. If they also automated the wires completely, the transactions go from online to out the door.
As an addendum, I’d like to mention that if my assertion is correct, it would have been prevented by having procedures in place in the event of a user compromise.
Every department of every bank should at least have some knowledge of who to contact in the event of a compromise, and should have an incident response team which jumps into action to prevent losses for the customer and for the bank.
@Not Impressed: “Surely any competent security engineer would start off with the assumption that the customer’s machine is already owned and try and build the security to take this into account, e.g. an external device to authorize transactions (not logins).”
Brian has been saying for years that a security solution must start with the assumption that the customer computer has been compromised. Alas, it is not at all clear that such a solution can exist. In fact, the idea sounds good in the same way that 1-time and 2-factor solutions sounded good–before they were shown to fail.
Think about it: We have a motivated malicious opponent present in real time inside the customer machine. The defender is a static security design which just sits there. The attacker can look at anything, change anything, and try and try again until he wins. Who would bet against the bot?
Even worse, all communication to and from the computer flows through the enemy. He may not be able to understand it, but he certainly can stop it, or damage it, or change it. That means a bot can deny banking services at will. And it might do so in a way that looked like some sort of believable problem, to deflect suspicion.
Even with an external device, the web account would have to be opened from a browser, even if that needed a 1-time code. At that instant, the bot would able to send banking orders to the account, unless every single bank command required tedious authorization. And, of course, the bot can choose to not allow that anyway.
The banking problem is just a small part of the consequences of bot infection. Bots have access to everything in the computer, including all files, all contracts, all schedules, all passwords as they go through, and all email, both locally and in the web accounts. They can read it, expose it, change it or write it. The real problem is not finding a way to bank around the bot, the problem is the bot itself.
“the problem is the bot itself
This is the problem with the Puppy Linux multi-session DVD. Even though one starts with read-only media, once multi-session is enabled, each new session gets appended. And what gets appended? Everything in the user’s home directory, /root, as the default user in Puppy is still ‘root’. And guess what’s inside /root? The /root/Startup sub-directory, where scripts may be placed to be run upon the start-up of X Windows.
Here’s a real example of a start-up script in Puppy:
http://murga-linux.com/puppy/viewtopic.php?t=56306
In this example, the application is the TightVnc server process. TightVnc is remote control software.
The solution for the use of Linux LiveCDs must involve a relatively frequent, periodic update (monthly, as an example) of all the software contained in the iso. Which, in this example, means that one would download a new LiveCD iso monthly for burning and use. In addition, the software placed on the LiveCD should be the minimum necessary to perform online banking. Finally, some hardening of the operating system should be applied. Hardening examples include a non-root default user, fully-enabled default-deny firewall, tight AppArmor profile for Firefox, grsecurity-hardened Linux kernel, etc.
@Rabid Howler Monkey: “once multi-session is enabled, each new session gets appended.”
No. New DVD sessions do not just occur. They must be specifically initiated or allowed by the user.
I have found that using the “Save” button on the Puppy Linux desktop tends to cause fewer optical write failures, so that is what I use, every couple of weeks or so. To update, I restart the system, only do what is necessary for the update, and then save. I decline all other system requests to save.
Is it possible for a DVD update to save a bot? Sure. But the infrequency of saves, and care about when a save occurs, makes things *comparatively* safe.
That would be “safe” *as* *compared* *to* Microsoft Windows, where most malware is targeted, and which boots from a hard drive that can be infected immediately and remain infected because there is no tool to expose the infection.
That would also be “safe” compared to any other hard drive installation (including Puppy Linux on hard drive or any writable USB flash drive), which also can be infected and also has no tool guaranteed to detect such an infection.
And it also would be “safe” compared to a static DVD without browser updates.
“The solution for the use of Linux LiveCDs must involve a relatively frequent, periodic update (monthly, as an example) of all the software contained in the iso.”
Surely anything labeled as “the solution” cannot stop with mere monthly updates! Surely they must be weekly or daily or even hourly! Inevitably there is a tradeoff which you apparently set at monthly, and I set at bi-weekly.
Simply doing a restart, thus starting with no bot, then going to the bank *before* doing anything hinky which might get a bot, would seem to prevent banking bot problems. If you do some wierd stuff later, you might pick up a bot, so do not save.
“Which, in this example, means that one would download a new LiveCD iso monthly for burning and use.”
No. By updating the DVD only after a reset clean start, and then doing Firefox and add-on updates, the the DVD is kept clean. These are incremental updates and do not involve a complete re-install of all website options. It is possible to start from scratch, but then it takes me a couple of hours to set up all my favorite stuff my way.
Start clean, go nowhere hinky, then do banking. That does not leave much opening for a bot to get inside the banking process. A new iso is not going to improve on that.
“Hardening examples include a non-root default user,”
Puppy Linux does not support the distinction between user and admin accounts, and I agree with that decision:
Once started in a user account, malware can certainly do everything the user can do in that account, and so everything the user has or does is exposed. We thus see that the whole point of having user accounts with reduced privileges is not to protect the user, but instead to protect other user accounts and the system itself. But when everyone can carry their own “account” on a DVD, there *are* no other users, and the system is always reloaded from DVD.
The very idea that any operating system could resist malware running in a user account seems like a delusion from another era. In practice, all large, complex systems can be penetrated.
“fully-enabled default-deny firewall, tight AppArmor profile for Firefox, grsecurity-hardened Linux kernel, etc.”
My Puppy Linux setup articles describe enabling the software firewall, as well as including a range of security add-ons for Firefox, which I would say are considerably more important since that is generally where malware will appear. The kernel is what it is and changes as Puppy changes versions.
@KFritz
Ok, I’ll bite…. you sound like some bleeding heart liberal! LOL 😉 /sarc
In all seriousness though, it’s not about any of that. It’s about looking at the whole picture and understanding there are shared responsibilities amongst all the involved parties. I get the impression you expect the bank should shoulder all responsibility regardless, and that they are one of those evil greedy big companies that exploit others?
I see it differently as I’m a strong believer in personal responsibility and not playing the victim mentality (I despise that!). If I were the business, I certainly wouldn’t take whatever the bank says as gospel or think for a minute they’re going to protect me no matter what. That’s rather naïve thinking. Even in the old days where a handshake meant something, you still didn’t blindly trust. Cynicism has a purpose you know!
As I said in my first post, “I’ve never understood the extreme risks many of these businesses seem to take with their financial assets. You’d think they would take better precautions to protect themselves considering what is at stake.”
As such, claiming ignorance is NOT an excuse! I hear way too many people put themselves in a box when it comes to computers. They fear it, only because they don’t take the time to understand it. It’s the same with any powerful tool. Get to know it and you’ll be able to use it to its full potential while minimizing any risks it presents. If you don’t, you only have yourself to blame when you get hurt! Then again, may be you shouldn’t be using it for those purposes to begin with.
One of the other problems of the WWW is reading people fr/ keyboard detritus. I’m a ‘freidenker’–think for myself. I’m not in a box, and I’m not trying to label anyone or put anyone in a box. An in-person meet would dispel any thought of ‘bleeding heart.’
You didn’t respond to the position of EMI and other business owners who have been similarly ripped off. They view technology as strictly a tool. They may like it or not, but they DON’T love it or have any sort of fascination or identification w/ it. To see why EMI decided for online banking, I’d love to see Comerica’s sales pitch for online banking. I hope it’s evidence in the trial so everyone w/ an opinion can see it.
I believe (repeat believe, not know) that most of the commenters w/ so little fellow feeling for EMI are technology devotees. If so, they’re being self-centered and borderline narcissistic if they expect people making widgets to share their fascination &/or focus. I don’t know if this is the case w/ yourself. I hope not! My comment earlier today was a sort of fishing expedition to see if there were any replies & to find out how long it would take to be negged off. (-:
PS While typing this, 4 negs came in. Is it organized? Has someone figured out how to game the site? I feel a tad paranoid to be negged that fast. I touch type, not slowly.
PPS: Ever since the day I paid someone $60 to clean the crap out of my software, I’ve been a computer security devotee. I razz my friends who aren’t paranoid about their security
I share gentle tips with my correspondents using SIG like the following:
Allowing one’s computer to be unprotected, while connected to the internet, can be compared to owning a handgun and putting it out on your doorstep every night, in case a passing robber might be in need of one. Unfortunately millions of people are doing exactly that, while thousands of them do so through networks of companies and government agencies that they manage
Any updates on these legal proceedings? I could not find online court docs other than the initial briefs and the denial of summary judgment last year. I am waiting on a pacer.gov account to see if I can learn more, but would appreciate any updates people can share.
I’ll update myself here: using a Pacer.gov account and searching U.S. District court of Eastern Michigan for case number 2:09-CV-14890, I found I could access court documents and the most recent filing was 22-Feb-2011 by Comerica to rebut a supplemental brief filed by Experi-Metal. I don’t know why there are no further court doc filings after February.
I haven’t paid for the Experi-Metal brief, but from quickly reading Comerica’s brief, they are arguing that Comerica employees dealt fairly with Experi-Metal in that no unfairness or self-profit was shown by their actions in honoring the wire transfer requests.
I guess it means they are not making any claims that anyone recognized the spike in transfer volume as unusual nor any information if the destinations of the transfers were available and could be seen as suspicious or unusual. They are making the case that the UCC doesn’t require them to go to those levels to review or question client transaction.
Wow, the judge ruled in favor of EMI – didn’t seem that would be the outcome:
http://www.bankinfosecurity.com/articles.php?art_id=3750
It seems to me that a secure transfer system can be set up by requiring that each new transfer destination be verified either by a phone call requiring a password or a personal visit to the bank. The password, of course, must be different than the online account password. A bot changing the telephone number would not get past the password requirement.
If one adds new employees or other transfer destinations, one either registers them personally at the bank, or confirms them when called by the bank. Obviously, there is an expense in that a bank employee must call, but I would expect that the extra expense would be minor compared to the added security.
Hi NJR, essentially the problem is you have shifted the authentication issue from the user to the bank with the bank now needing to authenticate incoming phone calls which is almost impossible. Without some form of mutual authentication or transaction verification by the user the attackers can inject themselves in the middle. Requiring in person authentication has its own authentication issues for instance as I have never personally known the girl behind the counter at the bank, it is also very costly for the bank and it seems to defeat the purpose of internet banking which by and large has been a boon in convenience.
You are correct though in focusing on authenticating the outgoing destination and in my PassWindow system we recommend banks using it require transaction verification on the creation of new outgoing accounts only as this is the critical focus for malware and not the most frequent action a user needs to do. Interestingly here in Asia where most countries regulate mandatory OTP devices for banks, word has come through the grapevine that there is to be a regulatory shift across the region towards transaction verification for all financial institutions very soon and so it will become the norm, over here in any case.