Washington Post Says Use Linux To Avoid Bank Fraud 422
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."
What about the banks? (Score:5, Insightful)
A little two factor authentication would be nice to see in American banks. Passwords just aren't adequate any more.
Re:VM? (Score:5, Insightful)
Because as the author explains in the comments, key loggers can run at the low level device driver level. At this level, it can hook key presses in a VM just as well as the host OS.
It's a pain, because nobody wants to go to the trouble of rebooting twice for the sake of paying a few bills. But it's the only way to be sure of a clean environment, unless your BIOS has been hacked. It's at least one good argument for the trusted platform, TPM, or whatever it is. In theory you could be sure that you are running only un-altered digitally signed executables and nothing else.
Alternate Headline (Score:5, Insightful)
"Washington Post Urges Thieves To Distribute Linux LiveCDs"
A few racks full of CDs in a highly visible place, or even cheap preloaded USB drives delivered right to the mark's front door along with a friendly letter explaining how running Linux would help improve security and thwart The Bad Guys could make your job of stealing from the clueless even easier than before.
Re:What about the banks? (Score:2, Insightful)
Countrywide had a nice system.
I had to enter my user name, and then then the password screen came up, I would type in my password, and then click on one of about 40 images on the screen.
I had to click the one that was my image (this was rather than a sign in button).
Also, I think a security token can count as a second factor of authentication, and I agree on security questions, never help at all, and often I can't find options with an obvious answer (for myself).
Re:What about the banks? (Score:5, Insightful)
A little two factor authentication would be nice to see in American banks. Passwords just aren't adequate any more.
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?
If your computer has been compromised in this fashion, you've already lost. For you car enthusiasts, it's like adding additional locks to the car doors -- it doesn't help if the windows (haha) are already broken.
Re:What about the banks? (Score:5, Insightful)
Re:VM? (Score:5, Insightful)
That doesn't solve the "but joe user doesn't want to reboot just to get to his overdrawn checking account" problem; but with real computers routinely showing up for $300 and lower, it isn't exactly an extremist position to suggest banking from dedicated hardware for any nontrivial amount of money.
Re:Just Linux? (Score:5, Insightful)
I think the point is Boot CD, not Linux.
This would preclude any with an intelligent GUI (actually I am quite fond of Gnome at this point, but that wasn't what you meant).
If I am correct, using a Linux boot CD would make sense for Linux users too.
Re:terrible advice (Score:3, Insightful)
Ya, it stops key loggers, and that's great
Yeah, it is great, because a huge part of on-line fraud is from keyloggers. Modern ones even record 'screencast' movies of you using your computer.
but it aint going to do much for your browser security unless you keep your LiveCD up to date
Between booting up and getting a DNS record for your bank how are they going to exploit a browser security problem? You could safely use unpatched IE5 to do online-banking. There might be some null-prefix type problems, but in reality going directly to your bank's site is pretty hard to get in between.
who says your CD burning software isn't infected - implications on trusting trust and all.
There are lots of different CD burning software, lots of different distributions, lots of AV software that might detect the modifications, and high risk of some paranoid geek with sha1 finding it out. Compared to just setting up a 'enter your password and win a free chocolate bar' site, it's not cost effective to do this.
Re:terrible advice (Score:5, Insightful)
Browser security is only an issue if you're visiting other sites, in the same session, on the same boot, on your LiveCD. Browsers on LiveCDs don't magically download malware from the internet by themselves - you have to direct them to. And most conventional malware must install itself - which won't happen on a LiveCD. There are a very few flash/js based attacks that work live in the same session - but really, if your either (a) your bank has third-party inline flash ads or (b) you don't trust java content from your bank's own website, then why are you banking with them online?
And going as far as questioning whether your CD burning software is infected is ridiculous. You can't be any more certain that your mouse doesn't have imbedded circuitry tracing your movement pattens, or your keyboard doesn't have a keylogger built directly into it, or the aliens aren't tapping directly into your cablings electromagnetic intereference patterns to directly access your bank account as you do. You're going to extremes purely for the point of argument, but although it may have passed you by, it was established several thousands years ago that "nothing is certain".
If you can imagine up scenarios like malware built into your cd-burning software specifically to target LiveCDs being used for online banking, I can't fathom how you trust a banks own employees enough to actually keep your money with them instead of under the mattress.
The browser may be out of date (Score:3, Insightful)
Devil's advocate: Deepfreeze? (Score:5, Insightful)
Devil's advocate here:
Of course, a diskless system running Linux would reduce the chance of malware on clients, but perhaps if a company is dependent on Windows, almost as good security (and I state almost) would be obtained from denying admin access and using something like DeepFreeze, Windows SteadyState, or similar?
Combine DeepFreeze with AppLocker, some decent enterprise antivirus utilities, BitLocker, and the usual physical and BIOS protection on a machine, and one can make a decently locked down terminal that can cleanly run Windows apps. Should additional software be needed, no need to install it, just use something like VMWare ThinApp and have it runnable from a central location.
There is nothing wrong with a diskless system and booting from a CD-ROM. However, unless one creates a custom image with reliable enterprise level auditing tools, it becomes difficult to extract data from a group of PCs (and this is important for larger businesses come tax season, or regulatory compliance), and it is definitely an issue to add or update software without a reboot, unless it is a precompiled binary on a central server that people run.
Also, instead of running live CDs, why not consider going to a vendor like Wyse and going with truly thin technology? This way, there is little to no fiddling with the client side. If a thin terminal has a problem, just swap it out for another one, chuck the old one in the RMA box and be done with it. This is arguably a lot easier than the cost for maintaining standard PCs [1].
[1]: I'm primarily intending enterprise level here. For some SMBs, it is a lot cheaper to go with a boot CD and a generic PC, but for larger companies, it may mean more futzing around with stuff for their IT staff, especially on the scale of thousands of endpoints. If I had a startup with a call center of 5 people, PCs are a lot more economical. However, 500 to 1000 people in a non-technical call center, then I'd take a serious look at thin terminals and a beefy internal network fabric.
it's not a matter of Linux vs. Windows... (Score:3, Insightful)
Also, honestly, how many people do you think check the MD5 sum on an ISO? Hell, I've never had a RedHat/Fedora disc that passed its self-check. I gave up on that ages ago.
Re:What about the banks? (Score:4, Insightful)
mostly because it's cheaper than doing it right.
Of course it's cheaper than doing it right. They've managed to twist bank robbery do to their lack of adequate security into identity theft that they blame on the costumer and force the costumer to suffer all the financial consequences. It's the perfect scam. If you walk into the bank with a fake id and steal money it's never been blamed on the costumer.
Re:What about the banks? (Score:5, Insightful)
Though I agree two factor authentication is useful, the 'taking the engine' analogy overestimates the difficulty of breaking through it.
All the scammers have to do is instead of recording your keystrokes, gesturing, etc., they display a 'fake' copy of the bank to you through whatever software they have installed on your computer. They take the information you think you are sending to your bank (but are sending to them instead) and instantly have their scripts login to the site from their own systems (or some other bot on the net).
If they prevent your initial login to the site from happening, they can use your username + password + rolling code themselves if their software auto logs in.
This of course requires a user to go to a phishing site (miscellaneous.scammersite.com or something more complex), or requires the phisher to own the user's computer enough that they can intercept their connections & deal with the SSL certificate issues) while the phisher's automated software automatically goes to the real miscellaneousbank.com site.
Re:Alternate Headline (Score:3, Insightful)
The only real solution is to make banks liable for online bank fraud, just like credit cards are liable for credit fraud. The customer has to pay $50, the bank covers the rest. This is really the value of credit cards. You are using someone else's money, so they take the risk. Once it is your money, your are at risk even if the banks security is at fault.
Re:What about the banks? (Score:2, Insightful)
If your computer has been compromised in this fashion, you've already lost. For you car enthusiasts, it's like adding additional locks to the car doors -- it doesn't help if the windows (haha) are already broken.
What's the computer equivalent of the "This car protected by Smith & Wesson" bumper sticker?
A Penguin.
Seriously. Because it doesn't matter what OS the computer is running, no matter how badass its security model is, when you have PHB's at the keyboard. Same for the Smith & Wesson: no matter how badass the gun is, that security is only as good as the guy with his finger on the trigger.
Re:VM? (Score:5, Insightful)
What about a Windows XP Live CD?
"Sir, there are some gentlemen here who say they are from an organization called the BSA. They want to see the license certificates for those Windows CDs we've been handing out..."
Comment removed (Score:4, Insightful)
Re:What about the banks? (Score:1, Insightful)
No it doesnt. You have to type in the code. On.an.infected.machine. The bad guys can STILL see that.
Read the lock analogy above. If you have an untrusted endpoint, no matter if you had a token, smartcard, sms message, or even other "2 factor methods" like geolocation, encrypted cookies, or velocity/risk weighting you would get hosed.
BTW, the bad guys can still screw you over because 1. Javascript based attacks to own your browser 2. they can still get your underlying data, because livecd's usually mount your disks. 3. Livecds are not updated much, so they grow stale, and susceptible to attack.
Re:terrible advice (Score:3, Insightful)
How does those malware affect live Linuxes?
Re:What about the banks? (Score:5, Insightful)
Because a 2 factor authentication token like an RSA key changes every 10 or so seconds so by the time Bad Guy #1 has finished parsing that log the 2nd authentication factor is out of date. The far cheaper way of doing this which most banks in Australia have started using is a one time password sent to you via SMS. This password works one time only (hence we call it a one time password, geddit) so if the Bad Guys(TM) get the entire password in real time and are reading their logs in real time then they still cant use it as the password has already been used.
Yes it's a band aid solution but at least it's a decent kind of band aid. The alternative is complaining that it doesn't work and then having nothing happen because no one has a better practicable idea.
Re:Non-random bits on LiveCD can compromise securi (Score:5, Insightful)
Not Linux. Randomness comes from the time (hardware, persistent), but also from the randomness of network traffic and other driver miscellanea such as HDD head seek times, mouse movements, keystrokes, CPU temperature data, electrical noise on the power supply (with the right hardware)...
I can't say for sure, but I think Linux actually has the most secure random-number generator of any OS - excluding dedicated hardware. Enough that it can probably be fairly called true RNG instead for PRNG, as long as you use /dev/random instead of urandom.
Re:What about the banks? (Score:0, Insightful)
People dont seem to be thinking about this properly. It doesn't matter how many factors you have of authentication, (or whether one of those factors was SMS'ed to you) you are entering them into your computer, which if compromised, will allow a smart attacker to act as you.
Example:
1) User goes to log in, enters his username and first password, gets the 2nd code from SMS or token generator etc.
2) User enters 2nd code to log in.
3) User gets delivered a 'please wait' page by malware, while his username, password, and valid token code are sent to the waiting hacker, allowing him to log in as the user before the timeout occurs.
There is no way to prevent this that I can see as long as the information is being entered into an invalid PC. The only possible way I can think of to bypass it would be by using SMS but requiring the user's registered cellphone to text (not receive) one of the codes to the banking authority - this would mean that at least one password travels across a system that is (hopefully) not compromised.
Please note that step 3 may not be as obvious as that anyway - the hacker could easily cause the users PC to hang or reboot and he'd just blame Windows, while the hackers merrily log on and steal what they can.
Re:What about the banks? (Score:5, Insightful)
And do you realise this authentication scheme has also been broken?
The crooks these days are breaking into your account in real-time by using your security token code as you login, and preventing you from logging in.
Read the article, he mentions this.
Re:What about the banks? (Score:5, Insightful)
None of this will work with the problems described in the article, if someone has control of your computer then you're screwed no matter what kind of authentication you have. In one of the examples they specifically stated that crackers used the token code and delayed the customer's request:
So, instead of the cracker getting blocked the customer would have been blocked because the "malware" made the customer's request come in AFTER the cracker's. If you were really clever you'd program the thing to intercept all the communication before it gets encrypted to go out to the bank and then fake the returned data so the user doesn't know that you're toying with them (yes, you can intercept the crypto library calls - I toyed with this some to get the Red Alert 3 Beta working on Wine). I don't know about you, but I can't think of a solid way around this interception (except having the bank only allow logins from a special custom browser that they load on a Live CD).
Re:What about the banks? (Score:3, Insightful)
And it will stay that way , Mr Balmer, as long as you don't release it.
Good one. That was the same story we heard when XP came out. Yeah, yeah, Windows 7 is all over that now.
For about six months.
Re:What about the banks? (Score:3, Insightful)
None of this will work with the problems described in the article, if someone has control of your computer then you're screwed no matter what kind of authentication you have.
That's not entirely true. If there is some sort of challenge-response scheme that involves the "what you have" part of the authentication (either by a lookup in a table of single-use tokens or by typing the challenge into a security token-like device) and the challenge is based on what the user is requesting to do (ex. the user explicitly types the amount and target account number into their security token and then feeds the response into the website), then you can avoid unauthorized transfers even from a compromised computer.
Of course, it would be best if computers weren't compromised, and booting an OS off a CD is good way to be relatively sure of that, but, realistically, most bank customers are going to be using computers with some amount of malware on them for the foreseeable future.
No it isn't (Score:4, Insightful)
So in the case of a properly designed security token, it ISN'T just data on the Internet. The reason is that it isn't as though the "something you have" is a card with a number on it or the like. If that were the case then yes, discover the data and you are good. However they don't work like that. There are two related systems that I've seen:
1) A card that gives you a number. What happens is when you want to log in, you push a button on the card/device and it hands you a number. However the number isn't fixed, it changes with time. You need the right number for the right time. The way it works is a crypto system. It uses the time and a key in the device to provide the output. The other end then can calculate the correct number needed. The only want to get the number is to have the device, or find out what the key is on the particular device.
2) A challenge/response system. Here you plug in a USB key or smart chip. The device you are connecting to then sends a challenge to your device, usually something in the form of "Sign/encrypt this message." Then again, public key crypto comes in to play. Your device encrypts the challenge or signs it or whatever and sends it back. The server checks that result against what it ought to get. If the answer is right, in you go.
In either case, the only way to get the data is to either find out the key, or to get your hands on the device. A simple intercept won't do it.
As for your "gun to the head" thing, well of course that gets around it. There is NO SUCH THING as perfect, unbreakable security. I think some geeks delude themselves in to thinking there is because you can build a computer that is at least seemingly perfectly secure. However in the real world there is no such thing as perfect security. There is only security that is better than what anyone is going to try.
I mean I can secure against your gun to my head thing: I hire armed, trained, guards. You try to come at me with a gun, they take you out. So you can counter that, you get trained snipers to kill them at long range. So I counter by traveling only in secure armored vehicles, so you counter by kidnapping my family, so I counter by securing the too, and so on. However at some point, I got past what you could reasonably do, and more importantly what you'd reasonably do. In fact, with good two factor authentication, I am already past it. You will not come and put a gun to my head to get at my bank account. The money isn't worth the risk. So I don't need to worry about that kind of attack. My security is good enough.
That's all it is ever about. That's even what it is in the case of extreme security. The government does not delude itself in to thinking that having tons of armed guys around, say, the CIA headquarters makes it impervious to attack. There are always ways to attack it. So why bother? Because it makes it impervious to any attack that anyone might actually be able to try to pull off. Yes, in theory you could find a way to kill all the guards, take the right people hostage, etc, etc. In reality, you couldn't even come close, you know this, and thus you won't even try.
It is secure against REAL threats, and that is what matters. Same deal applies to your bank account, however since you are protecting a small amount of money and not national secrets, two factor authentication and some vigilance on your part will suffice, armed guards are not necessary.
Re:Free Software not Linux (Score:3, Insightful)
Most distributions still include binary blobs in their corresponding source code that can bring the kinds of problems for which Microsoft Windows is advocated against in the article.
You won't find the word "proprietary", "open source", or "source code" in the article. The reason Windows is advocated against is simple: Malware is written to target Windows. Malware could as easily be written to target any operating system which is vulnerable.
Thankfully at this point, you can get machines that run a free bios, support wireless, and run 100% free software.
And 100% proprietary hardware, unless you've got schematics for all of it.
Never mind that you're connecting to a webserver running the bank's proprietary software...
Thankfully at this point, you can get machines that run a free bios, support wireless, and run 100% free software.
Which you've of course scrutinized every single line for security vulnerabilities... ...what's that? You haven't?
Why is it that you think free software is inherently more trustworthy than proprietary software, in that way? Or that the binary blobs in question are inherently compromising your security?
And, conversely, if you're a valuable enough target that you can afford to (and should) scrutinize every line, wouldn't you also have a budget to enroll in Microsoft's "Shared Source" program, and gain full access to the Windows source code, also?
No, you're right, there's nothing special about a "Linux LiveCD". But the magic word here isn't Linux, or even the implied "Free Software", but "LiveCD". From the point of view of the article, it could be a Windows PE disc, it's just that Linux CDs are free (as in beer), and Windows offers no real advantage in an environment which will only run a web browser.
I agree with many of the goals of software freedom, and I agree a solid open source process can yield more robust software than a closed one. But not every article with the word "Linux" is an appropriate place to bring it up. You sound kind of like this guy [bash.org].
Re:VM? (Score:1, Insightful)
What if you randomised the virtual keyboard layout each time it was displayed?
That, or just run native fucking Linux. The world will come around, don't worry, you won't die without Office.
Re:What about the banks? (Score:2, Insightful)
There is no way to prevent this that I can see as long as the information is being entered into an invalid PC. The only possible way I can think of to bypass it would be by using SMS but requiring the user's registered cellphone to text (not receive) one of the codes to the banking authority - this would mean that at least one password travels across a system that is (hopefully) not compromised.
If it is a one time code used not to give access but to complete a particular action then it doesn't make any difference if the attacker gets it from the compromised PC. It only gives them the ability to complete the transaction initiated by the user. The SMS with the code should also have the details of the transfer requested.
And banks do just that (Score:3, Insightful)
My bank (Bank of America) has optional two factor authentication. The way it works is you specify what it is used for. So login is an option (off by default when you get it), login on an unrecognized computer is an option (on by default when you get it), money transfer, adding a new bill pay recipient and so on. Now it asks you each time for the code when you do any of these things. So if you had everything on and logged in from a new computer you'd have to enter the code first to validate the new computer (along with answering a question). Then you'd have to enter a new code to actually do a login. You'd have to then enter a third code to add someone new to billpay. You choose when it asks (and for that matter if you want to use it in the first place).
So they already do as you suggest. Really, two factor security with banks is pretty good. It's not perfect, but no security is. However, it'll stop nearly all the attacks you can think of. You have to get MUCH more complex to get around it. Well, the harder you make a target, the less tempting that target is.
After all if someone has $5000 in savings and you can steal that with a 4 line Perl script, a thief probably find that worth it. However if to get the same $5000 you need a series of extremely complex custom programs that aren't even guaranteed to work and maybe increase your risk of exposure, well perhaps that $5000 isn't so worth it after all.
Compare it to money on the street. If there's a $100 bill laying on a bench with nobody around, maybe you just pocket it. Easy, risk free money. If that same $100 has a camera watching it, a strong guy by it, and a snarling dog on a chain near it, you probalby give it a miss. Could you take out the camera, guard, and the dog? Maybe, but it probalby really isn't worth the risk.
That rather assumes everyone has a mobile phone (Score:3, Insightful)
And that they have it to hand when they're doing the transfer. I suppose you could say that anyone who's doing internet banking is likely to have one but even so, it seems a bit presumptuous.
Re:terrible advice (Score:3, Insightful)
OK. I'll wait for actual implementation.
P.S. I have been waiting for the invasion of Linux viruses for over 15 years, how long you expect I need to wait for this?
Re:Devil's advocate: Deepfreeze? (Score:1, Insightful)
Of course, a diskless system running Linux would reduce the chance of malware on clients, but perhaps if a company is dependent on Windows, almost as good security (and I state almost) would be obtained from denying admin access and using something like DeepFreeze, Windows SteadyState, or similar?
Combine DeepFreeze with AppLocker, some decent enterprise antivirus utilities, BitLocker, and the usual physical and BIOS protection on a machine, and one can make a decently locked down terminal that can cleanly run Windows apps. Should additional software be needed, no need to install it, just use something like VMWare ThinApp and have it runnable from a central location.
Excellent idea. Once you have finished paying for all that, you might reflect you could have had as good or better security for the cost of a download and a CD, or alternatively just a single magazine purchase, most Linux friendly mags include a LiveCD of one sort or another.
I don't believe the article was aimed at enterprise level solution and costs, but rather how Joe Noob can access his online account safely.
Re:What about the banks? (Score:2, Insightful)
Hence TWO factor. The key fob number proves you have the key fob. The PIN proves you know the password.
Hence TWO factor. Something you have and something you know.