Slashdot Mirror
Washington Post Says Use Linux To Avoid Bank Fraud
christian.einfeldt writes "Washington Post Security Fix columnist Brian Krebs recommends that banking customers consider using a Linux LiveCD, rather than Microsoft Windows, to access their on-line banking. He tells a story of two businesses that lost $100K and $447K, respectively, when thieves — armed with malware on the company controller's PC — were able to intercept one of the controller's log-in codes, and then delay the controller from logging in. Krebs notes that he is not alone in recommending the use of non-Windows machines for banking; The Financial Services Information Sharing and Analysis Center, an industry group supported by some of the world's largest banks, recently issued guidelines urging businesses to carry out all online banking activities from 'a stand-alone, hardened, and completely locked down computer system from where regular e-mail and Web browsing [are] not possible.' Krebs concludes his article with a link to an earlier column in which he steps readers through the process of booting a Linux LiveCD to do their on-line banking." Police in Australia offer similar advice, according to an item sent in by reader The Mad Hatterz: "Detective Inspector Bruce van der Graaf from the Computer Crime Investigation Unit told the hearing that he uses two rules to protect himself from cybercriminals when banking online. The first rule, he said, was to never click on hyperlinks to the banking site and the second was to avoid Microsoft Windows."
Unless your browser is listening for incoming connections, or your bank is running third party banner ads(in which case, switch right the fuck yesterday), does a browser vulnerability really matter?
If you are using the LiveCD as a dedicated banking only environment, the only input your browser will see is your bank's website. If you can't trust user behavior, and want to really be sure, you could have it set to reject anything that doesn't have the bank's SSL cert. If your bank wants to 0wn you, you are already doomed. If no other site can reach your browser, your browser cannot be owned, no matter how buggy.
You realize that the way two factor security is supposed to work is that is requires you to know something and have something right? The way that two factor security is usually done from what I've seen is requiring a password that the client knows and a rolling code from a small device the client has. As long as a bank does not allow that same rolling code to be used twice it doesn't matter what kind of keystroke logging, mouse gesture capturing, or screen recording is used nor how fast it is sent to the bad guys.
For you car enthusiasts, it's like taking the engine with you when you leave the car. Even if the car is hot-wired, it's not going anywhere without that thing you still have.
A bank with any technical savvy would be immediately preparing a LiveCD/USB distro that boots as quickly as possible into a browser pre-configured with the bank's portal page set as the home page. The distro would contain nothing extraneous -- just enough for fast, safe banking. It would, of course, be thoroughly branded, but completely legit vis a vis source code and license notices. Give them away in the mail, or even sell USB drives.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
And how would an n-factor authentication scheme help when software on your computer is logging keystrokes, mouse gestures, and capturing images of your screen and then sending them near realtime to the bad guys?
The way it works here with some banks in Australia is they send you a code via SMS when you try to issue a transfer from Internet banking. You need to enter the code into the website to continue the transaction. So the extra factor here of having the phone offers a pretty useful extra layer.
My bank doesn't offer it; I wish it did.
Per TFA, the banks in the two cases mentioned in the summary used two factor authentication. The hackers' malware delayed their access, and the hackers used a VPN tunnel to access the bank through the compromised computer.
Understanding the scope of the problem is the first step on the path to true panic.
This can be automated easily enough.
Also, it's trivial to redirect the POST to login.cgi or add an entry to /etc/hosts for bank.com to a different site that just presents a 'failed to login' instead of logging in. Meanwhile your password, security code etc has been sent off to the bad guys machine which does an automated "transfer *.* funds to x" script using these credentials.
It's been done.
I.O.U One Sig.
True, but it doens't have to be that expensive to do right. My bank offers two different solutions for the second-factor. One is s crypto-key tokenthing that they send you to hang on your keychain. (so you log in with a password + a 5-digit security token from the gadget)
The other is, quite simply your mobile phone. You enter your username and password, if correct, they send you a SMS with a 5-char one-time-password, you enter this and are in.
Yes, it adds 10 seconds to the login-procedure, but it's a very efficient way of stopping keyloggers and malware from learning how to access your account. Even if they successfully snoop your password, that doesn't help them aslong as they can't ALSO intercept SMS-traffic to your cellphone. This isn't IMPOSSIBLE offcourse, but it sure as hell raises the bar.