Ticket #5530 (reopened Feature request)

Opened 4 years ago

Last modified 7 months ago

Encrypt stored passwords (using file system facilities; NOT master password)

Reported by: joshbw Owned by:
Priority: high Component: FileZilla Client
Keywords: Security Encryption DPAPI Cc: chinaski, geoff.j.lawrence@…
Operating system type: Operating system version:

Description

For Windows Clients, in %appdata%\filezilla\sitemanager.xml the passwords are stored plaintext. This is generally bad security practice, as any malware that is aware of filezilla (as many are aware of and utilize stored passwords in Windows Explorer FTP) can harvest FTP credentials and upload malicious files to any stored webserver FTP addresses.

Windows provides an easy mechanism to encrypt passwords using DPAPI:  http://msdn.microsoft.com/en-us/library/ms995355.aspx

Specifically, the two functions of interest are CryptProtectData:  http://msdn.microsoft.com/en-us/library/aa380261.aspx and CryptUnprotectData:  http://msdn.microsoft.com/en-us/library/aa380261(VS.85).aspx

These functions will handle encryption and key management to store the passwords. They should be used with the optional entropy to further increase the difficulty in other applications extracting that information. If working in .Net the System.Cryptography.ProtectedData class provides managed access to DPAPI so that PINVOKE marshalling is not necessary.

Alternitively sitemanager.xml could be entirely encrypted using AES with the passwords stored in the encrypted file, however the encryption key should be computer/user specific and stored via DPAPI.

Either route comes with drawbacks however - it makes migrating settings to new installs more difficult (can't just copy sitemanager.xml and drop it in the %appdata% directory of the new install) so that is a drawback to be aware of.

In OS X the same functionality is provided via the Keychain API in the functions SecKeychainAddGenericPassword and SecKeychainFindGenericPassword. I am unaware of a linux equivelent

Attachments

Change History

  Changed 4 years ago by btrower

  • priority changed from normal to critical

Like another person here, I registered specifically to put in this bug.

There is a long discussion elsewhere about this. Apparently the bug has been there for years. I call this a bug because it is a 'misfeature' that is so severe as to render the program unusable for some purposes. For instance, in my case, I was setting up FileZilla on what has to be a FAT32 USB Flash drive (and hence there is no file-system security). There are about five dozen sites in the XML file in question. There is no way to secure the file using the file system if I move it to the new drive. If I can't secure via a master password, it means I have to store passwords elsewhere in an encrypted file I manage myself. I will then have to go to that encrypted store, open the file up unencrypted using my password, find the relevant password, type it into FileZilla and then securely erase any persistent storage used by the encryption software. It also means that I have to make sure that whenever I move FileZilla that I remember to copy the encryption software plus the relevant encrypted password file.

The above is an extraordinary burden to place on the user. It renders the program either hostile or unsafe and possibly both.

The other discussion kept returning to the argument that in the event of a catastrophic breach by an attacker willing to do whatever it took to breach the system entirely, the system would be breached entirely and therefore a master password would add nothing. Even that is arguably not true since they may still have to sift through logs and divine which keystrokes constitute the master password. Of course, then they also still have to know exactly how to decrypt the file and have the software to do that with. However, the fact that there exist circumstances under which a master password would not be helpful does not imply that a master password is not helpful.

Whoever keeps closing this issue and/or dismissing its importance understands neither security nor logical argument. I apologize for the slam, but it is undeniably true. Making the same mistake over and over does not make it any less of a mistake. The fact that a critical deficiency has existed for years does not make it any less critical a deficiency. Similarly, the fact that there are others (pidgin) who indulge in the same faulty reasoning does not make the reasoning any more sound.

For me, this is now a show stopper. I can't do what I need to do using this tool.

I have been using this tool for years. I was originally aware of this a long time ago, but thought that the issue had been corrected. It was irrelevant since the files were on a secure machine in a secure area behind three firewalls on a secure file system protected by a strong password. I now need to have that facility on a USB drive that cannot be secured except to have individual files encrypted. The natural solution is for programs that will accept and store sensitive data to never store them in the clear. This is the case for any software that has had anyone with a knowledge of security involved.

From a basic discussion about security by the EFF:

The old adage that "a chain is only as strong as its weakest link" applies to security, too: The system as a whole is only as strong as the weakest component. For example, the best door lock is of no use if you have cheap window latches. Encrypting your email so it won't get intercepted in transit won't protect the confidentiality of that email if you store an unencrypted copy on your laptop and your laptop is stolen.  https://ssd.eff.org/risk/lessons

It is not sound practice for programs to store passwords in the clear. There is no qualifier for that. Software should not store passwords in the clear. The end.

I can not imagine any issue affecting FileZilla that should have as a high a priority as this one. It is a critical security defect and the fact that people dealing with the issue tracking do not understand that and have not understood that for a long time does not make it any less critical. In fact, because this security flaw has existed for a long time it is likely being actively exploited to gain unauthorized access to systems.

The correct fix to this is to always store the file encrypted at least on a previously generated and stored unique salt, then to allow an option to set a master password and then to allow options to export the file and to import a file to allow moving the file.

Whenever the file is being written, retrieve a saved 'salt' value. If it has not been saved, then generate one (uniquely), save it and then retrieve it. Encrypt on the salt plus the master password. When loading, get the salt plus the master password and decrypt. Only store the unencrypted file in RAM. If the salt is stored in the registry and is out of reach of someone who captures your file, they will not be able to decrypt it even if they have the master password.

There is no such thing as absolute security and even the most secure systems are vulnerable to attack. However, that does not mean it makes sense to lower the cost of an attack to the point where the effort required to breach the system is negligible.

Anyone with temporary access to a workstation with FileZilla on it can simply cruise to this page and cut and paste this into a command line and it will display all the passwords in the file:

find "Pass" "%APPDATA%\FileZilla\sitemanager.xml"

They don't even need to know who is logged on.

Encrypting the XML file would not make the program resistant to a strong attack. However, it would certainly make it resistant to the trivial attack above.

  Changed 4 years ago by joshbw

Updated to include the thread on FD:  http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/76111

To address a comment that the FD poster specifically complained about:

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

This is an utterly terrible sentiment. There is no such thing as a system properly secured and the person who made that comment is incredibly niave. With the common proliferation of zero day based exploits both malware scanners and product patches are always one step behind through no fault of the user. Finding an unpatched acrobat, flash, or quicktime vulnerability requires no sophistication whatsoever. Filezilla should always adopt the stance that it is a matter of when, rather than if, a system is compromised and design the product accordingly.

The fact is that malware has, for quite a while, adopted the tactic of looking for FTP credentials to upload itself to webservers. To date the focus has been on windows explorer FTP, but just because malware in the past has not felt targetting filezilla to be worth the time does not mean it will continue to believe the product irrelevent forever. When that occurs this product will be complacent in the exploitation. You know that malware targets FTP credentials, you know that the systems you are installed on can't be considered secure, and you know passwords should not be stored in plain text. And now you know that the defect has been posted to full disclosure by someone, and that malware authors do read that list for inspiration. Continueing to ignore this problem is the height of negligence.

The protections are not absolute. A sufficiently advanced form of malware could read the values out of memory while they are in use (though if you really worry about that you could use CryptProtectMemory), though that is highly unlikely. Similarly it could monitor outbound network traffic and sniff the communication, and a host of other techniques. However none of these are anywhere near as easy as simply reading an entirely unprotected and easy to find xml file. There is a huge difference between an exploit scenario that is "Technically doable" and "Trivially easy". Raise the bar a bit.

  Changed 3 years ago by redintray

Linux client also needs plain text passwords to be encrypted. Protection needs to be able to protect passwords stored in backups of a user's home directory. The simple filesystem directory protection currently used is not a strong enough mechanism for protecting the sitemanager.xml file.

  Changed 3 years ago by chinaski

  • cc chinaski added

I can not believe I have been using Filezilla all this time and the passwords were just plain text that can be seen with the Notepad. Plus the Malware can easily use it to upload itself to your hosting.

This has to be fixed asap, before any other feature.

  Changed 3 years ago by AUChemist

Just registered to also voice my concern over this issue. Recently migrated to a new system and found FileZilla's appdata. I was absolutely appalled that my passwords were being stored as plain text. This is absolutely unacceptable. I could ramble on and on about why it is but I think its plainly obvious why.

Developers, please fix this asap!

follow-up: ↓ 8   Changed 3 years ago by codesquid

  • status changed from new to closed
  • priority changed from critical to normal
  • resolution set to rejected

Whether passwords are stored encrypted or in plaintext makes no difference in security.

Two options for storing passwords encrypted:
a) Transparent encryption with an implicit master key stored somewhere
b) Encryption with the user required to enter a password to decrypt

In the first scenario, you can just as well use plain text passwords. If no interaction is needed, everybody still access the passwords, even if they are encrypted.

The second option would work, but if you always have to enter some master password, you can instead disable saving of passwords completely.

You can already disable saving of passwords in the settings dialog of FileZilla.

  Changed 3 years ago by redintray

  • priority changed from normal to high
  • status changed from closed to reopened
  • resolution rejected deleted

Ticket closed without full understanding of the implications.

Once Malware takes hold it can easily access files. So, you don't want to store any plaintext passwords on a system. Only store the results of encryption. When a user attempts to login to a remote system do the following: User enters a master password. Filezilla encrypts the entered password and confirms this encrypted password matches what is stored in the file system. This password is then used as a key to decrypt the password store for ftp sites. Using this method even when the machine is compromised the keys are not divulged.

I leave this comment simply as a basis for others to work on - I'm not a security expert but I do know plaintext password storage is a no-no. Filezilla is much less useful to me when I can't confidentially store passwords.

in reply to: ↑ 6   Changed 3 years ago by joshbw

Replying to codesquid:
"Two options for storing passwords encrypted:

a) Transparent encryption with an implicit master key stored somewhere
b) Encryption with the user required to enter a password to decrypt

"

If you had read the original ticket you would see that there is an additional option that I went out of my way to provide you up front. Using DPAPI or Keychain appropriately is NOT remotely the same thing as storing passwords in the clear. They were designed SPECIFICALLY for this situation. You can use them either to store the passwords themselves OR to store a crypto key that is then used to seperately encrypt the password file - in both examples you have protection that is significantly harder to compromise than a key stored on the local system through other means (config file/registry key, hard coded in source, etc). Is it bulletproof and unbreakable? No - but neither are locks/ignition systems on cars but you wouldn't buy a new car that allowed anyone walking by to get in and drive off with it. I absolutely hate the canard that because you can't 100% protect the client you should make no effort to protect it at all; there is rarely unbreakable security regardless of environment, but there certainly is security that is expensive to break and security that is cheap to break. One of those is better than the other.

"The second option would work, but if you always have to enter some master password, you can instead disable saving of passwords completely."

Oh come on - can you really not see that entering one master password once to log into filezilla is not remotely the same thing as entering passwords for every single site stored in the password list? If it was would password managers like LastPass or 1Password make any sense at all? Using a master password, if you want that route over a secure key storage solution like DPAPI, would not be an overly strenous burden on users that want to opt into that solution, and significantly more user friendly than entering every password for every site every time.


If you don't want to encrypt the password store in order to make it easy to backup and migrate the password file between installs, or because the best options (DPAPI or Keychain) require platform specific coding (though there is always master passwords or similar non-platform specific implementations), or because you have higher priority feature work or for some other use case that crypto makes more complex that's fine, but at least own that you are choosing that feature/work over a secure implementation rather than throwing out these unnuanced canards to justify ingoring concerns. Malware targets implementations like this specifically because of how trivial it is to get the passwords - it doesn't require much effort on your part to make it a heck of a lot harder for attackers and it can be done in a way mostly transparent or unburdensome to the user.

If nothing else, at least recognize it is a feature that your users are asking for and consider it as a feature request for a future version instead of ignoring it out of hand. That doesn't seem unreasonable

  Changed 2 years ago by RobIII

I also registered just to "+1 vote" this bug (if there were such a feature, it doesn't seem to be so I post a comment).

I can't believe, over the many, many years people have been asking for this this is still not implemented. A simple (heck, make it optional!) master-password will do. Using TrueCrypt or other ways of making sure the file is not easily accessible by malware is all nice 'n stuff but it requires way to much effort for the user. A simple checkbox ("require master password") and a password inputbox is all there's to it.

In the past, what, 5 years I've seen many, many people (and customers) with hacked sites just because this feature is not implemented and, excuse me for being so blut, the developers being too thickheaded to recognise the problem at hand here and helping these people out.

So I would like to +1 joshbw's comment, as with the other comments here and in many other threads online and in this bugtracker.

Please (re)consider your standpoint and at least give users the option to use a masterpassword.

  Changed 2 years ago by ci-dev

  • type changed from Bug report to Feature request

See issue #2935 for a "master password approach".

  Changed 2 years ago by sapincher

why was this ever rejected? that is so ridiculous.

i had a virus steal the credentials to 5 different sites' ftp accounts and inject malware into them. even notepad++'s ftp plugin encrypts these credentials.

if it takes 2 years to add this ridiculously simple feature, i might as well just stop bothering with filezilla.

  Changed 20 months ago by subnoodle

Have been a victim using FileZilla. A Trojan manipulated customer websites... very ugly.

I think FileZilla is one of the most beautiful applications.

I missed to check instead of to trust software.

And although there is a mini tutorial to switch FileZilla into more secure kiosk mode, this do not work on my PC.

Is this heavy bug still existing? Seriously?

  Changed 19 months ago by jonenst

+1

  Changed 18 months ago by ci-dev

  • summary changed from Encrypt stored passwords to Encrypt stored passwords (using file system facilities; NOT master password)

  Changed 15 months ago by MalwareVictim

It has happended to me. Tuesday this week my cell phone rang but I couldn't pick it up that moment. When I checked to see who called me, I saw the number of my business partner on the display. He almost never calls me. I thought it was about our tax declaration being due, so I didn't call back because I didn't feel like talking about this topic. I then drove to my office.

In my inbox there was an email by our web host. It said something about suspected malware on our web space, which my business partner had reported. So that was why he tried to reach me... They said they could find any problem on our web space but asked me to check it anyway. So I did...

I first went to the web site presenting one of our products. Within seconds, my anti virus software bombared me with malware alerts and an unwanted file loaded itself down to my desktop. I downloaded the index.htm file using FileZilla to see what was going on. There was a block of cryptic code in it. And not only there, but in every HTML file of that web site! I reported to our web host that the site was obviously totally infected with malware. So much for them not finding a problem with it. But that's a different thing.

Next web site I checked was our company web site: Same thing, malware all over. Meanwhile I answered some emails by upset customers reporting the issue. I also informed my business partner that I was already about to fix everything. We are also running a web forum for our products. Needless to say it was infect too, and so was our landing page for selling our product as well as some web sites still under construction.

Each and every of our web sites were totally contaminated with malicious scripts. Most infected files were HTML files, but certain other files were affected too, like .htaccess, .js, .tpl and sometimes .php files. Thank heavens I had a backup of most web sites, so I could just delete and reupload them. Before I did that, I did an extensive virus scan on my hard drive of course, just to make sure that any new FTP passwords I set would not be stolen again. All this took me hours.

Unfortunately, I did not have a backup of our company web site. That's because I have wanted to revise it anyway for months and thus considered it to be more or less temporary and not worthy of being backed up. So I had to manually remove the malicious blocks of code from hundreds of files. I finished at 3 am and went to bed around 5 am, after a final check for viruses on my hard drive and a message to my business partner and a couple of customers telling them that all viruses had been removed.

I woke up with a terrible headache next day, but was glad that everything was alright again. Or that's what I thought... By chance I found out that a private web site of mine was also infected! How could that be? It was hosted by a free web space provider having nothing to do with our business web site! It occurred to me that I used FileZilla to manage both our business web sites and my private one... But how exactly did the attacker steal my passwords? Maybe he was sniffing around my ports on transmission of the passwords between my machine and the remote server? No! Why not? Because I haven't used FileZilla for several months, neither for our business web sites nor for my private one. All web sites were running fine, so there was no need for FTP. So there is only one answer: The hacker must have stolen the passwords from the XML files stored by FileZilla!

Anyway, it took me another entire working day to also repair my private web site. I finished around 2 am last night, so today I also woke up with a massive headache. Meanwhile I learned that FileZilla does in fact store server passwords in a plain text file without encryption. I also learned that people have been complaing about this for years, and that the developer was refusing to fix that issue. Well, after all, FileZilla is a free software. Free software? I think that in the past 48 hours, I have more than paid for it...

I am using anti virus software and I am regularily doing scans for malware on my machine. So what else can I do to get my system "properly secured"? I am telling you this story to make you think twice. For me, the scenario of FTP passwords getting stolen from FileZilla and an attacker uploading malicious code to one or more web sites using the stolen information is not something that COULD happen. It's something that DID happen to me, and it wreaked havoc on both my business and my private life! I had to cancel business talks, postpone unpaid bills, put customer orders on delay, sacrifice my leisure time and more. Now I hope that the issue is fixed, but I will still have some very busy days clearing the backlog that I am now facing.

I too have just registered hered to file this complaint. FileZilla is otherwise a good piece of software and I like it a lot, but if you have read the above, I am sure you understand why I am saying that FileZilla MUST take appropriate measures to prevent the passwords it stores from being stolen!

  Changed 15 months ago by yereverluvinunclebert

I was previously hacked just as the above chap was - this was years ago and it surprises me that this vulnerability is still present. Ever since then I switched from being a strong advocate to recommending that Windows users avoid filezilla like the plague. I have influenced the decisions of hundreds of potential users in that time. Each person is astounded by the mistake Filezilla developers have made in this respect. There is no question about it, this one flaw is enough for any potential user to drop the program like hot cakes, immediately. It is almost acting as a trojan allowing any hacker to access your sites as long as they can access your PC. Hackers are incredibly clever and resourceful and they see filezilla as an open resource for harvesting passwords en masse.

Since my hack I simply recommend WinSCP as an open source alternative to filezilla. It is superior in many respects and it has in-built encryption controlled via a master password. The developers are also completely open to intelligent suggestion.
I can only reiterate: "Avoid filezilla like the plague - it stores your passwords in plain text, if your PC is hacked all your sites are open to compromise"

  Changed 15 months ago by RobIII

I propose everyone do that: if FileZilla's developers are (and keep being) too thickheaded, and trust me they are/will since this issue has been around for many years in many forms and tickets, we as a community take responsibility to inform current and potential users to avoid FileZilla. It's a shame, because the client is pretty good otherwise. But never, ever, have I met such stubborn developers. Granted, it's *their* project, but never have I seen a devoted and enthousiast community been ignored this hard. Shame, that's the only word that comes to mind.

  Changed 15 months ago by busybrian

My Filezilla was hacked about a year ago. A major headache. What is the issue with adding another layer of security. Is there such a thing as too much security? Security isn't about absolutes, it is about layers. What a major disappointment that the developers don't listen to their customers.

  Changed 15 months ago by aciid

  • priority changed from high to critical

Can not believe this point was raised over 3 years ago and it's not been implemented. Get on the case already! People shouldn't need to explain plaintext implications to developers?

  Changed 15 months ago by PanKJ

I have been in the malware developing industry for a while and I can say that storing passwords as plain text is just unacceptable. To put it simply, the more sophisticated your product is, the more sophisticated the malware has to be in order to exploit it. Writing code to read plain text and upload it is a matter of few minutes. Reading encrypted data on the other hand, not only requires knowledge of how it is encrypted, but also more time.

I would suggest using file system facilities to encrypt settings and connection history as well as the giving the option to use a master password to decrypt the latter. This way malware would find it hard even to know whether a master password is used. As for the argument that ftp passwords can be stolen anyway, just by intercepting the connections, not necessarily will all passwords be stolen. And even if malware developers manage to replicate the functionality that decrypts those files, they will most probably have hard time bruteforcing a master password (high memory/cpu usage attracts too much attention). Only way to open the encrypted files would be logging the password or stealing data directly from memory. But those methods are easier to notice for an antivirus and, in the end of the day, a malware developer has to write code for other functions and other ftp clients, so he might deem it not worth his time.

Being a developer myself I have to say that adding those features should not be too hard. I cannot understand why you give such little importance to security, which is one of the most vital factors nowadays.

  Changed 14 months ago by derfder

  • os_version changed from Win2k and up to Windows 7
  • type changed from Feature request to Bug report

I was using FileZilla for several years, but 1 month ago my passwords were stolen. There is no way to encrypt the passwords, so I need to use WinSCP that has a master password. Bye FileZilla ;( !

  Changed 14 months ago by ci-dev

  • priority changed from critical to high
  • os Windows deleted
  • type changed from Bug report to Feature request
  • os_version Windows 7 deleted

  Changed 13 months ago by webdev

My machine was compromised and all my FTP passwords stolen from Filezilla. No one should use Filezilla until this has been addressed. It's just not worth the risk.

  Changed 13 months ago by hobobobo

I can not believe that 3 years have passed, and this simple feature not been implemented. It`s not funy. In demand list of my odesk clients (They are managers - not administrators) has item: do not use FileZilla because it is not safe. Time to time I check FileZilla on this feature but nothing.

FileZilla now like a loaded gun that can fire at any moment. This shotgun spread charged. We say - it's dangerous. Developers say - your problems.

  Changed 12 months ago by Schweb Design

  • os set to Windows

Adding our voice here as well.

Per similar bug request here:  http://trac.filezilla-project.org/ticket/3176
the response was actually:
"This is by design. It's task of the operating system to protect your data.
...

Passwords will stay plaintext. There's no point in obfuscation. As soon as you got access to sitemanager.xml, it doesn't matter if it's plaintext or obfuscated."

WOW!! Isn't that flat out wrong? I would rephrase that to: "as soon as you get access to sitemanager.xml, if the passwords were encrypted there they would either be inaccessible or require the malware to do a lot more work in order to gain access to decrypt, thus protecting your passwords."

Never do i mean to sound ungrateful for great free software like Filezilla, but we also think this is ridiculous and if you think about it could be cascading into more and more harm across the landscape of FTP connected computers and at-risk servers since Filezilla is so popular, widely used, widely trusted.

We have also dropped Filezilla and moved to another FTP program.

  Changed 12 months ago by Schweb Design

  • os Windows deleted

didn't mean to change OS for entire ticket.

  Changed 12 months ago by IJustDownloadedWinSCP

Yet Another Register... just for that ticket.

Honestly... I don't care much about security : I use the same passwords on most of the websites I use, I don't have any anti-virus or other paranoïd software installed on my machines, I disable UAC on recent windows since it cripples user experience...

But storing password in PLAIN TEXT ?

No... thats just too much...

I probably wouldn't mind if it was only for my personnal FTP, but such a vulnerability just completely discredits this software for any serious use.

I hope you'll realize how important this is some day...
For the time being, I'll just spread the word.

  Changed 11 months ago by angaran

Please fix this or at least give us an option to securely crypt passwords.

  Changed 11 months ago by pkcinna

It does seem very strange that this serious security bug has not been addressed for so many years on an otherwise great tool. I'm embarrassed for recommending it to my coworkers over the years now that I know the passwords are in plain text. There are so many scenarios where the over simplified argument about "the operating system should handle security" doesn't hold up. Now I understand why no place I have ever worked used FileZilla as the standard. They all use WinSCP.

  Changed 10 months ago by geofflaw

  • cc geoff.j.lawrence@… added

  Changed 8 months ago by klam0

This bug was is a reason for not using FileZilla any more!

But there is one workaround, to make it (more or less) secure again:
 http://www.trailheadinteractive.com/making_filezilla_ftp_client039s_passwords_more_secure

Note: See TracTickets for help on using tickets.