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."
Its not just "linux vs Windows" but "trusted boot": All you need to rely on is that the live CD is OK and your BIOS is not corrupted and you can effectively safely connect to your bank.
I use it myself for my Schwab account, with the added bonus of there is enough math to show active traders lose big, so don't trade active, which goes into play here.
Test your net with Netalyzr
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.
sigh. Just off the top of my head I can think of about a dozen attacks one could direct against a bank user who thinks they're bulletproof because they're using a Linux LiveCD. For example, booting off a LiveCD won't save you from the truncated SSL cert attack that was demonstrated in the direction of PayPal the other day.. only having an up-to-date browser will do that. Encouraging people to use unpatched known-vulnerable software to do their banking just so they can avoid malware on their regularly patched machines makes no sense at all. Of course, that's the extreme case.. suggesting people use a LiveCD of Linux instead of an unpatched copy of Windows XP SP1 is a different kettle of fish.
How we know is more important than what we know.
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.
My battery is dead, you ignorant clod!
Actually, something like that happened at the Montreal Casino. The machines were shut down every day, so they would end up generating the same sequence of numbers. A guy named Daniel Corriveau noticed, played the numbers, won $600,000.
He initially claimed that he used chaos theory, and the casino claimed it was a bad random number generator. The reality was that the cmos batteries had been removed during development to make testing easier, and nobody put them back in, so every day, they started with the same seed. Simple incompetence. They paid the money after 2 weeks.
Wrong.
Security tokens store internally a crytographic key or a one time pad. It is mathematically impossible to find out what the secret key/OTP is on these devices from readouts on the display. You have to steal the device and read the bits using an electron microscope. Even if you could do that, it would be very difficult to create a cloned copy of the device and return it to the owner's possession in any length of time.
Thus, the inherent security is obvious : in order to break into an account protected by a keyfob, one absolutely HAS to steal the actual keyfob. That vastly limits the vulnerability : if the user still possesses the card, they KNOW they haven't been hacked to 99.9999999% certainty. Furthermore, only individuals who come in direct contact with the user have a chance to steal the card, and they cannot do so secretly - you could freely give your credit card to a waiter at a restraunt and have him use the keyfob with the secret code displayed, and know that the card could not have been skimmed.
And, of course, the moment the user of the card notices that it is missing, he can call the bank and cancel it and ask for a replacement, eliminating any further losses. If your account information had been compromised, you might not realize for month(s).
I will agree with you on "something you are" authentication. Even if you owned some kind of biometric reader and used it to log on to your bank, it is not any more secure than a password because a fingerprint or DNA sequence is a static piece of authentication. Well, ALMOST....
Theoretically, using technology not yet available, you could give the bank a sample of your genetic material and essentially have security whereby the bank asks your home DNA scanner "give me n->Z portion of the user's genome". This would only be a practical security measure if whole genome sequencing were still very expensive.
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.