A business telephone equipment company in Texas is trying to force its bank to settle a liability claim over an attack by organized cyber thieves last year that cost the company $50,000.
Attorneys for Dallas-based Hi-Line Supply Inc. recently convinced a state court to require depositions from officials at Community Bank, Inc. of Rockwall, Texas. Hi-Line requested the sworn statements to learn more about what the bank knew in the time surrounding Aug. 20, 2009, when crooks broke into the company’s online bank accounts and transferred roughly $50,000 to four individuals across the country who had no prior business with Hi-Line.
While the contents of that deposition remain closed under a confidentiality order, Hi-Line’s lawyers say the information gleaned in the interviews shows serious security missteps by Community Bank, and that they are ready to sue if the bank does not offer a settlement.
“In the event Community Bank refuses to resolve this matter, now that we have uncovered some of the information obtained by virtue of the court’s order, Hi-Line intends to assert claims for misrepresentation, violations of the Texas Deceptive Trade Practices Act, fraud, and breach of warranties, among other things,” said Michael Lyons, a partner with the Dallas law firm Deans Lyons.
Hi-Line president Gary Evans said the fraud began on Thursday, Aug. 20, about the same time the company processes its normal $25,000 payroll. After Hi-Line submitted that batch of payments to its bank, the unknown intruders attempted two more transfers of nearly identical amounts on Friday and the following Monday, Aug. 24.
Evans said he had trouble logging in to his account on Thursday and had the bank reset his password, but the fraudulent transactions hadn’t showed up on his account at that time. He said he took that Friday off as he always does, and when he tried again to log in after returning to work on Monday, he again found the bank’s site would not accept his password.
“When I finally got the bank to reset my password and got into my account, I noticed the duplicate payroll batches and said ‘Why are you all pulling my payroll out three times?'” Evans said of his recollection of how he came to realize his firm had been robbed. “At the time, as I was resetting my password, I had to scroll through the bank’s online customer agreement, which basically said the bank is not responsible for any fraud. I should have known at that point that they were not going to take any responsibility for this at all.”
Evans said the bank should have detected that something was amiss, and not just because of the unusual and repeated payroll batches. He said the crooks accessed his account from five different Internet addresses with locations that were nowhere near Texas, including from computers located more than 1,300 miles away, in Washington, D.C. and Maryland.
Community Bank did not respond to requests for comment. But in protesting the deposition, Community Bank claims (PDF) that hackers had infiltrated Evans’ computer with a virus and used it to steal his online banking credentials, which included a user name, password, PIN and several challenge/response questions.
The organized criminal gang that hacked and robbed Hi-Line could not have succeeded without the assistance of “money mules,” accomplices who were willingly or unwittingly hired through work-at-home job schemes to help cyber thieves launder stolen funds. Among those lured into the scam was Josh Enlow, a 28-year-old gas station attendant in Phoenix. Enlow said he was hired by an entity calling itself The Total Group Co., which initially contacted him in an e-mail stating it had found his resume on a job search Web site, and would he be interested in an “accounts payable” position?
A few weeks later, Enlow received “several” (he says doesn’t recall how many) deposits — including one transfer for more than $8,400. He then wired the money to individuals in Eastern Europe as instructed, he said. (See screen shots below taken from the Total Group Web site.)
The receipt Enlow received for one of the transfers from Hi-Line's hacked account.
It sounds like Hi-Lines’ computers had malware (Zeus) on them that allowed the bad guys to lift the login information. If that’s the case, how can it be said, “crooks broke into the company’s online bank accounts”? They didn’t break in, they had the keys to the locks! That’s different than if they actually hacked the banks system! I understand commercial banking users don’t have the same protections as consumers.
Regardless, all parties have a responsibility to properly secure their end of the deal by preventing malware on their systems that can steal the keys to the castle so to speak! So, I don’t think the bank should eat all the fraud! HiLine shares some of the blame! At the same time, the criminals behind the theft need to be pursued to the full extend of the law!
Also, I strongly believe these money mules know what they’re getting in to. How can anyone look at those e-mails and think it’s legit? Seriously! My BS detector is off the charts! As such, they should also be prosecuted for being an accessory to a crime!
@ xadmin
As I’ve often said, going after the mule will never work; putting it simply there will always be people looking for a quick buck.
If I deposit money with my bank and they forget to lock the doors/safe it’s their responsibility; equally if they don’t bother having a safe it’s down to them… why should it be different online?
That’s like saying going after speeders won’t work to enforce speed limit laws. Also, you can’t tell me that the high majority of speeders don’t know they are speeding. Doh, gee officer, I didn’t know I was over the speed limit! Right… They knew it and thought they’d get away with it. Same with these mules. If they were prosceuted, you don’t think it would help cut down on some of this fraud?
As to the bank forgetting to lock the safe door, they didn’t. Their online banking system wasn’t left open (unlocked). It still required credentials to access the account. It just so happened that the bad guys got the keys by compromising the account holders computer. That’s NOT the bank’s fault!
For all the laws to enforce speed limits, there’s not a day that you or I go out on the roads that we don’t see somebody speeding!
But road safety has been improved because manufacturers were pressured to provide safer cars; at the moment the US banks are providing a Pinto of a system; one that’s negligently lacking in security… so they locked the safe but it wasn’t a very good lock and they then proceeded to watch the criminals carry out the money.
You can argue all you like for US banks doing nothing but I don’t thinks it’s a great argument… unless your a scammer in China or E Bloc…
“If I deposit money with my bank and they forget to lock the doors/safe it’s their responsibility… why should it be different online?”
If you are standing at an ATM and get robbed, should the bank have to replace your money?
If the customer issues orders which are intercepted and changed inside the customer computer, how is the bank at fault?
See “The Banking Malware Mess” at:
http://www.ciphersbyritter.com/COMPSEC/BANKMALW.HTM
As long as banks are required to replace the money taken from individual accounts, they are liable for potentially huge amounts, and there is no technical solution banks can simply apply. No form of authentication can make it acceptable to have an attacker inside the customer machine when banking online. And no current tools can certify a machine as clean before going online.
When banks are forced to eat losses from individuals, they are less likely to embrace much larger losses from small business. It is increasingly important for a small business to learn how to stay out of the malware line of fire by not using Microsoft Windows when banking online.
Many people object to the very idea of having to do something like booting a Linux LiveCD just for online banking. Fine, but “you can’t beat a horse with no horse,” and the other proposed solutions do not work. Small businesses would be well advised either to not bank online at all, or to learn and use a free Linux LiveCD.
Ugh, not the LiveCD again! Just kidding 😛
It’s a great tool for many, although I don’t believe it provides much value for those of us who have the knowledge and experience to lock down a system from here to Sunday!
I know for a fact my security hasn’t been compromised in the 14+ years I’ve been using Windows systems. Also, the only time I ever reboot my systems is if a patch or system maintenance such as a disk check require it. Security, stability and convenience! It’s a win-win-win! 😛
There is no reason for me to justify a LiveCD.
If it ain’t broke, don’t fix it!
P.S. – Why the large bold font on your website for the computer security stuff? For those with bad eyesight? Dramatic effect? 😉 Seriously, I couldn’t read through it and had to bail. 🙁
“It’s a great tool for many, although I don’t believe it provides much value for those of us who have the knowledge and experience to lock down a system from here to Sunday!”
I believe that Microsoft Windows CANNOT be “locked down.” The problem is that Windows supports 91 percent of all browsing, which makes it THE PRIME TARGET for criminal profit. If there is even one single error which can be exploited in Windows, it will be, and there will always be such an error.
“I know for a fact my security hasn’t been compromised in the 14+ years I’ve been using Windows systems.”
You know no such thing. You CAN know no such thing. Absent a Microsoft tool which does not exist, it is virtually IMPOSSIBLE to know that no bot is present. The inability to certify a Windows machine as clean for online banking is a huge part of the current problem, which is why I cannot allow this to go by unchallenged.
Bots are built to hide and use rootkit technology to do so. Internal scanners can find infected files apparently unchanged. Even external scanners can only find a small subset of malware, and bots can change or re-encrypt themselves so they will not be found.
“Why the large bold font on your website for the computer security stuff?”
You found an HTML format error. While Firefox did not expose it for me, Opera (which I never use) did. Apparently the problem originated in an early file and was carried along in later work. The offending four files are now fixed. Sorry for the trouble, and thanks for your help.
Respectfully, that’s a bunch of FUD (Fear, Uncertainty, and Doubt).
If there are or have been bots on my systems, I guess they are waiting for some magical moment to steal my credentials and take my money! Because I haven’t had any fraud on any account in the last 14 years! That’s a fact! Just dumb luck? I don’t think so! 🙂
@xAdmin:
“Respectfully, that’s a bunch of FUD (Fear, Uncertainty, and Doubt).”
But risk IS uncertainty, coupled with potential loss. Fear of loss IS appropriate when the situation is out of our control, as it generally is now. And we are well beyond doubt, instead knowing with certainty that bots DO exist and DO steal real money.
There is no tool guaranteed to indicate the presence of a bot. But lack of knowledge is not knowledge of lack: Not having a test does not mean that if we had a test it would not come back positive. Online banking needs real assurance of a lack of bots, and not just that we have not found one because we have no test.
Many of the incidents discussed in the KrebsOnSecurity columns involve people who must have been living with a bot for at least a little while, but were unaware of it until *after* their loss. There is ample reason for fear.
“If there are or have been bots on my systems, I guess they are waiting for some magical moment to steal my credentials and take my money!”
In general, botmasters have a range of systems from which they choose the most useful, and they are not limited to stealing money. They also use systems to publish spam, conduct denial-of-service attacks, plus who knows what else. They can have far more bots than they use. Not actually experiencing a negative result does not mean that no bot is present.
Believing without proof that a system has no bot can be a big mistake,
I was being a bit sarcastic about the bots. Suffice it to say, I am quite certain my systems have been and continue to be bot free, make that malware free. Nothing has ever made it through my defenses. And no, that’s not based just on any lack of fraud activity on online accounts. Give me some credit, I’m not naive. Contrary to your statements, there are numerous methods to prove a system is clean. Any system admin worth their salt knows how to verify the presence or lack thereof of malware.
So, I have no compelling justification to switch to using a LiveCD as my current setup has proven time and again to be effective and useful. Like I said, if it ain’t broke, don’t fix it. 🙂
The fact is that if this goes to court, the company is going to lose out, because it was their computer which was compromised. The fact is that a year ago, the security precautions put in place by this bank (MFA and password protection) were considered “reasonable” by a lot of the industry. A lot has changed in a year.
However, if it happened today, with the raised awareness involving small business ACH and Wire Fraud, I could see them having to pay some damages, although the company would still share responsibility.
Of course, it’s easy to go out a year later and say, “They should have been following all of these protocols and weren’t!” But, as they say, hindsight is always 20/20. It’s easier to point the finger at the bank a year later when it was your computer which was compromised, causing the problem in the first place.
Ben, I don’t think the company is disputing that they had a breach. I believe they’re planning to make claims that the bank misrepresented the security of its transactions, and that it could have done a lot more to detect fraudulent activity.
My gut says that Hi-Line is trying to deflect any responsibility and put the onus squarely on the bank. Something here just doesn’t feel right. I think Ben is on to something! 🙂
@BK,
I didn’t mean to imply that the customer was denying they were compromised, but simply that the fault of the transactions leaving rests with the bank. This is clearly not the case.
Even with ACH limits in place (which I assume the bank had for this customer), if the transactions were spread out over two days, it does not exceed the per-day limit for the company.
However this bank should also have had in place a payroll calendar for this customer. If a payroll batch leaves on a day for which there is not a payroll scheduled, you contact the customer and hold the transaction until you can verify that it is intentional. My bank uses this practice. It doesn’t catch everything, but is another layer that is the onion of online security. (try saying that 10 times fast)
@xAdmin – thanks. That’s a much more concise way to say what I meant. I think the customer is just doing everything they can to avoid eating the loss all by themselves.
Still, it’s a bit like Terry’s metaphor of being robbed after using the ATM, except this ATM is in the dark, scary alley known as the internet. If you aren’t able to protect yourself fromt he criminals, maybe you should avoid that particular ATM and find other ways to access your money.
I’m betting the company is S.O.L. since the bank provided the agreed upon validation (userid/password) for “security”.
The question I’d like to see answered is whether the bank was providing any sort of extended “transaction protection” for that account that extended transaction validation beyond simple userid, password, account number identification.
From the mention of the typical “we won’t accept any blame for anything unexpected” EULA that was mentioned, I’m guessing that the bank wasn’t providing additional transaction validation.
Many years ago, one of my credit card companies phoned me to verify some transactions that didn’t fit my purchasing pattern. It happened to be that transaction was valid.
General question: has anyone had any recent experience with banks providing more in-depth transaction validation?
I cringe every time I read someone saying that an institution should have known something was amiss because the IP addresses were from “distant” locations.
The minute we start locking down IP addresses to a tight physical location, customers complain that they cannot access the service through their preferred ISP (I use a Verizon MiFi regularly which has IP addresses which are “located” ~300 miles from where I physically am). Geo-coding of IP addresses is at best a guess based on historical information and the historical topology of the Internet at a given moment in time.
Now, what would be fair is to keep historical record of the IP addresses used on an account and flag when they are grotesquely different, much like a credit card company tracks regular spending and flags when you seem to make a large purchase in a foreign country when you’ve never done so before.
Operationally, banks should flag any changes to an account’s routine transactions in temporal proximity to changes to the account’s authentication information. If the password is reset prevent and changes to transfers for some period.
The problem with any changes on the bank’s end is that the weakest link here is the user. If your computer is compromised, there is nothing I can do at the server end to detect that anything is amiss. MFA, secureId’s, etc are useless if the criminals are sniffing your keystrokes or watching the screen in real time.
Any idea of what operating system the victims were using in this case?
Additionally: say a bank does do some sort of IP profiling? If I’m criminally minded I’d just make sure that my transaction gets proxied through your computer (which I apparently already have decent access to if I grabbed your credentials in the first place). Now the user is doubly screwed: the evidence (from the Bank’s POV) will point back to the user’s desktop as the origination point. How is the bank to know that this is fraud committed by a 3rd party vs. fraud committed by one of the organization’s employees?
Regardless of whether an employee or 3rd-party’s doing it, if banks cannot tell the difference between a legitimate and a Zeus funds transfer in real time, doesn’t this mean that their customer-verification methods are ineffective and don’t meet the “commercially reasonable” standard in reality?
The few wire transfers I’ve seen that have come through via a ZeuS infected PC were very sloppy and sent up red flags immediately to our Ops Dept. Some of the examples I’ve seen online look a bit more expert. Currently we are batting 100% at catching all fraudulent transfers as our bank manually enters wire transfer requests when made through online banking and a phone call made if something seems unusual. This being said, making contact with the customer is a very important step.
Also, our commercial customers cannot change their contact information online, it must be done in person.
To date, these practices, although inconvenient have not made customers irate. If anything it makes them feel as though we are concerned for their online safety when banking with us. Regardless, I’m still a huge advocate for banking via a Linus distro on a LiveCD and will not bank online any other way.
My question refers to the typical verification methods used as described in the article – online username, online password, online PIN, online security questions – and not the untypical manual funds transfer entry and Out-Of-Band verification done by your bank and brava! BTW. Banks using these typical methods must believe these methods meet the “commercially reasonable” standard while your bank must not(?) because it’s doing something quite beyond the ordinary. Is it reasonable for these banks to claim “commercially reasonable” when Zeus is beating the pants off them? What’s the test for “commercially reasonable?” Banks’ loss rate below a certain percentage? If banks fend off lawsuits successfully, then their losses are zero and their methods are “commercially reasonable” now and will be forever. No need to change or improve because losses are borne by customers. Is this a satisfactory outcome?
I use puppy for banking and email (thanks to Mr. Ritter) but migration to puppy has not been smooth, Firefox fails to update among several other problems. IMO puppy isn’t ready for prime time but I’ve 4.3.1 and don’t know if 5.0’s better. Am going to try Browserlinux and xPUD sometime.
@Michael:
Firefox updates fine for me in Puppy 4.3.1 so I am using Firefox 3.6.8. My main update problem is that sometimes Firefox will not delete add-ons when I find a better alternative. Also the Perspectives add-on has not been updated, but if I install it and then save to DVD+RW before bringing Firefox up again, Perspectives does work on future sessions.
Like most Linux distributions, Puppy is volunteer code, and it shows. For me, just enough works right to be a real solution. More than once I have been caught by some limitation and thought there would be no answer, but there was. If there were any real alternative, I might well be using something else.
Few systems are really concerned with security, and that includes Puppy. It is something of a surprise to find that we are actually in a situation where security can make a measurable financial difference to ordinary people.
Puppy appears to be the only distribution which allows browser and add-on updates to be written to the boot DVD+RW. An optical boot device is crucial to resisting infection, but actually using a system which does not allow easy browser updates may open one’s eyes to Puppy advantages and lessen concern over faults. It is not professional code, but normally I just use Puppy to support Firefox.
Puppy does have issues:
1. Video selection is fixed on first use, and may be wrong when sticking that DVD into another machine, so we cannot just take a Puppy CD to another computer.
2. Networking seems similar: Once allowed for future sessions, networking seems enabled at startup. For security I would prefer it to always come up disabled, and the ability to enable or disable the networking *hardware* with a click. I want to know at a glance when it is online and when it is not.
3. Optical storage is slow. A flash drive can be much, much faster, but needs a hardware write-enable switch. More than that, the flash file system is a normal computer file system, updated in real time, instead of the archival, use-the-latest-file optical system. Which is sad, since the code is obviously there.
Puppy 4.3.1 is getting old, but every time I think about trying 5.0 I look at the discussion forums and get scared off.
Mostly (as now) I use Puppy on a system without a hard drive, and it works better than one might expect. I use Google Bookmarks a lot, and send myself files as attachments in Google Mail. I save files in a USB flash drive. Sometimes I use Google Docs for editing and for .PDF display and storage. With the CopyAllURLs add-on, I put the current session tabs in a LastPass Secure Note, which then becomes available to load into Firefox on other computers. That is just slightly more convenient than saving the current tabs as HTML, then sending that to myself as an email attachment. In either case, I avoid cumbersome bookmarks sync.
I would be glad to describe how I use Puppy, but I am not a Linux system programmer. Still, let me know if I can help.
@epc I noticed in the PDF to which Brian linked, the account was opened in July (in the first part of the document) or June 2009 (according to the testimony of the bank VP) and was compromised in August 2009. With such relatively short time, profiling would not help a lot, I think. It is quite possible the bot was already in Mr. Evans computer when the company opened the account with Community Bank and the thieves used the time to work out the attack plan.
@ Brian Was this case an already known one (published in the cybercrime maps from your June blog, or is a recently surfaced case) ? I’m wondering how long it takes since an attack is discovered by the victims and their bank until it goes public in media.
George – I mentioned Hi-Line last year, but only as a passing reference in a chart I compiled on victims for a story about how thieves had stolen $40 million from small businesses.
http://voices.washingtonpost.com/securityfix/2009/10/fbi_cyber_gangs_stole_40mi.html
I have actually seen fraudulent transactions coming fromt he right IP address. Not hard a stretch to accomplish if you have a bot on the PC.
Locking down IP’s is only a failsafe measure, and can only stop or delay other attacks. My bank currently has the ability to create IP whitelists for our customers, and we do so for some. It has a lot of limitations, just like time restrictions.
There is NO action a bank can take to prevent all fraudulent transactions which originate from an end-user being compromised, short of out-of-band verification on ALL transactions. This out-of-band verification severely hinders the convenience of online banking.
The best action for banks to take right now to prevent lawsuits and help their customers is to educate them. Community Banks should be stepping up and holding seminars and luncheons for their small business customers to help them understand the threats and solutions to fight them.
My bank is holding one this month, and has plans to hold more if this one goes well. They will be utilizing a security specialist who will give a 40 minute talk and will be providing materials to the customers to help them protect themselves (including an ubuntu LiveCD — Right, Terry?). The message will be simple – don’t be afraid, but be aware and protect yourself.
@epc: “Now, what would be fair is to keep historical record of the IP addresses used on an account and flag when they are grotesquely different, much like a credit card company tracks regular spending and flags when you seem to make a large purchase in a foreign country when you’ve never done so before.”
Much of the MFA software has this built into their risk engines. It’s up to the bank to tune MFA’s response. In most cases, this simply involves a challenge of one of their secret questions. Since the malware usually knows most of these answers already, it’s usually not that effective.
The best scenario I can think of is to invoke an out of band challenge on a high risk transaction. For example, if a wire was submitted over X dollars, the customer would have to type in a one time password sent via SMS to their mobile. This of course is easier said than done, especially at a large institution.
I agree with Dustin that an out of band challenge would work but I would not enter anything back into the browser; keep the entire challenge process out of band.
In general the banks need to change their approach with regard to security. It’s NOT we cannot do anything if your infected IT IS we know you’re infected now what can we do.
Isn’t this where we are today?
If the banks don’t wake up and figure out how to fix this problem then Washington, DC will. All it takes is the right group of well-connected small businesses and the banks will face Sarbox for the Internet. If I use a credit card in the “wrong” place, or the “wrong” way, or for the “wrong” amounts, their programs flag the transaction.
So why aren’t demand accounts put through the same discipline?
You have a company that, likely, regularly deposits a payroll and then disburses it via ACH to its employees. All of a sudden there are wire transfers out of the account at the same time? Wires are going to individuals? Passwords for access to the banking systems are being reset several times over a 24 to 48 hour period? And none of this registers with the bank? Sorry, I don’t buy it. It is called – connect the damn dots.
I would love to be a fly on the wall at those depositions – it will sound like the gang that can’t shoot straight.
Oh, and please, don’t tell me a community bank can’t afford to be as sophisticated as a big bank. They are buying their processing from large companies like Fiserv and Jack Henry. That security monitoring should be part of the service or maybe they become parties to the suits as well.
As an senior systems administrator for a community-based bank I’m always baffled by banks that allow unusual/atypical transfers like this to happen in the first place. Community Bank should have had a procedure in place for their Operations Dept. to make telephone contact with Evans or someone at Hi-Line regardless of Hi-Line’s computer(s) being infected or not. To me part of the bank’s job is to protect the customer’s money and to potentially avoid unwanted & negative press especially in this economy. I guess where I work we have more respect for our customers and are willing to pick up the phone to see if the $9K wire transfer that looked unusual is legit or not.
Terry is spot on about using a Linux LiveCD for banking. His article about the banking malware mess is an excellent read for everyone, particularly the small business owner.
It’s good you would catch a net new transaction. How about catching the existing payroll batch but with one of the participants changed? What if two of the participants were changed? What if the change was minor and the bad guys actually had their own account at a reputable U.S. bank.
If your bank would catch the difference between a legitimate payroll batch and an altered payroll batch with the same number of participants all going to U.S. based banks you rock. Many banks will not catch this soon enough. There are still a lot of fraudulent tricks that can pulled using existing batches and I fear we will hear more about them moving forward.
It sounds like part of the scheme was to time the withdrawals to be the same amount of money and at about the same time as normal payroll, and to occur when the owner was usually not around. There’s a good chance that if the bank called and asked if $25,000 in withdrawals were authorized, a weekend employee in the accounting department might have sad, “yes.”
You think the bank should be to blame? I believe so. The bank should have offered a minimum, MINIMUM security such as a physical crypto key that connected to that bank account. That way, a compromised account can be accessed by criminals but no transaction could be made unless the criminals get their hands on physical crypto key too.
“no transaction could be made unless the criminals get their hands on physical crypto key too”
But Mika, the attackers have a bot in the customer computer! So the customer reads the key, types in the number, which thus “hands it” to the attacker, who sets up a new transfer, and uses the key. Bots *defeat* external 1-time key dongles. Adding more complexity to a bot-in-the-middle transaction has not yet turned defeat into security. Why does this bad idea refuse to die?
See my article and the links:
http://www.ciphersbyritter.com/COMPSEC/BANKMALW.HTM
You state “…the customer reads the key, types in the number, which thus “hands it” to the attacker, who sets up a new transfer, and uses the key. Bots *defeat* external 1-time key dongles.” It is possible for the Bot to collect the passcode, which expires every 60-seconds. However, for a successful attack, the Bot must be able to enable the transaction to occur before the passcode expires.
In the Hi-Line case, the article states “After Hi-Line submitted that batch of payments to its bank, the unknown intruders attempted two more transfers of nearly identical amounts on Friday and the following Monday”, which means that this Bot was unable to complete a transaction before the passcode expired.
In my opinion, the american banking industry prefers to accept the risk of loss due to fradulent transactions to the on-going costs to support a token-based authentication system. Today, the risk of loss to the bank is mitigated by the legal requirements providing different rules for consumer versus business banking. I find the lack of two-factor authentication requiring “something you have” instead of goofy security questions to be misguided, at best. In the end, the risk of loss is carried by consumers via higher prices for goods and services, so perhaps the rules covering business banking need modification to align with the current protections for individuals.
A couple of points. In many, if not most, banking applications the token challenge is still done at a service level or login such that once you enter the service, say ACH, you don’t need to enter another token. So, one good token is all that is needed.
Perhaps more interestingly the 60 second rule isn’t really 60 seconds for at least one token vendor. There are normal variance windows that extend the life of the token to 2 minutes. This helps account for the normal token drift that takes places as the synchronization between the server and the token occurs. Special situations, that include infrequent users variance, can extend the life of a token code to 10 minutes or more.
So, if one token code establishes the connection and the system allows multiple transactions, then the biggest weakness is session length. This weakness is easy to mitigate via session time-out. I have several banking institutions with short session-time out which is not offset by activity. What session time-out do you recommend as a balance between security and usability?
“However, for a successful attack, the Bot must be able to enable the transaction to occur before the passcode expires.”
A bot is a computer program and works at electronic speed. As one possibility, it could have set up an alternate transaction, and be waiting to pounce on the 1-time code as the user types it in. Or the bot might do everything in a burst in a fraction of a second.
Anyone with bot-in-the-middle access has a wide range of strategies from which to choose. For example, the bot and attacker surely have the account number and password already, and might be able to reconfigure limitations or notifications or phone numbers.
If reconfiguring the account needs the dongle code, that might be the first thing the bot does. Then it might show the user what seems to be the bank error-response page saying something like “please get a new code and try again.” That page will, of course, appear to be SSL-protected, so who would doubt that it really came from the bank?
“I find the lack of two-factor authentication requiring “something you have” instead of goofy security questions to be misguided, at best.”
Bots DEFEAT 2-factor. Insisting that banks work to add 2-factor “security” which is now known to be broken needs a re-think.
There may be cases where 2-factor apparently would have helped. But in many of those cases, the attacker could just have gone on to a different strategy and won anyway.
In the current situation, adding 2-factor authentication would drape the delusion of security over the bank, customers, manufacturers and courts, while letting thefts continue.
The bank will never be able to completely secure the transaction from their end. It’s simply not possible as long as the customer is assumed to be compromised.
The best the bank can do is assume the customer is already compromised, and add as many layers of security as they can. Tokens, MFA questions, IP whitelists, ACH calendars, and time restrictions can all be used to add layers of security without excessively impacting the customer.
I still believe that the best form is an out-of-band confirmation for any transaction which does not fit the customer’s typical pattern. If the customer sends payroll out the 1st and third Thursday of the month, the bank should be contacting that customer prior to sending the transaction if the payroll batch does not fall on those days. If their Core software does not have the capacity to do this built into it, then it’s time to switch systems.
Hi Ben!
I am not sure, but there are a couple of things about this which do not feel right to me:
“The best the bank can do is assume the customer is already compromised, and add as many layers of security as they can.”
1. Security by Layer. I wonder if it is really true that just adding layers of partially-effective security actually helps. It seems to me that in many cases the attacker could steer the attack through whatever holes exist at each level, at modest inconvenience.
It seems to me that the security advantage of a “layer” comes when it can stand alone against a full attack when another layer is breached unexpectedly.
2. Assume Compromised Security? I think there is something odd about assuming a bot exists and then trying to get around it. Granted, there are many practical problems, but finding a way to apparently authorize each single transaction is not the same as having secure online banking.
How can it be a success to authenticate a transaction, when the attacker has every keystroke, id and password that goes out? Is it really OK that all that information goes to the attacker? If so, why bother with passwords in the first place? Let everybody forgo passwords, but if that is a problem, having a bot inside the online banking service is not something we can assume and just get around.
I guess one could argue that passwords are just one layer of several. But I would argue that we have to fix broken layers before we can again call them security layers. If an attacker has id and password, we need a new id and password, and, by the way, NO BOT!
I cannot see how banks can provide secure online banking in an environment where customers have bots. This is completely independent of authentication.
This all speaks to the first two Immutable Laws of Security:
http://itknowledgeexchange.techtarget.com/security-corner/10-immutable-laws-of-security/
“Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore“
We tend to take the programs and utilities we run for granted. We trust them to work as advertised and not harm our systems or corrupt our data. What we often don’t consider is that our computer is being controlled by the programs it’s running and those in control of it are the programmers who wrote the software. This isn’t a problem with normal software since we tell it when to run, what data to manipulate, and when to quit; we are able to exercise a measure of control. We still “own” our computer. With malware, “To run or not to run, that is the question” and those are our only two options.
Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore
As in #1, there’s a degree of trust that the operating system is doing what it’s supposed to be doing. If the OS is altered by a bad guy, then it’s doing his bidding, not yours.
All of which comes back to an ounce of prevention… 🙂 Oh, nevermind, why do I bother….? (Tired of beating my head against the wall) You can lead a horse to water… 🙁
My comment was in regards to the Hi-Line case specifics. Although it is possible for a Bot to do the things you describe, in this case the bogus transactions did not occur immediately. In fact, they did not occur on the same day.
You state that Bots defeat two-factor authentication. I agree it is possible for Bots to defeat two-factor authentication. Please provide some references to actual cases where this occurred.
@Rick Tuttle:
“I agree it is possible for Bots to defeat two-factor authentication. Please provide some references to actual cases where this occurred.”
Is that a trick request? I thought I had already done that. Are the links in my article:
http://www.ciphersbyritter.com/COMPSEC/BANKMALW.HTM
somehow unclear or insufficient? Here are some:
http://www.securelist.com/en/analysis/204792107/ZeuS_on_the_Hunt
http://www.zdnet.com/blog/security/modern-banker-malware-undermines-two-factor-authentication/4402
http://www.gartner.com/DisplayDocument?id=1245013
http://krebsonsecurity.com/2010/06/e-banking-bandits-stole-465000-from-calif-escrow-firm/
These articles do tend to be general, possibly since specifics may expose particular accounts. Also there may not be much 2-factor going on, relatively speaking, so most failures will not yet be 2-factor examples. But even one example is enough to open the eyes, because 2-factor is supposed to be unbreakable. Will you not take this seriously until everyone uses 2-factor and the failures become undeniable?
The main problem is a bot-in-the-middle inside the customer computer. The secondary problem is not having a test guaranteed to expose that bot.
Having a bot is something like asking an enemy to do for you everything you want done. Is it really true that giving your account numbers and passwords to an enemy can screw things up? Yes. Is it really true that a 2-factor dongle value can be taken by the enemy and used for their own nefarious purposes? Yes. Exactly what part of this is controversial?
The amount of victimhood with these cases is unreal. Hi-Line seemingly did nothing to protect its computers from malware and then blames the bank for their own lack of diligence. I am tired of that tune.
It’d be nice if banks could look at every single transaction that goes through, but service charges would be $100 per month. It’s clear that people are not aware of the transaction volume that goes through banks these days.
Hi Carl. I don’t know how familiar you are with the way the majority of the smaller banks deal with online banking, but they generally outsource most if not all of the process to a third party company. That company may or may not even offer the ability for banks to peer into the transactions for anomalies. In fact, I’ve found in my reporting that most smaller banks do not even have the option from their service provider to provide the service, should their customers want it.
Hi, Brian – I work in anti-money laundering in a small almost medium-sized bank and have also worked in larger institutions in the same field.
We do outsource some of the technology platform, but we do not outsource the fraud prevention. My point is that we do what we can to find anomalies, but there is no way we can look at each of the thousands of ACH transactions that go through every day. We do our very best to stop any fraud – We detest seeing it, whether it is our loss or the customer’s loss, but we cannot stay in business and look at every transaction.
I have found that the so-called victims in these crimes are incredibly negligent, considering they are managing a business with assets. It’s somewhat understandable with normal consumer online banking, but it is hard to fathom the lack of accountability from small business operators.
Aside from the suggestions to use a non-Windows computer or Linux boot CD and two-factor authentication, I don’t read a lot of ideas on what to do to mitigate the risk of fraudulent transaction due to manual on-line banking. Put yourself in the role of consultant to the bank. What would you tell bank managment they should do to achieve a real improvement? Are there practical technological methods you think are worthwhile and available? Are there human factors that can be tapped to improve security at either end of the connection?
“What would you tell bank managment they should do to achieve a real improvement? Are there practical technological methods you think are worthwhile and available? Are there human factors that can be tapped to improve security at either end of the connection?”
Online theft may seem like a small problem for bank management, in that their losses may be greater from other problems which they also cannot solve or control. However, one might question spending big bucks on security software that ultimately cannot work. Shift the bucks to expanding the drive-thru for business customers who cannot handle Linux.
Not everything in life has to be perfect, including authentication. There is, of course, no perfect security. However, if the only time authentication works is when an opponent does not care, it is not really working at all, it just seems like it.
The main problem is a bot-in-the-middle inside the customer computer. The secondary problem is not having a test guaranteed to expose that bot. The problem for the bank is that the bot is not in their computer, and there is no way for either party to know if a bot is there. Because of the risk, it is important to assume the bot *is* there.
I have become convinced that there can be no form of acceptable technical solution as long as the bot exists. Oh, you may be able to authorize a transaction, but the attacker will get all your account numbers and passwords and everything else on the computer besides. There is no way that can be an acceptable online banking arrangement.
The technical solution is to do whatever needs to be done to guarantee the absence of a bot on the customer computer. That runs from “do not bank online,” through “only use our custom hardware to bank online,” and “only use our custom software to bank online” to “only use a Linux LiveDVD to bank online.”
Technical improvements on the bank side may involve improved ways to detect and delay unusual payments pending confirmation. That probably would be by phone, although if the bot can change the phone number the bank has for the customer, phone confirmation will not help. So customers need to come to the bank to change their phone number and other account controls.
Some computer education might help improve the odds, but will not solve the problem. Even an expert can get a bot, and not know. That is the crux of it.
I like the concept of “only use our custom hardware”, if it is both practical and affordable. I have seen marketing for “an office on a USB stick” device (www.checkpoint.com/products/abra/).
Perhaps such technology can eliminate the Bot in the middle attack. Such a read-only device would be practical only if Joe User can plug it in and make it work – AND – it truly elimnates the Bot in the middle.
If standardization on such a device means that one device will work with all banks, then perhaps volume adoption reduces the cost so that the banking industry expense to deploy the devices is less than current losses – THEN – it also becomes affordable.
I guess I need to write more specifically.
What I meant by “only use our custom hardware,” was some sort of sealed computation box which communicated to the bank on broadband using only a secure subset of protocols. Because of the obvious danger inherent in our current concept of “operating system,” perhaps there would be no OS, and perhaps not even multiple programs.
While hardly in the same security category, one might consider a minimalist netbook without a hard drive, with something other than an x86 processor, running only bank-provided Linux and updated automatically.
The USB approach has various commercial examples (e.g., IronKey.com), although those generally require special hardware, and it is unclear to me that any such approach can possibly be as secure as they claim when running on an infected PC.
Trusteer Rapport software seems like a better way to get at detecting and killing the bot (not recovering damage), but seems almost like a good-guy bot itself, which is a little scary.
The general idea of putting Linux on a flash drive then booting from that drive, while much better even than a dedicated PC, still opens the door to infection. The flash must be writable in some sense, just to handle the endless browser updates. And allowing a hard drive adds much more insecurity.
My conclusion is that SMALL BUSINESSES SHOULD STOP BANKING ONLINE…
…unless they use a Linux LiveDVD.
I use Puppy Linux because it can update the browser on the boot DVD+RW easily enough to make that practical (and hard enough to make it unlikely for a bot to use).
I have used neither of the mentioned USB devices to understand the potential risk from an already infected host. To me, such a device only makes sense if it IS the boot environment, and it IS isolated from the host operating system. Isn’t that essentially is how any Linux Boot disk functions?
Again, I have not use the Linux Boot disk method to communicate with banks. The only downside that immediately comes to mind is the write limitation IF the Linux environment is completely isolated from the host hard-drive. I like to create transaction confirmations, which I currently output to an Adobe PDF printer and save locally. I use them as part of the monthly account reconciliation process.
Finally, perhaps Small Businesses should avoid on-line banking. The key to making this decision is for the owners to understand the risks and mitigation methods available, and for them to engage with their bankers to determine who owns the risk. At that point, they have three choices: 1. Cease on-line banking; 2. Accept the risks, as limited by mitigation technology and business practices; 3. Insure against the risk (usually in concert with choice 2)
What should banks do differently?
How about this, spend some money educating their customer base about the fact that password information can be stolen from your computer and your accounts drained with impunity even using the utmost care. That’s a fact, depending on what bank you use and there is no uniformity among what security measures banks are required to employ.
Smaller, regional banks spend millions of dollars to attract customers from larger banks who, in most instances, have more sophisticated online security measures for their customers.
I think the answer to the question above is: don’t sell a product that can hurt the user without taking reasonable steps to warn about the ways to prevent theft/fraud and the possible ramifications.
Product manufacturers have had to adhere to this standard of care for hundreds of years, so why shouldn’t a bank? The difference is lawmakers have afforded banks so much legal protection, banks can entirely ignore the risks associated with online products entirely in their marketing materials and promotions and can selectively push the pluses and conveniences with no recourse. How is this a fair balance and why should banks get a free pass?
Finally, even you don’t agree with me, take a look at what the Banking industry’s own Federal Financial Institutions Examination Counsel has been saying since 2005. The FFIEC said that Banks need to audit their customer base to find out what the customers’ awareness is about the dangers of online banking as well as continually assess the strength of authentication methodologies in light of the awareness of the banking industry’s customer base. This requires banks to spend money on educating their customers and adapting security measures to address the shortcomings. To the extent they can’t address the shortcomings in available security measures, here’s a novel idea: TELL THE CUSTOMER THE RISKS. Banks don’t do that because they don’t have to. Instead, many Banks spend considerable money telling their customers just how safe their online banking product are.
I would ask the following question rhetorically: “What if the banking industry knew that was needed, the FFIEC was telling banks they should do it, but the banks completely ignored these recommendations?” Do you still think Banks bear no responsibility.
I would submit to you that it is up to people like the subject of the article above to do something about it.
I’ve been reading this series of articles from Krebs for a long time, and I appreciate the arguments on both sides of the fence (bank responsibility vs. end user responsibility).
But, with all that said, there are some very basic and low cost steps that a bank could take to dramatically cut down on this type of fraud. The most obvious one I can come up with is:
(1) Allow the account owner to specify that NEW PAYEES can only be added in person at a bank branch.
There’s typically no harm done in allowing payments to EXISTING payees via online banking. It’s the NEW payees that are always fraudulent.
As a business owner, I would have no problem driving over to the local branch on the rare occasion that I need to add a new payee. But, perhaps the problem with this idea is that the banks want to keep their account holders out of their local branches as much as possible.
I am neither a bank nor a business owner, but enjoy Brian’s blog and the readers’ comments. I am extremely impressed with their courtesy and civilty. Most make logical arguments and some state their positions so well that I am honestly undecided whether to vote up or down, even if I don’t necessarily agree with them.
Brian, I attribute the demeanor of your commentators in part to the even-handed, factual, and civil tone you set in your essays.
You are much appreciated. Thank you!
Thanks for the nice comment, John. I do try to keep an even keel around here, and you’re probably right that it does set the tone. Better yet, the readers here don’t seem to tolerate blowhards, trolls and fools very well, so that kind of takes care of that too 🙂
I hope I’m on Brian’s and John’s list of the civil! 😀