Hackers are stealing money through customer computers during on-line banking. Most computers are easily infected by sophisticated remote-controlled robot programs which put the attacker inside the customer machine. "Bots" in customer computers can defeat virtually all known banking authentication schemes, including one-time 2-factor systems with an external dongle, public key certificates, out-of-band schemes and multiple authorization. Small businesses can be grievously hurt, because the bank generally will not make them whole. Serious protection is available, even free, but does require users and owners to learn to do things much differently.
The fundamental problem is criminal malware which installs a bot infection in the customer computer for profit. "Malware" is short for "malicious software" installed without permission from the owner. "Bot" is short for "robot," a hidden program with more power than the user, remotely controlled by an attacker. An "infection" is malware which has changed data on the hard drive, so the bot will run on each and every computer session. Often malware is installed by a "Trojan" email attachment or .PDF file which appears benign, but actually contains a dangerous bot and infects the computer.
Almost all malware is designed for Microsoft Windows and will not run in other operating systems. Windows is targeted because 91 percent of browsing occurs under Windows, not because the operating system is flawed: All large, complex systems have security flaws.
Malware is effectively "thrown to the winds," and will find itself on a Windows machine 91 percent of the time, and on a Linux machine only 1 percent of the time. If the malware was designed for Windows, it has a 91 percent chance of running. If the malware was designed for Linux, it has a 1 percent chance of running. Attackers design malware for Windows instead of Linux, not because Linux is stronger, but because only running bots make money for attackers. To avoid malware, it is important to not run Microsoft Windows online, especially when banking, and that is the first change which must be made.
An even more serious problem is infection, since an infected computer will remain infected, session after session, until the operating system is reinstalled. Infection occurs on the system hard drive, and no antivirus scanner will necessarily detect it. Without a tool to certify a computer as clean for online banking, the only way to avoid a hidden infection is to reinstall the operating system. Frequently. A better approach is to use an operating system which boots from a CD or DVD on every session, and that is the second change which must be made.
Many recommended solutions do not work: Security software is too little, too late, and cannot clean an infected machine. Laws and law enforcement are a decade behind. Banks are limited because the problem occurs inside customer computers (although banks may be able to delay suspicious transfers). Market forces issue false and contradictory statements which keep users running to buy the latest new solution which will not work. A solution that does work is a free Linux "LiveCD."
There are four main actors in the malware online banking drama:
The Attacker is, of course, the ultimate source of online banking problems. The goal is profit by whatever means possible, typically criminal theft. The tool of greatest menace is the bot:
A "bot" is a program that contacts the remote attacker, and essentially puts that attacker inside the customer computer. Bots hide, and often cannot be found by antivirus scanners.
Typically, a bot has access to everything on the machine, including everything typed or seen by the user, and can send it back to the attacker. That includes everything "remembered" (as in checking the browser "remember my password" box), all keystrokes (including login usernames and passwords), and even screenshots (to defeat on-screen keyboards). With a bot around, nothing on the computer can be private. A bot can even get between the Web and the browser to add questions to an existing page (originally from the bank but changed by the attacker), or modify information displayed (to hide account changes).
(See: "ZeuS on the Hunt" by Dmitry Tarakanov at: http://www.securelist.com/en/analysis/204792107/ZeuS_on_the_Hunt ).
A bot can send messages to a bank which are impossible to distinguish from valid customer orders. Banks are limited in what they can do to stop this, first because the bot is in the customer machine, and then because bots can defeat almost every type of authentication, including one-time 2-factor external hardware dongles, public keys and out-of-band phone or cell-based schemes. Some examples:
"The theft happened despite [the] use of a one-time password, a six-digit code issued by a small electronic device every 30 or 60 seconds."
(From "Modern banker malware undermines 2-factor authentication" by Dancho Danchev at: http://www.zdnet.com/blog/security/modern-banker-malware-undermines-two-factor-authentication/4402 ).
"Trojan-based, man-in-the-browser attacks are circumventing strong two-factor authentication, enabled by one-time password (OTP) tokens. Other strong authentication methods, such as those using chip cards and biometric technology that rely on browser communications, can be similarly defeated."
"Out-of-band authentication using voice telephony is also being circumvented by fraudsters using call forwarding so that the fraudster, rather than the legitimate user, is called by the service provider performing the authentication."
(From "Where Strong Authentication Fails and What You Can Do About It" by Avivah Litan at: http://www.gartner.com/DisplayDocument?id=1245013 ).
"[The] Owner said her financial institution...normally notified her by e-mail each time a new wire was sent out of the company's escrow account. But the attackers apparently disabled that feature before initiating the fraudulent wires.
"The thieves also defeated another anti-fraud measure: A requirement that two employees sign off on any wire requests. ...a few days before the theft, she opened an e-mail informing her that a UPS package she had been sent was lost, and urging her to open the attached invoice. Nothing happened when she opened the attached file, so she forwarded it on to her assistant who also tried to view it. The invoice was in fact a Trojan horse program that let the thieves break in and set up shop and plant a password-stealing virus on both [her] computer and the PC belonging to her assistant, the second person needed to approve transfers."
(From "e-Banking Bandits Stole $465,000 From Calif. Escrow Firm" by Brian Krebs at: http://krebsonsecurity.com/2010/06/e-banking-bandits-stole-465000-from-calif-escrow-firm/ ).
Malware is written and distributed for profit, but is limited by reality in ways which may not be readily apparent.
Malware consists of computer programs designed for particular systems. But malware is generally distributed to anyone browsing infected pages or email attachments, and then must exploit whatever system it finds. Some of the malware distribution will thus encounter the right system and will run, for potential profit. The rest of the distribution will encounter a wrong system and will fail, for a complete loss. Almost all malware is written for Windows, which means that computers which do not run Windows can avoid almost all malware.
Currently, about 91 percent of browsing occurs under Microsoft Windows (with 5 percent for Macs, and 1 percent for Linux). Yet almost all (probably more than 99.9 percent or 999 out of 1000) malwares are designed for Windows.
(See, for example: "Malware beyond Vista and XP," by Magnus Kalkuhl and Marco Preuss at http://www.securelist.com/en/analysis?pubid=204792070).
Now, perhaps Windows does have more security problems than other systems, but not 999 times more. So why is malware not exploiting the other targets to any significant extent? We have to look beyond security problems for the answer.
Malware for Macs and Linux does exist, but if attackers distribute those, they will run only 5 percent and 1 percent of the time. Windows malware is thus 18 times more likely to be profitable than Mac malware, and 90 times more likely to be profitable than Linux. The optimum profit occurs with all Windows malware and no other malware at all. Since the Windows target is vastly more profitable, the lack of malware targeting other systems should be no surprise. An attacker would have to be nuts to target any other operating system for profit, no matter how easy it would be to defeat. Malware is about market share, not operating system weakness.
We can of course expect a few, small, malware distributions targeting other systems, for development, market testing, intelligence and propaganda. For example, if attackers can convince users that other systems also have malware problems, users may not switch away from Windows, which keeps things simple for the attackers.
It may be possible to prepare malware for multiple targets, but doing so would be twice the work and increase profit by only 5 percent at best.
Malware attacks are designed for the single most expected environment. Even though Windows will be found only 91 percent of the time, attackers will prepare for Windows almost 100 percent of the time, because that will give them vastly better chances of success than any other alternative.
It may be tempting to blame the bank, but that may not be easy:
(From: "Cybercrooks stalk small businesses that bank online" by Byron Acohido at http://www.usatoday.com/tech/news/computersecurity/2009-12-30-cybercrime-small-business-online-banking_N.htm )."Article 4A of the UCC [Uniform Commercial Code] has been interpreted to absolve a bank of liability in cases where an agreed-upon security procedure is in place and a theft occurs that can be traced to a compromised PC controlled by the business customer."
Blaming the bank also may not be fair: When a robber takes money from a teller inside a bank, the bank itself loses money and presumably insurance pays. But nobody blames the bank when people are mugged at an ATM. So is online banking more like being a bank employee, or a customer using an ATM?
A common refrain is that if only the bank had such-and-such authentication, money would have not have been lost no matter what was in the customer computer. Unfortunately, there is no system like that.
The reality is simple:
Currently, there is no system that can offer provably secure banking transactions in the presence of a live bot. Many dramatic failures of serious authentication give substantial reasons to doubt that security can survive the presence of a live bot. Even if technically possible, the result would be unacceptable: the bot would still expose all customer data, including every bank login account ID and password. Even a secure SSL connection to the bank could not hide anything from the bot. The problem is not a failure of banking authentication, the problem is the bot in the customer computer.
The situation is thus:
Instead of trying to build a system to avoid an existing bot, a more responsible course might be for banks to disallow Microsoft Windows for online banking.
Unfortunately, knowing what operating system a user is using, in the context of a live bot, will be harder than one might think. Doing this well, if possible at all, would at least require development beyond what we now have.
Many attacks are "Trojans," which function by getting the user to accept an apparently innocuous document with hidden dangerous content. Most Trojans are specifically invited in by user action, which means managers may be happy to "blame the user." There is a lot of talk about a lack of computer education, which presumably would fix everything.
Malware infections often are the result of user error, so it is tempting to blame the computer operator. But how practical is that really?
Here is a BY NO MEANS EXHAUSTIVE list of secure computer configuration and operation tips, some of which come from hard-won personal experience. It does not get into the operational details of the operating system, browser or add-ons. It does not even start on the complex and ultimately hopeless mess of trying to configure and use Microsoft Windows securely.
Do we actually expect users to study lists like this until they can do everything right? Do we actually expect to avoid all human error?
Education is fine. Who can possibly be against education? But no matter how much education or training users get, it will still be impossible to avoid every risky online action. Even when the correct response is known, a human will eventually make a mistake. When even a single mistake can allow malware to infect the system, we have a system problem, not a human problem. Education cannot prevent human error.
Not using a LiveCD when banking online may be the worst of the user errors.
The problem is a bot in the customer computer, which the bank cannot detect or kill. So the bank is not responsible. But the customer also cannot detect the bot, so they are not responsible either! The only player left standing is the customer computing hardware and software.
If operating a computer is like driving a car, we ought to be somewhat familiar with manufacturing problems and recalls. If a car, in its normal environment, suddenly became undetectably dangerous to operate, would we blame the driver, or would we blame the car and the manufacturer?
Can the Microsoft Windows product, when operating in its expected PC environment, be considered "fit for the purpose" of secure online banking?
Despite loud cries to the contrary, I believe Microsoft Windows cannot be hardened enough, by any means whatsoever, to provide secure online banking for ordinary users. This is not due to poor program quality, since all large, complex systems have errors. This is due to market share. As long as any error whatsoever can be found in Windows, that will be exploited to leverage the 91 percent Windows market share for criminal attacks.
Infection has been around for decades, and not nearly enough system design effort has gone into preventing it. Unlike endless patching that never seems to make a difference, absolutely stopping infection is a real possibility.
Infection occurs when malware can modify the operating system startup processes so that the bot is started on each session. If we protect the startup and operating system files so they cannot be modified, they cannot be infected. Unfortunately, operating system protection is insufficient, because malware subverts the operating system. Hardware protection is needed.
Infection can occur from a single user error, and after infection, a bot will be watching and waiting until the user finally does some banking. The basis for most malware infection is a writable boot drive (normally a hard drive, but possibly a USB flash drive). To avoid infection, users can boot a LiveCD when online.
Users will screw up, no matter how much training they have had. If a user avoids taking the Trojan bait, there is no problem. But if the user bites, the consequences vary widely, and the difference is due to the system, not the user:
There you have it: A LiveCD prevents bot infection while a conventional system does not. A LiveCD gives the ordinary user some welcome freedom to be human.
Everybody has an idea about what to do. The most popular course seems to be doing nothing at all, but that will not prevent bad guys from stealing your money.
Some people argue that ordinary users simply cannot learn to boot Linux from DVD, so the whole idea is hopeless. But those who might benefit most are small businesses who have to deal with harsh reality all the time. If change is what is needed, change can happen. The result should be a less risky environment and considerably less anxiety.
The conventional approach has been to "harden" the PC with complex configuration, antivirus software, and extensive user training. Unfortunately, no part of that approach can be trusted to work enough to prevent malware from getting in and dropping a bot infection.
Demanding that the bank do something ignores the fact that the problem is in the customer computer and there is little the bank can do if the customer has a bot. The much vaunted banking authentication solutions simply cannot be trusted when an attacker is inside the customer computer.
New laws surely will take years, and they will get it wrong anyway. But there are some real possibilities:
Some articles claim the American Banking Association and FBI recommend using a "dedicated PC" for online banking.
(See, for example: "Feds Warn Small Businesses to Use Dedicated PC for Online Banking" by Kim Zetter at http://www.wired.com/threatlevel/2009/12/feds-warn-small-businesses/).
Searching the sites aba.com and fbi.gov yields no such recommendation, but we can still consider the proposition.
(See: "Tracing an FBI Warning" by Chris Larsen at http://www.bluecoat.com/blog/tracing-fbi-warning).
Presumably, the idea is that if a PC never browses any site other than the bank, and never does email, it cannot get infected. Of course, that only helps if the PC is not already infected, which means it must be new, or have an operating system reinstall. The idea also works only as long as banking pages are never infected.
(See: "Several Banks Have Their Websites Defaced" by Lucian Constantin at http://news.softpedia.com/news/Several-Banks-Have-Their-Websites-Defaced-147128.shtml).
There is nothing more secure about a dedicated PC than a normal PC, except the claim that it is used only for banking. But all it takes is a moment of inattention to infect it for the foreseeable future, and we cannot expect to detect the infection.
If a dedicated PC has ever been used for general browsing or email we cannot know, and if there is a bot in place we are unlikely to detect it. That makes the dedicated PC dangerously deceptive and a security disaster just waiting to happen.
Users can learn some best practices to improve online security:
No other browser has anywhere near the security features available to Firefox with security add-ons, including:
Until another browser has these features, the choice for secure browsing must be Firefox.