Recently someone reported an alleged security vulnerabilty in FileZilla. But very quickly it became visible that the problem is not a vulnerability at all, but infact a fundamental issue of every single program that can store passwords transparently.
Despite my reply the vulnerabilty got releases to several security sites. Someone even posted some sort of exploit: Sourcecode that decrypts the stored passwords of FileZilla. But how could this be an exploit? In order to connect to a server with the encrypted passwords, FileZilla itself has to decrypt it. And since FileZilla is open source (basically every single program is, just look at the machine code), everyone can decrypt the passwords with little effort.
The used encryption method to store the passwords is a very simple algorithm. It hasn't been designed to be cryptographically strong, it shouls just obscure passwords.
In fact it is impossible to transparently store passwords securly, see below for reasons.
So since the vulnerabilty report got released despite my explanations, I can only assume that the author has either very little experience or, what I don't hope, this is an attempt to discredit FileZilla.
The original message:
And my reply:Hello Tim,
I believe we have discovered a weakly-encrypted password
vulnerability in Filezilla. At the time of writing, we are
also contacting some security web sites to report this
vulnerability, albeit with less details but sufficient to
identify the vulnerability. We also have the PoC written up
should you require that.
Title: FileZilla weakly-encrypted password vulnerability
- 2.2.14b and possibly previous ones (previous versions were
-FileZilla client stores password using weak XOR "encryption"
-The value of the cipher key never changes and is hard-coded
Description of vulnerability
FileZilla saves configuration settings in two different ways:
- in an XML file
- in the Windows registry
The method used to save configuration settings depends on
the preferences used by the user during the installation of
FileZilla. In both cases, all configuration settings are
stored in cleartext, EXCEPT for the password. However, the
password is stored using very weak XOR "encryption" which is
There exists a problem in the way the XOR encryption is
implemented because the same cipher key is always used. This
key is hard-coded, which means that anyone can analyze the
source code of the application and find it. Of course, this
wouldn't be so easy if FileZilla wasn't an open source
Once the key is known, an attacker can use it to decrypt the
password back to its cleartext form. Because the XOR
cryptographic algorithm used is symmetrical, the same key is
used for both encrypting and decrypting.
As mentioned before, the rest of the configuration settings
are all in cleartext. Some information which can be useful
to an attacker includes hostname of the server to connect
to, default port, and username. If successfully exploited,
this vulnerability will allow an attacker to access FTP (or
SFTP) servers with the privileges of the user whose
configuration settings were stolen from.
In practice, this vulnerability could be exploited after a
machine has been compromised, or by fooling the user into
executing malicious code which dumps the configuration
settings and sends it to the attacker.
It is common to see many popular Trojans out there that
exploit weak encryption vulnerabilities of this type. These
Trojans dump the credentials of popular applications such as
Internet Explorer, VNC and even dialup connections.
FileZilla could be the next on the list.
This vulnerability is somewhat similar to the one found by
Conde Vampiro in VNC 3 back in 1999. It's similar because
in both cases we find an open source application using a
fixed cipher key to decrypt passwords, making it trivial to
find the key.
For more information on Conde Vampiro's findings visit
The XML configuration file is found at:
Where %programfiles% is the "program files" directory. This
is usually "c:\program files" by default.
The configuration settings are saved in the registry in:
Key: Software\FileZilla\Site Manager\[site_name]
Where [site_name] is the name given to the connection by the
The password is saved in the previous key as a value with
the following properties:
Type: REG_SZ (string terminated in NULL)
The cipher key can be found in Crypt.cpp and its value is:
I would like to discuss how and when to release this, and
the possibility of a joint release. Could you please drop
me an email so that we can set up some tentative timescale?
thanks for your concern about FileZilla. I would like to clarify that
this is not a security vulnerabilty. The password encryption has never
been designed to be secure, it's just meant to obfuscate the password.
In order to use the stored passwords, FileZilla itself has to be able to
decrypt the passwords, for this it needs the encryption key to be stored
along with the encrypted passwords. In this case the key is stored
inside the executable.
This is no different than with any other program that can store
passwords transparently: It's never secure and can always be cracked
with very little effort. This is especially true for open source
software where everyone can inspect the encryption code.
But there are a few ways to store passwords in a secure. I'll add a few
comments on all of them
1. Don't save passwords at all. Implemented in FileZilla, chose "Secure
mode" during setup.
2. Don't store the password itself, store hashes. This won't work for
FTP as FTP needs to send original passwords and hashes aren't reversible.
3. Encrypt settings using a master password, don't save the master
password at all, request it from the user on startup. Not implemented in
FileZilla, partially because of
4. Use the tools the operating system provides to protect data, that is
access rights and file encryption. Though obviously the user has to
setup this for himself.
Thus said, for FileZilla 3 I even plan to omit password obfuscation by
default. Transparent password storage is equally secure when passwords
are stored in plaintext.