Silently cached credentials?

[rdsears]

Hi all,

I just registered so I could talk to the community in regards to the fact that Filezilla, while an absolutely amazing piece of software that deserves the highest praise does one thing that I really don't think is secure. I understand the want to have convenience, but to the average end user, they are completely un-aware that their credentials are being cached for any server and any user they login as.

I tried searching the bug tracker, and the forums but I couldn't really dig up anything about this particular issue, but I can't imagine i'm the first person to say something about this.

Even just a pop up window, or maybe a check box to remember it in the quick connect tab? I'm not sure, but I'd love to hear some community response about this, and alternative ideas, so we can move to a more secure, still convenient way of doing things.

Regards,
Ryan Sears

[botg]

I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be.

You can always disable saving of passwords through fzdefaults.xml

[rdsears]

I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be.

It doesn't matter what system you run Filezilla on, the caching of credentials in plain text is *not* secure in any way shape or form, and should be a major concern for any person who truly cares about their data integrety. The notion that you can 'properly secure' a windows-based anything is a complete load of bunk. Pass the hash and network token manipulation attacks are a very real thing, affecting many, many computers. Not to mention physical access to *any* computer makes reading raw information off the hard drive elementary at best.

Malware and viruses would be able to use this path (and I'm sure they already do) to discover more spreading points, and without even basic encryption it makes it *so* much easier for malicious people to achieve something like this. The real dangerous part is the fact that it caches SCP credentials as well, so you have a shell account if you discover this file at all. Even a simple google search for 'inurl:recentservers.xml' revealed some passwords. Granted these are the most insecure tier of machines on the internet, set up by people who *really* don't know what they're doing, but any other indexing of that directory can potentially be used as leverage to find credentials.

Someone even posted in the bug tracker exactly how to securely store the credentials using Windows API calls, but it doesn't look like it's going anywhere:
http://trac.filezilla-project.org/ticket/5530

This behavior may be alright for a single-user environment for a home user, but you have to realize that that is most certainly not the only way Filezilla is used. Take the scenario of a computer lab. I realize that it caches the credentials into the users profile, but that's still not an alright way of doing it. There are ways to implement the same functionality in a secure way, and there have been systems to facilitate this kind of stuff. Pretty much any other program that caches credentials of any kind at the very least warns you.

It's not like I'm asking for a complete re-design of the security model of Filezilla, or even that much effort on the developers part. I'm simply requesting that the default behavior be changed, or at the very least a simple dialog be displayed on first time use warning of the plain-text storage of your credentials. A lot of the people I know weren't even aware that this behavior was on by default, which is *very* dangerous. I myself in the past have logged into private resources using Filezilla on another person's computer before I knew it did this, and I know for a fact that I'm not only person who has a problem with this.

Regards,
Ryan Sears

[maathieu]

Glad to see this upped (and on Full Disclosure!). How hard could it be to implement a Master Password system, just like the one of Firefox and Thunderbird? Simple and secure enough...

As far as I'm concerned I store passwords using KeePass. From a usability viewpoint it's less than efficient but at least my passwords don't appear in plain text on my disk - and don't get stored as plain text in my backups, and so on.

[eyebex]

I see the security risk in storing passwords in plain text, but still I share botg's opinion: IMHO it's a completely valid standpoint to say this is out of scope of FileZilla, or in fact any third-party application, and the task of the user / administrator to choose e.g. a file(system) / container-based encryption solution like TrueCrypt. It just does not make much sense to me that N applications you install should implement N encryption schemes. Such a thing should be done centrally.

[joshbw]

IMHO it's a completely valid standpoint to say this is out of scope of FileZilla, or in fact any third-party application, and the task of the user / administrator to choose e.g. a file(system) / container-based encryption solution like TrueCrypt. It just does not make much sense to me that N applications you install should implement N encryption schemes. Such a thing should be done centrally.

There is much wrong with this. First, applications don't have to implement encryption schemes, that is provided by the platform FOR THIS SPECIFIC PURPOSE. If you bothered to read my bug report and follow the suggested fixes you would notice that the entire point of CryptProtectData is enable applications to protect passwords and encryption keys. If you wanted to enrypt the whole file rather than just protect the password (which is arguably easier) Windows readily provides you with built in encryption algorithms. Protecting this data is trivial to achieve and all it requires is that you use the tools already available to you.

Additionally, if you actually think users should have to go implement third party solutions to secure your application's data you have a very distorted view on customer expectations. You are effectively telling users that if they care about security it is their responsibility to engineer around filezilla and that Filezilla cares so little about security that it cannot adhere to a common and well adopted security practice that is trivial to implement. You might as well say that you shouldn't be expected to prevent buffer overlows in your protocol handler because it is the user's responsibility to go out and get a HIPS to filter out dangerous malformed packets. "Security is the users problem" is a disgraceful attitude, but if that is the attitude of this project the very least you can do is put that in a giant banner to warn users that you don't give a crap.

You also do not understand several of the exploitation scenarios. The reason I opened the bug is because a known malware propogation technique is to scan the ftp capacity of an infected client, determine if the ftp provides access to a webserver, and to compromise the webserver via the stored FTP credentials. This has mostly affected Windows Explorer to this point rather than FileZilla, but that is not at all because Windows Explorer is easier to exploit. Quite the contrary, Windows Explorer doesn't provide direct credential access since it actually uses sane password storage best practices. In order to exploit it you have to script windows explorer and get it to make the transfer for you. With Filezilla you have the credentials - you do not need to do anything as clumsy as scripting another app to get your desired access. The vast majority of 3rd party file encryption will not protect against this, or even provide a speedbump and now that this problem is posted on full disclosure you can expect that at least some malware authors will know how trivial it is to compromise credential confidentiality.

You are ignoring well known security best practices, ones not disputed by any security professional, and ignoring trivial to implement fixes. Your attitude that it is the user's problem, when most users are probably not even aware that Filezilla employ such pathetic password handling, is not justified.

[eyebex]

[...] you have a very distorted view on customer expectations.

Indeed, to be honest, I personally do not care much about customer expectations for FileZilla. It's not a commercial product, and there's no product manager who is responsible for making FileZilla like his / her (paying!) customers want it to be. I just find it awkward to talk about "customer expectations" for a small Open Source project like this one is (in terms of developers / lines of code, not users).

[...] it is their responsibility to engineer around filezilla

By saying "engineer around" you imply that the lack of password encryption is some sort of design flaw. I guess botg would argue it is not. It is a know limitation, and it's meant to be like this.

[...] it cannot adhere to a common and well adopted security practice

Common and well adopted? As Ryan already mentioned in his FD mail, even programs like Pidgin do not implement password encryption, and I doubt that the majority of OSS projects in the size of FileZilla (again, in terms of developers / lines of code, not users) do. Don't get me wrong, this should not be an excuse for not implementing encryption. I just doubt it's well adopted.

You might as well say that you shouldn't be expected to prevent buffer overlows in your protocol handler because it is the user's responsibility [...]

I hope you see that there's clearly a difference between a deliberate design decision and unwanted bugs like buffer overflows.

[...] but if that is the attitude of this project the very least you can do is put that in a giant banner to warn users that you don't give a crap.

Please note that I'm just expressing my personal opinion, not botg's or that of the FileZilla project. But I agree that, if password encryption is not to be implemented, a note to the user about this, e.g. when running FileZilla for the first time, would be nice.

You are ignoring well known security best practices, ones not disputed by any security professional, and ignoring trivial to implement fixes. Your attitude that it is the user's problem, when most users are probably not even aware that Filezilla employ such pathetic password handling, is not justified.

If you care so much about the user's security, why don't you submit a patch instead of just pointing fingers? Again, FileZilla basically is a one-man project. What concerns me, I'm grateful for what a cool FTP client I'm getting, for free. If it misses features I'd like to see added, giving back some lines of code is the least I can do. And once such a patch exists, I doubt it would be rejected due to some religious reasons.

[boco]

My strong opinion is that kiosk mode 1 should be definitely the default mode from the start. In this mode FileZilla does not store even a single password on disk. If one would like to do that, one could enable it, after being told the consequences of that decision.

[rdsears]

Code: Select all

I see the security risk in storing passwords in plain text, but still I share botg's opinion: IMHO it's a completely valid standpoint to say this is out of scope of FileZilla, or in fact any third-party application, and the task of the user / administrator to choose e.g. a file(system) / container-based encryption solution like TrueCrypt. It just does not make much sense to me that N applications you install should implement N encryption schemes. Such a thing should be done centrally.

How is it a valid point to say that it's outside the scope of filezilla to handle the passwords it uses properly? 90% of users out there don't have the know-how (nor the ability) to implement proper encryption on their password/configuration files, not to mention all the other problems that would cause (a la encrypting the entire filezilla folder vs just the recentservers.xml and filezilla.xml?) and with the trend of password handling that is done by other programs, this leads to a very dangerous lapse in judgement.

People assume that no program is going to handle their sensitive information in such an in-secure way, because it IS and ALWAYS WILL BE a lapse in security. It is 2010, and this is behavior that crappy programs from the 90's did. It's a shoddy practice at best, but that's not even my point. A program that silently and without warning saves passwords *anywhere* be it in plain text or an encrypted string is borderline malicious.

To re-iterate this is a two-tiered problem:
1.) Filezilla DOES NOT warn against this kind of behavior (or even notify any user it's happening)
2.) Filezilla DOES NOT securely store the credentials of people if they wanted it done

I don't understand how these can be considered *not* a security risk of any type. I think you have a misconception as to how programs are supposed to interact with an operating system. The operating system does insecure things (creating sockets, writing files, etc) on the behalf of programs, using documented API calls. This has been how it's done since the mid 80's (and before), and that's the way it should be. You need to have segregation between your programs to prevent them from interfering with one another, which is why we have an isolated stack model. Each program thinks it's in its own computer of sorts, and the only interactions should be done from program > operating system. I agree that we shouldn't have N number of encryption schemes for N programs, but THAT'S WHY THERE ARE OPERATING SYSTEM CALLS TO DO SUCH THINGS. That's why any operating system's developers spent time developing robust and secure methods to do this, to have a universal encryption/decryption system. The idea that an end user needs to create a truecrypt volume for every single program and each programs *configuration* files is idiotic at best, I don't mean to sound harsh, but that's how I feel.

This is an Occam's Razor type of problem, you're suggesting a truecrypt volume to negate bad behavior on the program's part, which could easily be mitigated with a handful of changes to the source code. The simplest way to get rid of this problem is change the default behavior, and it always will be.

Filezilla does SCP and other encryption/decryption things, so someone who developed it knows how to do this properly, the reason it *isn't* implemented however escapes me. It makes no sense whatsoever.

(I started this response earlier this morning, and just had time to finish it. I noticed there are other posts following eyebex's post, but i have yet to read them, so I apologize for any redundant points)

Regards,
Ryan Sears

[joshbw]

Indeed, to be honest, I personally do not care much about customer expectations for FileZilla. It's not a commercial product, and there's no product manager who is responsible for making FileZilla like his / her (paying!) customers want it to be. I just find it awkward to talk about "customer expectations" for a small Open Source project like this one is (in terms of developers / lines of code, not users).

Sorry, I was ambigious (and sloppy in referring to customer - I typically try to refer to user when talking about OSS, but I do spend much more of my time consulting for commercial app security so it is habitual to talk about the customer rather than user). Let me clarify, what YOU expect of users is ludicrous, not what users expect of you. Considering that I have recommended filezilla to many a user just to get them off of windows explorer I know for a fact that at least some of your user base is not at all the type to use file system based encryption and you shouldn't operate under the mentality that it is reasonable to expect that is a common user scenario.

By saying "engineer around" you imply that the lack of password encryption is some sort of design flaw. I guess botg would argue it is not. It is a know limitation, and it's meant to be like this.

It is a design flaw. You might (but in no way have) argued that you considered this but felt other considerations warranted the plain text password, but that means you have accepted the risk of the flaw, not that the flaw is not present.

Common and well adopted? As Ryan already mentioned in his FD mail, even programs like Pidgin do not implement password encryption, and I doubt that the majority of OSS projects in the size of FileZilla (again, in terms of developers / lines of code, not users) do. Don't get me wrong, this should not be an excuse for not implementing encryption. I just doubt it's well adopted.

Yes, it is a problem endemic to smaller OSS projects, but speaking as a whole, most server apps protect passwords (even small OSS apps adhere to password hashing), and most large apps do as well. People would flip out if browsers still had such lax password standards for example, and FTP credentials are often just as important.

I hope you see that there's clearly a difference between a deliberate design decision and unwanted bugs like buffer overflows.

you haven't established that this was deliberate. There is no reason I should assume it exists for any reason other than people didn't think about the risk, anymore than people *still* don't think of the risk of unchecked buffer copies. My assumption is still that either no one thought of it, or no one gave a crap, not that someone was like "Hey, we should make this plain text instead of protecting it for the following deliberate reasons" though if you presented a rational justification I would certainly change my mind. That said, saying that if I fixed it myself it would be added to the repository underminds the deliberateness of this.

If you care so much about the user's security, why don't you submit a patch instead of just pointing fingers? Again, FileZilla basically is a one-man project. What concerns me, I'm grateful for what a cool FTP client I'm getting, for free. If it misses features I'd like to see added, giving back some lines of code is the least I can do. And once such a patch exists, I doubt it would be rejected due to some religious reasons.

Ah yes, the fix it yourself mentality that mars the entire open source community. When that is the habitual response it doesn't at all encourage people to give you any feedback.

To answer your question it is because it is a huge pain in the ass to grab source code, set up the appropriate build environment with all necessary dependencies, familiarize myself with the layout of functionality within the source (especially since, lets be honest, small open source projects rarely follow any stylistic guidelines that would make reading code easier, or even do trivial things like include comments. Your project might be better than most about that, and I am not accusing Filezilla specifically of that, but it is a common enough occurance that it is warrants default assumption status), make and test the change, and then sell whoever is the gatekeeper on the change. This flaw really wouldn't take someone invested and current in the project much time to fix and get adopted, but it is a pretty large time sync for someone not currently invested. If I was interested in continual involvement in the project it might be worth the effort, but I am committed quite enough to altruistic projects and really don't want to add another to that list.

[rdsears]

@joshbw I couldn't have said it better myself. It's easy to blame us for not submitting patches and whatnot, but the developer is already intimately familiar with his source code, and has been for almost 10 years now (since 2001), so it's not like he doesn't know exactly where the changes need to be made.

If the developer kept an open mind, and worked with the community instead of rejecting fix requests and saying it's not an issue, we wouldn't really be here. joshbw clearly knows how to implement this kind of behavior, and it would take no more than a half hour IRC session / a handful of emails even if the developer didn't know how to implement this to get it done.

This is one of those things that is tiny enough that a project fork into a secure version of Filezilla would be nothing more than a waste of time. Possible? Yes. Smart? No.

Yes, Filezilla is provided as open-source and 'as is' but it is easily the most popular FTP program for windows. Due to a combination of the end user not knowing it's default behavior (which they shouldn't be expected to in the first place), and the method of password storage though I believe would have put a damper on it's popularity. It's just the fact that a lot of people don't know about it.

Regards & thanks for all the good points!
Ryan Sears

[joshbw]

One thing that probably hasn't been clear from my somewhat brisk tone is that I really do appreciate the work that has gone into filezilla. It is one of the nicer clients (can't speak for the server) and I have felt it was worth recommending. That said, I do obviously believe this is a problem that should be addressed. It is literally my job to care about application security and I believe that the entire application security landscape would be much better off if so many people were not dismissive of sound advice. So while I am willing to be confrontational about this issue, I want to clarify that I am not taking the work done on Filezilla for granted.

What prompted me to recommend Filezilla over Windows Explorer was being asked by multiple people to help them clean up their website and figure out how the web root was altered. Each time the problem was traced back to client side malware that was using cached FTP credentials. I had recommended Filezilla since it is a good free alternitive, but after a stint of curiosity I found that my real reason for making the recommendation was largely pointless, since malware could access the FTP credentials even easier should it choose. That's why I am trying to convince you of the seriousness of this problem. This isn't a case for pushing for a best practice for the sake of being "proper" but rather because this is a very likely exploitation scenario. For all I know, it has been exploited already.

[botg]

Lots of interesting arguments. Instead of replying in detail, I'll answer with some general remarks.

One thing to consider is the intended target audience. I intend FileZilla to be used by experienced users that know what they are doing, colloquially called power users. While users most certainly should not need a PhD or similar degree to use FileZilla, I expect all users to have enough common sense to understand the importance of overall system security. Meaning that they are either capable of maintaining their system themselves or hiring somebody to maintain it for them. You might ask yourself, why hire somebody to maintain your system for you, isn't that totally unreasonable? But on the other hand, if you are sick, don't you go consult a doctor? If your car is broken, don't you go to a car garage and have a mechanic have a look at your car? But why is it that with computers, people always think they know better than the experts?

Regarding password encryption, I think it's futile. Consider the case that there is malware on your computer. If passwords are not encrypted, malware reads your passwords. If passwords are encrypted, malware reads the encrypted passwords and intercepts the decryption password when you enter it. If passwords are not stored at all, malware intercepts the passwords the next time you enter it. In all three cases the final result is utterly the same, your passwords have been compromised. Instead, you should ask yourself the question of why there is malware on your computer. If you can prevent infection in the first place, it doesn't matter if or how you store passwords.

As such, I have no intentions to ever implement password encryption. This decision of mine is final, good as carved into stone. On the prospect of not storing passwords at all by default, I have never ruled out that option. I can envision some sort of confirmation dialog shown after the user performs an action that might store the password for the first time. Unfortunately my time is limited and so far I did not even have time to think about the requirements for this feature, let alone implement it.

That said, volunteers may not do a step backwards . The FileZilla project is always looking for capable help.

[joshbw]

Regarding password encryption, I think it's futile. Consider the case that there is malware on your computer. If passwords are not encrypted, malware reads your passwords. If passwords are encrypted, malware reads the encrypted passwords and intercepts the decryption password when you enter it. If passwords are not stored at all, malware intercepts the passwords the next time you enter it. In all three cases the final result is utterly the same, your passwords have been compromised. Instead, you should ask yourself the question of why there is malware on your computer. If you can prevent infection in the first place, it doesn't matter if or how you store passwords.

Someone really and utterly determined to get the passwords who has code running on a system will. I don't dispute that. However there is a level of ROI for the malware author. When all that is required is reading a file off of the file system there is very little investment so even if the return isn't very large it probably justifies the investment. In this scenario there are many things that make the investment attractive - doing it ALWAYS works, doesn't require user interaction, and nets passwords for all stored sites. In other scenarios - keystroke logging, proxying the net connection, reading memory, etc those things don't hold true. The user has to be actively using the application, the chance of getting multiple site passwords is questionable, and the effort to do so increases significantly. Security is never an absolute thing. Security really is an effort to make it not worth a threat agent's time to target your area. We know that CAPTCHAs don't work - even if they stop automation they don't stop outsourced indian or chinese labor from breaking it. What they do is increase the cost and effort so that most of the time it isn't worth the investment.

The same thing applies here. Will encrypting the file ensure the passwords are never disclosed? No, it honestly won't. But it will mean that a malware author won't go after them simply because it is low hanging fruit, and again, I can't stress it enough, malware does go after this information specifically even if not in filezilla specifically (yet). Also, you can't prevent infection. My enterprise has malware scanning and HIPS on every workstation, internal scanning of all network traffic and feeding anomymolous traffic to a sandboxed malware analysis, strict email attachment filters, web traffic filtering, mature vulnerability and patch management, extensive mandatory user education, and so forth. Malware still gets onto machines (though in much lower volume than it would without all of that), because no matter what we do we can't stop the fact that there are many unknown vulnerabilities waiting to be discovered and exploited in the PDF file format, or in the browser, or in media codecs, etc. As an individual user I am in no way typical even of a power user - I know what the threat landscape looks like and behave accordingly. But I can't stop the fundemental fact that my computer is designed to execute code, and there are a lot of scenarios that get it to do just that.

I understand your time is limited. When I entered the bug I didn't expect you to drop everything and fix it, entirely because I know this is a volunteer project (my expectations would be vastly different if you charged for the product). I still don't expect it to be fixed tomorrow. You have a lot of things to prioritize. What I do hope though is that you understand why this vulnerability is a problem (this is data that is specifically targetted by malware) and why it is an application's responsibility to protect its own data. I still don't think you understand the actual risk present.

[sekurity]

I am glad the issue raised by Ryan is gaining a high profile since I think Filezilla has great potential and discussions like these can only serve to make the application even better.

That is why I considered the developer's initial response to Ryan unfortunate. If Filezilla wishes to be considered a serious implementation of secure file transfer protocols (e.g. SFTP) then it needs to revisit its official position on things as basic as credential management.

The developer's 2nd response is even more troubling as he still does not accept the importance of such basic privacy/security measures. Also, without getting into the actual details, the scenarios presented regarding malware interception of passwords were not exhaustive. I can imagine many other situations in which stored cleartext passwords are not desirable. I cannot more strongly disagree with the conclusion that encrypted credentials are irrelevant.

Finally, I am a bit saddened by the developer's comment about his decision being final. My read on this is that, if true, Filezilla will become yet another example of how a secure protocol can be made insecure through poor implementation.

Thanks.